<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">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/">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">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 style>- 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 style><br></div><div style>- 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 style>Thanks for any feedback!</div><div style><br></div><div>JP</div><div><div style><br></div><div style><br></div></div></div>