4 ms·

Adding a little bit of background here might help. Daniel defines what he means by "lane" in an earlier post: https://lemire.me/blog/2018/11/05/measuring-the-m

by nkurz 8y ago

Adding a little bit of background here might help. Daniel defines what he means by "lane" in an earlier post: https://lemire.me/blog/2018/11/05/measuring-the-memory-level-parallelism-of-a-system-using-a-small-c-program/ https://lemire.me/blog/2018/11/05/measuring-the-memory-level.... Restating, what he's doing is "pointer chasing", which is one of the slowest way of accessing memory because each load is delayed by the full latency of the lookup. Set up an array of random numbers, look up the value at a location, use the value you find as the next array location, then repeat. Because each load is data dependent on the previous, no prefetching is possible. So far, all data reported are for a single core. Each self-contained "pointer chase" is a "lane". To increase the number of lanes, do multiple pointer chases in parallel: lookup up N array values in quick succession on the same core, use the values you find as the next array location for each lane, repeat. You find that up to a point, the total number of "chases" per second increases as you increase the number of lanes. Different processors "plateau" at different levels of parallelism. Intel processors max out at about 10 lanes, which implies that they can keep about 10 requests to RAM "in flight" at a time. This matches the published number of "fill buffers" for the Intel chips. Apple's processors max out at over 20 lanes, saying that they can keep more than 20 requests in flight. Apple hasn't published how many "fill buffers" their chips have, so this is one of the first direct measurements. One of the big questions being asked is: "If increasing the number of requests-in-flight is important to performance, why doesn't Intel just increase the number of fill buffers?" If you have an answer, please let us know, either here, or as a comment on the blog, or in response to Travis's question at RWT: https://www.realworldtech.com/forum/?threadid=181499 https://www.realworldtech.com/forum/?threadid=181499.

davrosthedalek 8y ago
It might be interesting to know if these lanes are per logical core, physical core or CPU. If it's per core, it might be hard to find real-life code using more than 10 lanes outside of micro-benchmarks.
- mooman219 8y ago
  I would bet that Intel has decent statistics on the average number of lanes used, and opted for 10 based on that. Since die space is a premium, they either used the extra space where it's needed more, or shrunk the die by some small amount.
- nicoburns 8y ago
  I'm not an expert (so I could be completely wrong), but I could imagine in-memory data stores being bound by this kind of limit...
  - dragontamer 8y ago
    AMD processors have 44-stores in flight, but only 22-loads in flight. I presume Intel processors have a similar difference between their "store buffers" and their "load buffers".
    - nkurz 8y ago
      I'm not sure if we are using the same terminology, but I think Intel has the opposite arrangement, with more "load buffers" than "store buffers". In Table 2-7. L1 Data Cache Components from https://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf https://www.intel.com/content/dam/doc/manual/64-ia-32-archit..., it says: Sandy Bridge Load buffers 64 entries Store buffers 36 entries Line fill buffers (LFB) 10 entries I think Haswell (and later?) are 72/42/10 per physical(?) core, also with more load than store. How does this match up with what you know about AMD? And do you have a clear number of LFB's (or whatever they call the buffers which are allocated only for L1D misses) for AMD? Edit: I now see the link you gave in your other comment. Hmm. I think numbers you gave do correspond to the inverted ratio numbers for Intel, and I couldn't find any claimed number corresponding to LFB's. We do have a couple AMD machine we test on, and I think we did, but I don't recall the exact numbers, other than a general recollection that they were about about the same as the Intel. In his RWT post, Travis claims Ryzen as having 8-10.
      - dragontamer 8y ago
        > In his RWT post, Travis claims Ryzen as having 8-10. I wonder if they're statically partitioned: so that you only get ~11 per thread on Ryzen when SMT is activated. The AMD Optimization manual is cler that the LS unit handles cache misses. Intel's manual is clear that LFB handles cache misses. Load / store buffers seem to be a more general set of micro-op reordering in general. -------- It appears I've been mistaken btw. Let me post the full text of the section: > The LS unit includes a 44-entry load queue (LDQ). The LDQ receives load operations at dispatch. Loads leave the LDQ when the load has completed and delivered data to the integer unit or the floating-point unit. > The LS unit utilizes a 44-entry store queue which holds stores from dispatch until the store data can be written to the data cache ... > The LS unit can track up to 22 outstanding in-flight cache misses. So that's 44 load queue, 44 store queue, and 22-cache misses for AMD Ryzen. Presumably, this is split somehow in hyperthreads (which would lead to the ~10 number you suggested)
- BeeOnRope 8y ago
  The simple answer is that these lanes (buffers, I prefer to call them) are per logical core. The more complicated answer is that there are a variety of buffers involved in the "path to memory", starting with the core-private buffers between the core and L1 and L2, and moving to socket-shared buffers at the L3, memory controllers and DRAM. In this particular single-threaded test, it is the 10 core-private "line fill buffers" between the L1 and L2 which are the bottleneck, which is where you get the simple answer from. If you ran this test on enough cores at the same time, I would entirely expect the bottlneck to change to one of the shared buffers.
toast0 8y ago
At the end of the day, these requests are going to ram, which fetches one line of memory at a time, per channel. More buffers here, becomes more queuing elsewhere, and means more cache pollution if you mispredict and have to flush the pipeline. Probably real world programs are doing some work with the data they're reading, or their data structures might be more likely to be a little bit contiguous.
- tlb 8y ago
  That's not true, as shown by the benchmarks where 10 lanes makes it go nearly 10x faster. Modern memory systems have a lot of banking and interleaving that allows several requests to be making progress simultaneously.
