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]> 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
