I’m working on our next tutorial, which will cover using concurrency patterns in your Reconfigure.io programs, and I came across this really interesting blog post on visualising concurrency. It’s got a bit at the end showing how concurrency and parallelism are separate (but connected) endeavours too.
Hi Rosie. that visualization blog post was a great find, thanks for sharing.
I don’t know if concurrency vs parallelism is all that instructive for hw design. Here is my thinking: CSP and hardware design have some overlap, but diverge in their scope and scale. CSP can have arbitrary complex node functions, hardware cannot. The CSP/Golang channels/hw similarity is in the communication of whole data structures from one stage to another, which is ‘taught’ in the Golang space as sharing state via communication not via shared memory. It is that specific concept that works well for hardware design.
So visualizations that compare the Golang CSP ‘pipeline’ with the pipeline that Teak generates from that would be the holy grail to understand how the source description yields the hardware.
That is my $0.02
However I believe every arbitrary complex behaviour of CSP can be modelled in hardware, however we’d need to pay the associated costs for moving from a timed to a spatial domain.
In Golang everything, particularly the memory model, is kept simple to avoid breaking sequential consistency which is greatly in favour of transforming it into hardware (spatial domain).