<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'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"><<a href="mailto:racket@jverkamp.com" target="_blank">racket@jverkamp.com</a>></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've implemented a pure Racket version each for Perlin and simplex noise. It'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'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's definitely not pure / functional, but I think it's relatively easy to read (or as easy as noise functions can be).<br>
</div><div><br></div><div>What I'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'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'm probably missing something:</div>
<div><br></div><div>- using (racket/floum) -- I've tried just blindly replacing * + - / with fl* fl+ fl- fl/ (and fixing the numerous errors that crop up), but it doesn'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'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'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'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'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>