
Intel DDIO, LLC cache, buffer alignment, prefetching, and packet rates - eadler
http://adrianchadd.blogspot.com/2015/04/intel-ddio-llc-cache-buffer-alignment.html
======
ori_b
One thing that I've always wondered was why it seems like most cache line
mappings seem to collide at powers of two -- since so much software uses power
of two sized buffers, it seems like it would be a big win to bucket by some
non power of two size.

~~~
dfox
The point of having less-than-fully-associative cache is that it is both
cheaper and faster than fully-associative one. Using some kind of complex
mapping would require significant additional circuitry, which would certainly
introduce significant additional delay (or even additional clock cycle).

~~~
ori_b
I'm not saying that the cache should be fully associative, I'm saying that
instead of each bucket being a power of two, make it a prime number -- eg, 67
byte cache lines instead of 64, for example, seem to me like they would
prevent quite a bit of aliasing with common data sizes.

There would be more circuitry to divide the addresses. I haven't done too much
with hardware (only some light FPGA experience), so I don't know how much
extra, but it doesn't feel like it would be prohibitive. I could be wrong.

(If you're aware of someone doing analysis on that, I'd be curious to see it
-- I haven't seen any.)

~~~
zerohp
It would be prohibitively slow. Division and modulus are the slowest integer
operations.

~~~
TheLoneWolfling
Correction: Division by arbitrary integer valued variables are the slowest
integer operations.

You can accomplish division by a constant / modulus by a constant without a
full division, however. For example, (x == x % 256 - x * 256), mod 257. That
sort of thing.

------
ramubhai
Processor cache optimisations feel like true fine-art. :)

------
userbinator
Incidentally, unaligned data accesses on x86 CPUs have been basically as fast
as aligned ones in most cases for the past few years:

[http://lemire.me/blog/archives/2012/05/31/data-alignment-
for...](http://lemire.me/blog/archives/2012/05/31/data-alignment-for-speed-
myth-or-reality/)

