5 ms·
> I wonder if the history of x86 is holding us back in a big way. It started out being close to the metal but now it's an abstraction that can mislead you if y
by blattimwind 8y ago
> I wonder if the history of x86 is holding us back in a big way. It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes.
But when you compare high-end cores, you always see the same picture, regardless of ISA. Large surface area (~1/3 of the core) used for insn fetch/decode/schedule; they look all the same, whether it's POWERn or the latest Sandy-Bridge/Haswell rehash... people claim that other ISAs would be a lot easier/faster/more efficient to decode, but that doesn't seem to be true in practice. It seems to me that any difference that might be there gets dwarfed by the sheer complexity of OoOE and speculative execution.
What we do know is outside some niches (like DSPs, where VLIW reigns king) static techniques essentially do not work for application code, because it's impossible to predict statically.
- thechao 8y agoEven 15 decoders are a pinprick on the core’s area—at least when I saw die area for LRB. Fetch & schedule we’re a bit larger. Most of the core area was register files & floating-vector logic.
- bogomipz 8y ago>."..at least when I saw die area for LRB" What is LRB?
- woadwarrior01 8y agoProbably Larrabee, Intel’s cancelled GPGPU with an x86 ISA.
- brandmeyer 8y agoIn fairness, Larrabee was originally an in-order design.
- gpderetta 8y agoIt was also a simpler core, which means that for a complex OoO monster, the decoder would be an even smaller area. The OoO instruction scheduler would be a significant chunk, but that has nothing to do with being x86.
- bogomipz 8y ago>"What we do know is outside some niches (like DSPs, where VLIW reigns king)" Interesting, why is VLIW is so predominant in DPS chips?
- gaius 8y agoBecause VLIW is a great idea but we only know how to compile DSP code effectively for it, that being a subset of general-purpose code
- blattimwind 8y agoBecause typical DSP code does calculations using predictable memory access patterns and usually contains very little logic. This makes it possible to largely statically schedule the code. It's fairly similar in that regard to e.g. GPU shaders (and indeed GPUs have used VLIW-like designs in the past) and scientific data crunching code.
- gpderetta 8y agoalso DSP code has a decent amount of instruction level parallelism.
- bogomipz 8y ago>"typical DSP code does calculations using predictable memory access patterns and usually contains very little logic." Thanks, that's what I was missing - the access patterns of signal processing is what makes VLIW a good fit. Is there any other use case where VLIW architectures are prevalent or are DSPs the primary use case?
- ptx 8y agoWhat if the parts that are impossible to handle statically were instead handled in software by a JIT compiler that could speculate and deoptimize when necessary? Could that be a more efficient model for executing high-level languages like Java etc.?
- acqq 8y ago> Could that be a more efficient model No, because what the CPUs have is the advantage of being able to have specialized circuits with the new answers in each clock, every instruction in every pipelne stage and so fast adaptation to the use in run time.