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

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