LuaJIT 2 approaches C in some SCIMark benchmarks.(lua-users.org)
lua-users.org
LuaJIT 2 approaches C in some SCIMark benchmarks.
http://lua-users.org/lists/lua-l/2009-06/msg00071.html
4 comments
Out of curiosity, what do you do with LUA? Are you just using it as a generic scripting language (like python or ruby), or is it embedded in a C or C++ based project? The only place I've ever seen LUA in the wild is in Baldur's Gate, so I'm always curious about how other people use it.
First off, it's Lua, not LUA. Not an acronym. :) It means "moon" in Portuguese. (Its predecessor was called 'Sol'.)
I use it as my day to day scripting language, and also for parsing (with LPEG, which is awesome), general prototyping, etc. I tend to use Lua as a standalone language and as a nicer interface to C and its libraries, rather than embedded in mainly-C projects.
A couple personal projects I have going in Lua at the moment are 1) a language-independent tool for locating copy-and-pasted code that has been modified in place, and thus is hard to locate via simpler tools such as grep (which I hope to release this summer); this has involved research and a lot of dead ends trying various parsing-based techniques. It's a surprisingly tricky thing to do well. 2) a randomized testing framework (think QuickCheck) for Lua, which is usable, but needs more polish and documenting before I release it, 3) a profiler with different analysis than LuaProfiler, 4) an RSS library, and 5) a bunch of other wrapper libraries in various stages of polish. I have a wrapper for Redis (more idiomatic of Lua and a bit faster than the official one), a library for mpd, a wrapper for xosd, and other such odds and ends. There's probably stuff I'm forgetting. I start too many projects... All of the above will be released under one of the BSD/MIT-ish licenses, when/if I feel they're polished enough.
Overall, Lua has taken over the niches for which I used to use Python or Chicken Scheme. It's a really nice language, especially if you're comfortable with a bit of C now and then. It's not good for everything, but its design is refreshingly modest about just ducking out of the way and letting you use other tools when they're a better fit. (Its minimalism and prototype-based object system also appeal to me.)
There are a bunch of other little tools in my bin directory that I should clean up and share, but that's probably true for everyone here.
I use it as my day to day scripting language, and also for parsing (with LPEG, which is awesome), general prototyping, etc. I tend to use Lua as a standalone language and as a nicer interface to C and its libraries, rather than embedded in mainly-C projects.
A couple personal projects I have going in Lua at the moment are 1) a language-independent tool for locating copy-and-pasted code that has been modified in place, and thus is hard to locate via simpler tools such as grep (which I hope to release this summer); this has involved research and a lot of dead ends trying various parsing-based techniques. It's a surprisingly tricky thing to do well. 2) a randomized testing framework (think QuickCheck) for Lua, which is usable, but needs more polish and documenting before I release it, 3) a profiler with different analysis than LuaProfiler, 4) an RSS library, and 5) a bunch of other wrapper libraries in various stages of polish. I have a wrapper for Redis (more idiomatic of Lua and a bit faster than the official one), a library for mpd, a wrapper for xosd, and other such odds and ends. There's probably stuff I'm forgetting. I start too many projects... All of the above will be released under one of the BSD/MIT-ish licenses, when/if I feel they're polished enough.
Overall, Lua has taken over the niches for which I used to use Python or Chicken Scheme. It's a really nice language, especially if you're comfortable with a bit of C now and then. It's not good for everything, but its design is refreshingly modest about just ducking out of the way and letting you use other tools when they're a better fit. (Its minimalism and prototype-based object system also appeal to me.)
There are a bunch of other little tools in my bin directory that I should clean up and share, but that's probably true for everyone here.
Hmm... please, release them! :) I'm looking at Lua now and IMHO there is a lack of libraries.
I always thought that Python lacks marketing (f.e. comparing to Ruby), but now I understand real meaning of the words "lacks marketing". Lua should be spread wider.
I always thought that Python lacks marketing (f.e. comparing to Ruby), but now I understand real meaning of the words "lacks marketing". Lua should be spread wider.
I think Python has pretty good marketing, actually. Whoever does their webpage does a great job of making it look mature, stable, widespread, and approachable, IMHO. (If you want to see a language which is actually really cool, but historically hasn't done a good job of marketing itself, look at OCaml. Maybe it's had better marketing in French, though.)
Also, Lua is in a bit of a unique situation, because probably half the people using it (give or take) are using it inside of an existing project, which would provide most of the libraries they need. Also, the Lua team has intentionally made it easy to fork local dialects of the language, which in many cases are probably too nuanced to be of general use. (It's MIT licensed, so there's no requirement to contribute back.)
Also, Lua is in a bit of a unique situation, because probably half the people using it (give or take) are using it inside of an existing project, which would provide most of the libraries they need. Also, the Lua team has intentionally made it easy to fork local dialects of the language, which in many cases are probably too nuanced to be of general use. (It's MIT licensed, so there's no requirement to contribute back.)
That sounds fantastic. Is there a reason you choose BSD over MIT. I only ask as MIT seems more common for Lua projects because of course Lua itself is released under that license.
I just meant BSD-style, as opposed to GPL. (Clarified above.)
I'm butting in here. Check out the lists on the Lua-users Wiki and Wikipedia:
http://lua-users.org/wiki/LuaUses
http://en.wikipedia.org/wiki/Lua_(programming_language)#Appl...
I use it for general scripting purposes, but it's you run into many more roadblocks than with Python or Ruby due to the lack of libraries. However, there are a range of decent libraries available and packaged using Luarocks. The Kepler Project (http://keplerproject.org) might interest you.
By the way, it's Lua rather than LUA.
http://lua-users.org/wiki/LuaUses
http://en.wikipedia.org/wiki/Lua_(programming_language)#Appl...
I use it for general scripting purposes, but it's you run into many more roadblocks than with Python or Ruby due to the lack of libraries. However, there are a range of decent libraries available and packaged using Luarocks. The Kepler Project (http://keplerproject.org) might interest you.
By the way, it's Lua rather than LUA.
It's also the scripting language used to customize the World of Warcraft UI, around which there is an enormous addon scene.
[first post; hope it's not over the top or off topic]
A Lua testimonial: I've actively used Lua since version 5.1 (current version) was released (has it been 3 years now?). On Windows (only). After buying and poring over PiL, 2nd ed, my first trial was to replace an existing commercial scripting language in my text editor. That was completely successful, and got me up the learning curve.
Since then I've adopted it as my scripting language of choice at work, where it has almost totally replaced Perl (my previous choice).
* Yes, library support is limited, and lack of native regex support is on rare occasions a pain, but in my line of work these have not been significant handicaps.
* As mentioned by others, writing your own Lua functions in C is very approachable. SWIG? Who needs it? I used Perl heavily for years and after reading the docs was scared aware from writing C code to interface to Perl (or Python). Of course the counterargument is that with those P* languages, you don't _need_ to add much code that can only be written in C. Touche.
* If I had more time on my hands to hack, I could see making Lua the core technology for all sorts of low-level system- and embedded-app development [I was a "FORTH dreamer" for years, but Lua realizes a lot of the same dreams that FORTH offered but (for me at least) didn't deliver on].
* Since Lua is so tiny, it's easy to incorporate it, full-source-distro plus statically compiled EXE, into a project it's used in. I do just that, and among the benefits: NO installation needed (I hate installers, and while users expect installers for Windows apps, they don't miss having to run them to get my tools). Users pull down the Lua EXE (including a few custom/downloaded libraries statically linked in) along with the (non-Lua related) source code they're developing (Lua helps with all aspects of their build process) from SCM, and it's ready to run. If need be, it can be copied elsewhere and run. It just works. I can't imagine doing that with Perl/Python, which are also used by others at work, with the usual install/synchronization issues across dozens of hosts.
* I also appreciate that the language's designers have demonstrated a clear commitment to keeping the core language definition as simple as possible.
I'm not dissing the P* languages, one of which I loved for years, but it's nice to find a simple tool that isn't lacking in power. I'll keep using it until a better one comes alone!
A Lua testimonial: I've actively used Lua since version 5.1 (current version) was released (has it been 3 years now?). On Windows (only). After buying and poring over PiL, 2nd ed, my first trial was to replace an existing commercial scripting language in my text editor. That was completely successful, and got me up the learning curve.
Since then I've adopted it as my scripting language of choice at work, where it has almost totally replaced Perl (my previous choice).
* Yes, library support is limited, and lack of native regex support is on rare occasions a pain, but in my line of work these have not been significant handicaps.
* As mentioned by others, writing your own Lua functions in C is very approachable. SWIG? Who needs it? I used Perl heavily for years and after reading the docs was scared aware from writing C code to interface to Perl (or Python). Of course the counterargument is that with those P* languages, you don't _need_ to add much code that can only be written in C. Touche.
* If I had more time on my hands to hack, I could see making Lua the core technology for all sorts of low-level system- and embedded-app development [I was a "FORTH dreamer" for years, but Lua realizes a lot of the same dreams that FORTH offered but (for me at least) didn't deliver on].
* Since Lua is so tiny, it's easy to incorporate it, full-source-distro plus statically compiled EXE, into a project it's used in. I do just that, and among the benefits: NO installation needed (I hate installers, and while users expect installers for Windows apps, they don't miss having to run them to get my tools). Users pull down the Lua EXE (including a few custom/downloaded libraries statically linked in) along with the (non-Lua related) source code they're developing (Lua helps with all aspects of their build process) from SCM, and it's ready to run. If need be, it can be copied elsewhere and run. It just works. I can't imagine doing that with Perl/Python, which are also used by others at work, with the usual install/synchronization issues across dozens of hosts.
* I also appreciate that the language's designers have demonstrated a clear commitment to keeping the core language definition as simple as possible.
I'm not dissing the P* languages, one of which I loved for years, but it's nice to find a simple tool that isn't lacking in power. I'll keep using it until a better one comes alone!
I must be jaded. There are so many languages that can present some benchmarks where they're in the same speed magnitude as cleverly optimized C with no obvious bugs.
The squid-graphs from the language shootout of a few days ago told me so much more about the languages.
The squid-graphs from the language shootout of a few days ago told me so much more about the languages.
Right. Making everything about pure speed tends to favor languages for which you can always squeeze out another percentage of performance, yet ignores that the cost of doing so increases quite rapidly. (As it stands, Lua makes it very easy to move hotspots over to C.)
Lua scored pretty well in that shootout, IIRC.
disclaimer I've never even coded in Lua.
disclaimer I've never even coded in Lua.
If you don't know Lua make sure to follow the first sections of the tutorial. It is not as dynamic as you can think (that is, if you think is as dynamic as Ruby you are wrong). The authors of Lua did a wonderful work with optimizations, but it is more doable compared to other languages. Also I must admit I don't like the language a lot...
* I decided it would be better wait and post once LuaJIT 2 is actually released, so we can test it ourselves.
* The fact that he's comparing it against C's performance is because it's more useful to say, e.g. "75% as fast as C for benchmark X" rather than "47x faster than Ruby", since the speed of obsessively optimized C is usually the de facto target for such benchmarks. It isn't necessarily because it's beating C yet, just drawing closer. (Considering how dynamic a language Lua is, that's remarkable.)
FWIW: In my typical day to day use (as opposed to narrow benchmarks), swapping Lua for LuaJIT 1.1.5 leads to a 2-4x speedup, with no other changes to my code.
I'm really looking forward to LuaJIT 2, in part because it is expected to be more easily ported off i386. (I often work on amd64.) I use non-JIT'd Lua a great deal, and it's already quite fast. I care less about raw speed than expressiveness and portability, though -- I really like how expressive Lua is, while keeping its semantics simple enough that it's still easy to reason about. (That its simplicity makes it possible to write a top notch JIT-ing compiler for it is just icing on the cake.)
Here's a roadmap for LuaJIT 1.1.4 and 2, from last February (http://lua-users.org/lists/lua-l/2008-02/msg00051.html). It also has a bit of info about how JIT/traceing compilers work, and suggestions for further research.