a potential lisp convert, and interpreting the shootout
in [Lisp]
|
Prev: Pocket Lisp Machine
Next: Next Generation of Language
From: Juho Snellman on 30 Sep 2006 03:44 Henry Bigelow <hrbigelow(a)gmail.com> wrote: > juho, thanks for your response. i took a look at the benchmarks, and > saw that you'd modified several of them. is this your comment, by the > way, from the spectral-norm benchmark? : > > Note that sbcl is at least 10 times faster than either clisp or gcl > ;; on this program, running with an argument of 500. It would be nice > ;; to know why the others are so slow. > > if so, did you ever figure out the cause of the discrepancy? No, that's not my comment. But different implementations are naturally going to have different performance characteristics. As an obvious example, clisp is a bytecode interpreter. Why would someone expect it to perform as well as a native code compiler on computationally heavy code? Likewise the compiler technology that SBCL uses is completely different from that of GCL. It'd be more surprising if they actually did perform equally well on some program. > i don't > know whether it's true of c or c++ that different compilers can give > drastically different code speeds. It's true, there's just less room for a clever compiler to make a difference over a mediocre one than in Lisp. For example a few years ago Sun released a new version of their C compiler which resulted in a 10x speedup on one of the SpecFP 2000 programs (179.art). It did that by statically detecting a memory access pattern that was unfriendly to caches, and rearranging some loops in the code to make the access pattern more efficient while preserving the same semantics. > it looks like you have a lot of experience. so, benchmark politics > aside, do you find lisp to be fast enough to do heavy-duty computing, > (in my case, a bayesian network with hundreds of nodes and lots of > floating point addition, but also written in a very extensible, > abstract style) Many people seem to find CMUCL and SBCL fast enough for real-world numerical computing. > p.s. what would you say to changing the shootout such that multiple > programs can be submitted, and the results shown based on whatever > selection criteria wanted? Sounds like a horrible idea. You want *more* crappy programs for people to whine about? :-) -- Juho Snellman
From: Jon Harrop on 30 Sep 2006 20:33 Javier wrote: > 2) It is not 100x slower. Please take a look at: > http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=sbcl&lang2=gcc > That demonstrates that, except for some bechmarks in which algorithms > differ a lot, SBCL is almost as fast as C. According to the page you cite SBCL is certainly not "almost as fast as C". Just look at the graph. Moreover, as a HLL, Lisp should be relatively better than C when algorithms are allowed to differ (many algorithms are prohibitively complicated to write in C). -- Dr Jon D Harrop, Flying Frog Consultancy Objective CAML for Scientists http://www.ffconsultancy.com/products/ocaml_for_scientists
From: Henry Bigelow on 1 Oct 2006 11:43 Wade Humeniuk wrote: > Speaking of which. By modifying the original somewhat (I do not have SBCL) > I do not have the patience to code it like C, so.... > wow, thanks wade! i'm going to test this out and compare it to the original too. so far i've just downloaded slime and sbcl and am stumbling my way around it all. what sort of things do you use lisp for, by the way? and do you use other languages too? cheers, henry
From: Henry Bigelow on 1 Oct 2006 12:13 Juho Snellman wrote: > Henry Bigelow <hrbigelow(a)gmail.com> wrote: > > juho, thanks for your response. i took a look at the benchmarks, and > > saw that you'd modified several of them. is this your comment, by the > > way, from the spectral-norm benchmark? : > > > > Note that sbcl is at least 10 times faster than either clisp or gcl > > ;; on this program, running with an argument of 500. It would be nice > > ;; to know why the others are so slow. > > > > if so, did you ever figure out the cause of the discrepancy? > > No, that's not my comment. But different implementations are naturally > going to have different performance characteristics. > As an obvious > example, clisp is a bytecode interpreter. Why would someone expect it > to perform as well as a native code compiler on computationally heavy > code? right. i actually assumed we're talking all native, when comparing speeds. i didn't know that clisp doesn't generate native code! so then i'm not surprised. but, did they mean sbcl native is 10x faster than gcl native, or than gcl bytecode? > > Likewise the compiler technology that SBCL uses is completely > different from that of GCL. It'd be more surprising if they actually > did perform equally well on some program. > > > i don't > > know whether it's true of c or c++ that different compilers can give > > drastically different code speeds. > > It's true, there's just less room for a clever compiler to make a > difference over a mediocre one than in Lisp. that's interesting. it makes intuitive sense that this is the case, but i'd never thought about it. so what's your favorite compiler? more broadly, do you think theoretically, either gcl or sbcl or some other compiler has approached the maximum speed possible, or is there a lot more room for growth? > > For example a few years ago Sun released a new version of their C > compiler which resulted in a 10x speedup on one of the SpecFP 2000 > programs (179.art). It did that by statically detecting a memory > access pattern that was unfriendly to caches, and rearranging some > loops in the code to make the access pattern more efficient while > preserving the same semantics. wow! has anything like that happened with lisp compilers recently? or do you think anything like that is likely to happen? > > > it looks like you have a lot of experience. so, benchmark politics > > aside, do you find lisp to be fast enough to do heavy-duty computing, > > (in my case, a bayesian network with hundreds of nodes and lots of > > floating point addition, but also written in a very extensible, > > abstract style) > > Many people seem to find CMUCL and SBCL fast enough for real-world > numerical computing. > > > p.s. what would you say to changing the shootout such that multiple > > programs can be submitted, and the results shown based on whatever > > selection criteria wanted? > > Sounds like a horrible idea. You want *more* crappy programs for > people to whine about? :-) yes! :) > > -- > Juho Snellman
From: Wade Humeniuk on 1 Oct 2006 12:35
Henry Bigelow wrote: > Wade Humeniuk wrote: >> Speaking of which. By modifying the original somewhat (I do not have SBCL) >> I do not have the patience to code it like C, so.... >> > > wow, thanks wade! You're welcome. The fastest version I have tried (so far) of fannkuch is the algorithm I translated (yesterday) from the GCC entry (most others use the same approach). (defun fannkuch (n) (declare (optimize (speed 3) (safety 0) (debug 0) #+lispworks(fixnum-safety 0)) (type (integer 0 128) n)) (if (< n 1) (return-from fannkuch 0)) (let ((perm (make-array n :element-type '(integer 0 128))) (perml (make-array n :element-type '(integer 0 128))) (count (make-array n :element-type '(integer 0 128))) (flips 0) (flipsmax 0) (r n) (nl (1- n)) (perm0 0) (check 0) (k 0) (i 0)) (declare (type (simple-array (integer 0 128) (*)) perm perml count) (type (integer 0 256) flips flipsmax nl perm0 check k i) (type (integer 0 128) r)) (loop for i from 0 below n do (setf (aref perml i) i)) (loop (when (< check 30) (loop for i from 0 below n do (princ (1+ (aref perml i)))) (terpri) (incf check)) (loop while (> r 1) do (setf (aref count (1- r)) r) (decf r)) (unless (or (= (aref perml 0) 0) (= (aref perml nl) nl)) (setf flips 0) (loop for i fixnum from 0 below n do (setf (aref perm i) (aref perml i))) (setf k (aref perml 0)) (loop while (/= k 0) do (loop for j fixnum downfrom (1- k) for i fixnum from 1 while (< i j) do (rotatef (aref perm i) (aref perm j))) (incf flips) (rotatef k (aref perm k))) (when (< flipsmax flips) (setf flipsmax flips))) (loop do (when (= r n) (return-from fannkuch flipsmax)) (setf i 0 perm0 (aref perml 0)) (loop while (< i r) do (setf k (1+ i) (aref perml i) (aref perml k) i k)) (setf (aref perml r) perm0) (when (> (decf (aref count r)) 0) (loop-finish)) (incf r))))) I finally loaded SBCL 0.9.17 onto one of my FreeBSD machines. On the lowly PIIIx2 500MHz (time (fannkuch 10)) SBCL 0.9.17 3.01s LWL 4.3.7 4.75s gcc 1.80s (from the Shootout Site gcc -O3 -fomit-frame-pointer -march=pentium3) Scaling that to the results on the shootout site puts gcc=0.47, LW=1.24 and SBCL=0.79. Why the shootout site would have removed the previous faster Lisp version is beyond me. Wade > > i'm going to test this out and compare it to the original too. so far > i've just downloaded slime and sbcl and am stumbling my way around it > all. > > what sort of things do you use lisp for, by the way? and do you use > other languages too? > Not anything numerically intensive. Currently at work I use it to write testers/emulators. At home, my first CL program written and delivered as a complete app was... (I did it to learn CL). If you want to learn CL I would suggest you try something non-trivial like that. Nothing like getting your feet wet and to to see how CL makes development so much easier. http://www.download.com/The-Runner-s-Log/3000-2136_4-6893549.html?tag=lst-0-1 Wade |