krulwich@ils.nwu.edu (Bruce Krulwich) (08/21/90)
In article <9008151749.AA23832@mailhost.samsung.com>, gjc@mitech writes: >Interesting side-note: A company called Chesnut software was at AAAI >showing their LISP->C translator. It was interesting in that it >produced *readable* C code. ... >The disturbing thing was that it seemed to give BETTER performance >than native lisp implementations from the other 3rd-party lisp vendors. >Tells you something about the state of the art of lisp implementation >if such a crude but effective hack as idiomatic LISP->C can do better. I too saw this product and was intrigued. I asked the vendor (who actually seemed to know the technical aspects of the system) why he got a speedup over most LISP's, and his thought was that it was because most LISP systems are written in a system-independant way, while most systems have a C compiler that is heavily optimized in system-specific ways. In other words, more work has gone into making sure the C compiler uses all the fastest machine operations whenever possible, while LISP compiler writers have presumably worried about other things like run-time environment and portability. Bruce Krulwich krulwich@ils.nwu.edu
sinyaw@starbright.sinyaw.EBB.Eng.Sun.COM (Sin-Yaw Wang) (08/22/90)
In article <1438@anaxagoras.ils.nwu.edu> krulwich@ils.nwu.edu (Bruce Krulwich) writes: From: krulwich@ils.nwu.edu (Bruce Krulwich) Date: 21 Aug 90 14:16:20 GMT Lines: 25 In article <9008151749.AA23832@mailhost.samsung.com>, gjc@mitech writes: >Interesting side-note: A company called Chesnut software was at AAAI >showing their LISP->C translator. It was interesting in that it >produced *readable* C code. ... >The disturbing thing was that it seemed to give BETTER performance >than native lisp implementations from the other 3rd-party lisp vendors. >Tells you something about the state of the art of lisp implementation >if such a crude but effective hack as idiomatic LISP->C can do better. I too saw this product and was intrigued. I asked the vendor (who actually seemed to know the technical aspects of the system) why he got a speedup over most LISP's, and his thought was that it was because most LISP systems are written in a system-independant way, while most systems have a C compiler that is heavily optimized in system-specific ways. In other words, more work has gone into making sure the C compiler uses all the fastest machine operations whenever possible, while LISP compiler writers have presumably worried about other things like run-time environment and portability. To speed up your Lisp, or Scheme, code, there must be a way to measure its performance and profile the code. Is there any tool for this purpose? Say I've written a good-sized program, how do I find out where the program is spending its time?
hbs@LUCID.COM (Harlan Sexton) (08/22/90)
In reply to sinyaw@sun.com: To speed up your Lisp, or Scheme, code, there must be a way to measure its performance and profile the code. Is there any tool for this purpose? Say I've written a good-sized program, how do I find out where the program is spending its time? I don't know specifically about Scheme, but a lot of Common Lisp products, including the 4.0 release of Sun Common Lisp, have profiling tools in them. Also, if you are using a Lisp->C translator, most C compilers have a profiling "switch" (and associated library) that you can use. Finally, if you know the stack format for your system and have a timer interrupt (such as the profiling timer interrupt on BSD systems), you can write a backtrace profiler pretty easily that is quite useful. --Harlan
staff@cadlab.sublink.ORG (Alex Martelli) (09/06/90)
krulwich@ils.nwu.edu (Bruce Krulwich) writes: >In article <9008151749.AA23832@mailhost.samsung.com>, gjc@mitech writes: >>Interesting side-note: A company called Chesnut software was at AAAI >>showing their LISP->C translator. It was interesting in that it >>produced *readable* C code. >... >>The disturbing thing was that it seemed to give BETTER performance >>than native lisp implementations from the other 3rd-party lisp vendors. >>Tells you something about the state of the art of lisp implementation >>if such a crude but effective hack as idiomatic LISP->C can do better. >I too saw this product and was intrigued. I asked the vendor (who actually >seemed to know the technical aspects of the system) why he got a speedup >over most LISP's, and his thought was that it was because most LISP systems >are written in a system-independant way, while most systems have a C >compiler that is heavily optimized in system-specific ways. In other words, >more work has gone into making sure the C compiler uses all the fastest >machine operations whenever possible, while LISP compiler writers have >presumably worried about other things like run-time environment and >portability. I am NOT, repeat, NOT surprised at all: indeed I have measured the SAME thing with, of all languages, FORTRAN!!! I have a Fortran program that does 2d fft's on 256x256 complex arrays; running it through the free f2c converter from ATT, and compiling the resulting C, gave me TWICE the performance than just compiling the Fortran source!!! That was on a Sparcstation with the penultimate generation of Sun compilers (i.e., NOT the "Sparcompilers"). It seems to boil down to: the groups doing C compilers (on workstations, at least) are MUCH better at optimizers than all other compiler writers (if it holds for two such languages as LISP and Fortran, it should hold all 'round, shouldn't it now...?-). I have sent the sources to several people who wanted to check, if you want them too just send me E-mail (I don't regularly follow this group). Others have gotten very similar results, though, on (I imagine) completely different programs. Further discussion, if any, to comp.compilers, I guess? -- Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 45, Bologna, Italia Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; Fax: ++39 (51) 366964 (work only; any time of day or night).
lgm@cbnewsc.att.com (lawrence.g.mayka) (09/11/90)
> krulwich@ils.nwu.edu (Bruce Krulwich) writes: > >In article <9008151749.AA23832@mailhost.samsung.com>, gjc@mitech writes: > >>Interesting side-note: A company called Chesnut software was at AAAI > >>showing their LISP->C translator. It was interesting in that it > >>produced *readable* C code. > >... > >>The disturbing thing was that it seemed to give BETTER performance > >>than native lisp implementations from the other 3rd-party lisp vendors. > >>Tells you something about the state of the art of lisp implementation > >>if such a crude but effective hack as idiomatic LISP->C can do better. > > >I too saw this product and was intrigued. I asked the vendor (who actually > >seemed to know the technical aspects of the system) why he got a speedup > >over most LISP's, and his thought was that it was because most LISP systems > >are written in a system-independant way, while most systems have a C > >compiler that is heavily optimized in system-specific ways. In other words, > >more work has gone into making sure the C compiler uses all the fastest > >machine operations whenever possible, while LISP compiler writers have > >presumably worried about other things like run-time environment and > >portability. The literature I've seen indicates that Chestnut's Lisp-to-C translator requires that the entire Common Lisp program be submitted at one time. The translator essentially makes compile-time decisions (e.g., as to the argument list expected by each function) that a genuine Common Lisp implementation has no right to make. Chestnut's product may be very useful in its own right, but I would not classify it as a true Common Lisp system. Kyoto Common Lisp and its progeny, on the other hand, are genuine Common Lisp implementations that happen to use C as an intermediate code representation, primarily for portability reasons. Some such Lisp systems actually perform competitively, but not spectacularly. Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.