3 ms·
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
by 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 agoVLIW 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 agoNvidia 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.