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

191–200 of 301 posts

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

#191

Post by pjmlp »

quadcore wrote: post #168
pjmlp wrote: post #160

Earlier quoted context omitted.

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.

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.

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

#192

Post by magnetic »

quadcore wrote: post #10
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…

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

Beyond this "parallel breakdown design", it's the little touchpoints with shared data structures and synchronization that creates the difficulty of implementation, and I haven't seen any language or system that does magic there.

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

#193

Post by brazzy »

floatboth wrote: post #178
ethagnawl wrote: post #156

Earlier quoted context omitted.

FWIW, you can also achieve similar behavior in Clojure via pmap, Reducers, etc.

And in Haskell https://www.stackage.org/haddock/lts-10.6/parallel-3.2.1.1/C... And in .NET https://docs.microsoft.com/en-us/dotnet/api/system.threading... And in Java https://blog.oio.de/2016/01/22/parallel-stream-processing-in... Rayon is notable because Rust is a native-compiled, no-GC language.

To me, the "If it’s not thread-safe to do, then it won’t compile" part sounds rather more notable.

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

#194

Post by jedbrown »

Retric wrote: post #184
jedbrown wrote: post #177

Notably, single-thread performance of code that is not friendly to vectorization has not stagnated despite stagnant clock frequency. Indeed, SPECint performance continues to grow exponentially, albeit more slowly since ~2004. https://www.karlrupp.net/2018/02/42-years-of-microprocessor-...

Depends on the code, you can write ASM that's as fast on an old P4 as a modern i7. Just access random RAM locations and modern CPU's suck.

Increasing CPU clock speed also does not reduce DRAM latency.

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

#195

Post by stringer »

lmm wrote: post #170
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?

Right now I found Pony more approachable than Haskell. Maybe because that I never fully grok monads (probably my fault not persevering enough), I always had problems composing monads.

Also the promise of Pony is a garbage collection that is concurrent with program execution and since I want to write low latency server code this feature sounds very appealing.

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

#196

Post by burntsushi »

gameswithgo wrote: post #143
ilogik wrote: post #84

Earlier quoted context omitted.

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

Not especially. It has goroutines, C# has Tasks, C++ has green thread libraries. Added onto this are channels which are basically thread safe queues, other languages have those too. (I am aware that there are differences between what features goroutines and Tasks provides) Go's implementation of these things is nice, neat, and all included out of the box though which is nice. In general you can make parallelism easy,…

I think Go does make it relatively easy to write parallel code in comparison to most other frequently used languages.

> Not sure any other language includes that out of the box!

Rust's compiler does it by default, at compile time. ;-) Go's race detector is never wrong, but it may omit things. On the other hand, Rust's compiler is also neither wrong nor does it omit things, except under one circumstance: someone, somewhere, wrote `unsafe` code and committed a bug inside that block.

ThreadSanitizer is also a thing: https://clang.llvm.org/docs/ThreadSanitizer.html

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

#197

Post by deepnotderp »

Symmetry wrote: post #159

That was a bit misleading in some ways. First, in pipelining you'll typically measure how long a pipeline steps in FO4s, which is to say the delay required for one transistor to drive 4 other transistors of the same width. Intel will typically design its pipeline stages to have 16 FO4s of delay. IBM is more aggressive and will try to work it down to 10. But of those 10, 2 are there for the latches you added to create…

I don't think anyone uses U/LVT transistors in low geometries, the leakage would be a nightmare .

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

#198

Post by Retric »

jedbrown wrote: post #194
Retric wrote: post #184

Earlier quoted context omitted.

Depends on the code, you can write ASM that's as fast on an old P4 as a modern i7. Just access random RAM locations and modern CPU's suck.

Increasing CPU clock speed also does not reduce DRAM latency.

We are talking about the sum of latency's. The CPU needs to do something AND you need to fetch from DRAM. Modern CPU's have increased the worst case overhead to fetch form DRAM to decrease the average case.

That's usually a good trade-off until someone wants to make your CPU look terrible.

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

#199

Post by coldtea »

arbie wrote: post #167
gilrain wrote: post #139

Earlier quoted context omitted.

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.

>It does seem a little odd that every comment about Rust gushes about its progress and stability without discussing any downsides.

Doesn't seem odd at all.

First, a lot of people commenting about Rust are enthusiastic recent adopters that haven't seen much of the language, including any real ugly sides yet.

Second, it's not entirely true, almost all Rust threads mention the steep learning curve, the slow compiler, and other issues such as the variadic generics (or lack thereof to be precise).

Third, we have seen the same "early adopter enthusiasts seeing it all rosy" circle for RoR, Go, Node, and Mongo, nothing out of the ordinary here.

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

#200

Post by coldtea »

Thaxll wrote: post #188
gilrain wrote: post #175

Earlier quoted context omitted.

Try it out and write the critique, then. The posts are positive because Rust is genuinely achieving rapid progress and stability... but certainly not without flaws. I've experienced plenty of frustration, albeit outweighed by the massive benefits for my use case. And there are whole problem domains to which it's just not suited. I see these mentioned pretty frequently.

For once there is no consensus how to do parallelism an concurrency in Rust since none of the library are matures.

Don't most people opt for something called Tokyo? I don't do Rust much, but even I have heard of it by now...
Post reply on HN