Beating C with Dyalog APL
ummaycoc.github.io
Beating C with Dyalog APL
1–10 of 57 posts
Re: Beating C with Dyalog APL
#21st comment. Ever. Yes, here in the 23rd century APL has returned to its righteous glory and C is just a few bytes of late 20th century IT(to use your language) history
Re: Beating C with Dyalog APL
#3> Just like Chris Penner’s original article, I’m comparing against the OSX version of wc that shipped with my machine. Just like in the original article, I admit that there are likely faster versions of wc–I’m just comparing what I got.
Could someone on OSX post a benchmark of their system wc vs. one compiled manually from source using gcc or clang with -O3?
Last time around I did this for Ubuntu and found a 2x difference: https://news.ycombinator.com/item?id=21271951
So if this article ends up beating their system wc by 2x, that might not say anything about "beating C".
Re: Beating C with Dyalog APL
#4In the HN thread for the original article, geocar posted one line of q that does the job as well: https://news.ycombinator.com/item?id=21267923
Re: Beating C with Dyalog APL
#5Wow this is a bizarre esolang.
Re: Beating C with Dyalog APL
#6Wow this is a bizarre esolang.
It’s not an esolang. It has a long history of actual real production use.
Re: Beating C with Dyalog APL
#7Perhaps not a fair comparison until you account for the C library's string comparison behaviors. If your default is LANG=C.UTF-8, your wc may be a bunch slower than LANG=C. I think OSX is still using gnu wc, yes? Maybe the Dialog race should be repeated with this controlled for.
https://old.reddit.com/r/programming/comments/1sxpgp/make_gr...
Edit. Still true in Linux today.
$ LANG=C time -p wc /tmp/foo 2>&1 >/dev/null
real 0.29
user 0.28
sys 0.01
$ LANG=C.UTF-8 time -p wc /tmp/foo 2>&1 >/dev/null
real 0.86
user 0.86
sys 0.00Re: Beating C with Dyalog APL
#8In the HN thread for the original article, geocar posted one line of q that does the job as well: https://news.ycombinator.com/item?id=21267923
Beating benchmarks is always fun, but I think the ergonomics of the solution matter a great deal.
That is to say the words we use matter: I'm excited that Haskell, and OCaml (and so on) have efficient solutions, but I'm extremely disappointed that the best implementations look nothing like the "obvious" approach.
Maybe that's to be expected, after all an "obvious" implementation in C that pumps getchar() all day will be pretty slow, and experienced C programmers will do their own buffering and threading to win -- and that doesn't look like the "obvious" one either.
And yet, in k/q the "obvious" implementation is the fast one. That's cool, and way more cool than you might realise as long as you think coding is hard.
Re: Beating C with Dyalog APL
#9but being faster than c is actually trivial and obvious even in the general case...
here is something i crapped out 6 years ago to prove the point: https://github.com/semiessessi/CP1