Re: Comparing numerical objects for equality (patch)

[Ziyao <tswuyin_st127@...>]

On Fri, Jun 10, 2022 at 12:43:07AM +1000, Andrew wrote:
> 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.
Sure gcc does the optimizations,but do all compilers do that?

Since Lua has been ported towards a lot of platforms,it seems that we
had better not depend on the compilers too much.

> 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.
What about adding a new operator,which calls __eqval metamethod instead
of failing while the types of the two operands are different?
But this also seems to break the purity of the language
> 
> Is there a real-world example of time-critical code which could be used
> for a benchmark test?
> 
> -a