3 ms·
It's not even close. A per-byte loop is going to be be 4-6 times slower than the 8-byte chunks + a little math shown in the question. Let's say that all the st
by BeeOnRope 7y ago
It's not even close. A per-byte loop is going to be be 4-6 times slower than the 8-byte chunks + a little math shown in the question.
Let's say that all the stars align and you process an entire iteration of the byte-by-byte loop in 1 cycle. On a 4 GHz machine thats ... 4 GB/s. That's paltry compared to main memory bandwidth of 30-100 GB/s [1], not to mention say L1 bandwidth of ~ 256 GB/s (available to a single core).
This idea that everything is memory limited it just false: it's pretty hard to write code efficient enough that it can be limited by memory _bandwidth_ on a single core.
---
[1] Admittedly, a single core can usually only access 20-30 GB/s of that, but that's still >> 4 GB/s.
- bjourne 7y agoDid you benchmark it? I did and found that on a Core-M with MSVC, the optimized strlen beats the naive one by about 20% and on Xeon with gcc, by about 40%. Depending on string length and other parameters. I would expect the difference to be smaller on more recent processors. But without benchmarking I don't think you can say.
- BeeOnRope 7y agoYes, I have benchmarked it in the past which is where I got the 4-6x figure from. Maybe it's worth a revisit, but unless the compiler is doing something special with the byte version, I would be surprised if the speedup was much less. You may have to unroll both to get max speed. If you could share your benchmark I would be interested to look at it.
- bjourne 7y agoBenchmarks are always worth revisits. Mine is here https://github.com/bjourne/c-examples/blob/master/programs/strlen.c https://github.com/bjourne/c-examples/blob/master/programs/s...