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 > > <[email protected]<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 >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
