Re: any benefit to throwing off lua51 constraints?

  • From: Dan Eloff <dan.eloff@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Thu, 11 Apr 2013 15:35:29 -0500

I agree, it's good to see LuaJIT leading with things like bitops and the
ffi and Lua following. The LuaJIT ffi and performance were the reason I
chose it in the first place, I have no interest in vanilla Lua. It's ok as
a language, but there's a lot of good languages out there with different
strengths and weaknesses (usually less to do with their syntax and
semantics and more to do with the libraries and communities around them.)
The combination of easy and fast interop with C, plus very high speed and
dynamic language is a killer feature for me.

I don't think the GC redesign is a big rush though, If you want to use more
than 2GB of ram on x64, you're very likely in the same boat as me in that
you'd rather manage that memory yourself with the ffi, than have a GC
managing it. That can be too slow anyway - look at Java and .NET - the
collection time is just prohibitively expensive if you want billions of
small objects in RAM. Either way you have to do manual memory management,
and it's a lot easier (and more performant, and with lower space overhead)
in LuaJIT with the ffi than with the the JNI or PInvoke.

From my POV compatibility with Lua 5.1 is great in that it is driving
adoption of LuaJIT. However, that could very well change in the future as
LuaJIT is technically superior for most use cases, and it could become the
dominant Lua implementation (we're seeing a little bit of it already with
bitops, coroutines, and the ffi.) In such a future ABI compatibility would
no longer have many advantages.


On Thu, Apr 11, 2013 at 1:38 PM, William Adams <william_a_adams@xxxxxxx>wrote:

> This is an extremely good example of how LuaJIT is leading, and Lua is
> following.  LuaJIT came with the FFI, then it was made 'backward
> compatible' for Lua in general.
>
> If you're into 3D reprap printers, it's kind of how the Prusa became the
> de facto standard for the reprap implementation.  It was just better, so it
> took the lead.
>
> I see LuaJIT the same way.  Much more innovation is occuring on the LuaJIT
> front, and it should continue.  I'm pressing even further and saying "don't
> be afraid to 'innovate' even more, throwing off some of the current
> constraints and annoyances".
>
> 64-bit bitops support is another plus/example.  That might be 'back
> ported' as well, and hallelujah when it is, but don't wait for it to show
> up in Lua first.
>
> Fixing the memory layout problem would be a good help, as well as the new
> garbage collector.  For my usage, if those required a break from ABI
> compatibility, I'd be alright with that.
>
> -- William
>
> ===============================
> - Shaping clay is easier than digging it out of the ground.
>
>
> ----------------------------------------
> > Date: Thu, 11 Apr 2013 11:15:43 -0700
> > Subject: Re: any benefit to throwing off lua51 constraints?
> > From: chighland@xxxxxxxxx
> > To: luajit@xxxxxxxxxxxxx
> >
> >
> > luaffi is EXTREMELY close to being API-compatible with LuaJIT FFI
> > (IIRC the only difference is in null/nil handling), so even that's not
> > fatal.
> >
> > /s/ Adam
> >
>

Other related posts: