To offer another speculative solution, perhaps there could be a variant of Typed Racket structs that are opaque to untyped Racket. If only Typed Racket code is capable of constructing these objects, the types of their contents needn't be checked as they pass between typed and untyped code.
On Friday, May 1, 2015 at 10:08:07 AM UTC-6, Neil Toronto wrote: > Submit a bug report, because that number is obviously false. (Or you've > misunderstood how to use it, in which case the documentation probably > needs work. :D) > > The problem is that first-order polymorphic contracts are O(n) in the > size of the data. See my other, much, much longer reply to Matthias. > > It's a shame, because TR is such a nice language to write data > structures in. > > Neil ⊥ > > On 05/01/2015 12:00 PM, Michael Ballantyne wrote: > > I'm delighted to offer both. Here's a particularly pathological test case: > > > > https://github.com/michaelballantyne/typed-racket-performance > > > > Using a typed/racket/no-check variant of the tr-pfds package makes my > > untyped code run 1275x faster. The feature-profile tool reports that > > in the TR variant "Contracts account(s) for 0.49% of total running > > time", but I'm not sure I believe it. > > > > On Fri, May 1, 2015 at 6:02 AM, Matthias Felleisen <matth...@ccs.neu.edu> > > wrote: > >> > >> What I'd much prefer at the moment over speculative solutions are reports > >> of actual performance bottlenecks. -- Matthias > >> > >> > >> > >> > >> > >> On May 1, 2015, at 1:09 AM, michael.ballantyne wrote: > >> > >>> I've started using Typed Racket several times recently only to flip the > >>> switch to #lang typed/racket/no-check or remove types entirely. Something > >>> like Vincent suggests with an option to write with types and have them > >>> checked but turn off the type-driven optimizer and skip contract checking > >>> at typed/untyped boundaries would be fantastic. > >>> > >>> Having the option to flip this switch either from the code doing the > >>> requiring or at package installation time seems important, regardless of > >>> whether the author of the typed code wrote with that in mind. When I > >>> wanted to use the tr-pfds package from untyped code I had to modify it to > >>> use #lang typed/racket/no-check because the performance hit of contract > >>> checks was massive. > >>> > >>> A raco option to compile and install a package without Typed Racket > >>> optimizations or contracts might be another piece of the solution. > >>> > >>> > >>> On Monday, March 23, 2015 at 1:23:12 PM UTC-6, Robby Findler wrote: > >>>> Just to be sure we are on the same page, my comments were in the > >>>> context of push back that came for reasons that are unclear to me, but > >>>> I think had something to do with the thought that we shouldn't > >>>> compromise the type system. My comments were meant to be in that > >>>> context, trying to point out what the real value of a type system is; > >>>> that is, to give a judgment we can use as a basis for design decisions > >>>> here. > >>>> > >>>> As for smothering: the cost of contracts is "observable enough" (you > >>>> know what I mean) that we cannot just ignore it, as I'm sure you > >>>> agree. And since we do not have an acceptable solution we should > >>>> explore generalizing our support for unsafe operations that we already > >>>> have. It seems to fit very naturally to think of parallel libraries, > >>>> the safe and the unsafe version. > >>>> > >>>> I also like Vincent's idea about coupling the optimizer to the > >>>> contracts as a point worth pragmatic exploration. We shouldn't kid > >>>> ourselves, however, it is still unsafe and programs that turn it on > >>>> can behave in arbitrarily weird ways (when an error is skipped over). > >>>> > >>>> Robby > >>>> > >>>> > >>>> On Mon, Mar 23, 2015 at 2:12 PM, Matthias Felleisen > >>>> <matth...@ccs.neu.edu> wrote: > >>>>> > >>>>> On Mar 20, 2015, at 5:10 PM, Robby Findler > >>>>> <ro...@eecs.northwestern.edu> wrote: > >>>>> > >>>>>> Well, that's already the case if you use the FFI (which lots and lots > >>>>>> of Racket programs do). > >>>>>> > >>>>>> Fundamentally the typechecker is a tool that programmers can choose to > >>>>>> use to make their programs better. It should not try to be more than > >>>>>> that. > >>>>> > >>>>> > >>>>> I think these statements paint an image in broad brushstrokes that > >>>>> some people appreciate properly and some don't. > >>>>> > >>>>> Yes, ffi/unsafe makes Racket programs unsafe. They may introduce > >>>>> causes for segfaults beyond the Racket engine itself. That's not > >>>>> a good thing but ffi/unsafe suggests this problem by its name and > >>>>> I think we try to stick this to a layer where we know it's potentially > >>>>> problematic. > >>>>> > >>>>> Otherwise the goal is to smother the unsafety of the existing software > >>>>> infrastructure. If we don't have such a minimal goal, why bother with > >>>>> Racket (at least from a research perspective)? > >>>>> > >>>>> ;; > >>>>> ---------------------------------------------------------------------- > >>>>> > >>>>> On Mar 23, 2015, at 1:37 PM, Vincent St-Amour <stamo...@ccs.neu.edu> > >>>>> wrote: > >>>>> > >>>>>> Then there's the possibility of turning off the optimizer (makes most > >>>>>> sense for the `#lang` design), which would compromise by avoiding > >>>>>> contracts, but remain as safe as `#lang racket`. There's already a way > >>>>>> to turn off the optimizer (`#:no-optimize`), so that may be redundant. > >>>>> > >>>>> > >>>>> This is an acceptable and pragmatic alternative. It gives the programmer > >>>>> some of the advantages of types (checking, documentation, hooks for > >>>>> tools). > >>>>> And it does not lower the level of safety that Racket aims for. > >>>>> > >>>>> On a more general note: It also exposes the Reynolds insight that types > >>>>> are an inherent part of the meaning (static). As such, compiling uses of > >>>>> first in > >>>>> > >>>>> (: f (-> [List X Y Z] X)) > >>>>> > >>>>> to not check the listness of the argument is intrinsic to > >>>>> __compilation__, > >>>>> not __optimization__. I think the strict use of this guideline would > >>>>> establish > >>>>> another point in our language spectrum. > >>>>> > >>>>> > >>>>> -- Matthias > >>>>> > >>>>> > >>>>> > >> > > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
