4 ms·

Specifically, the promise of VLIWs (scalar parallelism) was overhyped--the Multiflow compiler couldn't find enough scalar parallelism in practice to keep all 28

by cpr 7y ago

Specifically, the promise of VLIWs (scalar parallelism) was overhyped--the Multiflow compiler couldn't find enough scalar parallelism in practice to keep all 28 ALUs busy (in the widest model we built), or even all 7 ALUs (in the narrowest). (I ended up running the OS group at Multiflow before bailing right before they hit the wall.)

zozbot234 7y ago
We need new programming models that make it easier to expose static parallelism to the compiler. Doing it all in plain old C/C++, or even in "managed" VM-based languages, cannot possibly work - and even conventional multi-threading is way too coarse-grained by comparison to what's most likely needed. Something based on a dataflow-oriented description of the code would probably work well, and be possible to integrate well enough with modern functional-like paradigms.
- pdimitar 7y ago
  I reached the same conclusion. We need a way to be able to explicitly say "this piece of code here is a standalone unit that is independent of everything else until we have to coalesce results of computation", or "this unit manages those other units and coalesces their results". Erlang's OTP captures this pretty okay-ish with their concept of processes (preemptively scheduled green threads that get aggressively multiplexed on all CPU cores) but I feel we can go a little bit further than that and have some sort of shorter markers in the code, say `actor { ... }` or `supervises(a1, a2, a3) { ... }` or something.
- Symmetry 7y ago
  VISC seems at least potentially promising. https://www.anandtech.com/show/10025/examining-soft-machines-architecture-visc-ipc/2 https://www.anandtech.com/show/10025/examining-soft-machines...
  - cpr 7y ago
    Yes, but VLIW's premise was that all that coordination that the VISC architecture is doing at runtime in hardware could be computed at compile-time in software.

by cpr 7y ago

zozbot234 7y ago

We need new programming models that make it easier to expose static parallelism to the compiler. Doing it all in plain old C/C++, or even in "managed" VM-based languages, cannot possibly work - and even conventional multi-threading is way too coarse-grained by comparison to what's most likely needed. Something based on a dataflow-oriented description of the code would probably work well, and be possible to integrate well enough with modern functional-like paradigms.

pdimitar 7y ago
I reached the same conclusion. We need a way to be able to explicitly say "this piece of code here is a standalone unit that is independent of everything else until we have to coalesce results of computation", or "this unit manages those other units and coalesces their results". Erlang's OTP captures this pretty okay-ish with their concept of processes (preemptively scheduled green threads that get aggressively multiplexed on all CPU cores) but I feel we can go a little bit further than that and have some sort of shorter markers in the code, say `actor { ... }` or `supervises(a1, a2, a3) { ... }` or something.
Symmetry 7y ago
VISC seems at least potentially promising. https://www.anandtech.com/show/10025/examining-soft-machines-architecture-visc-ipc/2 https://www.anandtech.com/show/10025/examining-soft-machines...
- cpr 7y ago
  Yes, but VLIW's premise was that all that coordination that the VISC architecture is doing at runtime in hardware could be computed at compile-time in software.