On Tuesday, 12 May 2015 at 10:03:16 UTC, Marco Leise wrote:
Am Tue, 12 May 2015 01:48:57 +0000
schrieb "bachmeier" <n...@spam.net>:
On Monday, 11 May 2015 at 21:15:33 UTC, Dzhon Smit wrote:
Seems this:
--dynamic-space-size 4GB
is pretty important. I don't have that much RAM on my
Chromebook so I removed it. It dies quickly with the error
Heap exhausted during garbage collection: 1408 bytes
available, 2240 requested.
I'm guessing that your code is not doing the same thing as the
D code if you have to use tricks like that just to get it to
run. Having used Common Lisp, I know your program requires
extensive knowledge of the language, and was the result of a
careful optimization exercise - unlike the D code. It's
definitely not the kind of code you'd write after reading
Practical Common Lisp.
I don't know LISP, but I find no trace of appending numbers to
a temporary dynamic array in the LISP code. If so, from an
algorithmic point of view Daniel Kozak's version is the most
spot-on translation of the original.
The idea behind porting code between languages as different as
D and LISP should not be to replicate the computational work
while staying true to the target language. Similar looks wont
get you there.
The main point in posting that was to show that the program
doesn't even run without an SBCL-specific command line option.
I'm not going to dig into this because it's a silly example.
However, my guess is that it has to do with this:
(fib '() (cons last fib))
That creates a new cons each time through. Reserving 4 GB
probably allows the program to avoid the garbage collector.
I'm assuming that the other part of the performance story is this:
(loop :for e :in fib2 :sum e)
where the sum is almost certainly optimized, so the benchmark
doesn't measure the speed of CL anyway, only the ability of the
SBCL compiler developers to write optimized code that covers a
handful of common cases.
