Hi Everyone I am Sachetan ,I was just experiementing with different operators to check wheather they are efficient or not , i found this when we use “==“ operator its takes more time compared to xnor+AND gate ,below is the picture as you can see ,why dont we just change the defination of “==” to use xnor+AND gate ? .Will their be any problem if we do that .
This will only work for ints and objects that define __xor__. == needs to work for any object.
See:
3 Likes
I’m actually not going to discuss the equality comparison here, but instead focus on the methodology: the way that your timing calculations are done.
Whenever you get timing results that are this short, they are basically meaningless. The number needs to be increased considerably before you can see any real result here. In general, unless your total time is at least half a second or so, add another zero to your iteration count and try again; once you have results over a second, you have something you can compare. On my computer, that requires at least two more orders of magnitude to get a reasonable result.
The second thing you need to be aware of, though, is that operations involving constants are often done once, as the program is being compiled, and aren’t done each time it’s run. Proving this with timeit.timeit() isn’t easy (though it is possible, and I did confirm before posting it here), but it’s a lot easier to demonstrate using a simple lambda function, and the dis module. Here’s what’s actually happening here:
>>> dis.dis(lambda: 5 == 5)
1 RESUME 0
LOAD_SMALL_INT 5
LOAD_SMALL_INT 5
COMPARE_OP 72 (==)
RETURN_VALUE
>>> dis.dis(lambda: not (5 ^ 5))
1 RESUME 0
LOAD_SMALL_INT 0
TO_BOOL
UNARY_NOT
RETURN_VALUE
In the first example, the comparison is done, and the result returned. But in the second, the XOR is actually precomputed; instead of calculating 5 ^ 5, Python just uses the number 0 as a constant. So instead of comparing, we’re just taking the boolean Not of zero. For a proper comparison, you can instead use a global variable that you compare to 5, which will prevent this optimization:
>>> timeit.timeit("x == 5", setup="x = 5", number=1000000000)
6.0377227030694485
>>> timeit.timeit("not (x ^ 5)", setup="x = 5", number=1000000000)
9.015756839886308
And now you can see that doing two operations (XOR followed by NOT) is slower than just one, which is more commonly what you will expect to see in Python.
But the most important point to note here is the immensely small diference between these two. In order to get over a second of runtime, I needed one billion iterations - which means that the numbers here are also the number of nanoseconds that each of these takes. Yes, this is the difference between taking six nanoseconds and nine nanoseconds. This is not meaningful to any program that is doing any sort of real work, so the correct takeaway from this isn’t that one of them is marginally faster, but that both of them are fast enough. Write the cleanest and most idiomatic code you can, and don’t worry about how fast it is - Python is pretty good at doing things efficiently without needing assembly-language tricks. 
16 Likes
@Rosuav thank you for your detailed explaination
1 Like
A bit off-topic: Python 3.13 was even smarter:
>>> dis.dis(lambda: not(5 ^ 5))
1 RESUME 0
RETURN_CONST 1 (True)
For 5 == 5, you get the same bytecode as for newer versions.
Heh, I didn’t even bother checking all the different versions, since the primary points apply across all variations. That’s an odd regression though.
To add to the other notes here, there is also a difference when specifically evaluating int values less than 257:
>>> for i, j in zip(range(1000), range(1000)):
... if not i is j:
... print(f'Cache miss at {i}')
Cache miss at 257
CPython stores the 8bit ints on startup, so using them for comparisons can lead to funky results.
@Rosuav Also showed that there’s a difference between literal
Here’s some more testing with the Jupyter %timeit magic method along with dis
5 == 5
>>> %timeit 5 == 5
19.5 ns ± 0.174 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)
>>> dis.dis('5 == 5')
0 RESUME 0
1 LOAD_CONST 0 (5)
LOAD_CONST 0 (5)
COMPARE_OP 72 (==)
RETURN_VALUE
5 is 5
Note: You will get a SyntaxWarning if you do this
>>> %timeit 5 is 5
16 ns ± 0.15 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)
>>> dis.dis('5 is 5')
0 RESUME 0
1 LOAD_CONST 0 (5)
LOAD_CONST 0 (5)
IS_OP 0
RETURN_VALUE
not (5 ^ 5)
Note: This optimization is a Cpython implementation detail. It only works with 2 matching constants
>>> %timeit not (5 ^ 5)
8.88 ns ± 0.0469 ns per loop (mean ± std. dev. of 7 runs, 100,000,000 loops each)
>>> dis.dis('not (5 ^ 5)')
0 RESUME 0
1 RETURN_CONST 0 (True)
>>> # Without the implementation detail/optimization for constants
>>> %timeit x = 5; not (x ^ 5)
29.3 ns ± 0.141 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)
>>> dis.dis('x = 5; not (x ^ 5)')
0 RESUME 0
1 LOAD_CONST 0 (5)
STORE_NAME 0 (x)
LOAD_NAME 0 (x)
LOAD_CONST 0 (5)
BINARY_OP 12 (^)
TO_BOOL
UNARY_NOT
POP_TOP
RETURN_CONST 1 (None)
Please don’t do that. Post it as text. How are we supposed to run a picture?
That’s local, not global.
No, they take less. Because they’re repeated in a loop, and that loop costs a significant part of the time. For something this tiny, better repeat the statement, for example:
timeit.timeit("x == 5;" * 10, setup="x = 5", number=10**8)
Or see Raymond’s var_access_benchmark.py which he used for the table in Optimizations of “What’s New In Python 3.9”.
Hmm, I was under the impression that they were saved into the local function’s globals (in the “globals” sense of exec(code, locals, globals)). Are they all actually locals? That may mean it’s necessary, to defeat some types of optimization, to use setup="global x; x = 5" to force it to actually be a global (which can’t be optimized).
Well, yes. But my point was that this amount of time is negligible, so really only the scale of the time is relevant. These figures are in nanoseconds. NONE of this is a significant amount of time.
1 Like
Yes, have a look at the code template:
template = """
def inner(_it, _timer{init}):
{setup}
_t0 = _timer()
for _i in _it:
{stmt}
pass
_t1 = _timer()
return _t1 - _t0
"""
Depends on how often you do them…
1 Like
The range of ints cached expands in 3.15 from -5 to 256 (inclusive) to -5 to 1024.
1 Like