4 ms·
I've always felt that vliw might have been a victim of this. I'm not super knowledgeable on it though, apart from being familiar with the disaster that was itan
by wheybags 6y ago
I've always felt that vliw might have been a victim of this. I'm not super knowledgeable on it though, apart from being familiar with the disaster that was itanium.
- londons_explore 6y agoVLIW suffers from lack-of-abstraction. ie. you can make some great hardware and software which perform really efficiently today. If you later try to make a v2 of that system, and want to reuse the same software, then sorry - you're outa luck! Also, while compilers today are very complex, they are still far from what's necessary to really make good use of a VLIW machine. If someone manages to solve the above two things, then VLIW will 100% wipe the floor with current architectures. Being able to throw out all logic trying to get parallelism out of a serial instruction stream would have massive power and area improvements for the same computation throughput.
- ncmncm 6y agoA perceived need to run old binaries seems apparent here. With a lot of code in use being Java and Javascript compiled JIT, the need to run somebody else's binaries is beginning to fade. Similarly, the high cost of memory page systems and context switches is an artifact of executing unvetted code. When everything untrusted is compiled in a way that it physically cannot breach memory boundaries, the need for the OS and programs to live in separate memory spaces evaporates, along with its overhead.