Lua vs Ruby benchmarks (similarly "high-level" languages, insanely different performance)

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=luajit&lang2=ruby

by critic • 17 years ago

39 72 17 years ago

shootout.alioth.debian.org

LuaJIT is x86 only, so it's not quite apples to apples.

lbrandy• 17 years ago

I don't know what's going on with Ruby's 'fasta' implementation, but I'm pretty sure it's not x86 assumptions that cause Ruby to use 231x the RAM.

darkhorse• 17 years ago

it's because the ruby implementation of "fasta" computes the entire result in memory and then prints it out; the lua one prints as it goes.

so, i'd take it with a huge slab of salt.

kingkongrevenge2• 17 years ago

I'm sure, but luajit wins handily over all the scripting interpreters. I'm not much concerned with ruby in particular. I'm suspicious that luajit is constrained in features. I doubt you can dynamically load in object code for modules, for example. This makes it not quite a straightforward comparison to the other interpreters.

nod• 17 years ago

I don't know Lua, but this is the first time I've heard Lua and Ruby equated in terms of expressibility/flexibility (i.e. "high-level"?). Is that a particularly relevant comparison?

fizx• 17 years ago

Me too. It motivated me to spend the last 15 minutes looking into Lua.

Similarities: Block/lambda support and syntax, optional parentheses, control statements as block, prefix, or postfix.

OTOH, "how come Lua is not as widespread as say, Python ? I'd say the answer is this: there is no real standard library, and as opposed to Python, Lua doesn't come with batteries included." -- http://www.ivy.fr/blog/index.php/2008/03/17/83-kahlua-lua-on...

brianm5• 17 years ago

Very true, Lua is optimized for being very small, fast, and portable. It optimizes for embedding, which means you cannot make assumptions about what you are allowed to do, so it errs on the side of very little.

On the other hand, interfacing to C is the nicest of anything I have done, by a long shot, so the lack of batteries isn't that painful in practice. It fills a different niche than python or ruby, in its, it shines.

palish4• 17 years ago

Yeah, actually. Lua isn't as clean as Ruby (or Python, or your_favorite_language), but it has the advanced features you'd expect from a powerful scripting language: closures, coroutines, etc. Rather, Lua is like a really experienced prostitute. Not necessarily beautiful, but can do all the tricks and can get the job done efficiently and inexpensively.

To get started with Lua, I'd recommend PIL: http://www.lua.org/pil/

LogicHoleFlaw8• 17 years ago

Are you serious? Lua has an extremely clean and orthogonal core. It's got serious CS mojo. The "batteries not included" bit is probably the greatest detraction to Lua as a general-purpose scripting language.

brianm5• 17 years ago

Having done a lot of both, Lua feels more pythonic than rubyish in many small ways. Objects are just syntactic sugar where self is the first arg (though unlike python, lua has the syntactic sugar to make it prettier to look at), etc. Interestingly, typical OO Lua is prototype based, not class based -- in that way it is more javascriptish.

Most lua codebases I have seen tend to be written in what I call an "imperative functional" style, where the language isn't purely functional, but functions are the most common means of abstraction.

It has proper anonymous functions, lexical scoping, etc so you can write very rubyish code (such as moonunit http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/lu... and using it http://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/lu... ).

Xichekolas2• 17 years ago

A unit testing framework in 37 lines of code, not too shabby.

silentbicycle8• 17 years ago

Yes.

In short, Lua's philosophy is to keep the core language as small as possible, but to include features that make it easy to add major language features as necessary. Adding an object system to the language is trivial, for example. (It doesn't have hygienic macros, though there are some side projects that attempt to add them. No experience with them, though...I'd just use Scheme.) Lua feels to me like a minimalistic, more internally consistent Python.

zcrar702• 17 years ago

I wonder how it would compare with Ruby 1.9 (released today)?

Zak3• 17 years ago

You don't have to wonder - all the code is downloadable. You can run the benchmark on Ruby 1.9 yourself.

zcrar702• 17 years ago

That's true, but I'll live with wondering a little longer. In the meantime, it seems that Lua is still quite a bit faster than ruby 1.9.0, even though ruby 1.9.0 is approaching Python 2 territory (tested 7 months ago):

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

jcapote• 17 years ago

Of course; Get a native JIT'ed version of ruby going, then you can make a fair comparison.

NyxWulf• 17 years ago

Unlike say...JRuby?

jim-greer2• 17 years ago

JRuby is not a JIT for Ruby, and it doesn't compile Ruby to Java bytecode. It's a Ruby interpreter, written in Java.

jcl• 17 years ago

For what it's worth, JRuby performs a tiny bit better.

I think Ruby in general is less amenable to analysis/compilation than Lua is, so even a JITed Ruby might not do as well as Lua.

Zak3• 17 years ago

"Fair" comparisons of the sort you're talking about are not useful when choosing a language. If I'm choosing a language for an application, I don't care if it's unfair that one is much faster than the other because it has a JIT compiler instead of an interpreter - I only care which one is the most suitable.

vegai• 17 years ago

That's like saying "Of course, get a non-sucky version of ruby going, then you can make a fair comparison."

brianm5• 17 years ago

Personally, I would hav just done Lua vs Ruby instead of LuaJIT vs Ruby.

Results look almost the same ;-)

