[racket] Small and short-lived data structures

From: Konrad Hinsen (konrad.hinsen at fastmail.net)
Date: Tue Oct 22 06:46:43 EDT 2013

Matthias Felleisen writes:

 > You can count on Racket to inline a bunch of such small functions. 
 > You can use Optimization Coach to check on your understanding of
 > what the compiler actually does, and you may benefit from its advice. 

Optimization Coach sounds interesting, I'll install it next time I am
in the free world (raco doesn't work through my lab's http proxy,
unfortunately).

For now I tried decompile to see what happens. I confirm that my vadd
function gets inlined, and also that there is no further useful
optimization in plain Racket.

When I move to Typed Racket, field accesses in structures and element
accesses in vectors are done by "unsafe-..." operations which are
presumably faster because they don't do type and value checks. I
suspect there is no difference in unsafe access performance between a
struct and a vector, since it's the same operation once the checks are
eliminated.

At the bytecode level, it doesn't make a difference which number type
I use for the elements of my struct or vector. Even Fixnum with
operations from unsafe/ops leads to the same code. There's probably a
difference for the JIT, but that's an exploration for another day.

 > Currently, Racket does not perform loop fusion or deforestation
 > for data structures that merely connect loops/functions/etc. 

What I like about this statement is the word "currently" :-)

 > In general, it is a mistaken assumption however that even in a 
 > 'managed' language -- such as Java or Racket -- mutation is still
 > faster than de/allocation of short-lived data structures. If you

I didn't make that assumption. In fact, I didn't even consider any
approach based on mutation. If I wanted to write Fortran code, I'd use
Fortran.

 > I would definitely recommend (1) using Typed Racket and (2) using 
 > the most efficient numbers that we offer in TR. I'd also keep the 
 > entire program in TR. I'd still write code in the most mathematical
 > manner and consult OC to see how to squeeze the most out of this style. 
 > When I found that certain styles don't get optimized the way I expect
 > them to get optimized, I would ask the Racket devs whether they could
 > make improvements so that specific functions/programs work better. 

Thanks for those recommendations, I'll see how far I get. After today's
explorations, I conclude that there's probably no difference between
structs and vectors once I am in the Typed Racket universe, so I'll
stick to structs for now.


Sam Tobin-Hochstadt writes:

 > I encourage you to find some evidence showing that Konrad's assumption
 > is mistaken, then.

It's not mine - but please go ahead figuring out what's best anyway!

Konrad.

Posted on the users mailing list.