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

181–190 of 301 posts

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

#181

Post by jacksmith21006 »

In some cases because not necessary. Take the Gen 1 Google TPUs. They use a 700 mhz clock rate but are processing 65535 things at the same time. Very simple instructions.

Here is a great paper on comparing to silicon using far higher clock rates.

https://arxiv.org/ftp/arxiv/papers/1704/1704.04760.pdf

Now what will be interesting is this new architecture can be used for more traditional CS functions.

I love this paper from Jeff Dean on using the TPUs instead of a CPU to replace a b-tree for example.

https://research.google.com/pubs/pub46518.html

This also solves our multi-thread issue. Basically it done in a multi-thread manner from the ground up.

We get a round peg for a round hole.

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

#182

Post by nullbyte »

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…

How do you know all this stuff?

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

#183

Post by pault »

chillee wrote: post #174
arbie wrote: post #167

Earlier quoted context omitted.

It does seem a little odd that every comment about Rust gushes about its progress and stability without discussing any downsides. One would be similarly suspicious if, e.g., Perl6 were discussed this way.

That's what happens when you have a new hip language/framework that has a lot of hype. You see the same with Rust, Elixir, VSCode, Elm, Purescript, ReasonML, etc. It's not astroturfing, it's just a lot of beginners that are overly excited to proselytize their new discovery.

I don't think it's fair to claim these people are all beginners. More likely it's a phenomenon where mature languages have been around long enough that you already know their strong and weak points, but when you look at a language in development you only see its potential.

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

#184

Post by Retric »

jedbrown wrote: post #177

Notably, single-thread performance of code that is not friendly to vectorization has not stagnated despite stagnant clock frequency. Indeed, SPECint performance continues to grow exponentially, albeit more slowly since ~2004. https://www.karlrupp.net/2018/02/42-years-of-microprocessor-...

Depends on the code, you can write ASM that's as fast on an old P4 as a modern i7. Just access random RAM locations and modern CPU's suck.

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

#185

Post by Symmetry »

nullbyte wrote: post #182
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…

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

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

#186

Post by Thaxll »

gameswithgo wrote: post #143
ilogik wrote: post #84

Earlier quoted context omitted.

Doesn't go also make it relatively easy to write parallel code?

Not especially. It has goroutines, C# has Tasks, C++ has green thread libraries. Added onto this are channels which are basically thread safe queues, other languages have those too. (I am aware that there are differences between what features goroutines and Tasks provides) Go's implementation of these things is nice, neat, and all included out of the box though which is nice. In general you can make parallelism easy,…

Except in other languages it's not part of the core, it's an external library. So on the end it's easy to write "parallel" code.

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

#187

Post by adwn »

boomlinde wrote: post #135
adwn wrote: post #109

Earlier quoted context omitted.

And yet you only have a single train of thought [1] – or multiple interleaved trains, but that's concurrency, not parallelism. [1] Plus a couple of background processes, like breathing, that execute in parallel.

That's a huge simplification not pertaining to the fundamental nature of the brain. Maybe it is in the nature of our consciousness (which in itself is probably only an abstract concept) to perceive the processes it emerges from as a sequence of single trains of thought rather than a chaotic, continuous consolidation of processes both internal to the brain/body and outside of it. You could look at society as a whole a…

> That's a huge simplification not pertaining to the fundamental nature of the brain.

I disagree. Conscious thinking is a crucial process that's inherently single-threaded, even though it runs on highly parallel hardware (the billions of neurons).

However, I must admit that my point doesn't necessarily contradict pjc's point, and I don't really agree with digi_owl's claim that parallelism is a "wild goose chase".

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

#188

Post by Thaxll »

gilrain wrote: post #175
arbie wrote: post #167

Earlier quoted context omitted.

It does seem a little odd that every comment about Rust gushes about its progress and stability without discussing any downsides. One would be similarly suspicious if, e.g., Perl6 were discussed this way.

Try it out and write the critique, then. The posts are positive because Rust is genuinely achieving rapid progress and stability... but certainly not without flaws. I've experienced plenty of frustration, albeit outweighed by the massive benefits for my use case. And there are whole problem domains to which it's just not suited. I see these mentioned pretty frequently.

For once there is no consensus how to do parallelism an concurrency in Rust since none of the library are matures.

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

#189

Post by losteric »

djsumdog wrote: post #138
Bitcoin_McPonzi wrote: post #136

Earlier quoted context omitted.

In fact, there is! Erlang is extremely parallel. Processes are lightweight, share nothing, and run on as many CPUs you have.

And also its derivatives, like Elixir.

Elixir is amazing! The original author, José Valim, took a brilliant approach: Take a 30 year-old battle-tested highly-parallel VM, and build a modern language on top of it. Syntax is inspired by the good parts of Ruby (very clean), but nothing comes close in terms of the ease of parallelism... it's so natural, and insanely fast.

The unit tests are what convinced me this will be the next big thing. Beautifully clear syntax, succinct tests, and most importantly: Parallel out of the box. Hundreds of unit tests run instantaneously. Ruby TDD setups run tests that changed with maybe 1-2s lag... Elixir runs all the tests so fast that, at the beginning, I wasn't sure the tests were running.

Post reply on HN