OnoSendai wrote:
Yup, I tried out Lua, in particular LuaJIT, which extends the Lua VM with a JIT compiler. Lua does indeed have a nice, lightweight, and low overhead VM. The JIT does work pretty well, at least for simple arithmetical code.
However I found the vector/composite structure handling of Lua to be quite slow. The JIT'er doesn't seem to work well here, due to calls into the VM and memory allocations etc..
Also, while Lua is threadsafe in the sense that you can have 1 VM per thread, it's a bit wasteful to duplicate so much shared data over mulitple threads.
I see you have done your homework
OnoSendai wrote:
SIMD shader evaluation is something I'll think about. Right now the architecture of Indigo doesn't allow for SIMD execution, but perhaps in the future I'll change it.
I wasn't very clear in my post, so just checking that we're talking about
the same thing. Your looking at LuaJIT seems to imply you're worried
about the speed of the VM when in fact it may not matter much.
I wasn't simply talking about SIMD the way it's generally understood
these days on (i.e. vectors of size 4 or 8 using SSE or Altivec), but
rather about _very_ long vectors (~16K long).
If you do implement this, then the speed of your VM becomes kind of
irrelevant because the VM overhead for decoding and executing an
instruction is amortized on 16K pixels. Renderman, for example,
implements this, and they never really had to make their VM fast.
There's of course the problem of dealing with diverging code path
for different pixels in the same vector, so it's not all fun and games
Another thing that's worth looking at if your brain is focused on
the programmable shader thing is LLVM (
http://llvm.org/).
Although a tad bulky, the project allows you to generate native
machine code on the fly whatever your shading language is.
Just my $0.02.
Keep up the good work with Indigo !
Cheers.
