Re: [racket-dev] Slow contracts
Oh, sorry: I just meant that it may be useful information if we were to run some micro-benchmarks to determine where the break-even point is between #:lazy and strict for some fairly simple tree type and an untyped program that just walks over the tree, say, twice. I'm imagining measuring the break-even point in size of the tree. If the break-even point is a tree with 10 nodes than I think we'd come to very difficult conclusions than if the break-even point was a tree with 10,000 nodes. Robby On Fri, Jun 13, 2014 at 1:06 AM, Eric Dobson eric.n.dob...@gmail.com wrote: The issue is TR doesn't know statically know how the value will be used, thus we have do the computation for determining the break even point at run time. This puts the actual work in the contract system (or at least the contracts that TR generates), and I don't understand all the internal workings of these. I do believe there are optimizations that we can do, for example unrolling the contract so that only every 5 struct contracts is a lazy chaperone contract. But I have no idea how we could dynamically pick the best unrolling strategy. On Thu, Jun 12, 2014 at 10:20 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Tue, Jun 10, 2014 at 2:27 AM, Eric Dobson eric.n.dob...@gmail.com wrote: On Mon, Jun 9, 2014 at 9:46 PM, Eric Dobson eric.n.dob...@gmail.com wrote: Splitting this out because this is actually a different issue. This is about us generating slow contracts. There are two things in play here. One is that TR doesn't use the new lazy parts of struct/dc. This would require changing struct contracts from flat contracts to chaperone-contracts. Given that I think we are going to need to change struct contracts to sometimes be chaperone contracts anyways for soundness that might not be a huge loss. I did performance measurements and it is about a factor of 60 slower for lazy chaperone contracts. I see a couple of ways to improve these numbers, so they could be better in the future with a bit more work on optimizing. Given that strict contracts actually change the big O notation I think that this is a reasonable performance price to pay, given that data structures with more than 60 elements are fairly common. Does it make sense to try to find the break-even point for a program that, say, makes two passes over the data-structure? Robby _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
Yes, I think this would allow all the optimizations that Eric talked about. Sam On Jun 13, 2014 4:26 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Would it be useful to get blame information back from a value, just like you can currently get the contract back? Robby On Tue, Jun 10, 2014 at 11:53 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: I was thinking of associating the contract with the type from which it comes and no that's not hash-consing. And if it's slower, too bad. -- Matthias On Jun 10, 2014, at 12:47 PM, Eric Dobson eric.n.dob...@gmail.com wrote: On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jun 9, 2014, at 6:02 PM, Eric Dobson eric.n.dob...@gmail.com wrote: Eric, are you talking about changing the proxy values that wrap HO/mutable contracted values? Yes. I want the proxy values to include information about who agreed to the contract in addition to the contract agreed to. I actually realize that I might need more than just the contract agreed to because of how TR changes the generated contract to remove checks for what it guarantees, so that info is not in the contract. But I believe that can be added back as a structure property on the contract. Would some form of hash-consing contracts work here? -- Matthias I don't think so. But not sure exactly what you are proposing. The issue is that there are 4 contracts here and 2 of them currently do not exist at runtime. The 4 are TRs checks/promises on an export/import. (Using import for a value flowing into an exported function). The promise contracts do not currently exist as removing them was my previous optimization (They never fail). What I want to do is change the check on import from (array/c symbol?) to (if/c (protected? (array/c symbol?)) any/c (array/c symbol?)). Where (protected? x/c) checks if TR already promised something stronger than x/c. I believe that you are proposing that we can use the identity of the contract returned by value-contract to determine what the promised contract would have been. This does not work as (Array Symbol) and (Array Float) both get translated to (array/c any/c) for export, and we would want to lookup different promised contracts for them. We could use weak hash map as an extra field but that seems like it would be slow. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Machinery for eliding contracts
You also can't protect against someone using the FFI to fake whatever value you thought was safe. I think your best bet here is to document what you're doing any why you're doing it and then treat uses of some primitive things (like directly constructing blame records in this case) as unsafe operations. Robby On Fri, Jun 13, 2014 at 10:32 AM, Eric Dobson eric.n.dob...@gmail.com wrote: I believe thats what I need for the optimization-half, but I don't think it allows for soundly implementing the optimizations. I still don't see how to test if a value came from TR instead of someone trying to fake that, especially if they can get the blame object from one export and reuse it on a different value. On Fri, Jun 13, 2014 at 6:29 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Okay, I'll push has-blame? and value-blame. Let me know if there are any problems. Robby On Fri, Jun 13, 2014 at 5:59 AM, Sam Tobin-Hochstadt sa...@cs.indiana.edu wrote: Yes, I think this would allow all the optimizations that Eric talked about. Sam On Jun 13, 2014 4:26 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Would it be useful to get blame information back from a value, just like you can currently get the contract back? Robby On Tue, Jun 10, 2014 at 11:53 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: I was thinking of associating the contract with the type from which it comes and no that's not hash-consing. And if it's slower, too bad. -- Matthias On Jun 10, 2014, at 12:47 PM, Eric Dobson eric.n.dob...@gmail.com wrote: On Tue, Jun 10, 2014 at 6:15 AM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Jun 9, 2014, at 6:02 PM, Eric Dobson eric.n.dob...@gmail.com wrote: Eric, are you talking about changing the proxy values that wrap HO/mutable contracted values? Yes. I want the proxy values to include information about who agreed to the contract in addition to the contract agreed to. I actually realize that I might need more than just the contract agreed to because of how TR changes the generated contract to remove checks for what it guarantees, so that info is not in the contract. But I believe that can be added back as a structure property on the contract. Would some form of hash-consing contracts work here? -- Matthias I don't think so. But not sure exactly what you are proposing. The issue is that there are 4 contracts here and 2 of them currently do not exist at runtime. The 4 are TRs checks/promises on an export/import. (Using import for a value flowing into an exported function). The promise contracts do not currently exist as removing them was my previous optimization (They never fail). What I want to do is change the check on import from (array/c symbol?) to (if/c (protected? (array/c symbol?)) any/c (array/c symbol?)). Where (protected? x/c) checks if TR already promised something stronger than x/c. I believe that you are proposing that we can use the identity of the contract returned by value-contract to determine what the promised contract would have been. This does not work as (Array Symbol) and (Array Float) both get translated to (array/c any/c) for export, and we would want to lookup different promised contracts for them. We could use weak hash map as an extra field but that seems like it would be slow. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
