From ... From: Erik Naggum Subject: Re: Java vs. CL speed (Re: Lisp versus C++ for AI. software) Date: 1996/10/04 Message-ID: <3053420345771365@naggum.no>#1/1 X-Deja-AN: 187504743 sender: erik@arcana.naggum.no references: <3250E6C3.3963@eis.uva.es> <3252DB5E.5495@sybase.com> organization: Naggum Software; +47 2295 0313; http://www.naggum.no newsgroups: comp.lang.lisp (Newsgroups trimmed to comp.lang.lisp. Removed newsgroups: comp.ai, comp.ai.genetic, comp.ai.neural-nets, and comp.lang.c++.) [tmb@intentionally.blank-see.headers] (Believed to be Thomas Breuel) | One thing that makes generating efficient numerical Java code so much | easier is that numbers are not objects, so passing them among compiled | functions, including structure accessors, without boxing is easier to | generate code for than in Lisp, where a compiler has to worry about the | possibility of boxed calls. Sadly, all Lisp compilers seem to throw in | the towel in that area, apart from some half-hearted special cases. I have used CLISP, GCL, WCL, and CMUCL extensively. They all represent fixnums as unboxed machine words. With proper declarations, they generate code that neither expects nor returns boxed fixnums. CMUCL is faster for unchecked fixnum-only functions than C is. (That is, when C does not do bignums, does not detect overflow, etc, neither does the Common Lisp code, and the Common Lisp code wins by about 10% in performance.) Methinks you have never actually programmed numerical code in Common Lisp. #\Erik -- I could tell you, but then I would have to reboot you.