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
Re: [racket-dev] [plt] Push #27767: master branch updated
On 11/14/2013 03:22 PM, stamo...@racket-lang.org wrote: stamourv has updated `master' from 44f810aa72 to a87dcc252e. http://git.racket-lang.org/plt/44f810aa72..a87dcc252e =[ 4 Commits ]== Directory summary: 20.3% pkgs/contract-profile/ 39.5% pkgs/typed-racket-pkgs/typed-racket-lib/typed-racket/optimizer/ 20.9% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/missed-optimizations/ 17.2% pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/ ~~ 0dccecc Vincent St-Amour stamo...@racket-lang.org 2013-11-12 17:40 : | Clarify impedance mismatch between profiler and blame info. : M pkgs/contract-profile/boundary-view.rkt | 15 --- ~~ 04eeeb1 Vincent St-Amour stamo...@racket-lang.org 2013-11-13 18:24 : | Log hidden prng parameter dereferences. : M .../typed-racket-lib/typed-racket/optimizer/hidden-costs.rkt | 8 ~~ 7616e26 Vincent St-Amour stamo...@racket-lang.org 2013-11-14 11:04 : | Add types and optimizations for flrandom and unsafe-flrandom. : A pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/tests/flrandom.rkt M .../typed-racket/base-env/base-env-numeric.rkt | 3 +++ M .../typed-racket/optimizer/float.rkt | 19 ++- M .../typed-racket/optimizer/hidden-costs.rkt| 4 ~~ a87dcc2 Vincent St-Amour stamo...@racket-lang.org 2013-11-14 14:11 : | Log non-optimized fixnum-specific ops as hidden costs. : M .../optimizer/missed-optimizations/fixnum.rkt | 6 +++--- M .../optimizer/tests/fixnum-bounded-expr.rkt | 8 M .../optimizer/tests/invalid-fxquotient.rkt | 2 +- A pkgs/typed-racket-pkgs/typed-racket-test/tests/typed-racket/optimizer/missed-optimizations/fixnum-no-bound.rkt M .../typed-racket/optimizer/fixnum.rkt | 18 -- =[ Overall Diff ]=== 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) IOW, it appears the optimization only helps when passing in a pseudo-random generator. I suspected this might be the case when I ran a bunch of tests of the math library's sampling algorithms and some of them were a hair slower after updating my Racket repo. The only reason I can think of that this would be the case is if the built-in's parameter retrieval is faster. Anyhow, changing (random) to (unsafe-flrandom (current-pseudo-random-generator)) looks like a pessimization for now. (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.) Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
