[racket] Calling TR modules from Racket modules is slow?

On Jan 6, 2012, at 1:37 PM, Vincent St-Amour wrote:

> At Fri, 6 Jan 2012 13:15:54 -0800,
> John Clements wrote:
>> Welcome to DrRacket, version 5.2.0.7--2012-01-05(fd5e40f/g) [3m].
>> Language: racket/load; memory limit: 256 MB.
>> a million in-module typed adds
>> cpu time: 404 real time: 425 gc time: 273
>> a million untyped adds
>> cpu time: 372 real time: 394 gc time: 212
>> a million untyped->typed adds
>> cpu time: 3763 real time: 3979 gc time: 2077
>> 
>> 
>> ... so in fact, TR is about the same speed as plain-old racket in
>> adding these (even though the plain-old-racket call is across
>> modules);
> 
> Ignoring GC time, TR is faster, but these measurements are very small
> (and GC-dominated) so I don't know how significant they are. That, and
> the bulk of the work is happening in the looping code (which is the
> same in both cases), not in the loop body.
> 
>> I conjecture that racket's optimizer is discovering the same
>> optimizations as TR, here.
> 
> I don't see how it could. There's nothing about the `ut' module that
> could help Racket specialize its addition to floats.
> 
>> However, making a cross-module call to a TR module is *much* slower.
>> Is this because this module-crossing requires a contract check?
> 
> Yes. Both arguments to `float-add' need to be checked for float-ness
> every time the function is called.

Wait... can you clarify this for me? If (as you say) there's nothing about the `ut' module that could help Racket specialize its addition to floats, then why doesn't it take 3.7 seconds, like the one that makes calls to typed racket across the module boundary? Are the contract checks 10x to 100x slower than the corresponding checks inserted by the + primitive? 

John

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4624 bytes
Desc: not available
URL: <http://lists.racket-lang.org/users/archive/attachments/20120110/20252eaa/attachment.p7s>