[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LuaJIT 2.0 and external C libraries
- From: "A.S. Bradbury" <asb@...>
- Date: Thu, 25 Mar 2010 10:27:44 +0000
2010/3/25 Pierre-Yves Gérardy <pygy79@gmail.com>:
> I've written a skip list library in Lua, but I would like to write an
> equivalent in C for efficiency reasons. If I want it to be as efficent
> in LuaJIT, I'll have to write yet another version. The same is true
> for other libraries. This is going to create two parallel ecosystems
> of libs, and such a fragmentation is not a good thing for Lua as a
> whole, IMO.
Maybe I'm not understanding you properly, but isn't your C skiplist
library just as efficient in LuaJIT as in standard Lua. It's just that
with LuaJIT the transition disables optimisations and so your other
plain Lua code is not as efficient as it once was. I haven't seen
timings to suggest that the LuaJIT 2.x interpreter is slower than the
standard interpreter in this case (though I think somebody posted that
LuaJIT 1.1 is faster for this).
Your concern about creating parallel ecosystems is valid, though
wouldn't be much of a problem if either of the following were true:
* The FFI (or at least something implementing its interface) can be
built for standard Lua and has support for more architectures than
LuaJIT
* LuaJIT and this FFI is ported to all common architectures
The first option would perhaps be preferable for people who want to
use libraries using the new FFI lib on an unsupported platform, as it
would be much easier to add a new backend to that than to LuaJIT.
Alex