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

[Peter Bex]

On Tue, Apr 07, 2015 at 10:41:32AM +0200, Felix Winkelmann wrote:
> Indeed, I was not trying to make it look otherwise. Apparently Flatt
> and Kawei did an excellent job in optimizing their implementations, no
> doubt about that.

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 ;)

Anyway, if anyone wants to have a crack at it, I've removed the eggs
from the benchmark so that it's a bit easier to run and analyze.  Find
it attached.

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.

> But I'm sick and tired of people throwing badly written code into the
> net and making gross assumptions about implementation performance. The
> possible options, the search-space available is massive and a little
> difference in programming style can make a vast difference in
> performance.

100% true.  However, this seems like a somewhat pathological case of
the "functional programming" approach.  As such, it's a good benchmark
for this type of programming, even if it happens to be a shitty way to
write a raytracer ;)

> 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?

> That there are so many implementors in the Lisp and Scheme community
> probably makes this irrational emphasis on (execution-time)
> performance so apparent in these groups. Or it's the remains of the
> trauma of the AI-Winter, I don't know (and I don't care anymore.)
> 
> That is (among a few other reasons) why I don't do much Scheme or Lisp
> programming anymore - thinking about the community, reading all this
> bullshit makes me sick.

That's very sad, because Scheme is such a nice language.  Besides,
CHICKEN has a nice community so who cares about the trolls?  Anyway,
I'm happy we got a useful new benchmark out of this, and something
to aim for in improving our fantastic compiler.

Cheers,
Peter

raytrace-benchmark.scm
Description: Text document

signature.asc
Description: Digital signature