Talk:CMU Common Lisp

Computing: Software / Free and open-source software Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).
	This article is supported by Free and open-source software (assessed as Low-importance).

"there is no interpreter"?[edit]

I think whoever wrote this was thinking of SBCL. CMUCL compiles to interpreted bytecode as well as native code; SBCL doesn't have bytecode. I don't think the CMUCL bytecode is used for much(I don't have the manual handy, and the site is down.), but it does exist.

Aha, here's the part I was looking for:Byte Coded Compilation--BlakeStone 01:43, 12 August 2005 (UTC)[reply]

Numerical performance[edit]

And it's not just non-assignment based functional languages where you can see supposedly less-efficient high level languages crushing the performance of C/C++. CMU CommonLisp can beat C/C++ on numeric code. There was a paper a few years back documenting it: using a Sun SPARC workstation, if you use the optional type declarations, and write scientific/numeric code in Lisp, using vectors (Lisp arrays) and assignments to implement exactly the same algorithm as C, the CMU CommonLisp code will perform better than C code generated by either the Solaris C compiler or GCC with maximum optimization.[1]

Can't seem to find the paper he references; all the CMUCL benchmarks I've dug up were inter-Lisp implementation benchmarks.