4 ms·
There's been a good number of VLIW attempts that had great peak possible performance and efficiency, but fall down in many current consumer use cases. (Itanium,
by kimixa 4y ago
There's been a good number of VLIW attempts that had great peak possible performance and efficiency, but fall down in many current consumer use cases. (Itanium, NVidia denver, many GPU/DSP architectures (though they focused on what that sort of architecture did well instead of trying to wedge it into other use cases).
Think about how wide the execution unit of a modern Intel/AMD CPU is compared to it's average IPC, if you could magic up an instruction stream that filled every port, and you could remove all the Out-of-Order/reordering/hazard logic it would make the cores a fair bit smaller and power efficient while giving the "same" peak possibly performance. But more ALU ports don't seem to the the bottleneck in current consumer software - keeping them filled is. Hence all the OoO/multithreading/big caches.
And the "Sufficiently Advanced Compiler" making up for OoO scheduling on the hardware itself has been a pipe dream for many years. Maybe this will be the one to break through the apparent barrier? But it's not like there haven't been a LOT of money and very clever people working on this exact thing before - and they have all fallen by the wayside compared to current large OoO CPU cores.
So to me it's just another cookie cutter attempt at VLIW, nothing special.
- incrudible 4y agoThe market has changed. There are now applications for filling every ALU port and those usually run on GPUs, which have awful DX. This chip can run x64, ARM or RISCV whenever performance does not matter, but also run native binaries compiled with GCC. I agree that the VLIW approach will likely fail to deliver in most other applications, but I do not see the product marketed to them either.