Ist & bei der Prüfung auf ungerade Zahlen schneller als %?

Question

Ist die Prüfung auf gerade und ungerade Zahlen mit dem niedrigsten Bit effizienter als mit dem Modulo-Prinzip?

>>> def isodd(num):
        return num & 1 and True or False

>>> isodd(10)
False
>>> isodd(9)
True

Answer 1

Jepp. Die timeit Modul in der Standardbibliothek können Sie diese Dinge überprüfen. z.B:

$ python -m timeit -s 'def isodd(x): x & 1' 'isodd(9)'
1000000 loops, best of 3: 0.446 usec per loop
$ python -m timeit -s 'def isodd(x): x & 1' 'isodd(10)'
1000000 loops, best of 3: 0.443 usec per loop
$ python -m timeit -s 'def isodd(x): x % 2' 'isodd(9)'
1000000 loops, best of 3: 0.461 usec per loop
$ python -m timeit -s 'def isodd(x): x % 2' 'isodd(10)'
1000000 loops, best of 3: 0.453 usec per loop

Wie Sie sehen, ist auf meinem (erst einen Tag alten==langsamen;-) Macbook Air, die & Lösung ist wiederholbar zwischen 7 und 18 Nanosekunden schneller als die % Lösung.

timeit sagt Ihnen nicht nur, was schneller ist, sondern auch, um wie viel (führen Sie die Tests einfach ein paar Mal durch), was in der Regel zeigt, wie äußerst unwichtig es ist (haben Sie wirklich sich um 10 Nanosekunden Unterschied kümmern, wenn der Overhead des Funktionsaufrufs bei 400 liegt?!)

Programmierer davon zu überzeugen, dass Mikro-Optimierungen im Grunde genommen irrelevant sind, hat sich als unmögliche Aufgabe erwiesen - obwohl es 35 Jahre her ist (in denen Computer um Größenordnungen schneller geworden sind!), seit Knuth schrieb

Wir sollten die kleinen Dinge vergessen Wirkungsgrade, sagen wir etwa 97% der der Zeit: Verfrühte Optimierung ist die Wurzel allen Übels.

was, wie er erklärte, ein Zitat aus einer noch älteren Erklärung von Hoare ist. Ich schätze, alle sind davon überzeugt, dass IHR Fall zu den verbleibenden 3 % gehört!

Anstatt also endlos zu wiederholen "es ist egal", haben wir (insbesondere Tim Peters gebührt hier die Ehre) das Standardmodul der Python-Bibliothek eingebaut timeit die es trivial einfach macht, solche Mikro-Benchmarks zu messen und damit zumindest die einige Programmierer überzeugen sich selbst davon, dass dieser Fall in die 97 %-Gruppe fällt;-)

Answer 2

Um ganz ehrlich zu sein, Ich glaube nicht, dass es darauf ankommt.

Das erste Problem ist die Lesbarkeit. Was macht für andere Entwickler mehr Sinn? Ich persönlich würde ein Modulo erwarten, wenn ich die Geradheit/Ungeradheit einer Zahl prüfe. Ich gehe davon aus, dass die meisten anderen Entwickler dasselbe erwarten würden. Durch die Einführung einer anderen und unerwarteten Methode könnten Sie das Lesen des Codes und damit die Wartung erschweren.

Der zweite Grund ist die Tatsache, dass Sie bei beiden Vorgängen wahrscheinlich nie einen Engpass haben werden. Ich bin für Optimierung, aber frühe Optimierung ist das Schlimmste, was man in jeder Sprache oder Umgebung tun kann. Wenn aus irgendeinem Grund die Feststellung, ob eine Zahl gerade oder ungerade ist, einen Engpass darstellt, dann finden Sie den schnellsten Weg, das Problem zu lösen. Dies bringt mich jedoch zu meinem ersten Punkt zurück - wenn Sie zum ersten Mal eine Routine schreiben, sollte sie so lesbar wie möglich sein.

Answer 3

Die beste Optimierung, die Sie erreichen können, ist no den Test in eine Funktion einbauen. ' number % 2 ' und 'Zahl & 1' sind sehr gebräuchliche Methoden, um ungerade/ungerade zu prüfen. Erfahrene Programmierer werden das Muster sofort erkennen, und Sie können immer einen Kommentar wie '# if number is odd, then blah blah blah' einfügen, wenn es wirklich offensichtlich sein soll.

# state whether number is odd or even
if number & 1:
    print "Your number is odd"
else:
    print "Your number is even"

Answer 4

"return num & 1 and True or False" ? Wah! Wenn Sie Geschwindigkeit-verrückt sind (1) "return num & 1" (2) inline es: if somenumber % 2 == 1 lesbar ist UND schlägt isodd(somenumber) weil es den Python-Funktionsaufruf vermeidet.

Answer 5

John spricht einen guten Punkt an. Der eigentliche Overhead liegt im Funktionsaufruf:

me@localhost ~> python -mtimeit -s'9 % 2'
10000000 loops, best of 3: 0.0271 usec per loop
me@localhost ~> python -mtimeit -s'10 % 2'
10000000 loops, best of 3: 0.0271 usec per loop

me@localhost ~> python -mtimeit -s'9 & 1'
10000000 loops, best of 3: 0.0271 usec per loop
me@localhost ~> python -mtimeit -s'9 & 1'
10000000 loops, best of 3: 0.0271 usec per loop

me@localhost ~> python -mtimeit -s'def isodd(x): x % 2' 'isodd(10)'
1000000 loops, best of 3: 0.334 usec per loop
me@localhost ~> python -mtimeit -s'def isodd(x): x % 2' 'isodd(9)'
1000000 loops, best of 3: 0.358 usec per loop

me@localhost ~> python -mtimeit -s'def isodd(x): x & 1' 'isodd(10)'
1000000 loops, best of 3: 0.317 usec per loop
me@localhost ~> python -mtimeit -s'def isodd(x): x & 1' 'isodd(9)'
1000000 loops, best of 3: 0.319 usec per loop

Interessant ist, dass beide Methoden ohne den Funktionsaufruf die gleiche Zeit wiederholen.