Databases
StackOverflow2013
Postsdbo
POWhy would memory access on x86 be slower when aligned to first 4 bytes of the cache line?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhy would memory access on x86 be slower when aligned to first 4 bytes of the cache line?
    primarykey
    data
    text
    <p>In writing a blog post on <a href="http://psy-lob-saw.blogspot.co.uk/2013/01/direct-memory-alignment-in-java.html" rel="nofollow">unaligned/aligned direct memory access</a> I've hit a result I struggle to explain: If my memory access is aligned to the first 4 bytes I see a measurable difference in performance for the worse when data structure fits into L1 cache. In some cases other locations are 20% faster.</p> <p>The article goes into allot more detail about the experiment and method, but here is the summary:</p> <ol> <li>Allocate a block of memory which fits into L1(32k on my laptop, use hwloc/check the spec of your cpu to find out). Align block to cacheline size(usually 64b, check your hardware). The allocation is done upfront and not measured.</li> <li>Iterate over the memory block and write a long(some value) into each cacheline in a given offset(effectively causing an unaligned write if the offset is not a multiple of 8).</li> <li>Iterate over memory block and read from same offset and verify the value is as expected.</li> </ol> <p>Why should there be any difference in performance when offset is 0-3?</p> <p>The essence of the measured code(as per request in comment):</p> <pre><code>for (address = startingAddress; address &lt; limit; address += CACHE_LINE_SIZE) { Unsafe.putLong(address, value); } for (address = startingAddress; address &lt; limit; address += CACHE_LINE_SIZE) { if (Unsafe.getLong(address) != value) throw new RuntimeException(); } </code></pre> <p>Where starting address is cache aligned + offset. Full experiment is available <a href="https://github.com/nitsanw/psy-lob-saw/blob/master/experiments/alignment/UnalignedMemoryAccessCostBenchmark.java" rel="nofollow">here</a>: </p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USNitsan Wakart
    1. USNitsan Wakart
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. POWhy would memory access on x86 be slower when aligned to first 4 bytes of the cache line?
      1. USNitsan Wakart
      1. VTFavorite
    2. VO
      singulars
      1. POWhy would memory access on x86 be slower when aligned to first 4 bytes of the cache line?
      1. UScmc
      1. VTFavorite
    3. VO
      singulars
      1. POWhy would memory access on x86 be slower when aligned to first 4 bytes of the cache line?
      1. USDThought
      1. VTFavorite
    1. COFar too little meat to tell. Show some actual code. Most likely you do not read from where you think you're reading OR your code structure triggers the CPU to perform a speculative read. BTW the pagesize paragraph contained not what I would expect. The term pagesize I know from the context of memory management (PMMU), not IO, which would also make more sense considering the topic.
      singulars
      1. POWhy would memory access on x86 be slower when aligned to first 4 bytes of the cache line?
      1. USDurandal
    2. COThe code is in the post and also on GitHub, I can cut and paste it here if it helps, but was hoping to avoid repeating it in one extra place.
      singulars
      1. POWhy would memory access on x86 be slower when aligned to first 4 bytes of the cache line?
      1. USNitsan Wakart
    3. CO@Durandal How would the code trigger a speculative read from 0-3 byte offset, but not from anywhere else? The term pagesize is not in the question and is indeed not that relevant to it.
      singulars
      1. POWhy would memory access on x86 be slower when aligned to first 4 bytes of the cache line?
      1. USNitsan Wakart
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload