lua-users home
lua-l archive

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

Hi Lorenzo,

> ..., unless one could show me that
> the impact is extremely limited (say under 1% slowdown for code that
> *don't* make use of __eqval).

I certainly agree that a significant performance penalty would make the
feature unacceptable for general consumption.

I've been trying to run some benchmarks but any differences between the
patched and unpatched versions seem to be swamped by variations due to
cache alignment etc. More often than not, the patched version appeared
to be faster! Looking at the generated code (x86_64), the changes
introduced by the patch cause gcc's optimizer to move things around a
lot, so anything is possible.

I think the slowdown would actually be much less than 1%, because it
only involves looking up the type of the operand and checking whether it
is a table or userdata. And only when comparing an operand with a string
or boolean constant. Comparisons with numerical constants are not affected.

Otherwise, the patch can only cause a slowdown when one of the operands
is a table or userdata. That should not happen very often, because
there's not much point in comparing tables for equality at the moment,
unless they do have an __eq metamethod. In that case there is no slowdown.

Is there a real-world example of time-critical code which could be used
for a benchmark test?


On 09/06/2022 20:50, Lorenzo Donati wrote:
On 09/06/2022 02:09, Andrew wrote:
Hi Eduardo,


Nathan's patch modifies the behaviour of the __eq metamethod so it
might (and almost certainly will) break some existing code. That's
why I suggest adding a new metamethod to 'fill in the gap'.

This way, the change is completely backwards compatible. There
should not be any code which puts an entry called '__eqval' into the
metatable, since all identifiers starting with '__' are reserved for
use by Lua.

My patch introduces a slight performance penalty on all comparisons
with a constant,

This might be a showstopper. Affecting every simple comparison just to
save some hassles in a corner case that a minority of users would be
interested in. IMO, that's a big "no, no", unless one could show me that
the impact is extremely limited (say under 1% slowdown for code that
*don't* make use of __eqval).

and an extra search for the __eqval metamethod iff
one of the operands to '==' or '~=' is a table or userdata.

This probably would be irrelevant in most cases.

I'm not very familiar with the internals of the VM, so it's probably
possible to implement the feature more efficiently.



-- Lorenzo