Re: [racket-dev] [plt] Push #27767: master branch updated
At Thu, 14 Nov 2013 20:37:28 -0500, Neil Toronto wrote: For the following program, on my computer, the new random - unsafe-flrandom optimization slows down the first loop and speeds up the second: #lang typed/racket (require math/flonum racket/unsafe/ops) (define g (current-pseudo-random-generator)) (define bx (make-flvector 1)) (for: ([_ (in-range 5)]) (time (for: ([_ (in-range 500)]) (unsafe-flvector-set! bx 0 (random) (newline) (for: ([_ (in-range 5)]) (time (for: ([_ (in-range 500)]) (unsafe-flvector-set! bx 0 (random g) On my machine, both are faster with the new optimization (first one is ~756ms before and ~675 after, second is ~361 before and ~223 after). How big is the slowdown you're seeing on the first one? Unless you're seeing a huge slowdown, I'm not too worried. This new optimization moves work from the runtime to Racket code, so as the JIT gets better, the new version will get better (which is what happened with, e.g., vector bounds checking elimination). (I'm going to speed up the math library's samplers by caching the parameter value and using the new `flrandom', but of course that's a separate issue.) The latest version of Optimization Coach can help you with that. It now reports implicit dereferences of `current-pseudo-random-generator'. Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #27767: master branch updated
On 11/15/2013 11:49 AM, Vincent St-Amour wrote: At Thu, 14 Nov 2013 20:37:28 -0500, Neil Toronto wrote: For the following program, on my computer, the new random - unsafe-flrandom optimization slows down the first loop and speeds up the second: #lang typed/racket (require math/flonum racket/unsafe/ops) (define g (current-pseudo-random-generator)) (define bx (make-flvector 1)) (for: ([_ (in-range 5)]) (time (for: ([_ (in-range 500)]) (unsafe-flvector-set! bx 0 (random) (newline) (for: ([_ (in-range 5)]) (time (for: ([_ (in-range 500)]) (unsafe-flvector-set! bx 0 (random g) On my machine, both are faster with the new optimization (first one is ~756ms before and ~675 after, second is ~361 before and ~223 after). How big is the slowdown you're seeing on the first one? Unless you're seeing a huge slowdown, I'm not too worried. This new optimization moves work from the runtime to Racket code, so as the JIT gets better, the new version will get better (which is what happened with, e.g., vector bounds checking elimination). It's a small one: ~410ms before, ~430 after. (I'm going to speed up the math library's samplers by caching the parameter value and using the new `flrandom', but of course that's a separate issue.) The latest version of Optimization Coach can help you with that. It now reports implicit dereferences of `current-pseudo-random-generator'. Cool! Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
