5 ms·
If I remember well what I learned in college, the organization of x86 processors is superescalar, which means that the processor uses an internal statistics mec
by lp4vn 4y ago
If I remember well what I learned in college, the organization of x86 processors is superescalar, which means that the processor uses an internal statistics mechanism for predicting the subsequent code that's going to be executed. Itanium on the other side used the VLIW architecture so that the instructions are optimized for a long vector of execution of instructions already in compilation time.
I always found the idea behind the VLIW processor architecture to be a quite good one to be honest, but I read many engineers in many places saying that it's a bad one and it was doomed from the beginning.
The article says that the death of Itanium is mostly due to the disinvestment in the IA-64 caused by the threat of AMD overtaking the x86 market, even though the competition for the x86 market probably benefited all of us, I still find it a bit sad that there was this loss of architectural diversity and sometimes I wonder how well the Itanium would perform today if it weren't killed.
- m_mueller 4y ago.. and then Nvidia brought their GPUs to the clusters and ate both Intel’s and AMDs lunch with a better version of VLIW. The CUDA programming model and hardware IMO is quite successful at abstracting vectors the right way[TM], separating the problem of the grid setup from that of the kernel code (which you can still largely program in a scalar way if you’re not after the last ~30% of performance). IMO a shame that OpenCL never got good.
- wrp 4y ago> ...I read many engineers in many places saying that it's a bad [idea]... I read an article several years ago from an engineer at...ooh, I think it was DEC or IBM. He said that during development of the Itanium, the Intel guys had talked to them and they advised most strongly that Intel drop the project, because they had been down that road and thought it was a dead end.
- wtallis 4y agoSuperscalar just means the processor can execute more than one instruction at a time (in parallel, not just pipelined). The main distinction between VLIW and mainstream x86 is in how the instruction execution is scheduled: x86 cores track dependencies between instructions, and most support reordering instructions to deal with stalls from things like cache misses or the next instruction being of the wrong type for any of the free execution ports. VLIW relies on the compiler to schedule instructions, so that the hardware does not need to do dependency tracking.
- devit 4y agoAnd the problem is that such a thing doesn't really work on mainstream CPUs, because memory access instructions take a highly variable amount of cycles depending on which cache level the data is in, which the compiler cannot know, and generating code for all possibilities leads to exponential blowup of the source code size. It's not clear how Intel thought it could possibly work.
- dw-im-here 4y agopredication and queues can go a long way
- geertj 4y agoFundamentally it seems though that more information is available at run time? You may get partway there in the compiler, but assuming you have sufficient transistor budget, it seems more optimal to do reordering in the CPU.
- zozbot234 4y agoThe runtime doesn't know all that much, though. All it has is a single instruction flow, that it can extract fine-grained parallelism from and try to speed up further via speculation. Nothing whatsoever about other work that may be scheduled in when the processor is stalled by memory, other than via SMT. Nothing about priorities or coarse-grained dependencies among work units. So there's a lot of parallelism that's left on the table, and a lot of speculated work that might just be wasted.
- inkyoto 4y ago> The runtime doesn't know all that much […] If we are talking about JIT, yes, it does, for it instruments the runtime, gathers the information about hot code paths and performs the in-place optimisation. Think of the profile guide compile time optimisation having been carried over into the runtime.
- dontlaugh 4y agoVLIW still lives today in various guises. GPUs are the most obvious. Even the M1 could be argued to be close, it’s a very wide machine.
- skavi 4y agoRecent GPUs have been RISC for some time now. Since AMD replaced their TeraScale architecture.
- flohofwoe 4y agoCan GPUs really be considered VLIW just because they might share an instruction pointer across a couple of 'micro cores'? AFAIK they went even back from SIMD to scalar a long time ago.
- dontlaugh 4y agoI suppose. They’re still very wide machines, which to me seems like the most interesting aspect of VLIW. Of course actual VLIW still are around as DSPs.
- wespiser_2018 4y agoNo, I don't think so. It's one instruction on multiple data (SIMD). That's the essence of a vector op!
- wespiser_2018 4y agoNo, not really. VLIW is considered: Multiple Instruction Multiple Data, in each line of assembly you can send out something like 4 (or 8) instruction each with a different target, and it will work as long as there aren't dependency issues. GPUs are still Single Instruction Multiple Data (SIMD), for every vector operation you are doing operation: adding vectors, taking a dot production you are only executing a single op at a time. SIMDs are really close to the RISC/CISC paradigm, and there's various extensions for other types of SIMD processing in different ISAs used today. VLIW is a much different set of assumptions, requiring the compiler to program in the same instruction level parallelism that a superscalar chip will parallelize via it's architectural features (pipelines/branch prediction/et cetera).