"Paul F. Dietz" <[EMAIL PROTECTED]> writes: > Nicolas Neuss wrote: > > > Very well put! I'm just getting accustomed to this factor 3:-). A factor > > from 1 upto 2 is due to the compiler backend. And there is another slowing > > down due to goodies like dynamic typing and GC, so that we probably have to > > accept this factor 3 for large applications. > > There's no reason the compiler backend couldn't be just as good > as any other compiler's, except perhaps finite developer time. > What would be most useful in improving CMUCL's code generator?
Off the top of my head, from pet vapourware projects of mine: * A peephole optimizer would remove certain stupid instruction sequences at VOP boundaries; * A more thorough understanding of the differences between subarchitectures, with their different-sized caches and so on; * A smarter register allocator that chooses registers for the innermost, not the outermost, loops; * A less braindead representation chooser (e.g. something that knows to represent an induction variable as an untagged number if it's going to be indexing a string of 8-bit characters); * A structural analysis phase that was, at a minimum, smart enough to be able to do partial-redundancy elimination, and at a maximum do things like replacing case schema with computed goto and/or unroll loops into vector/SIMD operations. There are probably other things, too :-) Cheers, Christophe -- http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757 (set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b))) (defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
