Chicken backend is unacceptably slow

[plt-amy]

• My hacked-together hash table implementation is really, really terrible. We need to improve it.
• We generate some awful, awful Scheme. Maybe we can improve it?

Some numbers, based on the stuff you can find over at nofact:

% time lua mandelbrot.lua
0.23user 0.01system 0:00.25elapsed 97%CPU (0avgtext+0avgdata 2668maxresident)k
0inputs+0outputs (0major+151minor)pagefaults 0swaps

% time ./amulet.out
1.15user 0.03system 0:01.19elapsed 99%CPU (0avgtext+0avgdata 5028maxresident)k
0inputs+0outputs (0major+4680minor)pagefaults 0swaps

Ouch!

[plt-amy]

New times:

0.41user 0.00system 0:00.41elapsed 99%CPU (0avgtext+0avgdata 5172maxresident)k
0inputs+0outputs (0major+648minor)pagefaults 0swaps

[SquidDev]

Some quick notes, partially taking from Programming for performance on the Chicken wiki.

Backend related

• It might be worth putting type definitions on every binding of a primitive type, and seeing if we get any improvements. We're already using the primitive functions, so Chicken might be able to specialise already, but not sure.

• Compile with -O2 or -O3 when optimisation is enabled. I'm not sure what the default is.

• Try to use some of the graph-based code generation from the Lua backend, so we can eliminate some usages of let/let-values. I don't know if this will actually impact performance at all, as one would hope Chicken is smart enough to optimise this already, but worth trying.

• Can we use something like srfi-136 to define records, instead of a hash table? I'm not sure how the record extension type classes interact with everything else, nor of the performance of these.

Optimiser related

• CSE optimisations for record and reference accesses
• Unboxed records - convert functions which take a record into one taking an unboxed tuple.

[CrazedProgrammer]

This issue should be closed since the Chicken backend has been removed.