That's why I tried to use it more as a methaphor. Because the whole point of explicit VLIW (EPIC was what Itanium folks called it) was to save that scheduling HW. But nowadays that piece of HW is relatively minor part. So it's no longer worth to save it in a general purpose CPU. As this thread is about general purpose CPU's for direct consumer use (not a controller in hard drive or whatnot, but a full fledged CPU you run arbitrary programs in) we're talking about chips like Itanium when it comes to VLIW.

I do not disagree that VLIW is a great for things like DSP where the power consumption is of the essence. One can get ridiculously high perf/watt by going explicit VLIW. I just don't see any way we'd see that approach in general purpose CPU's again.

GPU's do not need to reorder instructions to hide memory latency. It just happens on a different level. While a single threadgroup (as in that single instruction pointer that controls the SIMD unit) will not get reordered at all, one has multiple threadgroups in flight. So if one group stalls at a memory load the unit will just schedule a different threadgroup. Because one generally has tons of them in flight. It's all about throughput. One could think of this as an in order CPU (from viewpoint of a single thread) but with ridiculous amounts of hyperthreading (one thread stalls, we can pick an instruction from another thread but never one from the stalled thread).