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

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/aafd8c74/attachment.html>