Why has CPU frequency ceased to grow? (2014) • Hacker News Board

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

#131

Post by kamaal » Wed, Feb 21, 2018, 2:14 PM UTC

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…

New languages are coming up, it will just take long adoption cycles, given the library and surrounding tooling ecosystem has to be mature enough to go with it.

Prominent examples being Go and Perl 6.

Perl 6 especially, given how audacious the project is. There are performance issues with it currently though, from what I hear they are working to fix it soon.

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

#132

Post by ta2384428 » Wed, Feb 21, 2018, 2:15 PM UTC

dx034 wrote: post #113

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…

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

If you squint a little, you'll notice that go is pretty big on not hiding complexity. There are obvious exceptions to this such as the garbage collector, and heap/stack control.

I'm unsure if the intent of not including a map function was due to this, however with a for loop such as

    for x := range ch {
       slice = append(slice, x)
    }

, it is immediately obvious there are allocations happening in the background.

The fact that map access, and slice access is not thread safe means there is no trickery going on in the background. The fact that it is not threadsafe means I don't need to worry about a lock if I only write to a map when it's created. Sure the compiler could take care of this - they have the race detector after all, but the compile speed is one of the design goals of go. I really like being able to compile in less than 1 second.

`sync.Map` however calls a function which implies there is more going on in the background.

If you follow the go mantra of share memory by communicate, don't communicate by sharing memory - handling data becomes a whole lot easier. It does allow you to share memory in case you do need the extra speed.

Like most things, all designs are a matter of trade offs. Sacrifice one thing for another. There are other languages that provide the functionality you desire - but I understand the frustration when one thing is 90% what you want.

Go obviously has room for improvement, and perhaps a native threadsafe map is one of those areas.

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

#133

Post by icedchai » Wed, Feb 21, 2018, 2:16 PM UTC

ztoben wrote: post #108

ilogik wrote: post #84

Earlier quoted context omitted.

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

I believe you're thinking of concurrency, which go handles pretty well with goroutines.

Go can use multiple cores. Goroutines will run in parallel (assuming GOMAXPROCS > 1.)

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

#134

Post by stringer » Wed, Feb 21, 2018, 2:16 PM UTC

I've been looking at Haskell, Rust and Go for helping with parallelism but decided to go with a less known language: Pony. Not used actors a lot right now but looks really promising.

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

#135

Post by boomlinde » Wed, Feb 21, 2018, 2:21 PM UTC

adwn wrote: post #109

pjc50 wrote: post #78

Earlier quoted context omitted.

All of your cells and neurons operate in parallel.

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 and see the zeitgeist as a singular "train of thought", but you'd probably still recognize humans as individual agents. I think we have a bias towards thinking of ourselves as the ultimate individuals, neither recognizing the processes within us (like those of our cells) or the processes beyond us (like those of a group of people, animals, plants etc.) as having a similar nature. This is probably a genetically advantageous trait.

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

#136

Post by Bitcoin_McPonzi » Wed, Feb 21, 2018, 2:22 PM UTC

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…

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

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

#137

Post by Bitcoin_McPonzi » Wed, Feb 21, 2018, 2:22 PM UTC

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.

It seems like every thread here, not matter what the topic, brings out the Rust astroturfers.

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

#138

Post by djsumdog » Wed, Feb 21, 2018, 2:25 PM UTC

Bitcoin_McPonzi wrote: post #136

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…

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.

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

#139

Post by gilrain » Wed, Feb 21, 2018, 2:27 PM UTC

Bitcoin_McPonzi wrote: post #137

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.

It seems like every thread here, not matter what the topic, brings out the Rust astroturfers.

As someone who frequently posts about my personally-excellent experiences with Rust, what makes you suspect it's astroturf rather than just turf? You think Mozilla is paying people to post about Rust using puppet accounts? C'mon.

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

#140

Post by IIAOPSW » Wed, Feb 21, 2018, 2:31 PM UTC

slivym wrote: post #7

Seems like an incredibly long winded way of saying 'To go faster you either need to split up each instruction into lots of parts or increase the voltage for the transisters. We've split the instructions as much as we can, and power consumption is proportional to Voltage cubed, so it's not a scalable plan.'

More importantly than mere power consumption, we don't have a way to remove the waste heat generated. Dennards law (like Moore's law but for power consumption per transistor) ended 10 years ago. Exactly the same time clock speeds stopped improving. There are actually a few computers out there that run around 10Ghz but they all have impractical cooling systems.

If there ever were a return to exponential scaling, we would very soon run into the Launder limit.