[racket] TR memory optimization: 240 Bytes of garbage for calling TR?

On Nov 11, 2012, at 10:36 AM, Sam Tobin-Hochstadt wrote:

> On Sat, Nov 10, 2012 at 11:07 PM, John Clements
> <clements at brinckerhoff.org> wrote:
>> 
>> On Nov 10, 2012, at 7:29 AM, Robby Findler wrote:
>> 
>>> If you're calling from Racket to TR then you have the contract
>>> checking and probably the floats flowing thru there need boxing.
>> 
>> If I understand you correctly, the contract checking would just be "is this a float?" which I imagine wouldn't require additional memory. Certainly the return value would have to be boxed, and that would definitely be eight bytes, I'm guessing.
> 
> There's also the allocation overhead involved in wrapping the
> function, plus probably lots of other places where unboxing is
> inhibited.

When you say "wrapping the function", it sounds like a once-per execution thing, not a once-per-call thing.

Okay, while I've got you, my recollection is that you wrote a bunch of the decompiler. so, in this decompiled definition:

(define-values
     (_comb1)
     (lambda (arg0-117)
       '#(comb1
          #<path:/Users/clements/clements/teaching/csc123-fa12/examples/compiled/reverb-typed.rkt>
          58
          0
          1468
          309
          #f)
       '(flags: preserves-marks single-result)
       '(captures: #%modvars (_d1 _g21 _v1 _m1 _c1))
       (let ((local118
              (#%as-flonum
               (#%flonum
                unsafe-fl+
                (#%flonum flvector-ref _v1 (#%checked _c1))
                (#%flonum unsafe-fl* '0.46 (#%checked _m1))))))
         (let ((local125
                (#%flonum
                 unsafe-fl+
                 (#%flonum unsafe-fl* _g21 (#%from-flonum local118))
                 arg0-117)))
           (begin
             (#%flonum flvector-set! _v1 (#%checked _c1) local125)
             (let ((local133 (#%in add1 (#%checked _c1))))
               (begin
                 (set! (#%checked _c1) (if (#%in <= _d1 local133) '0 local133))
                 (set! (#%checked _m1) (#%from-flonum local118))
                 local125)))))))

... it looks like most of the places where I want to avoid unboxing are already correctly marked with (#%from-flonum...), which the documentation suggests will allow unboxing. It looks to me like the uses of  #%checked could be avoided by some kind of type cleverness, though it's not clear to me whether uses of #%checked are going to cause allocation, or just consume CPU time.

Also; can I assume from the separate presentation of 'comb1'--and the fact that this code doesn't appear anywhere else in the decompiled file--that it hasn't been inlined?

> 
>>> 
>>> Can you put the loop itself into TR?
>> 
>> Sadly, no; the loops themselves are written by students. Or, more specifically, written by students as  a "network" form that expands into a function that's called in a loop. I think that expanding into TR would be incredibly hard to get right.
> 
> I'm not sure why this would be.  Is the code students write unrestricted?

Pretty much, yes. So, for instance, a student might write:

(signal-play 
 (network ()
          [s ((looper song2))]
          [ctr ((loop-ctr 0 1))]
          [on? (toggle ctr)]
          [out (reverb s)]))

where the signals take on float, boolean, or any kind of value. This expands into something containing this "inner loop" procedure:

(lambda ()
  (define s (n1))
  (define ctr (n2))
  (define on? (toggle ctr))
  (define out (reverb s))
  (set! saved-s s)
  (set! saved-ctr ctr)
  (set! saved-on? on?)
  (set! saved-out out)
  out)

It would be pretty hard to assign types any tighter than "any" to these rhs expressions.



Thanks in advance for any advice!

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20121111/05410edc/attachment.p7s>