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.
