3 ms·
>He cherry picks optimizations for the Haskell, such as using Data.Vector.Unboxed instead of the regular lists and removing calls to isLetter Neither of those
by papsosouid 14y ago
>He cherry picks optimizations for the Haskell, such as using Data.Vector.Unboxed instead of the regular lists and removing calls to isLetter
Neither of those complaints are reasonable at all. What is wrong with using Vectors? That is like complaining that a C++ version uses vectors, which it presumably would.
And how is changing a single function call that is unicode aware to one that isn't unfair? How is using getc in the C version unfair?
- TheOsiris 14y agoThe 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 test.
- cgh 14y agoHe 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 agoThe 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 agoAnd that is a valid criticism. The criticisms that were being responded to were not valid.
- dllthomas 14y agoFor 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.