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 5000000)]) > (unsafe-flvector-set! bx 0 (random))))) > (newline) > > (for: ([_ (in-range 5)]) > (time (for: ([_ (in-range 5000000)]) > (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
