User: Password:
|
|
Subscribe / Log in / New account

The ups and downs of strlcpy()

The ups and downs of strlcpy()

Posted Jul 19, 2012 2:01 UTC (Thu) by Ben_P (guest, #74247)
Parent article: The ups and downs of strlcpy()

I've been told that strcpy on x86 receives some substantial help from hardware; more so than strlcpy and strncpy. Can anyone confirm?


(Log in to post comments)

The ups and downs of strlcpy()

Posted Jul 19, 2012 11:29 UTC (Thu) by cladisch (✭ supporter ✭, #50193) [Link]

x86 has several string instructions that essentially implement mem* functions: rep movs for memcpy(), repne scas for memchr(), rep stos for memset(), and repe cmps for memcmp().

As far as I can see, strcpy(), strncpy(), and strlcpy() could be implemented equally well on top of these primitives.

The ups and downs of strlcpy()

Posted Jul 19, 2012 22:00 UTC (Thu) by nix (subscriber, #2304) [Link]

Halfway so. On x86-64 with a recent enough glibc, there are multiple assembler versions of strcpy() using plain assembler, SSE2 and SSSE3, using the ifunc mechanism to choose between them: strncpy() has almost as many assembler implementations, lacking only a plain assembler one (indeed it uses the same code as strcpy(), with a tiny macro replacement). stpcpy() is similarly optimized. Furthermore, all three of these functions can be expanded inline in some situations by GCC, without calling down to glibc at all.

strlcpy() gets none of this. (However, a countervailing caveat: ome of the assembler implementations are so huge and unrolled that I'm not sure they don't cost more in icache hit than they gain in speed...)

The ups and downs of strlcpy()

Posted Jul 19, 2012 22:04 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

>Furthermore, all three of these functions can be expanded inline in some situations by GCC, without calling down to glibc at all
Quite often that actually _hurts_ the performance, because glibc versions are so über-optimized.

The ups and downs of strlcpy()

Posted Jul 20, 2012 2:45 UTC (Fri) by Ben_P (guest, #74247) [Link]

Hmm, thanks. Do you happen to know if SPARC, Niagara 2's specifically, give strcpy and strncpy similar assistance?

The ups and downs of strlcpy()

Posted Jul 20, 2012 12:54 UTC (Fri) by nix (subscriber, #2304) [Link]

glibc/sysdeps/sparc/sparc32/sparcv9/str*cpy.S redirect to the corresponding files in glibc/sysdeps/sparc/sparc64/, which use the 64-bit SPARC instruction set but do *not* use VIS or other extensions yet. There are VIS-using implementations of memcpy() and memset() in glibc/sysdeps/sparc/sparc64/multiarch/, but nothing similar for string instructions so far. (This is all in glibc trunk.)

Obviously the GCC builtins for strcpy() et al still work.

The ups and downs of strlcpy()

Posted Jul 23, 2012 17:58 UTC (Mon) by BenHutchings (subscriber, #37955) [Link]

David Miller was doing some work on string optimisations on SPARC and more generally a while back; see the March and April 2010 entries in <http://vger.kernel.org/~davem/cgi-bin/blog.cgi/index.html>.

The ups and downs of strlcpy()

Posted Apr 28, 2014 16:56 UTC (Mon) by mirabilos (subscriber, #84359) [Link]

If you want that, *and* if you want to safely use strcpy(), you’d better use memcpy() anyway.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds