Re: LuaJIT2 vs. JavaScript

[Geoff Leyland <geoff_leyland@...>]

On 17/02/2011, at 3:33 AM, Francesco Abbate wrote:
> 2011/2/16 Leo Razoumov <slonik.az@gmail.com>:
>> Would it be meaningful to port Geoff's Lua minimal raytracer to
>> JavaScript and then redo the benchmarks?
>> Comparing crappy Lua to crappy JS code makes no one no good.

That would be interesting.  You'll see there are versions in other languages at http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html (but not JS).

If you're porting from the code at flying frog, you might, as I did, find it difficult work out from diffing the five C++ versions what changes between the versions are "improvements" and what changes are just gratuitous differences in the code.  I think mine approximates ray1.

(Note that I'm not holding this up as good code, a good benchmark or a good raytracer, and that I know nothing about raytracing.  I just wanted to prove that someone on the internet was wrong)

> Well, of course it is possible to do another benchmark but what I
> understood about LuaJIT2 vs JavaScript V8 is that, as soon as there is
> any important pressure to the GC with a ton of small objects the GC
> will became dominant and JavaScript V8 will win because they have
> probably a better GC.

Which is why the raytracer I wrote keeps as much as it can in local variables and arguments rather than in small tables.  Using a lot of small tables makes a lot of work for the GC.  I discussed this with Mike at the time, wondering if LuaJIT couldn't eliminate the small, short-lived tables, and among other things, he said:

> The optimization in question is called 'Scalar replacement of aggregates'


It's worth googling.  Roughly, some Java compilers can replace aggregates on the heap (tables in Lua) with variables on the stack if they can prove that the address of the aggregate never escapes into "unknown" code.  This is good for GC'd languages because it means you can avoid allocating (and so having to collect) some tables (or, in the case of the raytracer, many tables).  Perhaps V8 does SRA?

I'll leave it for Mike to comment if he wishes to on if/when LuaJIT might do sufficient SRA to affect this kind of code.  At some stage I had planned to write the raytracer to use those nasty little tables just so as to give Mike an incentive to work on SRA :-)

Cheers,
Geoff