Re: [ANN] LuaJIT 1.0.3

[Mike Pall <mikelu-0509@...>]

Hi,

Adam D. Moss wrote:
> I was bitten by the Linux glibc bug/miscompile

Since this is missing some context: this applies to an ancient
Debian release only. See:

  http://lists.debian.org/debian-glibc/2002/12/msg00347.html

Yes, from 2002! I know you are not fond of upgrading, but ... :-)

> which makes Coco
> crash unless COCO_DISABLE (it would be nice if it were mentioned
> in the LuaJIT docs)

Quoting luajit_install.html: :-)

  If you have trouble getting Coco to work, you can disable it by
  uncommenting the COCOFLAGS= -DCOCO_DISABLE line in src/Makefile.
  Note that this effectively disables yielding from coroutines for
  JIT compiled functions.

> but this replacement coroutine.wrap()
> solved all my ills for use with COCO_DISABLE, as I only use
> coroutines as generators:

Note that JIT -> Lua calls are slower than JIT -> JIT calls, too.
If your app spends any significant amount of time in coroutines,
it's worthwile to measure the speed with Coco enabled on a
system with a 'proper' libc. :-)

> This is without the LuaJIT optimizer modules as of yet, so
> a bit more speed can probably still be gotten from my end.

The optimizer improves performance quite a bit. Especially
for table accesses. I think you should give it a try.

If you are not using the standalone executable you'll be happy
to know that
  require("jit.opt").start(level)
is all you need to do to activate it (nil level means default).

> I've experienced no strange problems with my large apps
> with LuaJIT since 1.0.3, and I was expecting to see a few, so
> it seems quite robust.  Linux/x86.

Strange enough I've not received a single bug report for 1.0.3!
I can hardly believe that, given the complexity of the task
at hand and the number of downloads.

I wanted to wait for the first bunch of bug reports before adding
more optimizations. Looks like I can go right on ...

Here's the top of my TODO list:
- Tables: inline some table.* calls, inline pairs/ipairs iterators
- Strings: inline some string.* calls, inline OP_CONCAT (..).
- Arithmetics: inline math.*, inline OP_MOD (%).
- Coroutines: inline yield and resume, improve Coco.
- Inlining misc. library functions (type()).
- Generalized constant shortcuts in the optimizer.
- Support for runtime instrumentation and profiling (faster than
  the debug hooks).

Anything more advanced (contract propagation, chained arithmetics,
shadow integer slots) will require a new MFP-based optimizer
(which is a larger undertaking)

The above list is not in any particular order. I'll gladly take
suggestions for the most needed optimizations and will tackle
them first.

Bye,
     Mike