4 ms·

> However, VLIW-like architectures could give us back the performance of out-of-order execution without the drawbacks since the compiler has much more direct co

> However, VLIW-like architectures could give us back the performance of out-of-order execution without the drawbacks since the compiler has much more direct control over the caches and registers used in the CPU as well as branch prediction and lots of other internals. > Of course, you also need much smarter compilers, since the Itanium failure, we've come a long way and I'm convinced that Rust and friends would be able to get the maximum out of a VLIW-like with some additional work. - What kind of compiler magic do you have upon your sleeves that will enable that kind of magic, but circumvents the problem of non-existence of a "sufficiently smart compiler" that plagued Itanium? In particular: What kind of magic does Rust offer for this? - How do you intend to solve the problem (that also plagued Itanium) that mostly scientific code has the kind of parallelity that is very suitable to VLIW which lead to the problem that "lots of ordinary, existing code" did not benefit so much from the potential speed that Itanium offered? - How do you intend to solve the problem that putting deep microarchitecture details into the instruction set is usually a bad idea, because it "cements" these details (I just say: MIPS' delay slots), while having a good instruction set makes deep changes in the underlying microarchitecture easy.

zaarn 8y ago
Compilers have advanced a lot since Itanium as have languages, Rust has lot of information to properly track shortly lived objects and optimize that. Lots of code runs fairly well in CPU pipelines with multiple work units, if the work pipeline is too wide that sucks of course and is a bit of a waste but, say, having a Intel-sized pipeline would run most of the current code with the same efficiency. This isn't purely about parallelizing threads, this is about microcode instructions which can be parallelized very easily; pull a instruction from the list of the program and put it in the first free execution unit on no conflict, if a conflict occurs resolve it (WaW; drop it or assign new register, RaR; free reordering, WaR; assign new register, RaW, strictly no ordering before), repeat. A compiler should be easily able to do that. Of course having the microarchitecture and instruction set tightly married is a problem but considering we have a fairly alive ARM marketplace of varying instruction sets from ARM, I think it's not unsolvable from the compilation direction and you can abstract out some details so porting is easier or you can atleast emulate the other CPU with high efficiency.
- wolfgke 8y ago
  > Of course having the microarchitecture and instruction set tightly married is a problem but considering we have a fairly alive ARM marketplace of varying instruction sets from ARM, I think it's not unsolvable from the compilation direction and you can abstract out some details so porting is easier or you can atleast emulate the other CPU with high efficiency. At least the first Itanium also had hardware emulation for x86 code. It was really slow (which gave AMD a strong competitive advantage at that time and enabled them to establish x86-64).
- gpderetta 8y ago
  VLIW cpus are being built today. While they do quite well for specialized workloads, they make pretty poor general purpose CPUs. If compiler magic was available it would be already in use. Transmeta style VLIW+JIT frontend seem to be viable, but I think they are as vulnerable to spectre as OoO CPUs.
  - wolfgke 8y ago
    > Transmeta style VLIW+JIT frontend seem to be viable, but I think they are as vulnerable to spectre as OoO CPUs. Transmeta's CPUs were in-order VLIW. The in-order property at least makes them at least less prone to Spectre-like vulnerabilities, just like the CPU used in the Raspberry Pi which is also in-order: > https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...
    - gpderetta 8y ago
      Nvidia Denver, which is basically an evolution of transmeta technology, appears to be vulnerable to spectre. It doesn't matter that the underlying cpu is in order if the cpu+runtime pair implement a deep out of order speculative engine.
deleted 8y ago
[deleted]
deleted 8y ago
[deleted]
snaky 8y ago
> What kind of magic does Rust offer for this? Not much, comparing to C, they both are too low-level for that. Just like almost all the programming languages widely in use. Except maybe Haskell. That's just impossible to optimize C code beyond some (not very impressive) level. And every CPU hoping for wide adoption is pretty much "CPU for C compiler" - and that's a problem.

zaarn 8y ago

Compilers have advanced a lot since Itanium as have languages, Rust has lot of information to properly track shortly lived objects and optimize that. Lots of code runs fairly well in CPU pipelines with multiple work units, if the work pipeline is too wide that sucks of course and is a bit of a waste but, say, having a Intel-sized pipeline would run most of the current code with the same efficiency. This isn't purely about parallelizing threads, this is about microcode instructions which can be parallelized very easily; pull a instruction from the list of the program and put it in the first free execution unit on no conflict, if a conflict occurs resolve it (WaW; drop it or assign new register, RaR; free reordering, WaR; assign new register, RaW, strictly no ordering before), repeat. A compiler should be easily able to do that. Of course having the microarchitecture and instruction set tightly married is a problem but considering we have a fairly alive ARM marketplace of varying instruction sets from ARM, I think it's not unsolvable from the compilation direction and you can abstract out some details so porting is easier or you can atleast emulate the other CPU with high efficiency.

wolfgke 8y ago
> Of course having the microarchitecture and instruction set tightly married is a problem but considering we have a fairly alive ARM marketplace of varying instruction sets from ARM, I think it's not unsolvable from the compilation direction and you can abstract out some details so porting is easier or you can atleast emulate the other CPU with high efficiency. At least the first Itanium also had hardware emulation for x86 code. It was really slow (which gave AMD a strong competitive advantage at that time and enabled them to establish x86-64).
gpderetta 8y ago
VLIW cpus are being built today. While they do quite well for specialized workloads, they make pretty poor general purpose CPUs. If compiler magic was available it would be already in use. Transmeta style VLIW+JIT frontend seem to be viable, but I think they are as vulnerable to spectre as OoO CPUs.
- wolfgke 8y ago
  > Transmeta style VLIW+JIT frontend seem to be viable, but I think they are as vulnerable to spectre as OoO CPUs. Transmeta's CPUs were in-order VLIW. The in-order property at least makes them at least less prone to Spectre-like vulnerabilities, just like the CPU used in the Raspberry Pi which is also in-order: > https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/ https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulne...
  - gpderetta 8y ago
    Nvidia Denver, which is basically an evolution of transmeta technology, appears to be vulnerable to spectre. It doesn't matter that the underlying cpu is in order if the cpu+runtime pair implement a deep out of order speculative engine.

deleted 8y ago

[deleted]

deleted 8y ago

[deleted]

snaky 8y ago

> What kind of magic does Rust offer for this? Not much, comparing to C, they both are too low-level for that. Just like almost all the programming languages widely in use. Except maybe Haskell. That's just impossible to optimize C code beyond some (not very impressive) level. And every CPU hoping for wide adoption is pretty much "CPU for C compiler" - and that's a problem.