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

221–230 of 301 posts

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

#221

Post by tomc1985 »

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 argument made sense 10 years ago. We've had dual cores for more than a decade, and CPU speeds stopped growing years ago. If you still can't think in threads and their primitives, or require crutches to handle multithreaded situations, then the problem is with you.

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

#222

Post by TickleSteve »

vondur wrote: post #158
navjack27 wrote: post #152

Re: all the programming replies. Preface, I'm not a programmer, I'm a hardware guy. It's all well and good to make sure your programs and future programs are able to be run in a parallel fashion but there is a big hole to that and it's the operating systems methods of handling cores and threads. Let's use folding@home as an example. Very multithreaded. Now let's use, at first, Ryzen 1800x as the hardware we'll run it…

How did the BeOS designers make the BeOS so good at multiprocessing? I remember how well the operating system scaled with more than one CPU.

Applications scale, not operating systems.

There was nothing magic in BeOS, simply multithreading that seemed novel at the time in consumer-level hardware.

Hate to say it, but there was no magic, just engineering that everyone now has.

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

#223

Post by smitherfield »

beojan wrote: post #44
madez wrote: post #17

Earlier quoted context omitted.

While Rust doesn't promote a specific model for parallelism, it's stronger compiler helps a lot with that. https://doc.rust-lang.org/beta/nomicon/concurrency.html https://doc.rust-lang.org/book/second-edition/ch16-01-thread... I don't think fixing C(++) can give what Rust can give, because Rust has a clean start with these strong guarantees built-in while for C(++) it would always be an addon. Defaults are powerful.

C++ has parallel algorithms built in ( http://en.cppreference.com/w/cpp/algorithm ). Parallelism is complicated though, and easy parallelism pretty much requires a functional style. Things like Haskell's Accelerate library ( https://www.stackage.org/package/accelerate ) seem the ideal way forward to me.

Should be noted that so far only Visual Studio (partially) implements C++17 parallel algorithms, although there are several third-party implementations.[1]

Apples to oranges comparison of course, since Rayon isn't [planned to become?] part of the Rust standard library.

[1] http://www.bfilipek.com/2017/08/cpp17-details-parallel.html#...

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

#224

Post by wmf »

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…

those 64-core CPUs I was promised

The people promising that were crackpots and no one really called them out on it, so that meme got repeated everywhere despite being wrong. Processor vendors can't release a new processor that runs existing apps slower because no one would buy it (not counting monopolistic tactics). And since many existing apps are single-threaded, that means new processors have to at least maintain the same single-threaded performance which means keeping brainiac cores which means you can only afford 6-8 of them. (And arguably there are 64 weak cores in your CPU; they're just in the IGP and you have to program them with OpenCL.)

Go/Rust/Elixir are not so much progress IMO as undoing the negative progress of writing large-scale software in scripting languages.

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

#225

Post by TickleSteve »

gone35 wrote: post #166
navjack27 wrote: post #152

Re: all the programming replies. Preface, I'm not a programmer, I'm a hardware guy. It's all well and good to make sure your programs and future programs are able to be run in a parallel fashion but there is a big hole to that and it's the operating systems methods of handling cores and threads. Let's use folding@home as an example. Very multithreaded. Now let's use, at first, Ryzen 1800x as the hardware we'll run it…

Very well put! Not an expert but, as far as I know, parallel OS development definitely seems to be a frequent blind spot in the systems literature...

It's not a blind-spot, concurrency and parallelism are the core of every CS level operating system course at uni-level. There are mountains of white-papers discussing every aspect you can imagine. It's simply that all existing OS's are simply good enough.

Applications scale, not operating systems.

The problem is now in the application/algorithm level, not the OS level.

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

#226

Post by TickleSteve »

whoisthemachine wrote: post #71

My senior design course focused on asynchronous (clock-less) cryptography circuits; after learning of these, I looked into asynchronous general purpose processors, and learned that ARM actually designed an asynchronous processor back in the 2000's [0]. While they've never quite taken off (the extra gates decrease speed and our harder to manufacture), with the recent side-channel attacks on processor pipelines, I've b…

That was Steve Furbers Amulet (https://en.wikipedia.org/wiki/AMULET_microprocessor)

He was one of my lecturers at uni, shame not much became of Armulet tho.

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

#227

Post by TickleSteve »

drudru11 wrote: post #218

Are there any CPUs out there with FPGAs tacked on that are available to the hobbyists/gamer/build your own PC crowd?

Not really, the market for combined processor/FPGAs are basically the opposite, FPGAs running a soft-core processor. Same effect tho.

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

#228

Post by eropple »

quadcore wrote: post #161
dx034 wrote: post #113

Earlier quoted context omitted.

And yet, Go's standard map doesn't allow concurrent access. They recently added a concurrent map feature but it's probably easier to add a lock to your code than refactoring it with the new map type. I would've preferred if they had introduced a map type that can be used exactly as the standard one (i.e. without function calls). Calling functions via go func() is really easy but handling data between goroutines can s…

Well, go isn't really a high-level language which maps can be seen as a feature of. The idea behind go, I believe, is to focus and provide innovative system-level features.

Go is not a language for "system-level features" in the first place. Its garbage collector largely precludes it from that in any modern context.

That it can't do something effectively does not mean that it shouldn't or didn't mean to. (And users can't really fix it, because hey, no generics. Sigh.)

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

#229

Post by mbrumlow »

Symmetry wrote: post #185
nullbyte wrote: post #182

Earlier quoted context omitted.

How do you know all this stuff?

Got my master's in it, before ending up in sensors then robotics instead. And a continued interest, I guess. Here are some free relevant courses. You might have to go back and take the pre-reqs. https://ocw.mit.edu/courses/electrical-engineering-and-compu... https://ocw.mit.edu/courses/electrical-engineering-and-compu...

How does one get into robotics? I have not looked much but none of my local schools seem to have "robotics".

I tinker with electronics and make some remote controlled robots for fun (internet controlled, live video with multi user input, sort of crowd controlled). I am now trying to self teach myself about kalman filters and control theory and want to build more autonomous robots.

But any info on getting into robotics for a day job would be nice.

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

#230

Post by JoachimS »

Symmetry wrote: post #159

That was a bit misleading in some ways. First, in pipelining you'll typically measure how long a pipeline steps in FO4s, which is to say the delay required for one transistor to drive 4 other transistors of the same width. Intel will typically design its pipeline stages to have 16 FO4s of delay. IBM is more aggressive and will try to work it down to 10. But of those 10, 2 are there for the latches you added to create…

Good points. One thing I would like to emphasize is the issue with clocks not arriving everywhere at the same time. Balancing the clock tree over a chip gets harder and harder.

But the clock setup, hold times also gets shorter and shorter when the clock frequency goes up. The clock signal will have jitter. The end result is that less and less time of the clock edge is usable to sample the signal into the register.

And this in turn put a strain on how well balanced the logic between the registers are. To allow all signals traverse the logic paths through the gates and stabilize in time to be sampled.

To add to the complexity, as we move down the geometries, the difference in performance of different transistors becomes relatively larger. One rason for this is that oxide layers consist of (in average) fewer and fewer molecules. When the layer was made up of 100 molecules, 101 or 102 didn't really make much of a difference. But when the average is 4 molecule one more or less will have a huge impact on the performance.

So controlling variance (clock tree balance, jitter in clock generatiom, imbalances between paths and variance in chip production) becomes ever more problematic and important.

Post reply on HN