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

51–60 of 301 posts

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

#51

Post by logicallee »

guys, I'll be honest: I found it really odd that the article didn't talk about the speed of light, and die size constraints. (c / 4 ghz = 7.49 cm only, if you double that frequency you have half that size to put components it between any two clock ticks.)

But there are limits to my hubris - this is on intel.com, so I'm going to go with "I'm the one missing something". Is the speed of light and number of transistors you can put in that path (due to die size) just not a practical constraint? Neither is mentioned.

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

#52

Post by pjc50 »

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…

Unfortunately it requires more than just a change of language, it requires a change in mode of thinking by developers. People are very used to reasoning in terms of "do X, then Y, then Z" or "compute a value X then do A or B on the basis of that". In order to achieve automatic parallelism you need e.g. a type+proof system that can determine that X/Y/Z are independent, or a system that can partially execute both A and B then retire the branch not taken - without invoking security bugs!

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

#53

Post by MichaelMoser123 »

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…

> However, most programmers, and programming languages, remain stuck in a serial-by-default paradigm

You still have to decide upon the unit of work that is going to be sent to a different thread/core/processor/NUMA node/whatever. The different units of work that are distributed should not share state; one really doesn't want to be sharing a lot of state between different processors, because synchronizing the processors memory caches in NUMA is a extremely slow.

I guess it is really hard to break up both the program and data and decide upon the optimal granularity of the work units, it is not something that can be easily done behind the scenes - human intervention is still required.

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

#55

Post by gall0ws »

tzahola wrote: post #41
quadcore wrote: post #40

Earlier quoted context omitted.

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.

https://play.golang.org/p/o8odLCRqUMA

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

#56

Post by z3t4 »

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

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

#57

Post by boomlinde »

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").

> 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. GOMAXPROCS defaults to the number of logical CPUs, IIRC since version 1.5. For example, I have four cores with 2 threads each, so goroutines will be executed on up to 8 threads unless I set GOMAXPROCS to something else or the application explicitly changes it using the runtime package.

And sure, you'll really have the same problems, but IMO channels and goroutines minimize the friction of implementing thread safe programs using CSP. GP seems a bit optimistic, agreed, but I think that there is at least some substance to the idea that go makes it easier to correctly utilize multiple cores.

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

#58

Post by pjc50 »

logicallee wrote: post #51

guys, I'll be honest: I found it really odd that the article didn't talk about the speed of light, and die size constraints. (c / 4 ghz = 7.49 cm only, if you double that frequency you have half that size to put components it between any two clock ticks.) But there are limits to my hubris - this is on intel.com, so I'm going to go with "I'm the one missing something". Is the speed of light and number of transistors y…

The key factors in integrated circuit delay are more to do with capacitance; in order to change a gate's transistor from off to on, the driving gate has to charge the capacitance of the driving wire and the driven gate. Making features closer together increases their mutual capacitance.

(source: worked on this for a chip design software company. The delay approximation was based entirely around R/L/C modelling and had no terms for the speed of light per se. If I remember rightly it was calculated in integer pico-meters; I definitely remember it emitting an error message if you had more than 2cm of wire in any one net!)

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

#59

Post by v_lisivka »

kowdermeister wrote: post #36
mtgx wrote: post #28

Earlier quoted context omitted.

TeraHertz CPUs would be nice.

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.

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

#60

Post by swiley »

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 are limits to how much parallelism will improve things, see amdahl's law.
Post reply on HN