The changes to TR contract generation are now in at HEAD.
If you can find any cases where contracts are still slowing programs
down by a lot I'd like to take a look at them. (Excepting the case of
structs where I know it is still an issue).
On Thu, Dec 12, 2013 at 10:52 AM, Robby Findler
Great, thanks!
It occurred to me this morning that there is probably a significant
slowdown for types that turn into case- instead of just - (due to the
contract system).
I would like to test this hypothesis, but I'm not sure how to. Do you mind
posting a little program, like the ones below that
Here is an example program. You need the step from 0 to 2 because TR
is smart enough to turn (case- (- R) (A - R) (A B - R)) into -*.
#lang racket/load
(module m typed/racket
(provide foo)
(: foo
(case-
(- Symbol)
(Symbol Symbol - Symbol)))
(define (foo [x 'x] [y 'y])
An update on my math-centered tests. The first is the built-in
`magnitude' vs. a TR near-transliteration of its C implementation,
called from *untyped* Racket. The numbers are in milliseconds, for 5
million calls, by input type:
Function Flonum Rational Fixnum Integer
Do any of these functions turn out to have case- contracts by the time TR
gets done with them?
Robby
On Tue, Jan 14, 2014 at 12:22 PM, Neil Toronto neil.toro...@gmail.comwrote:
An update on my math-centered tests. The first is the built-in `magnitude'
vs. a TR near-transliteration of its C
I don't think so. The flonum functions are Flonum - Flonum, and
`magnitude*' is Number - Number.
The best candidate from the math library is probably `mean'.
Neil ⊥
On 01/14/2014 11:24 AM, Robby Findler wrote:
Do any of these functions turn out to have case- contracts by the time
TR gets
Any will always be slow to check for values leaving TR. This is
because we don't statically know how we should protect the value and
have to do expensive runtime checks. Using return types like Number
will definitely see better performance.
The changes shouldn't see too much improvement on
On Thu, Dec 12, 2013 at 1:13 PM, Eric Dobson eric.n.dob...@gmail.com wrote:
The changes shouldn't see too much improvement on structs since struct
contracts are still expensive and I don't think it is possible to
elide them safely with rackets introspection features (but I may be
wrong about
FWIW, my push speeds up the any-wrap/c implementation a bunch. Those two
should have similar speeds after you get that, I guess.
Robby
On Thu, Dec 12, 2013 at 11:03 AM, Neil Toronto neil.toro...@gmail.comwrote:
I tried your branch that implements it and saw about 3.5x speedup for the
any-wrap/c still requires the check for one value, while any (which is
from Number not Any) does not. So I would still guess at Number being
faster, but Robby's changes may make it so that inlining and dead code
elimination can see through everything and turn it into the same code.
On Thu, Dec
Re-reading your message I see that you're not actually asserting something
different from what I said, but just for some precision here I wish to
point out that I wasn't basing my opinion on intuition from the code, but
on some microbenchmark timings. (There was a much more substantial
difference
On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote:
numeric primitives implemented in Typed Racket are faster than the same
primitives implemented in C.
Halleluja!
_
Racket Developers list:
http://lists.racket-lang.org/dev
On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote:
numeric primitives implemented in Typed Racket are faster than the same
primitives implemented in C.
Whoa! How did that happen?
Stephen Bloch
sbl...@adelphi.edu
GPG key at http://home.adelphi.edu/sbloch/sbloch.pubkey.asc
signature.asc
On 12/11/2013 01:55 PM, Stephen Bloch wrote:
On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote:
numeric primitives implemented in Typed Racket are faster than the same
primitives implemented in C.
Whoa! How did that happen?
Whoa! That's not what I meant! O_o
I said we might be getting
On 12/11/2013 02:49 PM, Neil Toronto wrote:
On 12/11/2013 01:55 PM, Stephen Bloch wrote:
On Dec 11, 2013, at 2:36 PM, Neil Toronto wrote:
numeric primitives implemented in Typed Racket are faster than the
same primitives implemented in C.
Whoa! How did that happen?
Whoa! That's not what
I see that TR's type-contract returns
(- (flat-named-contract (quote Float) flonum?) (flat-named-contract
(quote Float) flonum?))
for the type (Float - Float), but it could return
(- (flat-named-contract (quote Float) flonum?) any)
which wouldn't do any result value checking (this being
Removing the return value checking is in the works. It actually is
removing all of the checks that would blame typed code, so higher
order functions/datastructure get improvements too. It is actually
functional the last time I checked, but lacking documentation which is
what is holding up merging
17 matches
Mail list logo