http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

Lua is generally the fastest scripty language, ruby is generally the slowest. Ruby is much more general purpose though -- Lua is very optimized for embedding.

palish4• 17 years ago

LuaJIT makes the Lua mandelbrot program run 95 times faster than Ruby's, whereas the stock Lua interpreter is only 17 times faster.

Better yet, LuaJIT is a drop-in replacement. There's no reason not to use it, as far as I know.

LogicHoleFlaw8• 17 years ago

Well, LuaJIT only runs on x86, and only in 32-bit mode. Though, the work-in-progress LuaJIT 2 is supposed to be easily portable to ARM or other architectures.

brianm5• 17 years ago

I love the "only 17 times faster" bit ;-)

Zak3• 17 years ago

Without some discussion of why Lua is faster, this isn't very interesting. Lua is known for being small and fast, so this benchmark shouldn't be news to most people here.

SBCL is faster still, averaging about half the speed of GCC and about the same as Java.

critic2• 17 years ago

SBCL is not as "high-level", especially when you are aiming for speed. Yossi already wrote about this http://www.yosefk.com/blog/the-high-level-cpu-challenge.html , so there is no need for me to do it:

    If you use Lisp’s static annotation 
    system, your code becomes uglier than 
    Java, and much less safe (I don’t think 
    Lisp does static checking of parameter 
    types, it just goes ahead and passes you 
    an object and lets you think it’s an integer).

Additionally, Lua only has "one data structure type" - that's also "higher-level" than what you have to do in Lisp, deciding among singly-linked lists, arrays, hash tables, binary trees, lexical trees, etc.

So while SBCL has its place, there's something about Lua you have to admire, don't you think?

jbjohns• 17 years ago

SBCL actually does a lot of inferred type checking when type declarations are present.

silentbicycle8• 17 years ago

The first place to look is probably "The Implementation of Lua 5.0" (http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/sblp2005.pdf).

Short paper, but very interesting.

The LPEG paper (http://www.inf.puc-rio.br/~roberto/docs/peg.pdf) is great, too.

LogicHoleFlaw8• 17 years ago

The "History of Lua" paper written a few years ago for a presentation at HOPL is also great reading and gives good insight into why Lua is the way it is.

http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf

JulianMorrison• 17 years ago

The important difference is memory. It's generally possible to trade space for speed in a JIT and accelerate anything. SBCL is lisp with a JIT. It's as fast as Java - it's as fat as Java (to within 5x either way). Lua is both small and fast, and is more or less on its own as an interpreted language in that category. (Forth is smaller and faster, but forth is about as low level as macro assembler.)

Adkron• 17 years ago

Are both sets of code optimized?

Locke• 17 years ago

Which version of Ruby? 1.8 or 1.9? With my own projects Ruby 1.9 performs much better. Lua is well known for being small and fast, so I doubt Ruby 1.9 would beat it... Nevertheless, it'd be a lot more interesting comparison that Lua vs Ruby ???.

jmatt• 17 years ago

I had to reverse the dropdown values to get both the versions..

ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-linux]

joe_the_user• 17 years ago

Who would care to implement Ruby in Lua?

silentbicycle8• 17 years ago

While it would be an interesting project, the Ruby wouldn't necessarily be faster for it. I don't know Ruby well enough to say, but there are probably aspects in the language design itself that make it slower (as a trade-off for expressiveness). Lua is very fast, but that comes from aggressively simplifying the core of the language. Most things are ultimately built on only a few central constructs, and they have been very throughly optimized.

compay2• 17 years ago

This year my new year's resolution was to learn Lua. I think with some developer attention it has the potential to become a "better PHP" for web development because it beats PHP in performance, simplicty and elegance.

Although I doubt it's going to ever replace PHP I think it's poised to make some inroads now that the next version of Apache will include mod_lua out of the box.

http://news.ycombinator.com/item?id=452396

henning• 17 years ago

LuaJIT is not the standard mainline Lua interpreter that most people think of as "Lua the language". It's still a fairly young, experimental project and you wouldn't want to write production code in it. However, the standard Lua distribution is still much faster than Ruby.

But even though both are dynamic interpreted languages, it's still apples to oranges - they have very different design goals.

Still, I think it's a copout to say performance doesn't matter in any general-purpose language the way the core Ruby team seems to. Micro-optimization is a waste of time, but efficiency and intelligent implementation choices are necessary.

silentbicycle8• 17 years ago

It also only runs on i386.

In practice (not micro-benchmarks), I've found LuaJIT to be at least twice as fast as the standard version, and in some cases three or better.

FraaJad• 17 years ago

mod_lua will be in the next stable apache release. http://lua-users.org/lists/lua-l/2008-12/msg00119.html

rufius• 17 years ago

Looks like perf comparison between both Python and Python 3 against Lua isn't far off from Ruby and Lua... not really surprised. Like everyone else said, Lua is smaller and leaner.

Lua vs Ruby benchmarks (similarly "high-level" languages, insanely different performance)

Related Stories