Why has CPU frequency ceased to grow? (2014)

Post by Bitcoin_McPonzi » Wed, Feb 21, 2018, 6:17 PM UTC

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.

Post by gameswithgo » Wed, Feb 21, 2018, 6:41 PM UTC

Thaxll wrote: post #186

gameswithgo wrote: post #143

Earlier quoted context omitted.

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

Except in other languages it's not part of the core, it's an external library. So on the end it's easy to write "parallel" code.

Post by [deleted] » Wed, Feb 21, 2018, 6:45 PM UTC

pjmlp wrote: post #97

pjc50 wrote: post #52

Earlier quoted context omitted.

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…

I think it is easier to understand by those of us that also had electronic design as part of the engineering degree.

Post by deepnotderp » Wed, Feb 21, 2018, 6:51 PM UTC

pjc50 wrote: post #91

skrebbel wrote: post #79

Earlier quoted context omitted.

> 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. People have been warning us about this for about 10 years now, but I still don't see those 64-core CPUs I was promised anywhere. If we had the amount of parallelism we were told we were going to get, we could give every app its own core. OSes could even…

If you can find an Nvidia GTX 1080, that has 2560 cores.

Post by JetSetWilly » Wed, Feb 21, 2018, 6:56 PM UTC

nradov wrote: post #171

da_chicken wrote: post #163

Earlier quoted context omitted.

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

Intel processors essentially are RISC now internally. They just expose more complex instructions as a higher level API.