4 ms·

for comparison: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlen.c?rev=1.7;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/src/l

by there 18y ago

for comparison: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlen.c?rev=1.7;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/st...

yan 18y ago
And this is why I read (free|open)bsd's cvsweb repo when I'm curious as to how things are implemented. I used to visit that repo in university when I was bored just to read some clear, concise, well-documented code. I used to use and love FreeBSD (Since switched to OS X as desktop os, still run FreeBSD servers), but OpenBSD source code just looked more approachable. McKusicks' wonderful book and video course helped.
- deleted 18y ago
  [deleted]
henning 18y ago
That's the basic definition you might ask someone to write on a whiteboard in a job interview. How do they stack up in benchmarks? Edit: See other posts in this discussion for actual benchmarks. >_>
tjr 18y ago
http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html http://www.gnu.org/prep/standards/html_node/Reading-Non_002d... Don't in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.) If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can't write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results. For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler).
- scott_s 18y ago
  I'm confused. What are you getting at? The code linked is from OpenBSD, which is under a BSD-style license which is considered GPL compatible.
  - tjr 18y ago
    Possibly the original non-free version was similar to the OpenBSD, or perhaps the GlibC developers took applied this rule where not strictly necessary. Don't know; just offering a potential clue as to why the GNU version is so different.
    - scott_s 18y ago
      When they say "Unix," I think they mean the original, proprietary implementation. I don't think this is the reason why they differ. The BSD implementation is the obvious one. The GNU library version is optimized for a 32-bit processor. Given their domains, that makes sense to me.
dchest 18y ago
You're missing the architecture-dependent implementations. Here's one for i386: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/i386/string/strlen.S?rev=1.3;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/i386...
- tptacek 18y ago
  Note that this doesn't get used on x86-64, where the repne scasb sequence is apparently penalized.
  - dchest 18y ago
    Their x86-64 implementation is in amd64 tree: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/amd64/string/strlen.S?rev=1.1;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/amd6... It uses repne scasb. Comment in x86-65 directory says: "change amd64's MACHINE_ARCH from x86_64 to amd64. There are many many reasons for this, quite a few of them technical, and not all of them in response to Intel's broken ia32e crud. The gcc toolchain stays at x86_64 for now."
    - tptacek 18y ago
      Weird, I wonder why I thought it wasn't. I'll go look. Thanks!
mitchellh 18y ago
The architecture independent versions aside, I'm afraid a lot of people will take from this comment the BSD version is "cleaner" and therefore "better." While it is cleaner, the BSD version requires very many more jumps (4 times more if I remember correctly, I haven't looked at glibc in quite awhile). The glibc version is written in such a way to minimize the jumps in the assembly and therefore produce faster code. Besides reading 4 bytes at a time, it does some clever (and very nontrivial) "magic." But again, all to reduce the number of jumps.

by there 18y ago

for comparison: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/strlen.c?rev=1.7;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string/st...

yan 18y ago

And this is why I read (free|open)bsd's cvsweb repo when I'm curious as to how things are implemented. I used to visit that repo in university when I was bored just to read some clear, concise, well-documented code. I used to use and love FreeBSD (Since switched to OS X as desktop os, still run FreeBSD servers), but OpenBSD source code just looked more approachable. McKusicks' wonderful book and video course helped.

deleted 18y ago
[deleted]

henning 18y ago

That's the basic definition you might ask someone to write on a whiteboard in a job interview. How do they stack up in benchmarks? Edit: See other posts in this discussion for actual benchmarks. >_>

tjr 18y ago

http://www.gnu.org/prep/standards/html_node/Reading-Non_002dFree-Code.html http://www.gnu.org/prep/standards/html_node/Reading-Non_002d... Don't in any circumstances refer to Unix source code for or during your work on GNU! (Or to any other proprietary programs.) If you have a vague recollection of the internals of a Unix program, this does not absolutely mean you can't write an imitation of it, but do try to organize the imitation internally along different lines, because this is likely to make the details of the Unix version irrelevant and dissimilar to your results. For example, Unix utilities were generally optimized to minimize memory use; if you go for speed instead, your program will be very different. You could keep the entire input file in memory and scan it there instead of using stdio. Use a smarter algorithm discovered more recently than the Unix program. Eliminate use of temporary files. Do it in one pass instead of two (we did this in the assembler).

scott_s 18y ago
I'm confused. What are you getting at? The code linked is from OpenBSD, which is under a BSD-style license which is considered GPL compatible.
- tjr 18y ago
  Possibly the original non-free version was similar to the OpenBSD, or perhaps the GlibC developers took applied this rule where not strictly necessary. Don't know; just offering a potential clue as to why the GNU version is so different.
  - scott_s 18y ago
    When they say "Unix," I think they mean the original, proprietary implementation. I don't think this is the reason why they differ. The BSD implementation is the obvious one. The GNU library version is optimized for a 32-bit processor. Given their domains, that makes sense to me.

dchest 18y ago

You're missing the architecture-dependent implementations. Here's one for i386: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/i386/string/strlen.S?rev=1.3;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/i386...

tptacek 18y ago
Note that this doesn't get used on x86-64, where the repne scasb sequence is apparently penalized.
- dchest 18y ago
  Their x86-64 implementation is in amd64 tree: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/amd64/string/strlen.S?rev=1.1;content-type=text%2Fplain http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/arch/amd6... It uses repne scasb. Comment in x86-65 directory says: "change amd64's MACHINE_ARCH from x86_64 to amd64. There are many many reasons for this, quite a few of them technical, and not all of them in response to Intel's broken ia32e crud. The gcc toolchain stays at x86_64 for now."
  - tptacek 18y ago
    Weird, I wonder why I thought it wasn't. I'll go look. Thanks!

mitchellh 18y ago

The architecture independent versions aside, I'm afraid a lot of people will take from this comment the BSD version is "cleaner" and therefore "better." While it is cleaner, the BSD version requires very many more jumps (4 times more if I remember correctly, I haven't looked at glibc in quite awhile). The glibc version is written in such a way to minimize the jumps in the assembly and therefore produce faster code. Besides reading 4 bytes at a time, it does some clever (and very nontrivial) "magic." But again, all to reduce the number of jumps.