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

41–50 of 301 posts

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

#41

Post by tzahola »

quadcore wrote: post #40
tzahola wrote: post #37

Earlier quoted context omitted.

Your example will not run in parallel. The go runtime will schedule your goroutines concurrently , but they will be run by a single OS thread, and consequently on a single CPU core. Once you execute truly on multiple CPU cores (by increasing GOMAXPROCS), you'll be having the same kind of race conditions in Go as in any other imperative language (inb4 Rust Evangelism Strike Force saying "except Rust").

Wrong. Goroutines are not simply coroutines. GOMAXPROCS defaults to number of cores.

Prove it.

Prove it by replacing Sleep in your example with some number crunching, and show how it scales with the number of cores in your CPU.

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

#42

Post by tyingq »

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…

"there hasn't emerged a "parallel-by-default C++" kind of language + hardware system to exploit it"

That's roughly what Intel tried with Itanium. I don't know if whatever barriers they hit are still barriers today.

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

#43

Post by zxcmx »

tzahola wrote: post #37
quadcore wrote: post #10

Earlier quoted context omitted.

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…

Your example will not run in parallel. The go runtime will schedule your goroutines concurrently , but they will be run by a single OS thread, and consequently on a single CPU core. Once you execute truly on multiple CPU cores (by increasing GOMAXPROCS), you'll be having the same kind of race conditions in Go as in any other imperative language (inb4 Rust Evangelism Strike Force saying "except Rust").

GOMAXPROCS has defaulted to # of cores since 1.5.

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

#44

Post by beojan »

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.

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.

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

#45

Post by pjmlp »

kbart wrote: post #30
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 modern languages support for parallelism is adequate, tools are still lacking imho. I avoid parallelism when it's not necessarily, because debugging all these race conditions, deadlocks, synchronization etc. is a nightmare.

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.

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

#47

Post by Pica_soO »

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…

The sequential programming by default is because most people think sequential by default.

Even though claims of multi-tasking etc persist, the truth is good parallel programmers are a rare thing.

Many ordinary programmers already get into Hot-Water when they use two threads and access data where a Semaphore might be needed.

In addition many algorithms are sequential, so parallelizing them is tricky or gives you no true reward due to cross-thread communication. Add to that the OO-Software Structures that subtle encourage using sequential programming.

I think the future in parallel-programming is actually hiding the parallel programming completely - accept the fact that most humans are not made for it, allow for experts to unlock the ability to override that behavior- let compilers go as far as they can and live with the results.

It will suffer the same fate as functional programming. Really useful, but never dominant, due to limitations in the applying humans.

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

#48

Post by tedsanders »

ksec wrote: post #14

Until we have another material that could replace silicon. Not sure if we will see this happen in the next ten to twenty years.

The 60 mV/dec limit applies to all materials, not just silicon. Beating it will require a fundamentally different type of operation. Agree that changes in materials will require massive investment and learning.

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

#49

Post by chrismorgan »

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.

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 optimally, or not bothering with multiple threads if it’s not going to be worth it (e.g. single-threaded, or only one item in the iterator). And all that with close enough to no overhead.

Basically, Rayon makes data parallelism really easy in a way that few if any other languages do. I’d love to have an equivalent in Python or Node, but it’s just not possible to achieve such a thing in most languages—even if you ignore the thread safety aspect.

Parallelism hasn’t seen a great deal of use until it’s urgently needed, because it’s hard to get right in most environments, and you normally need to substantially refactor code to make it happen. My hope is that with the likes of Rayon, parallelism can be a much more natural thing that people that care even a little about performance will just do, because it’s so easy to do.

https://crates.io/crates/rayon

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

#50

Post by MichaelMoser123 »

krylon wrote: post #22
hackme1234 wrote: post #16

Earlier quoted context omitted.

The spectre of meltdown is haunting CPU manufactures.

Great, now I have to clean all that tea off of my display. ;-P

and i thought that humor is verboten around here... Does HN have an exception in the book that applies to Intel ?
Post reply on HN