I've written about my benchmarks and optimization efforts for my UMLisp library. Last month I spent a fair bit of time with Allegro's profiler. I optimized routines which used significant amounts of time. In some cases, this involved rewriting built-in Lisp functions with my own optimized replacements. So, my kmrcl library now has functions like prefixed-fixnum-string. No exactly what I wanted to do, but that optimized routine was many times faster than a frequently used invocation of (format nil "C~7,'0D" id).
Below are the initial and current print benchmarks. While I've previously lamented AllegroCL's speed, AllegroCL is now the fastest on the print benchmark. Its top rating was helped, no doubt, by using its profiler to guide my optimizations.
| Impl | Initial Time | Current Time | Increase |
|---|---|---|---|
| AllegroCL 6.2 | 8.2 | 0.79 | 930% |
| CMUCL 18e+ | 2.2 | 1.25 | 76% |
| Lispworks 4.2.7 | 5.8 | 1.97 | 190% |
| SBCL 0.8.1.30 | 2.8 | 1.64 | 71% |
| SCL 1.1.1 | 5.1 | 1.7 | 200% |
Comments (4)
Don't you mean (format nil "C~7,'0D" id)?
Posted by Paul Dietz | July 13, 2003 9:42 AM
Posted on July 13, 2003 09:42
Yes, I've added the missing comma -- thanks.
Posted by Kevin Rosenberg | July 13, 2003 12:10 PM
Posted on July 13, 2003 12:10
Don't you find that philosophically this is a bad idea? I'd have thought that this is what bug reports to vendors are for: rather than uglifying your own code, make the compiler smarter.
Admittedly, I don't know what the cost to a user of making a support request like this is; but probably the vendors want to know where they're 10 times slower than the competition and where their environments are proving the bottleneck.
Also I concede that there's value in making it fast now, rather than in the next release of whatever Lisp it is; still, you increase the fragility of your own code because of an environmental shortcoming that is by no means universal, and in the software world, it's usually possible to fix the environment.
(oh, and "it's" is not a possessive :-)
Posted by Christophe Rhodes | July 17, 2003 11:51 AM
Posted on July 17, 2003 11:51
Well, yes or no.
I don't expect FORMAT to be fast as the highly optimized, highly specialized function of PREFIXED-FIXNUM-STRING. Also, most of the changes weren't truly uglifactions. As an example, I initially cached the formatting of an object as a computed format control string and a function that produced the values of that object to use with format. That made the work of the printer function a bit harder having to extract two bits of data and then multiple-value-call with format. The new approach avoids format and compiles a sequence of forms to write the object components. while this involves more code in the format compiler, the printer's job is now easier because it just has to funcall the print function with the object and a stream.
The 10x speed on Allegro was due to a number of changes. As far as bug reports go, I agree they have value. I've already worked on this issue with Franz. They recommended using FORMATTER, but I'm happy with the changes that avoided the use of FORMAT.
As for the gratuitous apostrophe: thank's ;-)
Posted by Kevin Rosenberg | July 17, 2003 7:45 PM
Posted on July 17, 2003 19:45