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

I don't think it would be necessary.

For the optimization to trigger, the only thing a step in the chain can
do with its argument is use its components. Anything else (e.g. checking
whether it's a substruct) would require the argument to be boxed, and
would prevent the optimization from happening.

Each step of the chain is very limited in what it can do to its
argument, which works fine for complex numbers (most operations on them
only use the components), but I'm not sure it would work well for
structs.

Vincent


At Mon, 27 Aug 2012 10:15:04 -0500,
Robby Findler wrote:
> 
> Would you need a "and is not a substruct?" predicate to make such things work?
> 
> Robby
> 
> On Mon, Aug 27, 2012 at 10:11 AM, Vincent St-Amour <stamourv at ccs.neu.edu> wrote:
> > 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
> >
> > _________________________
> >   Racket Developers list:
> >   http://lists.racket-lang.org/dev