lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 13.02.2011 17:24, Mike Pall wrote:
Well, I did. It's probably the crappiest Lua code I've seen in a
while. And the crappiest ray tracer, too.

I mean ... lots of globals tons of trivial loops with an
iteration count of three, branchy as hell, and so on. This thing
spends more than 50% of its time in the garbage collector, too.
I sincerely hope nobody writes Lua code like this.

Well, what I've seen doesn't look so crappy. In fact, the only obvious 'bad code' thing I've seen is table.getn(t) used instead of #t, which causes additional slowdown and shows lack of Lua knowledge. I've no knowledge of ray-tracers though. Sure, code lacks any optimization for speed, which is the main thing for real ray-tracers, but I assume real ray-tracers are written in C anyway. I also think that 3-iteration loops unrolling is a work for compiler, unrolling them manually would be premature optimization unless one knows for sure that JIT doesn't unroll them. I also thought LuaJIT somehow magically makes globals access as fast as access to upvalues :)

Here is an answer from the author:

Hello Mike,

Today I suddenly found from agladysh that you know about my simple raytracer and you even analysed my code. You found that the code produces lots of temporary objects (that become garbage almost immediately after creation) and that the code dynamically inserts pixels to a Lua-table. These two things make the program extremely slow. Almost exactly the same code I've written in JavaScript — it also produces lots of temporary objects and inserts pixels one-by-one to an array — and this code appeared much faster under Chrome than the Lua code under LuaJIT.

You offered a simple solution: to replace the standard and simple array «pixels = {}» with a special array «pixels =». Your solution makes the program much faster — even faster than JS under Chrome. But from this point we're comparing not JS and Lua but JS and Lua+LowLevelFeatures. To make the comparsion correct, we must allow to use in JS features like WebGL and that'd make the comparsion meaningless — I didn't want to know what is faster WebGL or FFI.

It'll be more honestly to rewrite the Lua code so as it'll not create tons of objects with short life, but this thing must be done in both Lua and JS code and it's unclear who will appear faster: LuaJIT or JS V8.

Best regards,