Re: LuaJIT2 vs. JavaScript

[GrayFace <sergroj@...>]

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 = ffi.new(...)». 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.

ankh1989@habrahabr.ru


--
Best regards,
Sergey Rozhenkomailto:sergroj@mail.ru