3 ms·

The unfairness is that he optimizes the Haskell code but then doesn't do the same for the C code and declared Haskell faster. Not what I'd call a reasonable te

• cgh 14y ago
  He profiled both programs and made exactly one optimisation to the Haskell program (removing the call to isLetter). Profiling didn't reveal any obvious C optimisations. So he went with what he had. It all seems pretty reasonable to me. C fans (I am one, by the way) shouldn't get too upset by this. You still aren't going to write an operating system kernel in Haskell.
  • dllthomas 14y ago
    The obvious C optimization is using getc_unlocked and putc_unlocked, which cuts the C run-time in better than half, beating out Haskell by a smidge.
    • papsosouid 14y ago
      And that is a valid criticism. The criticisms that were being responded to were not valid.
      • dllthomas 14y ago
        For sure. The chorus of "Clearly you should be writing your own buffering" has been bugging me - it's not hard but there's a lot of room for an error and you're doing a lot of obfuscating of the code actually solving your problem reimplementing infrastructure that already exists in libc... If you're consuming a single character at a time from a single thread, I don't think you're likely to beat getc_unlocked by much anyway.