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
