[racket-dev] [plt] Push #27909: master branch updated
I see that TR's type->contract returns
(-> (flat-named-contract (quote Float) flonum?) (flat-named-contract
(quote Float) flonum?))
for the type (Float -> Float), but it could return
(-> (flat-named-contract (quote Float) flonum?) any)
which wouldn't do any result value checking (this being different from
any/c as the range of the arrow contract).
Robby
On Wed, Dec 11, 2013 at 6:18 PM, Neil Toronto <neil.toronto at gmail.com>
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 ⊥
>
>
> I can't figure out why `flsinh' is faster to call from untyped Racket
than `sinh'. All my tests with a Typed Racket `magnitude' show calls from
untyped code are significantly slower, except in the one case that it
computes Euclidean distance. That case is only twice as slow.
>
> I've attached the benchmark program. The `magnitude*' function is more or
less a direct translation of `magnitude' from "number.c" into Typed Racket.
Here's a summary of the results I get on my computer, in milliseconds, for
5 million calls from untyped Racket, by data type.
>
>
> Function Flonum Rational Fixnum Integer Float-Complex
> -------------------------------------------------------------------
> magnitude* 385 419 378 414 686
> magnitude 59 44 40 40 390
>
>
> The only one that's close in relative terms is Float-Complex. The others
just call `abs'. The decompiled code doesn't show any inlining of
`magnitude', so this comparison should be good.
>
> I'll bet checking the return value contract (which is unnecessary) is the
main slowdown. It has to check for number of values.
>
> 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.
>
> (I managed to make a `magnitude*' with type Number -> AnyValues, but TR
couldn't make a contract for it.)
>
> 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/20131211/a233f0a8/attachment.html>