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

271–280 of 301 posts

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

#271

Post by d-sc »

deepnotderp wrote: post #256
tagrun wrote: post #253

Earlier quoted context omitted.

That's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved. But if your switching frequency is slow, it doesn't matter if you use a superconductor for wires. It is the switching frequency that truly determines the limits for gate times, which in turn determines how fast yo…

>That's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved. No it's not. What is this magical material with ultra low resistance? And how do you plan to reduce capacitance? Btw, manufacturing terahertz speed transistors is very difficult. There are Mott FETs which will sw…

I can’t speak on their usability in circuits. However, materials that show properties characteristic of zero resistance exist. I’ve used them at work before.

https://en.wikipedia.org/wiki/Superconductivity

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

#272

Post by deepnotderp »

d-sc wrote: post #271
deepnotderp wrote: post #256

Earlier quoted context omitted.

>That's just a plumbing problem which can be solved by lowering temperature or using a different material with lower resistivity. Yes, it'll probably cost more, but it's a problem that can readily be solved. No it's not. What is this magical material with ultra low resistance? And how do you plan to reduce capacitance? Btw, manufacturing terahertz speed transistors is very difficult. There are Mott FETs which will sw…

I can’t speak on their usability in circuits. However, materials that show properties characteristic of zero resistance exist. I’ve used them at work before. https://en.wikipedia.org/wiki/Superconductivity

And how do you propose to cool every chip to cryogenic temperatures?

Not to mention the manufacturing challenge of integrating superconductors into chips (I think InP would be the easiest candidate, and that's saying something...)

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

#273

Post by quadcore »

magnetic wrote: post #192
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…

In my experience the facilities to throw tasks into a scheduler that will run them in parallel was never the hard thing to accomplish (regardless of the language: some may have built-in capabilities, others may have syntactic sugar provided by a lib, but at the end of the day, most systems provide some kind of runTask(f) method). What's really hard is to break down a problem into parallelizable chunks, figure out as…

throw tasks into a scheduler that will run them in parallel was never the hard thing to accomplish

Common mistake number 1. Goroutines are running in parallel AND concurrently - they are coroutines (common mistake number 2 is to think they are only coroutines). I suggest not to underestimate that, it's the big deal. Additionnaly, it's important to note that goroutines yields on sleeps (any kind of sleeps / waits, like disk reads, network requests, channel writes/reads, etc), and while it may sound like a detail, it's a wonder of cpu control. Due to that, there is also a rare elegance to the way Go solve sharing data via channels.

What's really hard is to break down a problem into parallelizable chunks, figure out as much independent work as possible to reduce the touchpoints, and coordinate all those tasks such that they keep the CPU as busy as possible and as a whole finish as early as possible.

That's exactly what Go is a wonder for due to the combination of parallelism, concurrency, yield-on-sleep and channels.

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

#274

Post by quadcore »

eropple wrote: post #228
quadcore wrote: post #161

Earlier quoted context omitted.

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.

Go is not a language for "system-level features" in the first place. Its garbage collector largely precludes it from that in any modern context. That it can't do something effectively does not mean that it shouldn't or didn't mean to . (And users can't really fix it, because hey, no generics . Sigh.)

Go is not a language for "system-level features" in the first place. Its garbage collector largely precludes it from that in any modern context.

I'm pretty sure I disagree with that largely because Go is low-level enough so that the GC is easily handled.

And users can't really fix it, because hey, no generics. Sigh.

Users can fix it by writing languages on top of Go (particularly dynamic ones).

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

#275

Post by quadcore »

brobinson wrote: post #252
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…

>marvel of parallelism If Go's m:n is blowing your mind, you should check out Erlang. Spawning a million "processes" is not a big deal.

Cool, thanks for the suggestion.

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

#276

Post by quadcore »

Const-me wrote: post #260
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…

> golang is one of those rare language Not sure how rare, .NET does that as well. Below is your sample translated to C#. It requires C# 7.1 because async main, but the rest of the stuff is available for many years, since 2010. static async Task routine() { await Task.Delay(TimeSpan.FromSeconds(1)); } static Task Main() { return Task.WhenAll(Enumerable.Range(0, 1000).Select(i => routine())); }

