<div dir="ltr">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<div> </div><div> (-> (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).</div><div> </div><div> Robby On Wed, Dec 11, 2013 at 6:18 PM, Neil Toronto <<a href="mailto:neil.toronto@gmail.com">neil.toronto@gmail.com</a>> 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: > <a href="http://lists.racket-lang.org/dev">http://lists.racket-lang.org/dev</a> > </div></div>