Re: LuaJIT missing from language shootout benchmarking site

[Tim Mensch <tim-lua-l@...>]

On 5/20/2011 3:33 PM, Isaac Gouy wrote:
>> And by deciding to exclude LuaJIT, you're deceiving the next 
>> generation of developers into thinking that Lua isn't a contender
> In case you haven't noticed the Lua language is shown.

And LuaJIT 2 is ~2x-131x faster than Lua [1], which means that someone
looking for a performant language would dismiss it as an option after
seeing only canonical Lua numbers.

> Your reasoning should apply to the many other language implementations that are not shown - unless your reasoning is just special pleading.

LuaJIT is more than just "an implementation." It's effectively blessed
(or at least respected) by the original authors of Lua and a large
portion of the Lua community, and on platforms where it's supported it's
probably used as much as the original, if not more -- certainly more
often when performance is an issue. It's as relevant to someone looking
for a language to use as the canonical Lua implementation -- more so if
they're concerned with performance and not just the code size.

Dismissing an argument without addressing its merits isn't useful to
anyone.

What's the point of a language comparison site AT ALL if the most
performant implementations of each language aren't represented? To
display pretty graphs that lack completely in meaning? Is it intended to
be useful, or intended to prove some point of yours?

If you want a BENCHMARKING SITE to be useful, you need to include the
fastest standard and robust implementations of each language.
Experimental versions of a language that aren't ready for prime time can
be excluded without hurting anyone; the "beta" label on LuaJIT 2 is
misleading, since it's pretty widely used, but that doesn't excuse the
lack of LuaJIT 1.x, which is extremely stable.

The outliers are INTERESTING. Excluding LuaJIT 2 makes the site less
interesting. And it makes people (myself included) feel that there's a
political motivation behind it, because there's no rational reason to
exclude an implementation as significant as LuaJIT 2, in comparison with
the other languages that are included (which I can't see ATM, because
the site seems to still be down).

Tim

[1] http://luajit.org/performance_x86.html