3 ms·
Agreed, the cost is shifted to the back-end. But sometimes it is worth to pay that cost up-front, cfr the memory management debate. Synchronization and concurr
by yvdriess 15y ago
Agreed, the cost is shifted to the back-end. But sometimes it is worth to pay that cost up-front, cfr the memory management debate.
Synchronization and concurrency are much simpler in a system where you do have guarantees. No amount of interfaces or libraries will indeed make OpenMP in C safe, but no amount of hacks are going to make a fine-grained acyclic data flow graph deadlock or share state. The backend of the latter can pay the upfront cost of optimizing the shit away, for example no-copy optimizations, in a safe environment.
One of the biggest research effort in dataflow at MIT came in the aftermath of Multics; the ambitious SMP time-sharing OS research project that later spawned UNIX. citing: http://en.wikipedia.org/wiki/Jack_Dennis http://en.wikipedia.org/wiki/Jack_Dennis
- scott_s 15y agoSynchronization and concurrency are much simpler in a system where you do have guarantees. I agree wholeheartedly, but there is a consequence that cannot be ignored: the resulting programming model is less expressive. The consequence of providing those guarantees is that there are something programmers just can't do. It's a trade-off, and I think we're still exploring how to provide a programming model that both abstracts away the complexity while still providing an expressive enough programming model to be useful in most circumstances.
- yvdriess 15y agoYou are right because the current hardware is biased towards sequential computation where threads&locks are the most efficient. This gives rise to situations where a handful of specialists work years on giving you that one lockless queue in the JVM. They would indeed not give you that edge in any higher-level programming model. It does not help the average programmer however. Our exploration of programming models seems to be stuck in the current processor architecture, which was designed for sequential work with some stuff bolted on to make it run parallel. I could say John Backus' speech is becoming relevant again. This is not ivory tower dreaming. The GPUs have made insane progress because they weren't tied to any computational model to start with. In other words, not being able to do some things is often exactly what is needed to go forward. I wouldn't for the world want to introduce shared memory in Erlang, nor would I want pointer arithmetic under Java's GC.