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 <[email protected]> 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 >>> <[email protected]> wrote: >>>> >>>> On Mar 20, 2015, at 5:10 PM, Robby Findler <[email protected]> >>>> 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 <[email protected]> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
