compare two strings (nul-terminated) other than doing it byte-by-byte? - string

Question

Like strlen() from glibc that performs a nice bit manipulation and 4 bytes checked per time making the function so fast, compared to a byte-by-byte routine as most all others do, is there something like this to compare two strings in assembly? I'm reading some pages on code implementation for C language, very interested in strings-handling part, but I still not found none like this.
I have to make this function as fast possible because it's the heart of my application.(don't recommend hash table)
Any assembler is welcome. But I'm a bit familiar with intel's assembly syntax, if assembly that you'll go to provide is different, please comment it.

Answer 1

You can compare word by word (eg. 32-bits or 64-bits at a time). You just need to be careful not to go past the end of the string. If you are making the strings, then you could pad them with zeroes so they are a multiple of the word size, then you don't even need to check.

Answer 2

Assuming zero terminated strings (although the same applies for memcmp()); the fastest way to do string comparisons in assembly depends on the length/s of the strings, and the specific CPU.
In general; SSE or AVX has a high setup cost but gives faster throughput once it's running, which makes it the best choice if you're comparing very long strings (especially if most of the characters match).
Alternatively, something that does one byte at a time using general purpose registers will typically have a very low setup cost and lower throughput, which makes it the best choice if you're comparing lots of small strings (or even lots of large strings where the first few characters are likely to be different).
If you're doing this for a specific application, then you can determine the average number of characters compared and find the best approach for that average. You can also have different functions for different cases - e.g. implement a strcmp_small() and a strcmp_large() if there's a mixture.
Despite all this, if the performance of string comparisons matters a lot, then it's very likely that the fastest way to compare strings is not comparing strings at all. Basically, the words "I have to make this function as fast possible because it's the heart of my application" should make everyone wonder why better ways of implementing the application aren't possible.

Answer 3

StrCompCase (case sensitive) as implemented in FreshLib/strlib.asm library.
Here is some code that uses dword comparison:
Note, that is first checks the length of the strings. That is because in the mentioned library the strings are length-prefixed, so StrLen is instant O(1) and scanning for termination NULL is provided only as a fall back (see the Second part of this answer).
Comparing lengths before actual comparison allows to make the speed O(1) for different strings, which in case of searching big arrays may significantly improve the performance.
Then the comparison goes on dwords, and, at the end, if the string length is not multiply of 4, the remaining 1..3 bytes are compared byte by byte.
proc StrCompCase, .str1, .str2
begin
push eax ecx esi edi
mov eax, [.str1]
mov ecx, [.str2]
cmp eax, ecx
je .equal
test eax, eax
jz .noteq
test ecx, ecx
jz .noteq
stdcall StrLen, eax
push eax
stdcall StrLen, ecx
pop ecx
cmp eax, ecx
jne .noteq
stdcall StrPtr, [.str1]
mov esi,eax
stdcall StrPtr, [.str2]
mov edi,eax
mov eax, ecx
shr ecx, 2
repe cmpsd
jne .noteq
mov ecx, eax
and ecx, 3
repe cmpsb
jne .noteq
.equal:
stc
pop edi esi ecx eax
return
.noteq:
clc
pop edi esi ecx eax
return
endp
About StrLen code:
Here is the implementation of StrLen.
You can see, that if possible, it uses length prefixed strings, this way making the execution time O(1). If this is not possible it falls back into scanning algorithm that checks 8 bytes per cycle and it pretty fast, but still O(n).
proc StrLen, .hString ; proc StrLen [hString]
begin
mov eax, [.hString]
cmp eax, $c0000000
jb .pointer
stdcall StrPtr, eax
jc .error
mov eax, [eax+string.len]
clc
return
.error:
xor eax, eax
stc
return
.pointer:
push ecx edx esi edi
; align on dword
.byte1:
test eax, 3
jz .scan
cmp byte [eax], 0
je .found
inc eax
jmp .byte1
.scan:
mov ecx, [eax]
mov edx, [eax+4]
lea eax, [eax+8]
lea esi, [ecx-$01010101]
lea edi, [edx-$01010101]
not ecx
not edx
and esi, ecx
and edi, edx
and esi, $80808080
and edi, $80808080
or esi, edi
jz .scan
sub eax, 9
; byte 0 was found: so search by bytes.
.byteloop:
lea eax, [eax+1]
cmp byte [eax], 0
jne .byteloop
.found:
sub eax, [.hString]
clc
pop edi esi edx ecx
return
endp
Note that the zero terminated strings have both performance and security issues.
It is better to use size prefixed strings. For example, the mentioned library uses dynamic strings, where the string contains dword field at offset -4 (string.len in the above code) that contains the current length of the string.

Answer 4

First rule for faster then byte-per-byte comparison is to malloc the strings or .align 16 any constant strings to ensure
robustness against security violations (reading past allocated area)
best alignment for xxm (or 64-bit) processing