News for hackers. Stuff that matters.
Re:Lua vs Ruby benchmarks (similarly "high-level" languages,... by lbrandy on Friday January 30, 2009 @04:10PM (#458696)
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.
Re:Lua vs Ruby benchmarks (similarly "high-level" languages,... by darkhorse on Friday January 30, 2009 @04:16PM (#458704)
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.

Re:Lua vs Ruby benchmarks (similarly "high-level" languages,... by kingkongrevenge on Friday January 30, 2009 @04:43PM (#458752)
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.
Re:Lua vs Ruby benchmarks (similarly "high-level" languages,... by LogicHoleFlaw on Friday January 30, 2009 @11:48PM (#459227)
Actually, this is incorrect. LuaJIT is explicitly compatible with the standard Lua ABI for modules.

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.