lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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