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

Oh, okay. And so if you have a function that accepts a struct, does some
work with it, and then returns a new version of it (and you wanted to
optimize the body of the function), then you could get away with doing
something like 'struct-copy' to make the final version that gets returned.

Robby

On Monday, August 27, 2012, Vincent St-Amour wrote:

> 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<javascript:;>>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120827/09009563/attachment-0001.html>