Hi Peter,
Peter Norvig (······@comet.menlo.harlequin.com) wrote:
: Tom Dean has released C++ and Lisp implementations of code for a new
: textbook, available for ftp from bc.aw.com. I thought it would be
: interesting to compare the lines of code for C++ and Lisp.
Well, that's interesting, but do you have any idea about the quality
of the generated code and the speed of the resulting program? Maybe
the students who did the C++ parts optimized the structures used and
didn't use lists and trivial accessor functions for the structures
represented thereby?
I don't know C++, but I find the result amazing!
Joerg Hoehle.
······@inf-wiss.uni-konstanz.de
In article <··········@eurybia.rz.uni-konstanz.de> ······@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle) writes:
Path: info-server.bbn.com!news2.near.net!satisfied.elf.com!wizard.pn.com!Germany.EU.net!zib-berlin.de!news.belwue.de!news.uni-konstanz.de!hoehle
From: ······@inf-wiss.uni-konstanz.de (Joerg-Cyril Hoehle)
Newsgroups: comp.lang.lisp
Date: 9 Feb 1995 18:15:23 GMT
Organization: Information Science, Univ. of Konstanz.
Lines: 18
Distribution: world
References: <····················@comet.menlo.harlequin.com>
X-Newsreader: TIN [version 1.2 PL2]
Hi Peter,
Peter Norvig (······@comet.menlo.harlequin.com) wrote:
: Tom Dean has released C++ and Lisp implementations of code for a new
: textbook, available for ftp from bc.aw.com. I thought it would be
: interesting to compare the lines of code for C++ and Lisp.
Well, that's interesting, but do you have any idea about the quality
of the generated code and the speed of the resulting program? Maybe
the students who did the C++ parts optimized the structures used and
didn't use lists and trivial accessor functions for the structures
represented thereby?
In looking briefly at one example (Discrimination, a discrimination net)
two differences were that a main program and a simple parser had to be
written to read assertions and deductions. The Formula class contained a
queue that was used during parsing, but was otherwise unnecessary. The
Lisp version had none of this code. Thus i suspect that the main
differences were things that helped them in C++ coding which may have a
performance advantage, but they were not done as optimzations.
There was no attempt to optimize the Lisp beyond writing good (hopefully)
algorithms, which is a good way to start. Interestingly, any code
compression comes for functions as there are no macros defined.
I don't know C++, but I find the result amazing!
Well, the results aren't quite as good as Peter reported. In the C++ line
count there were several duplicated files (some as many as 5 times). There
was also 3/4 of a page of a legal comment, and other comments that didn't
always get filtered out. Here are the counts i came up with:
C++
175 Files (including duplicates)
23965 All lines.
9671 Lines of code. (Remove comments and blank lines.)
7190 Non trivial Lines of code (Remove lines containing only "{", "}", or "};"
C++
122 Files (Removed duplicate files.)
17404 All lines.
7450 Lines of code. (No comments or blank lines.)
5437 Nontrivial LOC. (Removed lines containing only "{", "}", or "};".)
Lisp
24 Files
4916 All lines.
2189 Lines of Code
412 Forms (Lines beginning with '^('
Thus if you count duplicate files it is like treating each project in
isolation. Thus the C++/Lisp ration is 3.2 for small projects. Treating
all the files together, as if it were one large project, give a C++/Lisp
ratio of 2.5.
k
--
Ken Anderson
Internet: ·········@bbn.com
BBN ST Work Phone: 617-873-3160
10 Moulton St. Home Phone: 617-643-0157
Mail Stop 6/4a FAX: 617-873-2794
Cambridge MA 02138
USA