[racket-dev] Contract barrier inefficiencies

On Sat, Dec 29, 2012 at 3:57 PM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:

>
> On Dec 28, 2012, at 8:04 PM, Robby Findler wrote:
>
> Overall, I feel like some of what you're asking has to do with what TR is
> doing and some with what's going on inside the procedure chaperones and so
> I'm not sure the contract library itself is a place where fixes can happen.
>
>
>
> I think the questions really concern the interaction between TR's
> generation of contracts and contracts themselves:
>
>  1. TR does not seem to exploit as much knowledge as possible when it
> generates contracts.
> Example: (All (a) ((Foo -> a) Foo -> a) seems to be such an example
> (perhaps extreme)
> Where can Foo come from? Why does TR wrap a contract around the domain of
> Foo -> a --
> TR proved that it is applied to Foo if anything. Is TR too aggressive in
> negative positions?
>
>

In this case, the chaperone is necessary, since the "a" means one value
(not multiple), so you cannot eliminate the contract. Sadly.


>  2. Multiple crossings impose the same contracts over and over. BUT 'same'
> is not necessarily
> expressed as eq?. Can the contract library do better here? Is the 'inner
> loop' assumption
> wrong?
>
>
The contract system has support for comparing contracts in a useful way for
this (contract-stronger?). The problem Neil ⊥ identified is that the values
that go thru them are rarely eq? so checking the contracts that are on the
values isn't helpful since they've changed just enough to avoid being able
to detect that the are the "same" value.

At least that's what I understood from him.


>  3. And then there seems to be a chaperone question, though I don't
> understand that one.
>
>
>
What I meant was that the runtime system has much smoother paths in place
for calling a function than for calling a function with a chaperone on it.
And so when Neil uses the profiler to try to find the time difference, he's
not seeing anything because the time is invisible to the profiler: it is
all being taken up by the slow path for calling a function with a chaperone
on it.

But thinking a little bit more about this: I think that maybe we're seeing
a slightly distored picture on this last point. The functions that Neil was
using in his examples didn't do anything and normally functions would do
something, so the cost for this point is exaggerated as compared to what
would happen in a real program.

Robby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121229/78ef4bb0/attachment.html>