Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Destroying C with 20 lines of Haskell: wc

0xd34df00d.me

Post reply on HN
Print view View original

41–50 of 74 posts

Re: Destroying C with 20 lines of Haskell: wc

#41

Post by 0xd34df00d »

notacoward wrote: post #5

This doesn't seem to be comparing anything like the same thing. Does the Haskell version really do the same thing as the C version? Does it handle all of the same error cases, providing the same quality of error messages if they occur? Does it handle localization? If not, that makes the comparison very skewed, as unhammer already pointed out. Sure, if you strip out all of the things that the people who wrote wc actua…

Sup, author here.

> Does the Haskell version really do the same thing as the C version?

It counts bytes, words and lines and, modulo intended Unicode space handling and unintended bugs, does the same thing.

Indeed, it does not count things like max line length or char count, but those can be plugged in without significant performance overhead (and that's what the second part is gonna be about).

> Does it handle all of the same error cases, providing the same quality of error messages if they occur?

There are no error messages at this point. Although I don't really see how this should affect performance.

> Does it handle localization?

If you mean counting multi-byte characters, then not yet. Although I'm pretty convinced it does not require doing something much more complicated — but maybe I'm wrong, we'll see in the next part.

Also, thanks for the feedback, those are important questions! Something to keep in mind when writing subsequent posts.

Re: Destroying C with 20 lines of Haskell: wc

#42

Post by noxToken »

notacoward wrote: post #5

This doesn't seem to be comparing anything like the same thing. Does the Haskell version really do the same thing as the C version? Does it handle all of the same error cases, providing the same quality of error messages if they occur? Does it handle localization? If not, that makes the comparison very skewed, as unhammer already pointed out. Sure, if you strip out all of the things that the people who wrote wc actua…

Off-topic but tangentially related. There was Reddit post[0] about a clothes dryer's eco mode being a scam since it consumes more power than a regular drying cycle. Here[1] is a single comment thread noting that the user was measuring power output of the entire house. The user quickly changed their tune when this was highlighted.

[0]: https://old.reddit.com/r/dataisbeautiful/comments/eyevca/my_...

[1]: https://old.reddit.com/r/dataisbeautiful/comments/eyevca/my_...

Re: Destroying C with 20 lines of Haskell: wc

#43

Post by 0xd34df00d »

jstimpfle wrote: post #23

> So we’ve managed to just smash a C program that was looked at by thousands of eyes of quite hardcore low-level Unix hackers over a few decades. We did this with a handful of lines of pure, mutation-less, idiomatic Haskell, achieving about 4 to 5 times of throughput of the C version and spending less than an hour on all the optimizations. I've done many very arrogant things in my life, because I've been a strange gu…

Those are fairly trivial and well-known optimizations that I did (and I by no means am an expert in writing high-performant code), so all the honors go to GHC authors.

Re: Destroying C with 20 lines of Haskell: wc

#44

Post by ColinWright »

0xd34df00d wrote: post #41
notacoward wrote: post #5

This doesn't seem to be comparing anything like the same thing. Does the Haskell version really do the same thing as the C version? Does it handle all of the same error cases, providing the same quality of error messages if they occur? Does it handle localization? If not, that makes the comparison very skewed, as unhammer already pointed out. Sure, if you strip out all of the things that the people who wrote wc actua…

Sup, author here. > Does the Haskell version really do the same thing as the C version? It counts bytes, words and lines and, modulo intended Unicode space handling and unintended bugs, does the same thing. Indeed, it does not count things like max line length or char count, but those can be plugged in without significant performance overhead (and that's what the second part is gonna be about). > Does it handle all o…

Reproducing what your code does in the most simple, naive C program possible, I can beat the existing wc utility, taking only around 40% of the time that wc takes.

So until you put in locale handling, alternate line endings, option handling, and error handling, I don't see that your post is at all convincing.

Quite the opposite.

So I look forward to a Haskell version that supports everything the wc has so we can get a fair comparison.

Re: Destroying C with 20 lines of Haskell: wc

#45

Post by 0xd34df00d »

mkup wrote: post #7

But how would Haskell version of wc compare with C version of wc running with LC_ALL=C environment variable? UTF-8 locale is much slower than C locale in coreutils, it's a well-known fact, and their Haskell version of wc is already using fixed 8-bit characters.

wc was actually slower with LC_ALL=C as opposed to ru_RU.UTF-8 that my system normally runs with (about 10 s against 7.2 s).

Which actually raises a good question of whether I should have been comparing with that one — but that'd probably raise more questions and lead to more people accusing me of cheating in favour of Haskell.

Re: Destroying C with 20 lines of Haskell: wc

#46

Post by joosters »

iainmerrick wrote: post #39
StavrosK wrote: post #27

Earlier quoted context omitted.

But multiple people have been working full time on wc for decades! At least, if you believe the article.

Decades yes, but who said “full time”?

I've been working full time on 'wc' for only the last five years, since being promoted from full time working on 'cat'.

Once I've wrung every last drop of performance out of wc, I can move on to the next largest limiting factor in GNU performance, 'tail' :-)

Re: Destroying C with 20 lines of Haskell: wc

#47

Post by 0xd34df00d »

bobowzki wrote: post #17

I don't like these "Destroying C" titles.

Me neither. But experience shows that these titles lead to more folks looking at the post, leading to more feedback, leading to better writing/experimenting/etc in the long run.

Also, I was trying to make a reverence to the original post that was "beating C", with the connotation of further improving on that. I'm not a native speaker so my language model might be terribly flawed.

Re: Destroying C with 20 lines of Haskell: wc

#48

Post by _v7gu »

jacobush wrote: post #12
notacoward wrote: post #5

This doesn't seem to be comparing anything like the same thing. Does the Haskell version really do the same thing as the C version? Does it handle all of the same error cases, providing the same quality of error messages if they occur? Does it handle localization? If not, that makes the comparison very skewed, as unhammer already pointed out. Sure, if you strip out all of the things that the people who wrote wc actua…

Does it handle multiple files, and stdin? Anyway, destroying Haskell with 100 lines of C :-) https://raw.githubusercontent.com/gdevic/minix1/master/comma...

Isn't 100 lines too much for a simple utility like wc? I get that it has many edge cases to cover, but edge cases usually require some different handling when you run into them anyway. I'd rather use my one-liner (including calculation in a single pass, and even parallel processing!):

    wc:{sum (({1};ceiling 0.5*sum differ " "=;{1+count x})@\:) peach read0 x}

Re: Destroying C with 20 lines of Haskell: wc

#49

Post by 0xd34df00d »

ColinWright wrote: post #44
0xd34df00d wrote: post #41

Earlier quoted context omitted.

Sup, author here. > Does the Haskell version really do the same thing as the C version? It counts bytes, words and lines and, modulo intended Unicode space handling and unintended bugs, does the same thing. Indeed, it does not count things like max line length or char count, but those can be plugged in without significant performance overhead (and that's what the second part is gonna be about). > Does it handle all o…

Reproducing what your code does in the most simple, naive C program possible, I can beat the existing wc utility, taking only around 40% of the time that wc takes. So until you put in locale handling, alternate line endings, option handling, and error handling, I don't see that your post is at all convincing. Quite the opposite. So I look forward to a Haskell version that supports everything the wc has so we can get…

> So until you put in locale handling, alternate line endings, option handling, and error handling, I don't see that your post is at all convincing.

That's precisely what the second part would be about.

And, if I succeed, IMO, that's where Haskell would really shine (because composability and local reasoning), and where I would be able to claim to achieve something — the stuff in the post we're discussing is indeed trivial (I didn't want to say that in the post itself though as I think it'll look like I'm belittling the guy who did the original post), while modularizing this is _fun_.

Re: Destroying C with 20 lines of Haskell: wc

#50

Post by sauerbraten »

jstimpfle wrote: post #26
jacobush wrote: post #12

Earlier quoted context omitted.

Does it handle multiple files, and stdin? Anyway, destroying Haskell with 100 lines of C :-) https://raw.githubusercontent.com/gdevic/minix1/master/comma...

Do you get a speed-up if you use getc_unlocked() instead of getc()? And if you write your own isspace()? As far as I know, isspace() is locale sensitive.

isspace is defined as a macro at the top of the file, and it's definitely not locale sensitive ;)
Post reply on HN