Slashdot Mirror

May I introduce you to LuaJIT? http://luajit.org/

Here is my list of high-level & high-performance languages:

1. LuaJIT as alternative to C.
2. Julia as alternative to R, Octave/Matlab, Fortran.
3. Java as alternative to C/C++.

that's mostly the work of one programmer, for instance luajit http://luajit.org/ mostly the work of Mike Pall.

He's transitioning to open sourced without him though.

It's not perfect (for instance writing his own assembler instead of using a standard one for the interpreter makes debugging changes to the interpreter hard).

Naming it "Sponsor" would be a lot better. I really like the way LuaJit handles this and I think it's a rather good win-win. Someone gets a feature they want and the open source developer gets some funds to continue doing what they like. Hopefully the developer will say no to features that would take the software in the wrong direction.

What about LuaJit? http://luajit.org/ I don't see any reason why this couldn't be integrated into browsers and in addition to that it is extremely fast.

That benchmark uses non-JIT implementations of all dynamic languages except JavaScript V8. LuaJIT is much faster than regular Lua, and I've been told that it's even faster than V8. So, thanks to Lua and JS, the performance argument for using Scheme as a scripting language is no longer valid.

Also note that Racket is almost 2x as verbose (and Lisp 3x as verbose) as other scripting languages! That, combined with its relative obscurity and the fact that many (most?) programmers don't have any experience with functional languages, makes it an extremely poor choice for an embedded scripting language.

--libman

Then use Lua, or even better LuaJIT.

Ruby is for suckers. Suckers that like slow-ass software.

Exactly.

Lua is better and has been around for ages. Very stable, simple, powerful, and faster than everything else (LuaJIT is probably the fastest scripting language ever made).

Heh, I came here to make the same post.

And anyone interested in high-performance computing/scripting should check out LuaJIT. One of the coolest software projects ever. Imagine a simple, powerful scripting language that runs as fast (or really close) as compiled C. Kick-ass fast built-in FFI interface and super easy to embed.

Plain Lua is nice and all but LuaJIT is where the fun is. It blows the doors off of any other scripting language (and many compiled languages) in terms of performance. I actually have some LuaJIT financial data processing code that runs faster than anything I have been able to code in C. It also has an incredibly awesome and fast FFI interface so you don't even need to write native code to interface with most native libraries.

Lua's Achilles Heal is string performance. It does have awesome tools like LPeg and has powerful string handling functions but if you're handling massive amounts of string data then it starts to bog down because of the string interning. It's still very fast and usually faster than other scripting languages like Python (not as fast as Perl though) but it is a long standing problem that pisses me off considering how fast it is otherwise.

Lua is very Javascript-like already except it's very small, simple, clean, and fast. Much faster; LuaJIT is incredible.

LuaJIT is not much faster anymore.

LuaJIT gets to about 2-3X slower than the fastest gcc, while the latest JS engines (V8 with CrankShaft, SpiderMonkey with TypeInference) get to 3-5X slower than gcc. That's still a significant difference, but the JavaScript engines are also improving faster. In a year or so the difference will have vanished.

Those numbers are also a little misleading. They are mainly simple benchmarks, where LuaJIT's tracer is phenomenal. But if you take a complete program, with a lot of use of classes/inheritance/closures/etc., LuaJIT won't do as well - it hasn't been tuned for those things. In other words, on real-world code the difference would be nonexistent or even reversed. But what is representative 'real-world code' is debatable so it's hard to come up with numbers for that. (But you will often see it in practice in the field.)

Lua is very Javascript-like already except it's very small, simple, clean, and fast. Much faster; LuaJIT is incredible.

Damn, Mozilla changes JIT engines like every year. Why should be believe this one will last any longer than all the others they have tried?

Javascript is a poorly designed language that is hard to JIT and I imagine that's why we keep seeing people trying to redo things better than the previous JIT engine. It's damn near impossible though, just micro-fractional improvements and a whole lot of wasted effort.

Meanwhile things like LuaJIT offer a Javascript-like scripting environment with damn near the performance of native C applications. Pretty much all done by one guy.

Lua is what Javascript should have been. It's dynamic, simple, and fast (partly because it's so simple). The language itself is so much cleaner than Javascript which makes it easy to parse and optimize while still giving you all the power.

I'm surprised none of the browser vendors hired the author of this virtual machine, which beats both V8 and TraceMonkey in the shootout benchmarks by a wide margin.
I'm hoping Google or Mozilla does that eventually, it'd be a pity if he got hired by a closed source browser vendor.

Just curious, given all these advances in JS speed, are there technical reasons why stuff like Python, Ruby and Perl aren't getting similar improvements in speed?

Just needs someone to do the work...

One non-JS language that has seen some excellent tracing JIT development is Lua, in the form of Mike Pall's LuaJIT project.

Even though the standard Lua interpreter is already amazingly fast (far faster than the standard python/ruby/perl implementations), LuaJIT makes many programs run much faster yet.

There's plenty of programming languages out there worth learning as a primary language and ruby isn't one of them.

• go
• javascript / V8 see also node.js
• lua and luaJIT
• racket
• ...

Ruby is one of those languages that you learn in addition to another more general language. In that respect, PHP and ruby are about the same. As respects performance, both PHP and ruby are toys.

Lua with a just-in-time compiler like LuaJIT is considerably faster than the typical JavaScript implementation. In some (naive) cases, the code generated by LuaJIT is faster than what comes out of gcc.

The catch is that you pay two penalties: startup time and memory. Lots of memory: for keeping stats on what needs compiling, trampolines to call in and out of the interpreter vs. JIT native code, and the native code *plus* the byte code.

That JITs automatically incur large memory footprint or startup time penalties is the logical conclusion you come to if you look at the JVM. But the truth is that JITs don't have to suck as much as the JVM does.

For example, take LuaJIT, a JIT for the already-speedy dynamic language Lua. It speeds up Lua roughly 2-5x while starting up in less than 0.01 CPU-seconds and introducing less than 20% memory overhead. It also takes 2-8x less memory and starts up 10x faster than the JVM, despite the fact that Lua is compiling from source, whereas the JVM starts with bytecode.

I've never looked at the source for the JVM, so I can't say just why it takes so many resources, but I can only conclude that it's because Sun just doesn't consider startup time or memory footprint a priority.

I'm in the position of designing a JIT for my latest project (well not quite yet, but soon), and while I'm considering LLVM, I'm leaning towards DynASM. Why? DynASM is 27kb of source compressed and builds in zero time (it's just a few header files) whereas LLVM is a 4.8MB download and takes something like 15 minutes to build.

I love the goals and scope of the LLVM project, I just wish it were a bit lighter-weight.