> I don't know where I was unclear. I don't think you were unclear. As respectively as possible (and I really do like your perspective and many of your other

> I don't know where I was unclear. I don't think you were unclear. As respectively as possible (and I really do like your perspective and many of your other posts) I think the problem is that you were clear and wrong[1]. > it's that the darned addressing is too slow or > there's too much of it Generally, no. Current processors have two dedicated address calculation ports that each calculate (ptr + index*size + const) in the same cycle that the request is issued. Separately, there are almost always unused arithmetic ports such that one could easily double the amount of other arithmetic without adding any additional latency. Address calculation is not a significant performance factor. > So, get to save on fetching and decoding all those > instructions and much of the addressing arithmetic > they would do My argument is that these are almost never a bottleneck, and that removing them altogether will not produce a significant speed up. > If electronically memory is still too slow, then have > interleaved memory -- since the addressing is so simple > and regular, the hardware implementation will know how > to look ahead, much as in speculative execution now > except there will be less or no speculating. Recent generations have been 2-, 3-, or 4-way interleaved. 6-way is promised for a (I think) 2018. Hardware prefetchers are excellent at getting out ahead of just about any regular pattern. The issue is that most software is designed to require unpredictable access patterns, and thus is latency sensitive. > And, in addition, might design the sending of read > commands to main memory not just one at a time but > as a list, boom, and with no more attention, waiting, > synchronizing, hand shaking, the memory delivers all > the data at all the addresses in the list. This is essentially the 'gather' instruction that has been supported in the last 3 generations of Intel processors. It's a single instruction that sends out parallel requests for 8 addresses and returns 8 32-bit values with about the same latency as a single request would take. To an first approximation, it's never used[2] to advantage, because it's no faster than issuing 8 requests serially while being less flexible. Mostly, I'm suggesting that hardware currently supports far more performance than we are getting, because modern software is still designed as it it was running on in-order processors with a flat memory hierarchy. I agree with you that C (and other) compilers could do a better job, but mostly I think the issue is with the mindset of the programmers who are making it. [1] I find that clear and wrong however is almost always preferable to unclear and wrong. And I reiterate: I don't mean this as an attack. [2] I love it in concept, and hope to show that it actually can speed things up on the latest Skylake generation, but until now it's been mostly a bust.