[racket-dev] TR's optimizer eventually going to unbox structs?

TR's complex number optimizations eliminate repeated boxing and unboxing
in chains of operations that each consume and produce complex numbers.

Similar optimizations for structs would eliminate structs for
intermediate results in chains of operations that each consume and
produce that same (single) kind of struct.

If your code has such chains of operations, then these optimizations
could apply.

Do you have code that you think would benefit that I could look at?

Vincent


At Sat, 18 Aug 2012 12:40:21 -0600,
Neil Toronto wrote:
> 
> Is TR's optimizer eventually going to unbox structs in the same way it 
> unboxes rectangular flonums?
> 
> I have a design choice right now: how to represent probabilities. Floats 
> are good because of their speed, but because of floating-point 
> limitations, *four different representations* are typically used. (For 
> the curious: p, 1-p, log(p), and log(1-p).) I'd like to make functions 
> that accept any one of these representations, denoted by this type:
> 
>    (define-type Probability
>      (U probability 1-probability log-probability log-1-probability))
> 
> The types are simply struct types that tag Float.
> 
> Of course, manually boxing flonums ruins any chance of the compiler 
> emitting code that keeps the flonums unboxed. If TR's optimizer unboxed 
> structs, though, everything could be speedy.
> 
> FWIW, by "eventually," I mean "within the next n years", where "n" is a 
> smallish number.
> 
> Neil ⊥
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev