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

Oh right! A generalized version of that strategy might work for Neil's
program too.

On Saturday, August 18, 2012, Matthias Felleisen wrote:

>
> Vincent got TR to 'split' complex numbers, if that's what you mean by
> 'wide enough' arguments, and he did so w/o changing R. So perhaps there is
> a way to get the computation on floats and the tag for their meaning.
>
>
>
> On Aug 18, 2012, at 4:13 PM, Robby Findler wrote:
>
> One could, concievably, still do that without boxing/unblocking by passing
> "wide enough" arguments. And it does seem like TR could help with that, but
> IIUC the untyped portion of the compiler needs significant work to support
> that before TR's knowledge of the program would help (But doing a better
> job with structs is, iiuc, a long standing "something could be much better
> here" type of thing.)
>
> On Saturday, August 18, 2012, Matthias Felleisen wrote:
>
>>
>> But don't you need the 'tag' from the struct to distinguish .4 in p from
>> .4 in 1-p? They may be the same number but they denote distinct ideas. --
>> Matthias
>> '
>>
>>
>> On Aug 18, 2012, at 2:40 PM, 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20120818/19a9fc22/attachment.html>