5 ms·
Lua vs Ruby benchmarks (similarly "high-level" languages, insanely different performance)
- kingkongrevenge 18y agoLuaJIT is x86 only, so it's not quite apples to apples.
- lbrandy 18y agoI 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 18y agoit'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.
- kingkongrevenge 18y agoI'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.
- LogicHoleFlaw 18y agoActually, this is incorrect. LuaJIT is explicitly compatible with the standard Lua ABI for modules. http://luajit.org/luajit_features.html http://luajit.org/luajit_features.html Since it is able to use certain non-ANSI C features on the various platforms it supports it can do other neat things like enable coroutine calls across Lua/C stack boundaries.
- nod 18y agoI 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 18y agoMe 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-the-jvm http://www.ivy.fr/blog/index.php/2008/03/17/83-kahlua-lua-on...
- brianm 18y agoVery 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.
- nihilocrat 18y agoLua presumes you've already got your own batteries, thank you, and you don't want those crummy off-brand ones that always seem to come "included". Thus, I feel a Lua - to - Ruby/Python comparison is sort of erroneous. Use Lua when you already have all your tools. Use Ruby/Python when you don't have any tools, and you want cool whizbang higher-level stuff. Honestly the benchmark is wholly unsurprising to me; Lua is a much more minimal language. If you need another language to lump Lua with, lump it with Javascript sooner than you would Ruby or Python.
- nuclear_eclipse 18y ago
- zcrar70 18y agoI wonder how it would compare with Ruby 1.9 (released today)?
- Zak 18y agoYou don't have to wonder - all the code is downloadable. You can run the benchmark on Ruby 1.9 yourself.
- zcrar70 18y agoThat'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&lang=yarv&lang2=lua http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...
- jcapote 18y agoOf course; Get a native JIT'ed version of ruby going, then you can make a fair comparison.
- NyxWulf 18y agoUnlike say...JRuby?
- jim-greer 18y agoJRuby is not a JIT for Ruby, and it doesn't compile Ruby to Java bytecode. It's a Ruby interpreter, written in Java.
- cschneid 18y agoRecent work in JRuby does exactly that. It'll JIT your code, and you an even pre-compile if you want. (AFAIK, just seen references to all this).
- jim-greer 18y agoCool! Looks like it's been around for over a year: http://wiki.jruby.org/wiki/JRuby_Compiler http://wiki.jruby.org/wiki/JRuby_Compiler
- jcl 18y agoFor 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.
- Zak 18y 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.
- 18y ago
- brianm 18y agoPersonally, 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&lang=lua&lang2=ruby 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.
- palish 18y agoLuaJIT 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.
- LogicHoleFlaw 18y agoWell, 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.
- brianm 18y agoI love the "only 17 times faster" bit ;-)
- lliiffee 18y agoTry comparing ruby to c++!
- Zak 18y agoWithout 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.
- deleted 18y ago[deleted]
- critic 18y agoSBCL 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 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 18y agoSBCL actually does a lot of inferred type checking when type declarations are present.
- silentbicycle 18y agoThe first place to look is probably "The Implementation of Lua 5.0" (http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/sblp2005.pdf 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 http://www.inf.puc-rio.br/~roberto/docs/peg.pdf) is great, too.
- LogicHoleFlaw 18y ago
- Adkron 18y agoAre both sets of code optimized?
- Locke 18y agoWhich 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 18y agoI had to reverse the dropdown values to get both the versions.. LuaJIT 1.1.4 Copyright (C) 2005-2008 Mike Pall ruby 1.8.7 (2008-08-11 patchlevel 72) [i686-linux]
- joe_the_user 18y agoWho would care to implement Ruby in Lua?
- silentbicycle 18y agoWhile 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.
- compay 18y agoThis 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 http://news.ycombinator.com/item?id=452396
- henning 18y agoLuaJIT 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.
- silentbicycle 18y agoIt 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 18y agomod_lua will be in the next stable apache release. http://lua-users.org/lists/lua-l/2008-12/msg00119.html http://lua-users.org/lists/lua-l/2008-12/msg00119.html
- rufius 18y agoLooks 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.