Re: [ANN] LuaJIT 1.0.3

["Adam D. Moss" <adam@...>]

Mike Pall wrote:
> > I was bitten by the Linux glibc bug/miscompile
>
> Since this is missing some context: this applies to an ancient
> Debian release only.

Well, AFAICT, not a single ancient release but a succession of
them until someone realized that there was a real problem here. :)

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

I'm quite fond of upgrading actually. :)  But what I'm fond of
isn't too relevant - there are glibc's in the wild that Coco
will crash hard with and I don't have the luxury of asking my
users to upgrade their system libs even if they knew how.  I
support Windows98 so I feel bad about dropping Linux2002 if
I can help it. :)

> > 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. :-)

'Fast' seems more attractive than 'Fastest (but will crash
a small % of users)'.  It's a bit sad but I feel like I
should just swallow it, for a couple more years anyway.
It's not Coco's fault.

> 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).

Thanks, I'd figured that out at around the time I got this
email.  Sadly I can't seem to measure any further speedup
from it with these apps though.

> 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.

Pretty amazing. :)

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

It's quite hard to say where the bottlenecks are - LuaJIT has
really moved them around I think.  Personally my apps aren't
very numerical - I'd guess (when they're in the Lua side of
things) they're a big morass of reading and writing table
entries, branching and function calls (guessing 90% lua->lua,
10% lua->C).  App-logic stuff rather than number/string/data
crunching.

I think that when people (like me) get more used to LuaJIT's
strengths it's going to be quite exciting to expand the scope
of uses of Lua.  I find the idea of using it for real-time
data-crunching (graphics particularly) quite attractive, which
isn't really feasible on a large scale with vanillua.

Cheers,
--Adam
--
Adam D. Moss   -   adam@gimp.org