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

161–170 of 301 posts

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

#161

Post by quadcore »

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…

Well, go isn't really a high-level language which maps can be seen as a feature of. The idea behind go, I believe, is to focus and provide innovative system-level features.

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

#162

Post by Symmetry »

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.

Carbon nanotube transistors would be great if we could get them to form reliably instead of having 10% of the transistors fail to form.

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

#163

Post by da_chicken »

vondur wrote: post #158
navjack27 wrote: post #152

Re: all the programming replies. Preface, I'm not a programmer, I'm a hardware guy. It's all well and good to make sure your programs and future programs are able to be run in a parallel fashion but there is a big hole to that and it's the operating systems methods of handling cores and threads. Let's use folding@home as an example. Very multithreaded. Now let's use, at first, Ryzen 1800x as the hardware we'll run it…

How did the BeOS designers make the BeOS so good at multiprocessing? I remember how well the operating system scaled with more than one CPU.

Probably because it ran on PowerPC. If I remember my systems design class from 20 years ago, RISC makes implementing or scaling multiprocessing easier.

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

#164

Post by Symmetry »

tedsanders wrote: post #48
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.

Sure, but many materials have much higher electron and hole mobility than silicon has.

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

#165

Post by z3t4 »

dx034 wrote: post #115
z3t4 wrote: post #56

Earlier quoted context omitted.

I think JavaScript is nice because it's async in nature. Concurrency is hard so it's nice to deal with it using a simple language, so that everything besides the business logic is abstracted. Yes you do not get the same performance, but CPU cores are relatively cheap compared to engineer salaries.

> but CPU cores are relatively cheap compared to engineer salaries I often experienced that this backfired. Single machines are still constrained in their power and while it's easy to spin up additional VMs in the cloud, scaling a program properly to run on dozens of machines takes a lot of work. It can be faster to develop a program that is really efficient and can solve the problem on one machine than to develop fa…

I kinda regret adding the note about performance, because switching to a lower level language used to yield orders of magnitude more performance, but optimizers have evolved and today there's not much difference. Sometimes the higher level language will be even faster because of optimizations. And bad performance is often not to blame on the language, instead blame the programmer or more likely the business people as they think it's great to waste resources as it gives them an excuse to charge more.

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

#166

Post by gone35 »

navjack27 wrote: post #152

Re: all the programming replies. Preface, I'm not a programmer, I'm a hardware guy. It's all well and good to make sure your programs and future programs are able to be run in a parallel fashion but there is a big hole to that and it's the operating systems methods of handling cores and threads. Let's use folding@home as an example. Very multithreaded. Now let's use, at first, Ryzen 1800x as the hardware we'll run it…

Very well put! Not an expert but, as far as I know, parallel OS development definitely seems to be a frequent blind spot in the systems literature...

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

#167

Post by arbie »

gilrain wrote: post #139
Bitcoin_McPonzi wrote: post #137

Earlier quoted context omitted.

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.

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.

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

#168

Post by quadcore »

pjmlp wrote: post #160
ta2384428 wrote: post #122

Earlier quoted context omitted.

I'm not familiar with OMP, so please forgive me if I'm incorrect - but OMP from my quick search appears to be thread based, while go routines are much lighter weight than threads. They have their own scheduler - which like most things is both good and bad depending on what you want them for. If you use them as intended, the internal scheduler is a great design decision. This means I can happily spawn 10,000 without c…

You can do the same in C++ on Windows with PPL, UNIX/Windows with Intel TBB, or any of the fiber/co-routine libraries. Then there is the ongoing work to add async/await patterns into C++20.

As a matter of fact, you can do the same in assembly if you want to.

Notice how you can always have that answer when it comes to programming languages: you can do the same in. The point is that, the way it's made in go, is awfully handy.

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

#169

Post by lmm »

gone35 wrote: post #166
navjack27 wrote: post #152

Re: all the programming replies. Preface, I'm not a programmer, I'm a hardware guy. It's all well and good to make sure your programs and future programs are able to be run in a parallel fashion but there is a big hole to that and it's the operating systems methods of handling cores and threads. Let's use folding@home as an example. Very multithreaded. Now let's use, at first, Ryzen 1800x as the hardware we'll run it…

Very well put! Not an expert but, as far as I know, parallel OS development definitely seems to be a frequent blind spot in the systems literature...

The traditional OS is becoming increasingly irrelevant in these days of virtualisation. I predict that future high-performance systems will be built with unikernels.

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

#170

Post by lmm »

stringer wrote: post #134

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.

Particularly given you haven't used actors, what advantages does Pony give you over Haskell?
Post reply on HN