<div dir="ltr"><div><div><div>Hi Will,<br><br></div>I think flvectors are supposed to be more efficient than f64vectors (one less level of indirection).<br><br></div>In addition, you can use unsafe-flvector-ref .<br><br></div>
Stephan<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/12 William Cushing <span dir="ltr"><<a href="mailto:william.cushing@gmail.com" target="_blank">william.cushing@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>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).<br>
</div><div>
<br>Attached are examples of the kind of output (instantiations of MCMC) we'd like to be able to generate given the tried-and-true Bayes Net linking the probabilities of earthquake, burglary, john calling, and mary calling.  Classic AI fare.<br>

<br></div>Predictably, C is fastest.  But Stalin and SBCL also put in a very fine showing.<br><br>For 50,000,000 iterations on my machine, I get the following semi-serious, semi-bogus timings for a random assortment of systems (petite chez just for fun):<br>

<br>1 SBCL 2.20<br>2 Bigloo 5.25<br>3 Chicken 11.49<br>4 Stalin 2.15<br>5 Racket 16.67<br>6 Petite-Chez 30.42<br>7 GCC 0.82<br>8 Clang 0.92<br><br></div>There is much about the comparison that isn't fair.  Chiefly, this is primarily a test of speed of random number generation, but I haven't controlled for the algorithm being used to generate random numbers.  Stalin may very well be using GLIBC random number generation, for example.  I know SBCL uses MT; in fact, the SBCL experts responded to my little encoding by halving the shown runtime figure via dynamically linking in a new and improved (SIMD-aware) implementation of MT.  Which is quite impressive, as that puts it within 30% of my C version...and my C version is "totally cheating" by employing a simple little LCPRNG.  <br>

<br>Porting the same generator to Racket in the obvious way more than triples its running time. (!) <br>(Is it the global var?  Is the conversion to double being compiled as a real division?)<br><br></div>In any case, even just sticking with Racket's default PRNG, it seems the performance of a simple number crunching loop leaves something to be desired.  I have done what I can to try and shave off time here and there.  Using unsafe ops, and threading most of the state through the parameters of a tail-recursive loop (thus avoiding set!), I managed to shave off 3 seconds from my original encoding (so about 15%), which isn't too shabby.  Of course, for even less effort, Stalin is already 800% times faster.<br>

<br>I couldn't get typed/racket to type check, and /no-check doesn't seem to help performance at all (not surprising).  I suspect that getting typed/racket to be able to process this file might help substantially...but I don't really understand its type theory enough to help it figure this benchmark out.  <br>

<div><div><br></div><div>I though Racket experts might have some suggestions for how to convince Racket to run a simple number crunching loop without quite so much in the way of constant-factor slowdown.<br><br></div><div>

-Will<br></div><div><br></div></div></div>
<br>____________________<br>
  Racket Users list:<br>
  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br></div>