6 ms·
Do you have actual benchmarks comparing the the runtimes to justify the competitiveness between the two programs? With no types declared and no optimization dec
by reikonomusha 7y ago
Do you have actual benchmarks comparing the the runtimes to justify the competitiveness between the two programs? With no types declared and no optimization declarations, I feel it would still be around 2-10x slower than C. (I have no quantitative evidence for that feeling though, except that I write Common Lisp in my day job. I have no doubt the program could be within 1-2x of C with appropriate massaging.) That’s certainly “good enough” in most cases, as evidenced by Python running so much of the world.
The blasé attitude toward adhering to POSIX/GNU wc behavior was a bit dissatisfying to me. Those additions are “trivial” and probably don’t change the shape of the program too much, but are nonetheless complicating and time-consuming factors. I would prefer that Lispers strive to complete 100% of the job, not the 80% cut that matters to them. :)
With all that said, I agree with the opinion of the article, being preferable to write Lisp over C, though I would be up-front about the meaning of “beating C”. C has been beat—in my and the author’s opinion—because Lisp strikes an unusually good balance between execution efficiency, speed of development, program safety, and expressiveness. But even better, Lisp lets you push in any of these directions, often with only modest sacrifices in the others.
However, the original spirit of the wc exercise was to make it fast, Benchmarks Game-style.
- verisimilitudes 7y agoI do have some testing that showed me the Common Lisp was roughly the same speed as the C, when testing against a file of a few dozen megabytes. As I explain, I wasn't interested in optimizing it further, as I feel showing this achieved in just a few minutes to be valuable on its own. I also note that a C programmer may boast about being a small fraction of a second faster, ignoring everything else that goes into the program, which I find foolish. The reason I didn't strictly adhere to the POSIX behavior was because I don't know where this is documented and don't feel like scanning through the C to find out. On all of the files I've tested, which include a wide array of punctuation and other such things, the results were identical, but I'm merely not making any promises. I'd prefer to not be accused of being one of those Lispers who only complete part of the program; if you look at the libraries I've written, which actually concern me, then you'll find they're well-documented and rather comprehensive for their purposes.
- reikonomusha 7y agoI think it would be a great addition to the article to show the speed as-is with a couple measurements, then show what popping in a few DECLAREs does.
- threatofrain 7y agoThat data is context for your claims, and we're missing it.
- santoshalper 7y agoSure, but he's not going to provide it because it either (a) doesn't exist or (b) doesn't support his argument.
- fwip 7y agoPOSIX specifications are available here: https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html https://pubs.opengroup.org/onlinepubs/9699919799/idx/utiliti...
- saagarjha 7y agoTIL C99 is part of the POSIX standard…
- fwip 7y agoYeah, there's a number of surprising (but optional) inclusions. c99 is part of the "C-Language Development Utilities" optional group.
- LukeShu 7y agoPOSIX is about compatibility for 2 programming languages: C99 and Bourne Shell. POSIX incorporates the C99 spec by reference, and duplicates much of it (lots of pages say "The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional."), but does not fully include/duplicate the C99 spec.
- jshaqaw 7y agoCan I ask what you do in your day job that you get to write Common Lisp?
- reikonomusha 7y agoI help build quantum computers, and a good chunk of the software is written in Lisp. The quantum compiler and simulator are in Lisp and they’re open source. [1,2] [1] compiler https://github.com/rigetti/quilc https://github.com/rigetti/quilc [2] simulator https://github.com/rigetti/qvm https://github.com/rigetti/qvm
- jshaqaw 7y agoJealous!
- begriffs 7y agoEven supposing they beat the GNU wc, that's not too hard... try beating this one: https://github.com/begriffs/wc https://github.com/begriffs/wc I wrote it in reply to an earlier post, where someone "beat C" with Haskell.
- eMSF 7y agoGNU wc is actually fairly fast for what it does. That being said, even with all the extra stuff it's doing, I'd assume it to perform roughly as well as your single-threaded version (when you use a non-multibyte locale to keep the comparison even remotely fair).
- aqrit 7y agohere you go: https://github.com/expr-fi/fastlwc https://github.com/expr-fi/fastlwc "Beating wc with C"
- begriffs 7y agoThat's awesome, thanks for sharing. :) There's always someone smarter...
- fao_ 7y agoInteresting! Looks like my twc written in the style of Sean Barrell's Lexing paper was beat :) alx@foo:~/Git$ time ./wc/threads 1 twc/big.txt 128457 1095695 6488666 real 0m0.022s user 0m0.022s sys 0m0.000s alx@foo:~/Git$ time ./twc/twc twc/big.txt 128457 1095695 6488666 twc/big.txt real 0m0.037s user 0m0.025s sys 0m0.012s
- igouy 7y ago> Benchmarks Game-style Once upon a time https://salsa.debian.org/benchmarksgame-team/archive-alioth-benchmarksgame/tree/master/contributed-source-code/shootout/wc https://salsa.debian.org/benchmarksgame-team/archive-alioth-... https://web.archive.org/web/20010616231931/http://www.bagley.org/~doug/shootout/bench/wordfreq/ https://web.archive.org/web/20010616231931/http://www.bagley...
- nwallin 7y agoThe author has updated his post with benchmarks. The Lisp version is ~30% slower than the coreutils C version. Which I don't see what the point of the article is then. It's just some guy ranting about his preferences I guess. Which is fine, but like... lead with that.