[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] LuaVela, an implementation of Lua 5.1 based on LuaJIT 2.0
- From: Anton Soldatov <igelhaus@...>
- Date: Thu, 8 Aug 2019 23:43:37 +0300
Hi Javier,
> the first thing I'd like to check is how much
> work and overhead is there from
> the bigger TValue struct
The benchmarks from the LuaJIT's suite show that the wide TValue and
"fair" 64-bit pointers are somewhat slower than LuaJIT (although there
are cases when LuaVela is faster). However, as far as I know, we did
not experience any severe degradation in production (sometimes we even
won over FFI-based code, but this is whole another story), and
IPONWEB's business (real-time bidding) is all about fitting business
logic into hard timeouts (80-120ms).
Anyway, please do share your results!
tor. 8. aug. 2019 kl. 23:27 skrev JeanHeyd Meneide <phdofthehouse@gmail.com>:
>
> Dear Anton Soldatov,
>
> This looks wonderful! I'm glad you worked on it and put it out there. I know a lot of people who had problems with the 2GB memory limit.
>
> As a side note, there were some problems with LuaJIT and Mac OSX, where on 64-bit builds LuaJIT would twiddle bits in the 32-bit range. This required people to build their applications with -pagezero_size=(something much smaller than the default 2^32) and -image_base=(something much smaller than 2^32, which is the default). This ruined people who wanted to inject Lua extensions as part of a dylib extension to a main application which did not change their image_base/pagezero_size.
>
> Does 64-bit "clean" mean that, if this makes it to Mac OSX, this would no longer be a problem?
>
> Sincerely,
> ThePhD
--
Med vennlig hilsen,
Anton Soldatov