"Thomas F. Burdick" <[EMAIL PROTECTED]> writes:
> On a Sun Blade 100, this takes about 2x as long to run as the C code
> (CMUCL 18d and both gcc and the Sun compiler).
This is interesting. And I also think it is very good. Gcc is fairly
good and widely used and developed. And the Sun compiler is probably
very well targeted.
> I haven't looked
> through the 9 pages of disassembly very carefully yet, on account of
> it's 9 pages, so there might be something obvious I can do.
I know that gcc uses lots of "peephole" optimizations. That is, they
substitute sequences of assembly with other sequences "known" to be
faster. I think that the reason is that in x86 there is a lot more
voodoo available than pipelining and cache-line-filling, like implicit
over-allocation of registers, etc (1).
I remember looking at the disassembles Nicolas posted and noticing a
ton of MOVs. Does python use the newer instruction sets form the later
Intel P* line?
Finally, I think it is clear that you can /say the same/ in Lisp than
in C, and thus the search for a lisp program that is faster than a C
program is just comparing compiler backends. On the other hand you
cannot easily /say everything/ you say in lisp in C. I think also that
any further discussion on this should be held on comp.lang.lisp or
somewhere else, because it's not on topic here.
Mario
---
(1) Carelessly and probably inaccurate quote from a friend of mine who
really knows this stuff.
