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

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