Re: [racket-dev] TR performance (was: Re: [plt] Push #27909: master branch updated)

[Sam Tobin-Hochstadt]

On Wed, Dec 11, 2013 at 7:25 PM, John Clements
 wrote:
>
> Wow! I had no idea TR was that fast.

In fairness, much of this is that Racket is that fast -- Matthew's put
a lot of work into the JIT over the last few years.

> Related question: how hard is it to reason about the GC behavior of TR code? 
> These numbers suggest to me that it might be possible to write TR code that 
> could be pretty much guaranteed not to collect, and therefore potentially 
> appropriate for use in audio callback functions, where the #1 rule is: NO GC 
> PAUSES.

First, contracts allocate (less after Robby's changes, but still), so
typed/untyped boundaries are bad for GC.

Second, TR doesn't change GC or allocation behavior except if you're
using floating point or complex numbers (where it reduces allocation).
 So you can reason about it similarly to how you'd reason about
untyped Racket code.

Sam

_
  Racket Developers list:
  http://lists.racket-lang.org/dev

[racket-dev] TR performance (was: Re: [plt] Push #27909: master branch updated)

[John Clements]

On Dec 11, 2013, at 4:18 PM, Neil Toronto wrote:

> On 12/11/2013 02:49 PM, Neil Toronto wrote:
>> On 12/11/2013 01:55 PM, Stephen Bloch wrote:
 On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote:
 
> numeric primitives implemented in Typed Racket are faster than the
> same primitives implemented in C.
>>> 
>>> Whoa!  How did that happen?
>> 
>> Whoa! That's not what I meant! O_o
>> 
>> I said "we might be getting close" to that. I haven't tried porting a
>> numeric C primitive to TR yet, but I have a hunch that it'll still be
>> slower. I'll try one now and report what I find.
>> 
>> Neil ⊥
> 

...

> For comparison, here are the timings for running the benchmarks in TR with 
> #:no-optimize:
> 
> 
> Function Flonum  Rational  Fixnum  Integer  Float-Complex
> ---
> magnitude*  45   70*  37 102*   318
> magnitude   61   45   39  91*   394
> 
>  * = unexpectedly high
> 
> 
> Here's what I understand from comparing the numbers:
> 
> * Except for non-fixnum integers, calling `magnitude' in TR is just as fast 
> as in untyped Racket. I have no idea why it would be slower on big integers. 
> That's just weird.
> 
> * Calling `abs' in Racket is faster than calling `scheme_abs' in C, except on 
> rationals and big integers.
> 
> * Operating on flonums in Typed Racket, using generic numeric functions, is 
> faster than doing the same in C.
> 
> Overall, it looks like the TR code is within the same order of magnitude (pun 
> not intended) as the C code. I would love to try this benchmark with either 
> 1) a `magnitude*' with an `AnyValues' return type; or 2) a contract boundary 
> that doesn't check TR's return types for first-order functions.

Wow! I had no idea TR was that fast.

Related question: how hard is it to reason about the GC behavior of TR code? 
These numbers suggest to me that it might be possible to write TR code that 
could be pretty much guaranteed not to collect, and therefore potentially 
appropriate for use in audio callback functions, where the #1 rule is: NO GC 
PAUSES.

John


_
  Racket Developers list:
  http://lists.racket-lang.org/dev