<div dir="ltr">Just based on past experience and not a careful look at your code, I think that it is safe to say that TR is the way to go here. That&#39;s going to have the best bang for your buck as a tradeoff of simple-to-do vs spedup-gained.<div>
<br></div><div>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 11, 2013 at 12:07 PM, JP Verkamp <span dir="ltr">&lt;<a href="mailto:racket@jverkamp.com" target="_blank">racket@jverkamp.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Partially out of curiosity and partially in my ongoing quest to try out game development in Racket, I&#39;ve implemented a pure Racket version each for Perlin and simplex noise. It&#39;s pretty much a direct translation of the code from this PDF, originally in C:<div>


<a href="http://webstaff.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf" target="_blank">http://webstaff.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf</a></div><div><br></div><div><div>Here is a blog post with some pretty pictures but little actual code:</div>


<div><a href="http://blog.jverkamp.com/2013/04/11/perlin-and-simplex-noise-in-racket/" target="_blank">http://blog.jverkamp.com/2013/04/11/perlin-and-simplex-noise-in-racket/</a><br></div><div><br></div><div>Here&#39;s just the code:</div>


<div><a href="https://github.com/jpverkamp/noise" target="_blank">https://github.com/jpverkamp/noise</a></div></div><div><br></div><div>It&#39;s definitely not pure / functional, but I think it&#39;s relatively easy to read (or as easy as noise functions can be).<br>


</div><div><br></div><div>What I&#39;m wondering though is if someone with a bit more experience in optimizing Racket code could take a look at it. I know that it should be possible to get a bit more speed; it&#39;s almost all number crunching, mostly floating point math but with a few integer only bits (those are causing the most trouble...). At the moment, I can think of at least three routes for optimization although I&#39;m probably missing something:</div>


<div><br></div><div>- using (racket/floum) -- I&#39;ve tried just blindly replacing * + - / with fl* fl+ fl- fl/ (and fixing the numerous errors that crop up), but it doesn&#39;t seem to result in much of a speedup at all. I think that this is a combination of still requiring runtime checks on the values and having to convert between exact/inexact, but I&#39;m not sure. </div>


<div><br></div><div>- using Typed Racket -- Theoretically this will allow the compiler to choose the correct functions as above and avoid having to do any runtime checks at all, although I&#39;m not sure how much of that has been implemented.</div>


<div><br></div><div>- using the FFI to bind to a native C interface -- This would probably be the fastest in the end, but I&#39;d like to do as much in pure Racket as I can for the time being (although it would be interesting to learn how to do this). Not to mention that a part of me rejects that it wouldn&#39;t be possible for Racket to at least match C code in a perfect world. </div>


<div><br></div><div>Right now the code takes about 1-2 seconds to generate a 256x256 image. Optimally, that should run in near realtime, although I would be happy just getting it into the tens or even hundreds of ms range. A part of that time is turning the noise into a color (for testing), but even without that it still takes about 1 second on my machine for simplex noise.</div>


<div><br></div><div>Thanks for any feedback!</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>JP</div><div><div><br></div><div><br></div></div></font></span></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>