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

81–90 of 301 posts

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

#81

Post by pjmlp »

kbart wrote: post #63
pjmlp wrote: post #45

Earlier quoted context omitted.

That is mostly an issue with the "avoid IDE" crowd. While IDE tooling can still be improved, the parallel debugging tools in .NET and Java eco-systems are already quite good. On VS, I can have at any given moment a graphical snapshot on how all threads and tasks are interacting with each other, or just execute some of the threads. It doesn't solve everything, but it makes it easier than a typical gdb session.

.NET has one of the best ecosystem overall, so it's more an exception than a rule (can't comment on Java as I don't work with it). As I'm mostly in low level, embedded system programming, you are still stuck with gdb, Valgrind and other primitive tools there, because if there's some legacy "IDE" at all, it's most often just some half-assed Eclipse plugin.

At least looking to their product sites, Microchip and Green Hills seem to have quite good tooling, then again I don't have embedded experience on modern systems, beyond mobile devices.

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

#82

Post by skummetmaelk »

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…

They have been here for a while, just for a very specific market.

Threadripper and EPYC exist now though. With 32 and 64 logical cores respectively.

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

#83

Post by skrebbel »

skummetmaelk wrote: post #82
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…

They have been here for a while, just for a very specific market. Threadripper and EPYC exist now though. With 32 and 64 logical cores respectively.

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.

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

#84

Post by ilogik »

madez wrote: post #17
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…

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.

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

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

#85

Post by marcosdumay »

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…

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.

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

#86

Post by kowdermeister »

v_lisivka wrote: post #59
kowdermeister wrote: post #36

Earlier quoted context omitted.

Crank them up a little more and they will glow due to reaching visible light territory :)

Crank them up a little more and they will go into deep ultraviolet. Problem solved.

There is no problem here, marketing folks would love it :)

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

#88

Post by otabdeveloper1 »

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'm surprised that there hasn't emerged a "parallel-by-default C++" kind of language + hardware system to exploit it to keep things going forward.

There has. GPU programming is exactly that. CPU-heavy tasks (games, bitcoin mining, machine learning) have already migrated.

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

#89

Post by jonathanstrange »

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 agree, programming languages have not caught up yet.

The right kind of language looks at serial program formulations and based on flow-analysis automatically identifies parallelizable fragments that are large enough to benefit from multicore, then schedules these fragments e.g. by using work-stealing in a system of green threads, i.e., mapping green threads to OS cores as efficiently as possible. Something like that.

In a good parallel language there need to be many immutable constructs by default, exception handling is tricky, and ordinary flow control needs to be compatible by default with parallel evaluation. The languages I've seen such as Parasail are not yet production ready.

Making the programmer control parallelism can be okay, like in Go and Ada, but in the end it should be automatic.

Edit: The problem is also that finding a neat way of solving the problem academically does not readily translate into an efficient implementation, so much that I wonder whether green threads are actually worth it over OS threads. In most languages/VMs they aren't but Go seems to be an exception.

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

#90

Post by pjmlp »

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…

> Parallelism hasn’t seen a great deal of use until it’s urgently needed

This is the main reason why, initially, Windows Store APIs were all async.

Microsoft learned that when developers can choose between both models, by default most chose synch models.

Post reply on HN