4 ms·

It's cute. Will I employ similar technique in my own code? Absolutely not. It hinders readability and byte comparison instructions in consecutive memory addres

• lacker 18y ago
  Sure, but... you're not writing glibc. How many computers run that code? At some point, if it's faster and correct, it's worth it.
  • yan 18y ago
    I agree, but I'm sure a gigantic portion of developers never have to worry about this. Also, most architectures have efficient SIMD instructions to handle things like strlen. I'm just curious if the speed-up of this hack was ever benchmarked. Or if anyone spent a while tracking down a source of bottlenecks, and found it to be an inefficient strlen implementation.
    • axod 18y ago
      You could do this on x86 as a single instruction rep scasb Unfortunately though, this is slower than comparing 4 bytes at a time yourself. Working bytes 1 at a time is pretty expensive. 4 at a time is great on a 32 bit cpu (As long as they're aligned).
      • yan 18y ago
        My overall point was that it makes little sense for developers coming up for similar hacks on their own pet projects or apps. This is a linear runtime issue, and the efficiency-speed up here is trivial. Obviously, if you're maintaining gnu's libc, you probably know about this more than I do and in a better position to decide if this is needed, but to Joe Developer, it's just a side-track that obscures the end-goals.
        • scott_s 18y ago
          Someone posted numbers that showed this is a 2x speedup over the naive implementation. That's not "trivial." Most developers don't have to worry about such optimizations. But this is Hacker News, and a lot of hackers do.
          • yan 18y ago
            Point taken, and you're right. The speed-up I was referring to howeverwasn't "strlen speedup" but "your entire app running with naive strlen implementation, vs your entire app with clever strlen." I also wasn't saying this has no place in it. I was trying to add that these hacks aren't usually what makes your app execute twice as fast or feel more 'snappy', unless the bread and butter of your app is string processin (in which case there are better running time algorithms, not just low-level hacks). I love these as much as the next person, but early and misappropriated optimization, in my opinion, is suboptimal as a practice.
            • scott_s 18y ago
              Of course, that's Knuth's warning that "Premature optimization is the root of all evil." I assumed we've all heard that before, and we're only thinking about applying optimizations after measurement.
              • jrg 18y ago
                which is a good time to mention the recent ACM Ubiquity article, "The Fallacy of Premature Optimization" (http://www.acm.org/ubiquity/volume_10/v10i3_hyde.html http://www.acm.org/ubiquity/volume_10/v10i3_hyde.html) by Randall Hyde.
            • whughes 18y ago
              I think you're making a good point, but it's misguided here. We're talking about a 2x speedup for strlen on pretty much every Linux system and probably other systems as well. That's millions of machines. This optimization has probably saved untold amounts of computing time.
      • tptacek 18y ago
        For short strings (the common case), scasb performs the same as a smarter C loop, reduces code size, and saves branches (which is good for caching), which is why most compilers compile strlen to it automatically. But this is kind of a silly point since performant code doesn't call stlen often.
      • tlb 18y ago
        The advantage of 'rep scasb' is that some future version of the intel processor will be more clever and handle a word per cycle. An advantage of optimizing the hell out of the library version is that nobody will be tempted to roll their own string compare in their application code. Slow APIs are terrible because they force application developers to work around them. So the answer isn't just to write something slow, then measure. You'll find performance doesn't matter because everyone has avoided using it.
• tlb 18y ago
  In places where I've done this sort of thing, I prefer #ifdef NO_CLEVER_OPTIMIZATIONS obvious version #else complicated fast version #endif It's good as documentation, good as a test case, and good for isolating weird problems like compiler optimization bugs.
  • path 18y ago
    Agreed, that's a great way to handle the case