Re: [Chicken-hackers] Any thoughts on performance woes?

[Felix Winkelmann]

> Or maybe there's some small mistake in our implementation that causes
> it to retain too much data.  I'm not sure of course, just theorizing,
> because even though it generates a lot of garbage, my gut says it
> shouldn't need this many major collections.  But my gut has been wrong
> often enough ;)

The allocation-strategy in CHICKEN is rather simple, but retention is
not the problem, as long as data is not held unnecessarily long -
C-o-t-MTA + flat closures is safe-for-space-complexity. It's the
mapping of generic math primitives over lists that allocates in this
particular case. There are ways to optimize for such cases, but it's
not worth the trouble to optimize for bad code, IMHO.

> If anyone wants to add it to the chicken-benchmark repo, I would
> recommend removing the writing of the output file, as that's really
> not where the bottleneck is, and writing a file isn't very nice in a
> benchmark suite.  Also, the "(use extras)" can be removed.  Finally,
> the displaying could be killed as well.

Yes, and please use -O5, even though this doesn't seem to make much of
a difference.

>> I'm a compiler-writer, my job is to be paranoid about performance.
>> But otherwise raw speed is in most cases secondary (try to run large
>> real-world programs on Larceny or Stalin and you know what I mean.)
> 
> Could you elaborate on that?  Does Larceny's compilation time degrade
> on large programs like Stalin does, so you would have to wait for weeks
> for your program to compile, or are you referring to the lack of
> community/infrastructure?

Stalin is full of bugs and doesn't provide enough primitives to do
even the simplest of things. Compile-times are not the real problem,
it just breaks quickly. Larceny is a research compiler, and large
pieces of code will also trigger bugs, at least for the tests I did
(what you usually read is that everybody likes Larceny, but very few
actually use it...)


felix