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

61–70 of 301 posts

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

#61

Post by Santosh83 »

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…

One reason is that our thinking process is inherently serial and we do really badly at multitasking naturally. At least those involving deliberate thought. And our programs are almost an extension of our way of thinking, so we will have to push the boundaries of how we think and model systems in our mind before we can build excellent parallel programming languages. Not that it isn't being done, but the weight of the "serial" legacy is long...

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

#62

Post by krylon »

MichaelMoser123 wrote: post #50
krylon wrote: post #22

Earlier quoted context omitted.

Great, now I have to clean all that tea off of my display. ;-P

and i thought that humor is verboten around here... Does HN have an exception in the book that applies to Intel ?

The guidelines do not mention humor as such. It is often frowned upon, but I think the delicious irony in this case warrants an exception. ;-)

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

#63

Post by kbart »

pjmlp wrote: post #45
kbart wrote: post #30

Earlier quoted context omitted.

While modern languages support for parallelism is adequate, tools are still lacking imho. I avoid parallelism when it's not necessarily, because debugging all these race conditions, deadlocks, synchronization etc. is a nightmare.

That is mostly an issue with the "avoid IDE" crowd. While IDE tooling can still be improved, the parallel debugging tools in .NET and Java eco-systems are already quite good. On VS, I can have at any given moment a graphical snapshot on how all threads and tasks are interacting with each other, or just execute some of the threads. It doesn't solve everything, but it makes it easier than a typical gdb session.

.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.

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

#64

Post by v_lisivka »

pjc50 wrote: post #58
logicallee wrote: post #51

guys, I'll be honest: I found it really odd that the article didn't talk about the speed of light, and die size constraints. (c / 4 ghz = 7.49 cm only, if you double that frequency you have half that size to put components it between any two clock ticks.) But there are limits to my hubris - this is on intel.com, so I'm going to go with "I'm the one missing something". Is the speed of light and number of transistors y…

The key factors in integrated circuit delay are more to do with capacitance; in order to change a gate's transistor from off to on, the driving gate has to charge the capacitance of the driving wire and the driven gate. Making features closer together increases their mutual capacitance. (source: worked on this for a chip design software company. The delay approximation was based entirely around R/L/C modelling and ha…

I.e. the problem is the state of processor, which need to be erased. So we can make stack of stateless processors, which will readily accept fresh data, because they will need to fill capacitors only, not discharge, and then discharged after use. Kind of multicore design, but with each core used for only 1/n of time at e.g. 1Thz frequency. Unlike parallel system, sequential calculation will work faster in such setup.

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

#65

Post by monocasa »

Santosh83 wrote: post #61
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…

One reason is that our thinking process is inherently serial and we do really badly at multitasking naturally. At least those involving deliberate thought. And our programs are almost an extension of our way of thinking, so we will have to push the boundaries of how we think and model systems in our mind before we can build excellent parallel programming languages. Not that it isn't being done, but the weight of the…

It's not just our thought process; there are upper limits to the gains from increased parallelism.

https://en.wikipedia.org/wiki/Amdahl%27s_law

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

#66

Post by dschuetz »

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 complex. In case of the CISC arch Intel established it's a huge trade-off, since CISC is supposed to make its processors easier to program, as opposed to RISC. I don't think that CISC is a good choice when it comes to massive parallelism.

But, since chip design is so expensive and is considered state of the art high-tech, we'll need to deal with everything that chip makers throw at us. Or do we?

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

#67

Post by UncleSlacky »

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…

This issue was discussed in my Occam class ~28 years ago. Occam itself is an example of a concurrent/"parallel-by-default" programming language intended for a Transputer hardware environment (now retargetable to x86 etc.), but it's not the easiest of languages to learn:

https://en.wikipedia.org/wiki/Occam_(programming_language)

https://en.wikipedia.org/wiki/Transputer

https://en.wikipedia.org/wiki/KRoC

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

#68

Post by pjc50 »

tyingq wrote: post #42
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…

"there hasn't emerged a "parallel-by-default C++" kind of language + hardware system to exploit it" That's roughly what Intel tried with Itanium. I don't know if whatever barriers they hit are still barriers today.

Not really - Itanium tried to move the instruction-level parallelism and the burden of re-ordering execution to the compiler. You could only execute the maximum six instructions per cycle if there were no data dependencies. So it only really works for certain kinds of algorithmic data-heavy execution; that's why VLIW is only found in DSP architectures today.

Good SE answer here: https://softwareengineering.stackexchange.com/questions/2793... especially the ones focusing on cache misses.

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

#69

Post by digi_owl »

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.
Post reply on HN