[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [ANN] LuaJIT 1.0.3
- From: "Adam D. Moss" <adam@...>
- Date: Mon, 12 Sep 2005 16:26:15 +0100
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
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
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
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.
Adam D. Moss - firstname.lastname@example.org