a potential lisp convert, and interpreting the shootout
in [Lisp]
|
Prev: Pocket Lisp Machine
Next: Next Generation of Language
From: Henry Bigelow on 26 Sep 2006 15:41 hi, i am writing to get an idea whether lisp would be useful. so far, i think it would be ideal as a mode of expression, but i'm not sure whether it has (or i would be able to write) memory efficient or sufficiently fast code with it. i have zero lisp experience. i started with perl, then c++, then o'caml. a few days ago i read paul graham's summary of john mccarthy's paper, and then started reading the original, and On Lisp. i'm completely wowed, and would love to use it to write my programs. i'm a bioinformatics student, writing a bayesian network software with a very demanding memory requirement, and potentially long running time for training. it predicts protein structure, and must have hundreds of nodes for each protein, each with a matrix storing relationships between amino acids and structural states. if this is done efficiently, it certainly fits in a 2GB machine. but i'm not sure why certain lisp programs in the shootout are so large. how do i interpret the results of the shootout? for example, lisp fannkuch is 26 times slower than the c version, and lisp chameneos is 120x larger. i'm surprised to see such large discrepancy actually. is it possible to improve on these numbers? so far, the idea of macros and code-as-data and mini-compilers is completely fantastic and foreign to me, and seems to hold much promise for writing code with an eye on memory and speed efficiency. but the shootout isn't encouraging in certain cases. TIA henry chameneos -1.2 -120 1.2 fannkuch -26 -2.5 -1.2 k-nucleotide -8.1 -3.1 1.4 n-body -1.4 -92 -1.2 pidigits -5.7 -51 -1.1 regex-dna 139 -7.7 2.0 300,000 (yay)
From: Paolo Amoroso on 26 Sep 2006 16:03 "Henry Bigelow" <hrbigelow(a)gmail.com> writes: > i'm a bioinformatics student, writing a bayesian network software with See: BioBike http://nostoc.stanford.edu/Docs/ KnowOS: A Knowledge Operating System http://nostoc.stanford.edu/Docs/KnowOS.html Bio-Informatics http://www.cl-user.net/asp/tags/bio-informatics Paolo -- Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film The Common Lisp Directory: http://www.cl-user.net
From: pbunyk on 26 Sep 2006 16:18 Henry Bigelow wrote: > i have zero lisp experience. i started with perl, then c++, then > o'caml. a few days ago i read paul graham's summary of john mccarthy's > paper, and then started reading the original, and On Lisp. i'm > completely wowed, and would love to use it to write my programs. Welcome here! > but i'm not sure why certain lisp programs in the shootout are so > large. how do i interpret the results of the shootout? for example, > lisp fannkuch is 26 times slower than the c version, and lisp chameneos > is 120x larger. It would be useful to post a link to the actual data page -- at least to see what they count as "program size". Unless one does lisp -> C -> executable conversion (which is totally possible with some less popular lisp dialects), I'd assume that resulting lisp executable is a complete image, which would include all of the library AND compiler. > is it possible to improve on these numbers? Minimize consing, use lisp arrays, make sure to declare your variables (to let compiler know what it is allowed to optimize) -- at the end memory requirements should not be much worse with lisp than for C or Fortran (except for the above-mentioned constant additon of having compiler and library "always there", which is a bonus ;-) ). As to speed -- this is the required reading: http://www.flownet.com/gat/papers/lisp-java.pdf ;-) Of course one would want to use compiled version of lisp, check out SBCL... Just my $0.02, Paul B.
From: Javier on 26 Sep 2006 16:38 Henry Bigelow ha escrito: > hi, > > i am writing to get an idea whether lisp would be useful. so far, i > think it would be ideal as a mode of expression, but i'm not sure > whether it has (or i would be able to write) memory efficient or > sufficiently fast code with it. It depends on the implementation you choose, and the plattform you are going to develop for, but it usually is very fast. > i have zero lisp experience. i started with perl, then c++, then > o'caml. a few days ago i read paul graham's summary of john mccarthy's > paper, and then started reading the original, and On Lisp. i'm > completely wowed, and would love to use it to write my programs. Why not first start learning with Practical Common Lisp? On Lisp is more advanced and focused on macros. http://www.gigamonkeys.com/book/ > i'm a bioinformatics student, writing a bayesian network software with > a very demanding memory requirement, and potentially long running time > for training. it predicts protein structure, and must have hundreds of > nodes for each protein, each with a matrix storing relationships > between amino acids and structural states. if this is done > efficiently, it certainly fits in a 2GB machine. Lisp helps you when need to develop complex algorithm and big appliations. > but i'm not sure why certain lisp programs in the shootout are so > large. how do i interpret the results of the shootout? for example, > lisp fannkuch is 26 times slower than the c version, and lisp chameneos > is 120x larger. http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch&lang=sbcl&id=0 120x larger? It ocupes 1.2 more when gziped, but acctually the Lisp version is shorter in number of lines. Take in count that Lisp uses long named statments, for example: (defun call-with-permutations (fun initial-permutation) (call-with-permutations-rec fun initial-permutation (array-dimension initial-permutation 0))) But I believe that the Lisp version is more manteinable and clear to read (once you are used to Lisp, of course). For what I can observe, the Lisp algorith is very different from the C one. If you make it the same way, I'm pretty sure that the SBCL version would be very similar in speed. > i'm surprised to see such large discrepancy actually. I insist: this is due to the difference in selecting the algorith used. Using similar code, SBCL should not be more than 20% slower than C.
From: Javier on 26 Sep 2006 16:44
Henry Bigelow ha escrito: > hi, > > i am writing to get an idea whether lisp would be useful. so far, i > think it would be ideal as a mode of expression, but i'm not sure > whether it has (or i would be able to write) memory efficient or > sufficiently fast code with it. It depends on the implementation you choose, and the plattform you are going to develop for, but it usually is very fast. > i have zero lisp experience. i started with perl, then c++, then > o'caml. a few days ago i read paul graham's summary of john mccarthy's > paper, and then started reading the original, and On Lisp. i'm > completely wowed, and would love to use it to write my programs. Why not first start learning with Practical Common Lisp? On Lisp is more advanced and focused on macros. http://www.gigamonkeys.com/book/ > i'm a bioinformatics student, writing a bayesian network software with > a very demanding memory requirement, and potentially long running time > for training. it predicts protein structure, and must have hundreds of > nodes for each protein, each with a matrix storing relationships > between amino acids and structural states. if this is done > efficiently, it certainly fits in a 2GB machine. Lisp helps you when need to develop complex algorithm and big appliations. > but i'm not sure why certain lisp programs in the shootout are so > large. how do i interpret the results of the shootout? for example, > lisp fannkuch is 26 times slower than the c version, and lisp chameneos > is 120x larger. http://shootout.alioth.debian.org/gp4/benchmark.php?test=fannkuch&lang=sbcl&id=0 120x larger? It ocupes 1.2 more when gziped, but acctually the Lisp version is shorter in number of lines. Take in count that Lisp uses long named statments, for example: (defun call-with-permutations (fun initial-permutation) (call-with-permutations-rec fun initial-permutation (array-dimension initial-permutation 0))) But I believe that the Lisp version is more manteinable and clear to read (once you are used to Lisp, of course). For what I can observe, the Lisp algorith is very different from the C one. If you make it the same way, I'm pretty sure that the SBCL version would be very similar in speed. > i'm surprised to see such large discrepancy actually. I insist: this is due to the difference in selecting the algorith used. Using similar code, SBCL should not be more than 20% slower than C. |