Re: Simplex noise (2D and 3D) with the LuaJIT FFI

[Steven Johnson <steve@...>]

On Wed, Feb 23, 2011 at 4:43 AM, Mike Pall <mikelu-1102@mike.de> wrote:
> Steven Johnson wrote:
>> Also, since I brought up "register coalescing too complex", what will
>> that account for when it's no longer NYI? Or considered otherwise, are
>> there specific constructs to avoid now, if it can be helped?
>
> This happens if too many locals are live across a branch to a side
> trace. The bytecode data-flow analysis I've added yesterday should
> help with this, provided the locals are actually unused in that
> branch.
>
> If that analysis fails, you can limit the impact with 'do ... end'
> wrappers around lengthy calculations, which involve lots of
> temporaries that go dead after that. Moving this to an extra
> function may be a good idea, too.
>
> Also: always declare temporaries in the innermost scope of their
> use, preferably initializing them at the same time. This happens
> to be good Lua coding style, too. Don't give in to the habit of
> declaring all local variables at the top of the function (which
> originates in a limitation of the ancient K&R C).
>
> --Mike
>
>

Got it. And I'll update once I can reliably pin down the crash I
mention in the A* topic.

Code is now cleaned up and in module form, MIT'd. Stefan Gustavson
wrote back to me and mentioned that he had
updated the license on his code here to public domain:
http://webstaff.itn.liu.se/~stegu/aqsis/DSOs/DSOnoises.html
Much of the code was close enough to what was in his paper to make me
unsure, earlier.

With the previously mentioned Duo I now see these averages:

  Simplex2D: 0.000000093 s
  Simplex3D: 0.000000141 s
  Simplex4D: 0.000000224 s

Further improvements welcome, but I'm certainly not complaining about
this. :) The multipliers in the 2D and 4D cases
could probably do with some tuning to cover a wider expanse of [-1,
+1], but my initial target has just been matching
the output from the paper.

- Steve

Attachment: Noise.lua
Description: Binary data