With regards to the measurements; as is obvious from this mailchain, I know about and use the `time` form. It hasn't skewed the results.

Using the optimizing coach in DrRacket has yielded no results, really. I tried using it and there wasn't any advice on what to do for speedups (unless that advice isn't very discoverable, I don't know.).

The only meaningful difference I discovered for TR was using 6.1.1, as apparently there was an optimization that'd been borked for 6.2.0 and onwards.

I'm still curious about speed-ups with TR. I had expected it to perform better than Racket, but I guess the big win is that you get contracts with better performance instead of much faster, brittle code?

On Mon, 24 Aug 2015, Vincent St-Amour wrote:

On Mon, 24 Aug 2015 08:38:46 -0400,
Rickard Andersson wrote:

Yes, that indeed seems to be the problem. However, even after managing
to wrap the types properly, using `divides?` still ended up being a bit
slower. Not dramatically slower, but still noticably and unexpectedly.

As I'm not at all comfortable with Typed Racket I would appreciate if
someone could show how one would annotate the example minimally to give
the optimizer enough information to surpass Racket. As of this moment I
haven't really managed to see any improvement from using Typed
Racket. It cut down the time `divides?` needed to a few seconds more
than Racket. Otherwise, it had no effect (on the other example either).

In general, if you want to ensure that your code "plays nice" with the
Typed Racket optimizer, I recommend you try the optimization coach, in
DrRacket. There should be a button in the toolbar when you're working in
Typed Racket. The coach points out portions of your programs where
additional optimizations could apply if you were to change your program
a bit, and give you advice on how to change it.

The Typed Racket guide also has some general performance advice:

   http://docs.racket-lang.org/ts-guide/optimization.html


As a point of curiosity; I had to work around the fact that apparently
there were not enough type annotations by wrapping the `for`s in
functions
and typing them accordingly. Is there a better way to do this?

Have you tried adding annotations to the `for` forms directly? The docs
show the syntax:

   
http://docs.racket-lang.org/ts-reference/special-forms.html#%28form._%28%28lib._typed-racket%2Fbase-env%2Fprims..rkt%29._for%29%29


I'm currently trying to compare some performance between OCaml, C and
Racket and I'm currently using the aforementioned example.

Here are some timings:

|> time racket divides.rkt; time ./divides_c; time ./divides_ocaml
41666666583333333
racket divides.rkt  7.32s user 0.02s system 100% cpu 7.336 total
41666666583333333
./divides_c  0.49s user 0.00s system 99% cpu 0.488 total
41666666583333333
./divides_ocaml  0.75s user 0.00s system 99% cpu

The idea is to see how fast one can make the following:

#lang racket/base

(define (divisible-by? x d)
  (= (modulo x d)
     0))

(module+ main
  (for/sum ([x (in-range 3 500000000)])
    (if (x . divisible-by? . 3)
      x
      0))
  )

In this particular example, you may get speedups by using Typed Racket's
sub-`Integer` types, such as `Index` or `Fixnum`. These can guarantee to
the typechecker that your code will not generate bignums, which will
allow TR to optimize accordingly.

A note on your particular measurement methodology. When you use unix's
`time` command on `racket x.rkt`, this measures not only the actual
execution time, but also compilation to bytecode and, in the case of
Typed Racket programs, typechecking time as well (which can be
significant). If you run `raco make x.rkt` before measuring, you avoid
measuring that extra overhead. If you also want to avoid measuring the
startup overhead of the Racket VM (which only really matters for short
scripts), you should use the `time` form in Racket, instead of the unix
`time` command.

Vincent


--
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.

Reply via email to