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

281–290 of 301 posts

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

#281

Post by jbergens »

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 guess it's not going to help a lot except in special cases. See for example what Linus had to say about many cores and the long discussion after.

https://www.realworldtech.com/forum/?threadid=146066&curpost...

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

#282

Post by beojan »

smitherfield wrote: post #223
beojan wrote: post #44

Earlier quoted context omitted.

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

If you're including third-party libraries, you have things like ArrayFire and Intel TBB.

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

#283

Post by BenoitP »

microcolonel wrote: post #118
BenoitP wrote: post #111

Earlier quoted context omitted.

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

> I'm excited to see what goes on in that committee.

I am too. So far, this post on the general RISC-V mailing list and a few videos online talk about it. I'd love to have some other sources of information on their progress.

Also, I've heard that the RISC-V foundation is actively seeking collaboration for Java. There is some work on having RISC-V backends in HotSpot and JikesRVM, but so far it is limited to interpretation IIRC. The fact that Oracle is not jumping at it and pouring hundred of millions into it is beyond me.

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

#284

Post by whoisthemachine »

deepnotderp wrote: post #258
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…

Shameless plug, we at Vathys run asynchronous: https://youtu.be/4nSn0JhZX18

Very cool :)

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

#285

Post by ta2384428 »

pjmlp wrote: post #278
quadcore wrote: post #277

Earlier quoted context omitted.

Are those Tasks coroutines? If yes, do they yield on any sleeps ? These aspects are key to goroutines.

Yes they do, they are the building blocks for async/await, get a thread allocated from a thread pool when running, and you can control how the scheduling takes place, by providing your own scheduler implementation.

That is pretty cool, C++ has come a long way since I used it last about 15 years ago.

It seems like both languages are equally capable here, with C++ having more power and foot guns when required as usual.

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

#286

Post by microcolonel »

BenoitP wrote: post #283
microcolonel wrote: post #118

Earlier quoted context omitted.

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

> I'm excited to see what goes on in that committee. I am too. So far, this post on the general RISC-V mailing list and a few videos online talk about it. I'd love to have some other sources of information on their progress. Also, I've heard that the RISC-V foundation is actively seeking collaboration for Java. There is some work on having RISC-V backends in HotSpot and JikesRVM, but so far it is limited to interpret…

> There is some work on having RISC-V backends in HotSpot and JikesRVM, but so far it is limited to interpretation IIRC.

Well, JikesRVM is a proper JIT. Palmer Dabbelt from SiFive has worked on a HotSpot port before (for a different platform). I'm currently working on a V8 port. The availability of platform software and language environments is obviously of paramount importance, since it'll shape the remaining first impressions of the architecture.

> The fact that Oracle is not jumping at it and pouring hundred of millions into it is beyond me.

Well, it's a lot of work, and they have their SPARC investment to continue.

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

#289

Post by hinkley »

Sammi wrote: post #106
mysterypie wrote: post #80

The article doesn't answer the question at the fundamental level. The closest it gets is this: "Increased frequency depends heavily on the current level of technology and advances cannot move beyond these physical limitations." Certainly, Moore's law is just an observation and cannot go on forever. Would it fair to say that we've simply reached the point where we can no longer "keep up" with Moore's observation becau…

You're skipping over the main point of the article, which is that the reason it's hard to increase the clockrate is because it is dependent on the slowest instruction that can be done in one tick. And the main method of making an instruction faster is by splitting it, but all instructions have now already been split as much as is possible, while still having them operate correctly.

But this shouldn’t be true for a superpipelined processor, right?

Or put it another way, let’s say phase 3 contains several important instructions that cannot be reduced to a length of less than 1.7 clock ticks. If the pipeline stalls you have other pipelines that won’t.

Or you get crazy and put in 2 copies of the slow paths of phase 3 and one takes the even ticks and the other the odd ones.

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

#290

Post by kec »

pjc50 wrote: post #73
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…

The RISC/CISC "tradeoff" is mostly a non-issue at the higher end of processor design: everything is now a hybrid. You have ARM64 with its SIMD and floating point extensions that hardly qualifies as "reduced" on one side, and Intel systems that have a suspiciously RISC-like internal architecture fed by decoder of the "legacy" CISC instruction set. It still matters at the small end, which is why Cortex-M exists. > Or d…

It worked for P.A. Semi (eventually).
Post reply on HN