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.

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.

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.

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.