December Potpourri #
hacking, December 1st 2011
Features of Common Lisp Abhishek Reddy used to have a page up on the topic, based on Robert Strandh's list. It's been down for a while now, so I rescued a copy from the Wayback Machine and put it up. So: Features of Common Lisp.
Reporting Bugs, Howto. I think it is actually a good thing that I need to say this, because it tends to be a sign of new people in the community, but if you've never read it, go now and read Simon Tatham's How to Report Bugs Effectively.
TL;DR. *sigh* Short version: provide directions to reproduce such that your idiot cousing could follow them while drunk. Don't be afraid of giving too much details. Don't speculate on causes.
Specific hints.
- Use (lisp-implementation-version) to check the version of the Lisp you're actually running.
- Use "uname -a" to get information about the OS and architecture you're running on.
- When providing information, copy-paste as much as possible directly from the terminal or Emacs.
SBCL 1.0.54 due in a few days. This means we're in our monthly freeze, and testing is much appreciated. This month's release contains a lot of changes — including plenty of threading work.
Microbench. A while ago I mentioned a microbenchmarking suite I'd been working on on-again, off-again. It's still not much to look at, and comes with zero documentation — but curious souls can now get it from Github It should work on SBCL, CMUCL, CCL, and Lispworks. Clisp and ACL not tested yet, but a port should be fairly trivial.
What Microbench Is Good For, and Why You Should Not Trust Benchmarks at All. Look here (EDIT: Same on logarithmic scale, per request.). Pay special attention to double-sans-result+ and double-unsafe-sans-result+. When I published some of the results earlier, I was a bit surprised that they didn't perform much better then double+. Then I ran the same benchmarks on CCL and saw it running those two benchmarks 5 times faster!
With a bit of help from Paul Khuong the difference turned out to be in SBCL's loading of floating-point constants, which is heavily optimized for inline-use. I have a pending patch that makes this smarter, the effect of which you can at link see above. (First set is with the patch, second without.)
The moral of "be sure what it is you're really benchmarking" is an old one, but bears repeating. What makes microbenchmarks attractive to me, however — despite their many shortcomings — is that when something turns out slow (in comparison to another implementation, a previous version of SBCL, or another comparable benchmark) is tends to be easier to figure out the cause than with a macrobenchmark.
You probably also noticed that CCL seems to do really badly at inline floating point arithmetic if my benchmarks are to be trusted. They're not. I'm 99% sure this is a case of the something specific in the way those benchmarks are implemented heavily pessimizing them for CCL.