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.<div> </div><div>Robby On Monday, August 27, 2012, Vincent St-Amour wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <<a href="javascript:;" onclick="_e(event, 'cvml', 'stamourv@ccs.neu.edu')">stamourv@ccs.neu.edu</a>> 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: > >> <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> > > > > _________________________ > > Racket Developers list: > > <a href="http://lists.racket-lang.org/dev" target="_blank">http://lists.racket-lang.org/dev</a> </blockquote></div>