At Tue, 12 Nov 2013 23:10:53 -0500, Sam Tobin-Hochstadt wrote:
> On Tue, Nov 12, 2013 at 10:17 PM, Matthew Flatt wrote:
> >
> > For fun, I tried adding `unsafe-flrandom` to use in place of
> > `random-real`, in which case the JIT can leave the flonum result
> > unboxed. That saves another 40% or s
On Tue, Nov 12, 2013 at 10:17 PM, Matthew Flatt wrote:
>
> For fun, I tried adding `unsafe-flrandom` to use in place of
> `random-real`, in which case the JIT can leave the flonum result
> unboxed. That saves another 40% or so, but only if I manually inline
> `unsafe-flrandom` in place of `random-
As you say, at least for Racket, this seems to be largely a benchmark
of the random-number generator. In particular, it turns out to be
mostly measure the overhead of getting from JIT-generated code to the
random-number generator and back.
Sam pointed out a part of the cost that you can avoid (by
I've realized one big slowdown in your code -- `random` by default
uses a parameter to find the `current-pseudo-random-generator`. By
removing the parameter lookup from the loop, I cut the time by about
33%.
My new version is at the same Gist url, with some very minor
additional speedups.
Sam
O
I now know why your custom RNG was slow. Racket fixnums are (a)
signed and (b) have a width 1 less than the width of the host
architecture: [1]
-> (fixnum? (- (expt 2 64) 1))
#f
-> (fixnum? (- (expt 2 63) 1))
#f
-> (fixnum? (- (expt 2 62) 1))
#t
Therefore, your random number generation calculati
Here's a start: https://gist.github.com/samth/7431213
This is a Typed Racket version of your program, converted to use
flvectors instead of f64vectors. I haven't taken a look at the code
for your random number generator yet, but you could try doing the
timing by creating a large array of random nu
Hi Will,
I think flvectors are supposed to be more efficient than f64vectors (one
less level of indirection).
In addition, you can use unsafe-flvector-ref .
Stephan
2013/11/12 William Cushing
> I'm in the process of benchmarking various systems for their ability to
> handle the inner loop of
I'm in the process of benchmarking various systems for their ability to
handle the inner loop of compilations of MCMC from a higher level
probabilistic modeling language (BLOG).
Attached are examples of the kind of output (instantiations of MCMC) we'd
like to be able to generate given the tried-an
8 matches
Mail list logo
