[racket] Perlin and simplex noise - optimizing Racket code

Oh and one other thought: in case you didn't find them yet, you probably
want to use this function:

http://docs.racket-lang.org/reference/generic-numbers.html?q=current-random#%28def._%28%28quote._~23~25kernel%29._current-pseudo-random-generator%29%29

and friends, so you can be sure that other code that might also use random
doesn't interfere with your code.

Very nice post, btw!

Robby


On Thu, Apr 11, 2013 at 2:24 PM, Robby Findler
<robby at eecs.northwestern.edu>wrote:

> 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.
>
> Robby
>
>
> On Thu, Apr 11, 2013 at 12:07 PM, JP Verkamp <racket at jverkamp.com> wrote:
>
>> 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:
>> http://webstaff.itn.liu.se/~stegu/simplexnoise/simplexnoise.pdf
>>
>> Here is a blog post with some pretty pictures but little actual code:
>> http://blog.jverkamp.com/2013/04/11/perlin-and-simplex-noise-in-racket/
>>
>> Here's just the code:
>> https://github.com/jpverkamp/noise
>>
>> It's definitely not pure / functional, but I think it's relatively easy
>> to read (or as easy as noise functions can be).
>>
>> 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:
>>
>> - 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.
>>
>> - 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.
>>
>> - 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.
>>
>> 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.
>>
>> Thanks for any feedback!
>>
>> JP
>>
>>
>>
>> ____________________
>>   Racket Users list:
>>   http://lists.racket-lang.org/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130411/0ff34391/attachment-0001.html>