On Tue, Jul 26, 2016 at 12:07:31PM +0100, Rainer Weikusat wrote:
> I think you meant to write coroutines, not closures, as that's what go
> adopted based on Hoare's 'Communicating Sequential Processes'. That's
> also pretty 'old stuff'. It's also unfortunately an instace of something
> which should really be called such-and-such-a-law,
>

>     As soon as one guy has learnt that people use multi-threading to exploit
>         shared-memory multi-processors and not to avoid state machines, on comes
>     the next "been living under a rock since 197x" person and re-implements
>     cooperative userspace threading again.

Coroutines _are_ a nice thing that simplifies producer/consumer code and a
bunch of other schemes, but they are stuck within a single thread. As
interthread/interprocess synchronization is costly, this is often the right
thing to do.

But, these days, any software that actually needs processing power (rather
than merely wasting it because of being written in Visual Basic or PHP, or
without understanding how to code) will need multiple threads/processes.
The Moore's law for single threaded computation is dead. At 4GHz, light can
travel just 8cm per clock cycle, there's only so much we can do to improve
performance. Tricks like pipelines, speculative execution, etc, has been
mostly exhausted within the last decade, and we quite hit a wall. It'd take
a completely new paradigm to get us a significant improvement, and even
that'd bring no more than a single order of magnitude more speed. Perhaps
two orders with extreme nanotechnology of the future.

So, we're at the end of the road of current style of processors, and not
that far from the end with speculative future technology with anything that
resembles classical processors. Thus, sorry, there's no way around
multithreading.


--
An imaginary friend squared is a real enemy.