[racket] Cost of the contract boundary in the math library

I can't recall why exactly now, but there is something about how the
contract system wraps first-order contracts that lets things run
faster.

Robby

On Sat, Nov 3, 2012 at 4:42 PM, Matthias Felleisen <matthias at ccs.neu.edu> wrote:
>
> On Nov 3, 2012, at 1:46 PM, Neil Toronto wrote:
>
>> Higher-order functions, though, are dog slow. In particular, all the array functions are higher-order, because an array is just a function with a rectangular domain; e.g. `array-map' is composition.
>
>
> That's the only thing I am talking about. And your 33x slowdown is what I am afraid of.
>
>
>>
>>> If it is bad, we should consider including both a typed and an untyped
>>> variant where the latter is generated from the former (I believe
>>> you are working in TR so that's why I wrote the last sentence).
>>> That is, when the library is installed the Untyped one should be
>>> generated by disabling types and type checking.
>>
>> We should consider it, then, unless there's a way to significantly speed up a type's generated, higher-order contracts.
>>
>> I'm a bit confused about how this would help, though. The interface between the library and the user will still have to be contracted, so where does the performance gain come from?
>
>
> No, the idea would be that the generate version does NOT use contracts and avoids the cost. -- Matthias
>
>
>
>
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users
>