It's unclear to me if these parallel tasks are also coroutines (there seems to be a call to yield but its unclear what it really does), and if they yield on any sleeps which is a key features of goroutines.

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

#277

Post by quadcore »

pjmlp wrote: post #191
quadcore wrote: post #168

Earlier quoted context omitted.

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.

I hardly see a difference from go func () { } and Task.Run(() => { }) With the benefit that on the latter example, the runtime allows me to customise how scheduling is done.

Are those Tasks coroutines? If yes, do they yield on any sleeps?

These aspects are key to goroutines.

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

#278

Post by pjmlp »

quadcore wrote: post #277
pjmlp wrote: post #191

Earlier quoted context omitted.

I hardly see a difference from go func () { } and Task.Run(() => { }) With the benefit that on the latter example, the runtime allows me to customise how scheduling is done.

Are those Tasks coroutines? If yes, do they yield on any sleeps ? These aspects are key to goroutines.

Yes they do, they are the building blocks for async/await, get a thread allocated from a thread pool when running, and you can control how the scheduling takes place, by providing your own scheduler implementation.

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

#279

Post by Const-me »

quadcore wrote: post #276
Const-me wrote: post #260

Earlier quoted context omitted.

> golang is one of those rare language Not sure how rare, .NET does that as well. Below is your sample translated to C#. It requires C# 7.1 because async main, but the rest of the stuff is available for many years, since 2010. static async Task routine() { await Task.Delay(TimeSpan.FromSeconds(1)); } static Task Main() { return Task.WhenAll(Enumerable.Range(0, 1000).Select(i => routine())); }

It's unclear to me if these parallel tasks are also coroutines (there seems to be a call to yield but its unclear what it really does), and if they yield on any sleeps which is a key features of goroutines.

> if these parallel tasks are also coroutines

I don’t have hands-on experience with golang but based on what I know about it yes, they are.

> there seems to be a call to yield but its unclear what it really does

You mean “await”?

It waits for the completion of whatever is on the right side of “await”. If the result is already available, it just continues. If the result is not yet available (e.g. Task.Delay creates a task that will complete in some moment in the future), the control goes away from the async method to the scheduler. The scheduler can then run some other task on the same OS thread. When the result of that operation becomes available (in the sample code, when 1 second delay passes), the scheduler resumes execution of that async method, on the statement after the await.

> if they yield on any sleeps

No, not any sleep. You can call Thread.Sleep() which will put the whole OS thread to sleep. It’s up to programmers to avoid calling blocking APIs from their async methods, i.e. use await Task.Delay() instead of Thread.Sleep(), await stream.ReadAsync() instead of stream.Read(), and so on.

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

#280

Post by versteegen »

pjc50 wrote: post #128
jokoon wrote: post #25

Earlier quoted context omitted.

I wonder if the future will be massively parallel, when CUDA and opencl came out I thought that future processors would have more and more core, so if you follow Moore's law, CPUs would see their core count double each 6 months. The problem is that GPU don't have error correcting codes, so you cannot really run application code on a GPU. The problem with parallelism is that C-like language don't fit well, only functi…

> The problem is that GPU don't have error correcting codes .. eh? What are you referring to here? Mainstream CPUs don't have error correction either, unless you're talking about ECC on the higher-end ones.

Actually, mainstream CPUs do use error detection and correction for internal operations and memory.

https://en.wikipedia.org/wiki/Machine-check_exception

Realise that if you only protected RAM with ECC then you're leaving a lot of data vulnerable in caches and registers, so those need parity bits too (as well as lots of other error checks on CPU operations). And anyway, CPU errors are common due to bad power supplies and overclockers. And you don't want to add a whole lot of design effort to create a marginally cheaper-to-produce version of the CPU which doesn't do any error checking.

I've seen a lot of MCEs on non-ECC CPUs :(

IANAEE

Post reply on HN