Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why has CPU frequency ceased to grow? (2014)

software.intel.com

Post reply on HN
Print view View original

91–100 of 301 posts

Re: Why has CPU frequency ceased to grow? (2014)

#91

Post by pjc50 »

skrebbel wrote: post #79
mjfl wrote: post #8

I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…

> Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. People have been warning us about this for about 10 years now, but I still don't see those 64-core CPUs I was promised anywhere. If we had the amount of parallelism we were told we were going to get, we could give every app its own core. OSes could even…

If you can find an Nvidia GTX 1080, that has 2560 cores.

Re: Why has CPU frequency ceased to grow? (2014)

#92

Post by pjmlp »

tzahola wrote: post #33
jokoon wrote: post #25

Earlier quoted context omitted.

I wonder if the future will be massively parallel, when CUDA and opencl came out I thought that future processors would have more and more core, so if you follow Moore's law, CPUs would see their core count double each 6 months. The problem is that GPU don't have error correcting codes, so you cannot really run application code on a GPU. The problem with parallelism is that C-like language don't fit well, only functi…

Intel Larrabee also got cancelled.

Kind of, it became Xeon Phi.

Re: Why has CPU frequency ceased to grow? (2014)

#93

Post by til »

simias wrote: post #23

I find their explanation of the pipelining issue slightly confusing, probably because they tried to simplify it to the extreme: >One could object to this and note that due to shorter clock ticks, the small steps will be executed faster, so the average speed will be greater. However, the following diagram shows that this is not the case. Said diagram shows that the two-clock-tick step locks the pipeline, that is you c…

> If you can split "step 3" across two clock cycles, couldn't you effectively subdivide it into two steps that could run in parallel?

There is a difference between splitting "step 3" across two clock cycles and splitting "step 3" into two separate steps. The underlying assumption here is that "step 3" is indivisible. E.g. say "step 3" was memory access and the latency for that is 500 picoseconds, it's not like you can just split it into two steps and make it load faster.

Re: Why has CPU frequency ceased to grow? (2014)

#94

Post by pjmlp »

jokoon wrote: post #25
mjfl wrote: post #8

I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…

I wonder if the future will be massively parallel, when CUDA and opencl came out I thought that future processors would have more and more core, so if you follow Moore's law, CPUs would see their core count double each 6 months. The problem is that GPU don't have error correcting codes, so you cannot really run application code on a GPU. The problem with parallelism is that C-like language don't fit well, only functi…

I always like to think of FP dataflow pipelines as doing digital circuits modeling.

Re: Why has CPU frequency ceased to grow? (2014)

#95

Post by simonh »

digi_owl wrote: post #69
mjfl wrote: post #8

I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…

I can't shake the feel that this parallelism thing will be nothing but a wild goose chase, because nature seems to be highly serial in all but the most macroscopic of senses.

How can you say that? Almost every part of every organism functions simultaneously all the time. At the community scale, organisms cooperate and communicate continuously in real time. My eldest daughter is going through an ant obsession phase at the moment, their communities and how they coordinate hundreds of individuals simultaneously are amazing. Nature and natural selection are the ultimate optimizers - if there is any way for an organism or species to extract even the tiniest survival or reproductive advantage, nature ruthlessly optimises for it. Parallel function and behaviour is one of it's primary tools.

Re: Why has CPU frequency ceased to grow? (2014)

#96

Post by pdpi »

skrebbel wrote: post #83
skummetmaelk wrote: post #82

Earlier quoted context omitted.

They have been here for a while, just for a very specific market. Threadripper and EPYC exist now though. With 32 and 64 logical cores respectively.

Sure, there's been high end niche products for anything forever. You could buy a 64 core computer in 1990 (they'd call it a supercomputer, but same thing). The people telling us we had to go change our code to use parallel processing fast predicted a significantly faster increase in amount-of-cores on commodity hardware. Instead, CPUs stopped getting faster and hardly gained more parallellism.

You could buy a 64 processor machine in 1990, but it wouldn’t have been a 64 core machine in the sense we’re talking about — a single socket system. This isn’t some trivial distinction either, as the whole memory architecture is very different indeed for the two scenarios.

Re: Why has CPU frequency ceased to grow? (2014)

#97

Post by pjmlp »

pjc50 wrote: post #52
mjfl wrote: post #8

I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…

Unfortunately it requires more than just a change of language, it requires a change in mode of thinking by developers. People are very used to reasoning in terms of "do X, then Y, then Z" or "compute a value X then do A or B on the basis of that". In order to achieve automatic parallelism you need e.g. a type+proof system that can determine that X/Y/Z are independent, or a system that can partially execute both A and…

I think it is easier to understand by those of us that also had electronic design as part of the engineering degree.

Re: Why has CPU frequency ceased to grow? (2014)

#98

Post by userbinator »

dschuetz wrote: post #66

The rule of thumb in chip design: your chip clock is as slow as your slowest logic pipe. Complex logic circuitry slows down potential clock rates significantly. You can make your logic gates switch faster, thus allowing longer signal paths, but it has a huge energy trade-off, as the article states. Multi-core design seems now to compensate for slower clock rates, but it also has its trade-offs. It makes software more…

I don't think that CISC is a good choice when it comes to massive parallelism.

On the contrary, I think the increased code density (reduced fetch bandwidth --- very important for multiple cores) and greater semantic information of CISC instructions is crucial for parallelism. Large operations can be broken up into individually scheduled uops inside the core, and those uops can then be parallelised, without the equivalent of fetching all those uops from memory as might occur in a classic RISC.

In fact, even modern ARMs use this uop-based "instruction splitting" in their microarchitecture.

Re: Why has CPU frequency ceased to grow? (2014)

#99

Post by kbart »

pjmlp wrote: post #81
kbart wrote: post #63

Earlier quoted context omitted.

.NET has one of the best ecosystem overall, so it's more an exception than a rule (can't comment on Java as I don't work with it). As I'm mostly in low level, embedded system programming, you are still stuck with gdb, Valgrind and other primitive tools there, because if there's some legacy "IDE" at all, it's most often just some half-assed Eclipse plugin.

At least looking to their product sites, Microchip and Green Hills seem to have quite good tooling, then again I don't have embedded experience on modern systems, beyond mobile devices.

Do Microchip even produces multi-core MCU's? Haven't seen one, though I worked mostly with Cortex-A series so might miss something.

Re: Why has CPU frequency ceased to grow? (2014)

#100

Post by pdpi »

z3t4 wrote: post #56
mjfl wrote: post #8

I took a class that went over this in depth like 3-4 years ago. Basically the message was that serial performance is saturating, and the only way to get speed improvements in the future is going to be by exploiting parallelism. However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm. I'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardw…

I think JavaScript is nice because it's async in nature. Concurrency is hard so it's nice to deal with it using a simple language, so that everything besides the business logic is abstracted. Yes you do not get the same performance, but CPU cores are relatively cheap compared to engineer salaries.

The notion that cpu cores are cheap compared to engineer salaries only scales so far.

Scaling upwards, your opinion on that changes when a single engineer’s service is running on 10k machines.

At the other end of the spectrum, if you’re developing high-performance applications for small systems (desktop, laptops, mobile), Your workload isn’t going to look like tens of thousands of concurrent independent requests, So the approach of getting parallelism by deploying multiple copies of the application no longer works

Post reply on HN