3 ms·
>What's interesting though is this: now that code size is comprehended to be the huge issue it is, could we see new experimental architectures that do radical t
by cube13 14y ago
>What's interesting though is this: now that code size is comprehended to be the huge issue it is, could we see new experimental architectures that do radical things in that department such as the use of actual data compression algorithms in instruction encodings?
I'm not sure that's going to result in that much improvement. Linus points out in one of the later emails that instruction fetching and decoding ends up being the major bottleneck on high-performance code, especially when the architecture contains optimizations like out of order execution. Higher compression means more cycles to decompress, and you still need cache space to store and cache the decoded instructions, so you don't get multiple hits for running the same instructions in a loop.
The additional prefetch hit can certainly be mitigated by additional pipelining, but it's still more silicon every instruction needs to go through.
Realistically, I think the best approach may be more RAM and larger onboard caches.
- filereaper 14y agoPardon me, I'm not a CPU architect but I have a couple of questions. Why would prefetch and decode affect out of order execution? Prefetch and decode is done on the frontend of the chip, so you'll have prefetch happening on L3, L2 and L1, along with decode and u-op breakdown. This is a matter of memory throughput getting instructions from the bus into the caches. The out-of-order execution should be a matter of issuing to the backend execution units. It is true that the backend will be stalled if we don't issue quickly, but that's where you have staging and prefetch on the front end side. At least the above is what I thought to be the case. I could be very wrong. Please educate if I've gotten something wrong. Also we do have the matter of throughput vs completion of an instruction, basically a tradeoff. Deeper pipelines so can have more throughput but take the hit of longer completion times. Again might be bad for certain tasks, but going through more sillicon isn't necessarily always bad. Thanks.