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
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 wrote:
> An update on my math-centered tests. The first is the built-in `magnitude'
> vs. a TR near-transliteration of its C implementation, call
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 Float-Complex
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
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 tha
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
wrote:
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 y
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 12,
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 wrote:
> I tried your branch that implements it and saw about 3.5x speedup for the
> `magnitude*' test. This is o
On Thu, Dec 12, 2013 at 1:13 PM, Eric Dobson 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 that, but it requir
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 structs
I tried your branch that implements it and saw about 3.5x speedup for
the `magnitude*' test. This is of course without Robby's recent
first-order contract changes.
(I think it's about 3.5x: I tried with magnitude* : Number -> Any first
and got 2400ms on the easy tests. I changed it to magnitud
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 w
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 d
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
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 clo
> 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
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 12/11/2013 11:07 AM, ro...@racket-lang.org wrote:
robby has updated `master' from 542e256206 to c321f6dd0c.
http://git.racket-lang.org/plt/542e256206..c321f6dd0c
=[ One Commit ]=
Directory summary:
37.6% pkgs/racket-pkgs/racket-tes
19 matches
Mail list logo
