From: Mateusz Guzik > Sent: 30 August 2023 15:03 ... > Hand-rolled mov loops executing in this case are quite pessimal compared > to rep movsq for bigger sizes. While the upper limit depends on uarch, > everyone is well south of 1KB AFAICS and sizes bigger than that are > common. That unrolled loop is pretty pessimal and very much 1980s. It should be pretty easy to write a code loop that runs at one copy (8 bytes) per clock on modern desktop x86. I think that matches 'rep movsq'. (It will run slower on Atom based cpu.) A very simple copy loop needs (using negative offsets from the end of the buffer): A memory read A memory write An increment A jnz Doing all of those every clock is well with the cpu's capabilities. However I've never managed a 1 clock loop. So you need to unroll once (and only once) to copy 8 bytes/clock. So for copies that are multiples of 16 bytes something like: # dst in %rdi, src in %rsi, len in %rdx add %rdi, %rdx add %rsi, %rdx neg %rdx 1: mov %rcx,0(%rsi, %rdx) mov 0(%rdi, %rdx), %rcx add #16, %rdx mov %rcx, -8(%rsi, %rdx) mov -8(%rdi, %rdx), %rcx jnz 1b Is likely to execute an iteration every two clocks. The memory read/write all get queued up and will happen at some point - so memory latency doesn't matter at all. For copies (over 16 bytes) that aren't multiples of 16 it is probably just worth copying the first 16 bytes and then doing 16 bytes copies that align with the end of the buffer - copying some bytes twice. (Or even copy the last 16 bytes first and copy aligned with the start.) I'm also not at all sure how much it is worth optimising mis-aligned transfers. An IP-Checksum function (which only does reads) is only just measurable slower for mis-aligned buffers. Less than 1 clock per cache line. I think you can get an idea of what happens from looking at the PCIe TLP generated for misaligned transfers and assuming that memory requests get much the same treatment. Last time I checked (on an i7-7700) misaligned transfers were done in 8-byte chunks (SSE/AVX) and accesses that crossed cache-line boundaries split into two. Since the cpu can issue two reads/clock not all of the split reads (to cache) will take an extra clock. (which sort of matches what we see.) OTOH misaligned writes that cross a cache-line boundary probably always take a 1 clock penalty. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
