Comments on: Optimising strlen()

By: inmarket

inmarket — Thu, 18 Jun 2009 01:12:35 +0000

Actually – on some architectures method 1 may be the most efficient. The C compiler could automatically loop unroll (like method 3). The compiler may produce better code from method 1 than method 2 if it supports a double base indirect memory test instruction. The memory cache may pre-read a long word even on byte access and may support multiple byte instructions simultaneously (a common feature on modern processors) thus giving you all the optimisations of the later methods without the code overheads. Remember longer code also means less efficient instruction cache use.
The point of all this is that any optization is COMPLETELY processor dependant and even supposedly obvious optimisations may in-fact slow the routine. The only way to tell is to profile based on a thourough understanding of the processor and memory achitecture.

By: Paul Jakma

Paul Jakma — Mon, 18 May 2009 09:41:11 +0000

colmmac/wolf: Yes, I know about pages and mmap(). They (or analogues) might be very common, but they’re not part of the C spec, and there definitely are machines without. Anyway, it doesn’t matter because that’s not what the code is generally relying on. It’s relying on the longword access to never cause a fault.

So is that assumption safe? Obviously it is if memory access faults are on longword-aligned, page-boundaries. But do machines exist with sub-longword fault or memory-mapping granularity? (E.g. could you have RAM mapped at the bottom of a longword and, say, an I/O port at the top?).

Basically, my question is, I get the impression this code relies on common machine-properties for correctness – not on any guarantees made by C. Am I correct in thinking that?

By: Leonid Volnitsky

Leonid Volnitsky — Thu, 05 Mar 2009 08:30:57 +0000

My some what similar travails in optimizing static sized array:
http://volnitsky.com/project/lvvlib/array.html

By: wolf550e

wolf550e — Thu, 05 Mar 2009 05:56:39 +0000

@paulj: the error you get from reading past the end of a string (or any array) is a page fault. Reading past the array inside the page is completely “kosher” – the processor and the OS can’t help you if you read (or overwrite) a different variable than the one you intended. Only when you are trying to touch a page that’s not yours will you trap (You won’t get an error if the next page is also yours). Anyway, since the error can only happen on page boundary (that’s how the mmu works), and that is usually not less than 4096 bytes (sometimes much more!), while reading a properly null terminated string in word size chunks you will be completely ok. Barring off-by-one bugs, of course.

By: j

Thu, 05 Mar 2009 04:47:14 +0000

> You can’t drag and drop that kind of improvement in an IDE.

But you can get it for free if you use modern libraries or a modern language!

By: colmmacc

colmmacc — Wed, 04 Mar 2009 23:25:02 +0000

@paulj – both pages from mmap should be aligned along word boundaries, and memory on the stack, so it seems safe. If the zero is completely absent then we might get a protection fault, but that’s fair enough. I can’t see any other magic :/

@barryluk true.

By: Justin

Justin — Wed, 04 Mar 2009 23:13:36 +0000

Method 3 reminds me an awful lot of Duff’s device, which is even more fun
http://en.wikipedia.org/wiki/Duff%27s_device

By: baryluk

baryluk — Wed, 04 Mar 2009 22:11:51 +0000

@colmmacc, Actually it’s not tail recurisve.

Proper version:

size_t strlen(const char * str)
strlen(str, 0);

size_t strlen(const char * str, size_t a)
if (!*str)
return a;
else
return strlen(++str,a+1);

By: josh

josh — Wed, 04 Mar 2009 20:45:49 +0000

Eh, my preferred optimization for strlen is to stop calling it so much. Other library functions tend to return a pointer to the beginning of the string, which you already have, rather than the end of the string, even though they typically already have that internally. If you don’t throw that data away, you don’t have to recalculate it.

By: Keith Gaughan

Keith Gaughan — Wed, 04 Mar 2009 20:38:55 +0000

More tests will interfere with pipelines, but there will be less jumping.

That’s pretty much dependent on the machine architecture, mind. For instance, processors, such as the ARM, with predicated instructions don’t have this problem, so it’s hard to squeeze more performance out of a strlen() implementation than this variant of method 3:

; Entry:
; r0 – String pointer
; Exit:
; r0 – Length of the string.
; r1, r2 corrupted.
MOV r1, r0
.loop LDR r2, [r0]
TST r2, #&000000FF
ADDNE r0, r0, #1
TSTNE r2, #&0000FF00
ADDNE r0, r0, #1
TSTNE r2, #&00FF0000
ADDNE r0, r0, #1
TSTNE r2, #&FF000000
ADDNE r0, r0, #1
BNE loop
RSB r0, r1, r0
MOV pc, lr

Mind though, I haven’t written any ARM assembly in some nine years or so, so caveats apply, and that obviously won’t work on a big-endian ARM, and it assumes the string is word-aligned.