- BeeOnRope 8y ago
  The time to actually access DRAM itself is actually a relatively small part of the total time. Most of the time is spent getting from the core to the DRAM in the first place. As little as 10ns out of the total of 50 to 100 ns is spent accessing the DRAM itself. So even if the DRAM access was totally serial there is a lot of opportunity in parallelizing the rest of the path. Of course, as a sibling comment pointed out, DRAM access is generally far from serial: you have multiple channels which are inherently parallel, and even within a single channel you can use things like command overlapping to have the DIMM do more than one thing at once. The numbers bear this out: the single serial access pattern in Daniel's test gives me a latency of 80 ns per read on my Skylake client machine, but with a parallelism of about 10 that drops to about 8 ns, so the DRAM subsystem is able serving up a cache line at least every 8 nanoseconds.

by nkurz 8y ago

davrosthedalek 8y ago

It might be interesting to know if these lanes are per logical core, physical core or CPU. If it's per core, it might be hard to find real-life code using more than 10 lanes outside of micro-benchmarks.

mooman219 8y ago
I would bet that Intel has decent statistics on the average number of lanes used, and opted for 10 based on that. Since die space is a premium, they either used the extra space where it's needed more, or shrunk the die by some small amount.
nicoburns 8y ago
I'm not an expert (so I could be completely wrong), but I could imagine in-memory data stores being bound by this kind of limit...
- dragontamer 8y ago
  AMD processors have 44-stores in flight, but only 22-loads in flight. I presume Intel processors have a similar difference between their "store buffers" and their "load buffers".
  - nkurz 8y ago
    I'm not sure if we are using the same terminology, but I think Intel has the opposite arrangement, with more "load buffers" than "store buffers". In Table 2-7. L1 Data Cache Components from https://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-optimization-manual.pdf https://www.intel.com/content/dam/doc/manual/64-ia-32-archit..., it says: Sandy Bridge Load buffers 64 entries Store buffers 36 entries Line fill buffers (LFB) 10 entries I think Haswell (and later?) are 72/42/10 per physical(?) core, also with more load than store. How does this match up with what you know about AMD? And do you have a clear number of LFB's (or whatever they call the buffers which are allocated only for L1D misses) for AMD? Edit: I now see the link you gave in your other comment. Hmm. I think numbers you gave do correspond to the inverted ratio numbers for Intel, and I couldn't find any claimed number corresponding to LFB's. We do have a couple AMD machine we test on, and I think we did, but I don't recall the exact numbers, other than a general recollection that they were about about the same as the Intel. In his RWT post, Travis claims Ryzen as having 8-10.
    - dragontamer 8y ago
      > In his RWT post, Travis claims Ryzen as having 8-10. I wonder if they're statically partitioned: so that you only get ~11 per thread on Ryzen when SMT is activated. The AMD Optimization manual is cler that the LS unit handles cache misses. Intel's manual is clear that LFB handles cache misses. Load / store buffers seem to be a more general set of micro-op reordering in general. -------- It appears I've been mistaken btw. Let me post the full text of the section: > The LS unit includes a 44-entry load queue (LDQ). The LDQ receives load operations at dispatch. Loads leave the LDQ when the load has completed and delivered data to the integer unit or the floating-point unit. > The LS unit utilizes a 44-entry store queue which holds stores from dispatch until the store data can be written to the data cache ... > The LS unit can track up to 22 outstanding in-flight cache misses. So that's 44 load queue, 44 store queue, and 22-cache misses for AMD Ryzen. Presumably, this is split somehow in hyperthreads (which would lead to the ~10 number you suggested)
BeeOnRope 8y ago
The simple answer is that these lanes (buffers, I prefer to call them) are per logical core. The more complicated answer is that there are a variety of buffers involved in the "path to memory", starting with the core-private buffers between the core and L1 and L2, and moving to socket-shared buffers at the L3, memory controllers and DRAM. In this particular single-threaded test, it is the 10 core-private "line fill buffers" between the L1 and L2 which are the bottleneck, which is where you get the simple answer from. If you ran this test on enough cores at the same time, I would entirely expect the bottlneck to change to one of the shared buffers.

toast0 8y ago

At the end of the day, these requests are going to ram, which fetches one line of memory at a time, per channel. More buffers here, becomes more queuing elsewhere, and means more cache pollution if you mispredict and have to flush the pipeline. Probably real world programs are doing some work with the data they're reading, or their data structures might be more likely to be a little bit contiguous.

tlb 8y ago
That's not true, as shown by the benchmarks where 10 lanes makes it go nearly 10x faster. Modern memory systems have a lot of banking and interleaving that allows several requests to be making progress simultaneously.
BeeOnRope 8y ago
The time to actually access DRAM itself is actually a relatively small part of the total time. Most of the time is spent getting from the core to the DRAM in the first place. As little as 10ns out of the total of 50 to 100 ns is spent accessing the DRAM itself. So even if the DRAM access was totally serial there is a lot of opportunity in parallelizing the rest of the path. Of course, as a sibling comment pointed out, DRAM access is generally far from serial: you have multiple channels which are inherently parallel, and even within a single channel you can use things like command overlapping to have the DIMM do more than one thing at once. The numbers bear this out: the single serial access pattern in Daniel's test gives me a latency of 80 ns per read on my Skylake client machine, but with a parallelism of about 10 that drops to about 8 ns, so the DRAM subsystem is able serving up a cache line at least every 8 nanoseconds.