The important difference is memory. It's generally possible to trade space for speed in a JIT and accelerate anything. SBCL is lisp with a JIT. It's as fast as Java - it's as fat as Java (to within 5x either way). Lua is both small and fast, and is more or less on its own as an interpreted language in that category. (Forth is smaller and faster, but forth is about as low level as macro assembler.)

The first place to look is probably "The Implementation of Lua 5.0" (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) is great, too.

The "History of Lua" paper written a few years ago for a presentation at HOPL is also great reading and gives good insight into why Lua is the way it is.

http://www.tecgraf.puc-rio.br/~lhf/ftp/doc/hopl.pdf

SBCL 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 , 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?

SBCL actually does a lot of inferred type checking when type declarations are present.