Why has CPU frequency ceased to grow? (2014) • Hacker News Board

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

#151

Post by tbrock » Wed, Feb 21, 2018, 2:51 PM UTC

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…

Golangs’s web server, by default serves every request in a new goroutine (thread of execution) making it parallel by default with no effort on the user’s behalf.

Obviously this problem domain is easily parallelized but it’s nice to see parallelism be the refs to standard when possible and reasonable to do so.

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

#152

Post by navjack27 » Wed, Feb 21, 2018, 2:53 PM UTC

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 on. We have 8 physical cores. We also have two separate dies. Each die has four cores. Each die module has their own level 3 cache. As you use your system and you are also folding, even in the newest Linux kernel, data and instructions might get evicted and bounced around and take latency hits and thus performance hits. Nothing really locks the work to the cores or threads taking into account locality. You can adjust this with HTOP and set each thread of folding manually.

Beyond AMD, even Intel has similar issues still with the 8700k. Hell, in general just efficient multithreading seems like a tough compromise for OS development. "Users" want things to be smooth upon interaction, so you have preemption. Work wants to get done but it also wants to be a good citizen to the rest of the system.

Developers are going to have to learn about, and keep up to date with, much more then a fancy new language. You're going to have to learn each new CPU inside and out and how each OS treats it.

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

#153

Post by yaantc » Wed, Feb 21, 2018, 2:57 PM UTC

userbinator wrote: post #98

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 equiva…

If the performance gets significantly limited by instruction cache misses, then yes code density can become important as you point out. However, there are two things to keep in mind:

1) most actual RISC ISA have compact modes, typically using 16 bits instructions mixed with the regular 32 bits ones. That's Thumb2, Micro MIPS, RISC-V Compact mode, and others for embedded CPUs (ARC, Andes, ...). Their code density are competitive (and sometimes better) then x86. So with practical RISC implementation the code density is not a factor in RISC vs CISC;

2) there's a big outlier if I remember correctly: ARM in 64 bits mode dropped Thumb2 support. They certainly have to know how to keep a compact mode, and they decided not to bother. So I guess the I-cache limitation is maybe not a such a problem in real life? I don't have the data but I trust ARM to take benchmarking seriously, particularly for an ISA that also target server chips.

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

#154

Post by Maybestring » Wed, Feb 21, 2018, 2:58 PM UTC

monocasa wrote: post #110

pjc50 wrote: post #91

Earlier quoted context omitted.

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

They're playing games with the term 'core'. In CPU terms, a 1080 is 40 cores, each with a 64 way vector unit.

I'm surprised they don't sell it as a 40 core, 64-dimensional processor.

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

#155

Post by kbart » Wed, Feb 21, 2018, 3:00 PM UTC

pjmlp wrote: post #105

kbart wrote: post #99

Earlier quoted context omitted.

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

As I said, I don't have much experience in real embedded domain outside mobile devices (iOS, Android, UWP), but aren't Cortex-A5 supposed to handle up to 4 cores?

Yes, so it looks like Microchip produces multi-core MCUs after all, though as I've mentioned, I haven't encountered them and can't comment about quality of their tools.

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

#156

Post by ethagnawl » Wed, Feb 21, 2018, 3:02 PM UTC

chrismorgan wrote: post #49

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.

A really powerful outworking of it is seen in the Rayon crate, where you can change a sequential iterator into a parallel iterator just by adding the crate, importing the trait and changing `iter` to `par_iter`. If it’s not thread-safe to do, then it won’t compile. (That’s the big difference from C++.) If it is, it will, and it’ll be smart about how it runs, spreading the load across all available cores pretty much o…

FWIW, you can also achieve similar behavior in Clojure via pmap, Reducers, etc.

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

#157

Post by seanmcdirmid » Wed, Feb 21, 2018, 3:08 PM UTC

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…

The first GPU models were basically stateless (via pixel and vertex shaders with texture input and outputs), but this was incredibly inefficient for many GPGPU tasks, so compute shaders and CUDA have ways to load from and store to arrays. The memory model is a bit funky, but I’m not sure how going back to functional is viable for GPU programming.

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

#158

Post by vondur » Wed, Feb 21, 2018, 3:09 PM UTC

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.

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

#159

Post by Symmetry » Wed, Feb 21, 2018, 3:20 PM UTC

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 the stage and 2 are there to account for the fact that a clock edge doesn't arrive everywhere at exactly the same time. So if you take one of those 16 FO4 Intel stages and cut it in half you won't have a two 8 FO4 stages but two 10 FO4 stages. And since those latch transistors take up space and energy you're got some severe diminishing returns problems.

One thing that's changed as transistors have gotten smaller is that leakage has gotten to be more of a problem. You used to just worry about active switching power but now you have to balance using higher voltage and lower thresholds to switch your transistors quickly with the leakage power that that will generate.

And finally velocity saturation is more of a problem on shorter channels making current go up more linearly with the gate voltage than quadratically.

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

#160

Post by pjmlp » Wed, Feb 21, 2018, 3:21 PM UTC

ta2384428 wrote: post #122

VHRanger wrote: post #104

Earlier quoted context omitted.

How is that an example an improvement over c++? C++ has had pragmatic omp parallel for for two decades

I'm not familiar with OMP, so please forgive me if I'm incorrect - but OMP from my quick search appears to be thread based, while go routines are much lighter weight than threads. They have their own scheduler - which like most things is both good and bad depending on what you want them for. If you use them as intended, the internal scheduler is a great design decision. This means I can happily spawn 10,000 without c…

You can do the same in C++ on Windows with PPL, UNIX/Windows with Intel TBB, or any of the fiber/co-routine libraries.

Then there is the ongoing work to add async/await patterns into C++20.