3 ms·
Even more importantly, and I'm surprised you didn't mention it, static compile time VLIW doesn't know what to do for memory access. A load might take any number
by jleahy 6y ago
Even more importantly, and I'm surprised you didn't mention it, static compile time VLIW doesn't know what to do for memory access. A load might take any number of cycles depending on whether the line is in L1, L2 or L3 cache, with static compile time VLIW then the compiler has to guess, if it's optimistic the whole CPU stalls, if it's pessimistic then you're much slower than you would otherwise be.
I believe this is the real thing that make superscalar OoO (ie. JIT to VLIW in silicon) win.
- sharpneli 6y agoThat's a great point to emphasize. Because memory access times are inherently more or less nondeterministic. I consider it to be roughly as important as being able to reorder instructions across non statically determined branches and function calls. And both of these expose the fundamental weakness in explicit VLIW, if it's essentially nondeterministic it cannot be taken advantage of. Then we naturally have some other benefits, like hyperthreading. Which basically is just compiling two instruction streams together on the fly.
- mhh__ 6y agoThe performance on particularly memory-bound workloads is why I chose it as an example rather than a prediction. For it to work statically (although it really could be halfway in between), it would probably require a complete paradigm shift away from the current way we think about cpu caches Regardless of whether it'll work or not, I'll be very happy if the mill ever makes it onto a chip.