1. I think the Flonum -> Nonnegative-Flonum change would be easy to do. 2. `define-predicate` uses contracts, and contracts have significant overhead that simpler functions like `positive?` don't. 3. Can you file bugs for the OC issue?
Sam On Wed, Feb 27, 2019 at 2:23 PM 'John Clements' via Racket Users <racket-users@googlegroups.com> wrote: > > I was doing some very low-key monte carlo testing today, and I wanted to > whether it would magically get faster if I used TR. The short answer is … > well, wait on that. Here’s my program; it’s supposed to check the likelihood > that three randomly chosen numbers in the interval 0-1 could be the sides of > an acute triangle: > > #lang typed/racket > > > (define-predicate nneg-flonum? Nonnegative-Flonum) > ;; comment it out for no-check... > ; (define (nneg-flonum? n) #t) > > (define (run-trials [trials : Natural]) > (exact->inexact > (/ (for/sum : Natural > ([i (in-range trials)]) > (define a (assert (random) nneg-flonum?)) > (define b (assert (random) nneg-flonum?)) > (define c (assert (random) nneg-flonum?)) > (if (and (< (abs (- a b)) c) > (< c (sqrt (+ (* a a) (* b b))))) > 1 > 0)) > trials))) > > > (time > (for ([i : Natural (in-range 26)]) > (define trials (expt 2 i)) > (printf "~v trials: ~v\n" > trials (run-trials trials)))) > > ;; IN DRRACKET, "no debugging or profiling" > > ;; TR: cpu time: 37953 real time: 36371 gc time: 3849 > ;; TR/NC: cpu time: 33632 real time: 33959 gc time: 8511 > > ;; COMMAND-LINE > > ;; TR: cpu time: 24707 real time: 24693 gc time: 27 > ;; TR: cpu time: 26602 real time: 26610 gc time: 27 > ;; TR/NC: cpu time: 12735 real time: 12727 gc time: 132 > ;; TR/NC: cpu time: 12715 real time: 12713 gc time: 116 > > > One thing that I was curious about was the necessity for the assertion on the > result of random. Specifically, it appears to me that the result of the call > (random) is guaranteed to be a Nonnegative-Flonum, but the type on Random is > not that specific: > > (case-> > (->* (Integer Integer) (Pseudo-Random-Generator) Nonnegative-Fixnum) > (->* (Integer) (Pseudo-Random-Generator) Nonnegative-Fixnum) > (->* () (Pseudo-Random-Generator) Flonum)) > > > Is there a reason for this? > > > More generally, of course, I’d like to know why the TR version isn’t faster; > I ran the given timings on the command-line, which seemed to speed up the > no-check version immensely and the TR version hardly at all. I checked the > optimization coach, and all of the numeric portions are solid green. Maybe > the numeric portion of the inner loop isn’t the slow part? > > I tried some amateur loop-unrolling, duplicating the inner body 4 times and > running the loop 1/4 as many times, and … got essentially no difference, > which would suggest that the arithmetic part *is* the slow part. > > … > > or > > … Ah! It’s the calls to “random”. reducing the calls to random by a factor of > four makes the code run about four times faster. Hmm… How about those > assertions? > > Oh! look! changing (assert (random) nneg-flonum?) into (assert (random) > positive?) makes the code twice as fast! So apparently using an assert with a > define-predicate is not a good idea, at least in this case. Is that generally > true? > > Okay, I just went to “show more” on the Optimization Coach, and two > fascinating things happened > 1) The colors went bananas, and editing the file put me in sliding-highlight > hell, so I had to close and re-open the buffer. > 2) The optimization coach suggested that the parameter lookup of > (current-pseudo-random-generator) could be slow, so I should look it up once. > I took this advice and… > racket is now segfaulting reliably. Whoops! Time to file a PR. > > Well, okay, that’s (tallying…) one change request (type of random), one > question (bad idea to use define-predicate?), one vague bug report > (optimization coach coloring), and one straight-up crash (seg fault). I think > I’ve used my quota, back to real work. > > John > > > > > > > -- > 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 racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
