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

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Aug 27 11:15:04 EDT 2012

Would you need a "and is not a substruct?" predicate to make such things work?


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

Posted on the dev mailing list.