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

111–120 of 301 posts

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

#111

Post by BenoitP »

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'd say exploiting parallelism is not the only way at all. Parallelism is only one way to compute differently. Specialization of hardware to specific workloads will explode in the next years as we can't rely anymore on Moore's law. This will happen on RISC-V, IMHO.

We already have these:

* Rendering, medium precision mathematics: GPU

* Low precision mathematics: TPU

* Software Defined Networking: Microsoft is deploying FPGAs, AWS has its own hardware

We could have:

* Databases: Projections, hashing, sorting in hardware.

* Dynamic runtimes: Hardware implemented memory models, HW assisted GC, code caches and user-level interrupts for the JITs. Here is the J extension RISC-V working group: [1]

etc.

Also, why not have the usual hot paths in Node.js|Spring Framework|Django directly etched into hardware? HW http header parsing surely could bring benefit to them all.

----

Of course language and programmers will have to adapt, but in a lot of cases the runtimes will take care of it automatically.

[1] https://groups.google.com/a/groups.riscv.org/forum/#!msg/hw-...

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

#112

Post by monocasa »

marcosdumay wrote: post #85
skrebbel wrote: post #79

Earlier quoted context omitted.

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

There are plenty of 64 cores servers. Yet, multi-core architectures seem to have hit a wall caused by slow memory access. I'm still waiting for the massively parallel NUMA machine in a chip, but there are many manufacturing problems keeping those away.

And hit a wall for power/density.

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

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

#113

Post by dx034 »

quadcore wrote: post #10
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…

https://golang.org/ In case you dont know, Golang goroutines are a marvel of parallelism. They are coroutines which are dispatched on a few OS threads. So you can use 100% of a multi-cores CPU and yet, spawn, say, 10K of those light threads without worrying about context switches PLUS have them all run concurrently. I've found that golang is one of those rare language, like Lisp, that actually change the way you thin…

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 still cause headaches and is something that could be improved.

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

#114

Post by Androider »

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…

With just Chrome and IntelliJ running on Ubuntu, I have 281 processes and kernel workers running (as reported by ps). Just stitching the apps together for display on your screen requires 3-4 different processes (and a GPU). That's why 4 logical cores is a bare minimum these days for a desktop, even if no individual application takes advantage of more than a single core.

On the server side, when we deploy a Node.js web service on AWS we start one instance per logical core, for 4-64 processes all independently serving connections.

It seems the process has become the new thread, the smallest unit you should design for. So today's workloads actually make pretty good use of all those cores. Unless you're doing high performance computing and need to squeeze every last drop of performance, processes are a straightforward way to parallelize.

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

#115

Post by dx034 »

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.

> but CPU cores are relatively cheap compared to engineer salaries

I often experienced that this backfired. Single machines are still constrained in their power and while it's easy to spin up additional VMs in the cloud, scaling a program properly to run on dozens of machines takes a lot of work. It can be faster to develop a program that is really efficient and can solve the problem on one machine than to develop faster only to then spend the time scaling it to a large fleet of servers.

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

#116

Post by makomk »

pdpi wrote: post #96
skrebbel wrote: post #83

Earlier quoted context omitted.

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.

Even in single-socket configurations, Threadripper and EPYC are still both NUMA architectures - the cores are split across two or four dies, each of which has its own memory controller and memory attached to it, with requests from a core to memory on another die going via an interconnect.

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

#117

Post by quietbritishjim »

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 option is that you write in a high-level language where the top-level control code is single threaded, but you call APIs that perform multi-threaded operations seamlessly. The prototypical example of this is Python with numpy/blas (or with deep learning libraries like TensorFlow).

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

#118

Post by microcolonel »

BenoitP wrote: post #111
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'd say exploiting parallelism is not the only way at all. Parallelism is only one way to compute differently. Specialization of hardware to specific workloads will explode in the next years as we can't rely anymore on Moore's law. This will happen on RISC-V, IMHO. We already have these: * Rendering, medium precision mathematics: GPU * Low precision mathematics: TPU * Software Defined Networking: Microsoft is deployi…

Currently working on software for RISC-V and I can definitely see some opportunities here. One thing that's becoming apparent though, is that some level of abstraction needs to be available in order for many of these things to become useful. RISC-V has a very exciting Vector processing extension, which is intended to replace packed SIMD in most cases, but some software systems assume packed SIMD is the only way to get more FP performance.

For example, WebAssembly specifically exposes SIMD primitives, which means that it may be necessary to work backwards from those SIMD primitives to make use of a true vector machine.

I think many people simply underestimate the cost of adopting a new programming model.

> Also, why not have the usual hot paths in Node.js|Spring Framework|Django directly etched into hardware? HW http header parsing surely could bring benefit to them all.

Well, in all the listed cases here, the CPU is not the bottleneck on throughput. As far as I can tell problem with HTTP is not that headers take too long to parse, it's that memory is still too slow, and context switches cost us precious time. The problem with Node is not that the hardware doesn't adequately model the semantics, it's that dynamic, weak typing makes it hard for any system (software or hardware) to understand what type things are.

Update: The J extension seems interesting, and I've read some research (not thoroughly) recently showing considerable power and time savings from hardware GC primitives. I'm excited to see what goes on in that committee.

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

#119

Post by PaulHoule »

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…

Materials other than silicon can support higher clock rates.

From reading the open literature and advertisements by foundry companies, I think you could make a 6502 equivalent processor with Indium Phosphide with 64kb of static RAM that clocks at 30 GHz. With a more refined process you might push 90 GHz and a much more complex processor.

Yes, InP is more expensive than Silicon but part of that is the low volume that InP parts are made in. Advances in Silicon are getting much more expensive, and one InP microprocessor could do the work of ten Silicon-based cores so you can save on die area without the "race to the bottom" in size.

The main issue with high clocks is fast access to memory, probably you would need an optical interface to off-chip RAM, also I don't know what the InP equivalent of DRAM is. (Something like Optane?)

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

#120

Post by whoisthemachine »

rcxdude wrote: post #72
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…

Wouldn't asynchronous CPUs increase the amount of side-channels? AFAIK in an asynchronous circuit every aspect of the calculation may affect the time it takes to complete.

The attacks I'm aware of use processor timings to measure the effects their programs are having. However, because an asynchronous circuit doesn't complete tasks in a reliable cycle, you can't measure how the pipeline is being effected by your program in the same way. You could find new ways to force the processor to act in a reliable manner that you could measure, but that may change quite randomly from processor to processor, or even from moment to moment, depending on external environmental factors.
Post reply on HN