3 ms·

> Instead of more cores, give me more ALUs. It kinda didn't work that way though. In practice, all of your ALUs, including your extra ones, were waiting on ca

> Instead of more cores, give me more ALUs. It kinda didn't work that way though. In practice, all of your ALUs, including your extra ones, were waiting on cache fetches or latencies from previous ALU instructions. Modern x86 CPUs have 2-4 ALUs which are dispatched to in parallel 4-5 instructions wide, and these dispatches are aware of cache fetches and previous latencies in real time. VLIW can't compete here. VLIW made sense when main memory was as fast as CPU and all instructions shared the same latency. History hasn't been kind to these assumptions. I doubt we'll see another VLIW arch anytime soon. I accept the idea that x86 is a local minimum, but it's a deep, wide one. Itanium or other VLIW architectures like it were never deep enough to disrupt it.

xscott 7y ago
> In practice, all of your ALUs, including your extra ones, were waiting on cache fetches I think if anyone could get around memory bandwidth problems they would, but for some very interesting and useful algorithms, I can tell you way in advance exactly when I'll need each piece of memory. For these problems, VLIW/EPIC with prefetch instructions would be a win over all the speculation and cleverness. > Itanium or other VLIW architectures like it were never deep enough to disrupt it. History is what it is, but I'm just imagining an alternative timeline where all the effort spent making Pentium/AMD64 fast was pumped into Itanium instead, and compiler writers and language creators got to target an architecture that didn't act like a 64 bit PDP-11.
- zozbot234 7y ago
  Are these sorts of prefetch instructions widely supported in VLIW, though? AIUI, one of the "tricks" the Mill folks had to come up with as part of designing a generally-usable VLIW-like architecture, is making RAM accesses inherently "async", making it easy to statically-schedule other instructions in case the RAM access stalls.
- derefr 7y ago
  Rather than individual-memory-address prefetch instructions, how would you feel about sending a DMA program to a controller on-board a memory DIMM, that would then enable you to send short external commands to the memory that would be translated by the DMA program into custom “vector requests”, to which the memory could respond with long streams of fetch responses—shaped somewhat like the output of a CCD’s shift-register—where this stream of fetch responses would then entirely overwrite the calling CPU’s cache lines with the retrieved values?
derefr 7y ago
Random thought: what’s stopping main memory from being as fast as CPUs (in throughput, not necessarily latency)? TDP? The unwillingness to pay $100s per DIMM?
- pdimitar 7y ago
  Several times in the last months we've seen that various AMD CPUs performed better on certain benchmarks with overclocked RAM. I am not sure the RAM that can help the CPU saturate the transfer channels even exists today.
- marcosdumay 7y ago
  The problem is latency, not throughput. Memories do have the bandwidth to keep the processor caches full, but they can not handle random access. Anyway, you increase throughput by just adding more hardware. That's easy and widely done.
- dfox 7y ago
  As far as throughput is concerned, mostly the idea that there is an DIMM at all. That means that there has to be some wiring between the CPU/MC and actual DRAM array that has manageable number of wires and reasonable RF/EMC characteristics.
  - derefr 7y ago
    The bandwidth between the CPU and the DIMM (and any overhead from ser/des narrowing in the physical signalling layer used to connect the two) is only a constraint if the DIMMs are, to put it in a funny way, RISC—if you have to send them a stream of low-level retrieval requests to describe a high-level piece of state you’d like to know. Which does describe most modern DIMMs, but not all of them. https://en.wikipedia.org/wiki/Content-addressable_memory https://en.wikipedia.org/wiki/Content-addressable_memory (CAM), as used in network switches, isn’t under the same constraints as regular RAM. The requests you make to CAM are CISC—effectively search queries—putting the whole memory-cell array to work at 100% utilization on each bus cycle. But even CAM is still slower than the CPU. Even when it’s on the same SoC package as the CPU, it’s still clocked in such a way that it takes multiple CPU cycles to answer a query. So, at least in this case, bus bandwidth is not “the” constraint.

xscott 7y ago

> In practice, all of your ALUs, including your extra ones, were waiting on cache fetches I think if anyone could get around memory bandwidth problems they would, but for some very interesting and useful algorithms, I can tell you way in advance exactly when I'll need each piece of memory. For these problems, VLIW/EPIC with prefetch instructions would be a win over all the speculation and cleverness. > Itanium or other VLIW architectures like it were never deep enough to disrupt it. History is what it is, but I'm just imagining an alternative timeline where all the effort spent making Pentium/AMD64 fast was pumped into Itanium instead, and compiler writers and language creators got to target an architecture that didn't act like a 64 bit PDP-11.

zozbot234 7y ago
Are these sorts of prefetch instructions widely supported in VLIW, though? AIUI, one of the "tricks" the Mill folks had to come up with as part of designing a generally-usable VLIW-like architecture, is making RAM accesses inherently "async", making it easy to statically-schedule other instructions in case the RAM access stalls.
derefr 7y ago
Rather than individual-memory-address prefetch instructions, how would you feel about sending a DMA program to a controller on-board a memory DIMM, that would then enable you to send short external commands to the memory that would be translated by the DMA program into custom “vector requests”, to which the memory could respond with long streams of fetch responses—shaped somewhat like the output of a CCD’s shift-register—where this stream of fetch responses would then entirely overwrite the calling CPU’s cache lines with the retrieved values?

derefr 7y ago

Random thought: what’s stopping main memory from being as fast as CPUs (in throughput, not necessarily latency)? TDP? The unwillingness to pay $100s per DIMM?

pdimitar 7y ago
Several times in the last months we've seen that various AMD CPUs performed better on certain benchmarks with overclocked RAM. I am not sure the RAM that can help the CPU saturate the transfer channels even exists today.
marcosdumay 7y ago
The problem is latency, not throughput. Memories do have the bandwidth to keep the processor caches full, but they can not handle random access. Anyway, you increase throughput by just adding more hardware. That's easy and widely done.
dfox 7y ago
As far as throughput is concerned, mostly the idea that there is an DIMM at all. That means that there has to be some wiring between the CPU/MC and actual DRAM array that has manageable number of wires and reasonable RF/EMC characteristics.
- derefr 7y ago
  The bandwidth between the CPU and the DIMM (and any overhead from ser/des narrowing in the physical signalling layer used to connect the two) is only a constraint if the DIMMs are, to put it in a funny way, RISC—if you have to send them a stream of low-level retrieval requests to describe a high-level piece of state you’d like to know. Which does describe most modern DIMMs, but not all of them. https://en.wikipedia.org/wiki/Content-addressable_memory https://en.wikipedia.org/wiki/Content-addressable_memory (CAM), as used in network switches, isn’t under the same constraints as regular RAM. The requests you make to CAM are CISC—effectively search queries—putting the whole memory-cell array to work at 100% utilization on each bus cycle. But even CAM is still slower than the CPU. Even when it’s on the same SoC package as the CPU, it’s still clocked in such a way that it takes multiple CPU cycles to answer a query. So, at least in this case, bus bandwidth is not “the” constraint.