Re: Comparing numerical objects for equality (patch)

[Andrew <ajc@...>]

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?

-a

On 09/06/2022 20:50, Lorenzo Donati wrote:
> On 09/06/2022 02:09, Andrew wrote:
> > Hi Eduardo,
> Hi!
>
> > 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.
> >
> > -a
>
> Cheers!
>
> -- Lorenzo