Was ist schneller: x << 1 oder x << 10?

Ich möchte nichts optimieren, ich schwöre, ich möchte diese Frage nur aus Neugier stellen. Ich weiß , dass auf den meist Hardware gibt es einen Montag Befehl von Bit-Verschiebung (zB shl, shr), die ein einziger Befehl ist. Aber spielt es eine Rolle (in Bezug auf Nanosekunden oder CPU-Takt), wie viele Bits Sie verschieben? Mit anderen Worten, ist eine der folgenden Funktionen auf einer CPU schneller?

x << 1;

und

x << 10;

Und bitte hasse mich nicht für diese Frage. :) :)

Hängt möglicherweise von der CPU ab.

Alle modernen CPUs (x86, ARM) verwenden jedoch einen "Barrel Shifter" - ein Hardwaremodul, das speziell für beliebige Verschiebungen in konstanter Zeit entwickelt wurde.

Das Endergebnis ist also ... nein. Kein Unterschied.

Einige eingebettete Prozessoren haben nur eine "Shift-by-One" -Anweisung. Auf solchen Prozessoren, würde der Compiler ändert x << 3in ((x << 1) << 1) << 1.

Ich denke, das Motorola MC68HCxx war eine der beliebtesten Familien mit dieser Einschränkung. Glücklicherweise sind solche Architekturen mittlerweile recht selten, die meisten enthalten jetzt einen Barrel Shifter mit variabler Schaltgröße.

Der Intel 8051, der über viele moderne Derivate verfügt, kann auch keine beliebige Anzahl von Bits verschieben.

Es gibt viele Fälle dazu.

1. Viele Hochgeschwindigkeits-MPUs verfügen über eine Multiplexer-ähnliche elektronische Schaltung mit Barrel Shifter, die jede Verschiebung in konstanter Zeit ausführt.

2. Wenn MPU nur eine 1-Bit-Verschiebung haben, ist x << 10dies normalerweise langsamer, da dies meistens durch 10 Verschiebungen oder Byte-Kopieren mit 2 Verschiebungen erfolgt.

3. Es ist jedoch ein häufiger Fall bekannt, bei dem x << 10noch schneller als x << 1. Wenn x 16 Bit ist, sind nur die unteren 6 Bit davon betroffen (alle anderen werden herausgeschoben), sodass die MPU nur ein niedrigeres Byte laden muss, um nur einen einzelnen Zugriffszyklus auf den 8-Bit-Speicher durchzuführen, während x << 10zwei Zugriffszyklen erforderlich sind. Wenn der Zugriffszyklus langsamer als die Verschiebung ist (und das untere Byte löscht),x << 10 ist er schneller. Dies kann für Mikrocontroller mit schnellem Programm-ROM gelten, die auf langsamen externen Daten-RAM zugreifen.

4. Zusätzlich zu Fall 3 kann sich der Compiler um die Anzahl der signifikanten Bits kümmern x << 10und weitere Operationen auf solche mit geringerer Breite optimieren, z. B. das Ersetzen der 16x16-Multiplikation durch die 16x8-Eins (da das untere Byte immer Null ist).

Beachten Sie, dass einige Mikrocontroller überhaupt keine Anweisung zum Verschieben nach links haben, sondern add x,xstattdessen verwenden.

Auf ARM kann dies als Nebeneffekt einer anderen Anweisung erfolgen. Daher gibt es für beide möglicherweise überhaupt keine Latenz.

Hier ist meine Lieblings-CPU , die x<<2doppelt so lange dauert wie x<<1:)

Das hängt sowohl von der CPU als auch vom Compiler ab. Selbst wenn die zugrunde liegende CPU eine willkürliche Bitverschiebung mit einem Barrel Shifter aufweist, geschieht dies nur, wenn der Compiler diese Ressource nutzt.

Beachten Sie, dass das Verschieben von Daten außerhalb der Breite in Datenbits in C und C ++ "undefiniertes Verhalten" ist. Die Rechtsverschiebung signierter Daten wird ebenfalls als "Implementierung definiert" bezeichnet. Anstatt sich über die Geschwindigkeit Gedanken zu machen, sollten Sie sich Sorgen machen, dass Sie bei verschiedenen Implementierungen dieselbe Antwort erhalten.

Zitat aus ANSI C Abschnitt 3.3.7:

3.3.7 Bitweise Verschiebungsoperatoren

Syntax

      shift-expression:
              additive-expression
              shift-expression <<  additive-expression
              shift-expression >>  additive-expression

Einschränkungen

Jeder der Operanden muss einen integralen Typ haben.

Semantik

Die integralen Promotions werden für jeden der Operanden durchgeführt. Der Typ des Ergebnisses ist der des heraufgestuften linken Operanden. Wenn der Wert des rechten Operanden negativ ist oder größer oder gleich der Breite in Bits des heraufgestuften linken Operanden ist, ist das Verhalten undefiniert.

Das Ergebnis von E1 << E2 sind E1 linksverschobene E2-Bitpositionen; Leerzeichen werden mit Nullen gefüllt. Wenn E1 einen vorzeichenlosen Typ hat, wird der Wert des Ergebnisses E1 multipliziert mit der Menge, 2 erhöht auf die Potenz E2, reduziert modulo ULONG_MAX + 1, wenn E1 einen vorzeichenlosen Typ hat, andernfalls UINT_MAX + 1. (Die Konstanten ULONG_MAX und UINT_MAX sind im Header definiert.)

Das Ergebnis von E1 >> E2 sind E1 rechtsverschobene E2-Bitpositionen. Wenn E1 einen vorzeichenlosen Typ hat oder wenn E1 einen vorzeichenbehafteten Typ und einen nichtnegativen Wert hat, ist der Wert des Ergebnisses der integrale Teil des Quotienten von E1 geteilt durch die Menge 2, die zur Potenz E2 erhöht wird. Wenn E1 einen vorzeichenbehafteten Typ und einen negativen Wert hat, ist der resultierende Wert implementierungsdefiniert.

So:

x = y << z;

"<<": y × 2 ^z ( undefiniert, wenn ein Überlauf auftritt);

x = y >> z;

">>": implementierungsdefiniert für signiert (meistens das Ergebnis der arithmetischen Verschiebung: y / 2 ^z ).

Es ist denkbar, dass auf einem 8-Bit-Prozessor x<<1tatsächlich viel langsamer sein könnte alsx<<10 bei einem 16-Bit-Wert.

Zum Beispiel kann eine vernünftige Übersetzung von x<<1sein:

byte1 = (byte1 << 1) | (byte2 >> 7)
byte2 = (byte2 << 1)

wohingegen x<<10einfacher wäre:

byte1 = (byte2 << 2)
byte2 = 0

Beachten Sie, wie x<<1sich häufiger und sogar weiter verschiebt als x<<10. Darüber hinaus x<<10hängt das Ergebnis von nicht vom Inhalt von byte1 ab. Dies könnte den Betrieb zusätzlich beschleunigen.

Bei einigen Generationen von Intel-CPUs (P2 oder P3? Nicht AMD, wenn ich mich recht erinnere) sind die Bitshift-Operationen lächerlich langsam. Bitshift um 1 Bit sollte jedoch immer schnell sein, da nur Addition verwendet werden kann. Eine weitere zu berücksichtigende Frage ist, ob Bitverschiebungen um eine konstante Anzahl von Bits schneller sind als Verschiebungen mit variabler Länge. Selbst wenn die Opcodes die gleiche Geschwindigkeit haben, muss auf x86 der nicht konstante rechte Operand einer Bitverschiebung das CL-Register belegen, was der Registerzuweisung zusätzliche Einschränkungen auferlegt und das Programm möglicherweise auch auf diese Weise verlangsamt.

Wie immer hängt es vom umgebenden Codekontext ab : Verwenden Sie z. x<<1B. einen Array-Index? Oder es zu etwas anderem hinzufügen? In beiden Fällen kleine Verschiebung Zählungen (1 oder 2) kann oft optimize sogar mehr , als wenn die Compiler Enden bis zu mit nur verschieben muss. Ganz zu schweigen vom Kompromiss zwischen Durchsatz und Latenz und Front-End-Engpässen. Die Leistung eines winzigen Fragments ist nicht eindimensional.

Eine Hardware-Shift-Anweisung ist nicht die einzige Option eines Compilers zum Kompilieren x<<1, aber die anderen Antworten gehen meistens davon aus.

x << 1 ist genau gleichbedeutend mit x+x für vorzeichenlose und für 2-Komplement-vorzeichenbehaftete Ganzzahlen. Compiler wissen beim Kompilieren immer, auf welche Hardware sie abzielen, damit sie solche Tricks nutzen können.

Auf Intel Haswell , addverfügt über 4 pro Takt Durchsatz, aber shlmit einer sofortigen Zählung hat nur 2 pro Takt Durchsatz. (Sehen Anweisungen und andere Links finden http://agner.org/optimize/x86Tag Wiki). SIMD-Vektorverschiebungen betragen 1 pro Takt (2 in Skylake), aber SIMD-Vektor-Integer-Additionen betragen 2 pro Takt (3 in Skylake). Die Latenz ist jedoch dieselbe: 1 Zyklus.

Es gibt auch eine spezielle Shift-by-One-Codierung, bei der angegeben wird, shlwo die Anzahl im Opcode enthalten ist. 8086 hatte keine Schichten mit sofortiger Zählung, nur nacheinander und nach clRegister. Dies ist hauptsächlich für Rechtsverschiebungen relevant, da Sie nur für Linksverschiebungen hinzufügen können, es sei denn, Sie verschieben einen Speicheroperanden. Wenn der Wert jedoch später benötigt wird, ist es besser, zuerst in ein Register zu laden. Aber trotzdem shl eax,1oder add eax,eaxist ein Byte kürzer als shl eax,10, und die Codegröße kann direkt (Decodierungs- / Front-End-Engpässe) oder indirekt (L1I-Code-Cache-Fehler) die Leistung beeinträchtigen.

Im Allgemeinen können kleine Verschiebungszahlen manchmal in einem Adressierungsmodus auf x86 in einen skalierten Index optimiert werden. Die meisten anderen heutzutage gebräuchlichen Architekturen sind RISC-Architekturen und verfügen nicht über Adressierungsmodi für skalierte Indizes. X86 ist jedoch eine Architektur, die häufig genug ist, um dies zu erwähnen. (Ei, wenn Sie ein Array von 4-Byte-Elementen indizieren, können Sie den Skalierungsfaktor um 1 erhöhen int arr[]; arr[x<<1]).

Das Kopieren + Verschieben ist in Situationen üblich, in denen der ursprüngliche Wert von xnoch benötigt wird. Die meisten x86-Integer-Anweisungen werden jedoch direkt ausgeführt. (Das Ziel ist eine der Quellen für Anweisungen wie addoder shl.) Die x86-64-System V-Aufrufkonvention übergibt Argumente in Registern mit dem ersten Argument in ediund dem Rückgabewert in eax, sodass x<<10der Compiler bei einer zurückgegebenen Funktion auch copy + shift ausgibt Code.

Mit der LEAAnweisung können Sie verschieben und hinzufügen (mit einer Verschiebungsanzahl von 0 bis 3, da die Maschinencodierung im Adressierungsmodus verwendet wird). Das Ergebnis wird in einem separaten Register abgelegt.

gcc und clang optimieren diese Funktionen auf dieselbe Weise, wie Sie im Godbolt-Compiler-Explorer sehen können :

int shl1(int x) { return x<<1; }
    lea     eax, [rdi+rdi]   # 1 cycle latency, 1 uop
    ret

int shl2(int x) { return x<<2; }
    lea     eax, [4*rdi]    # longer encoding: needs a disp32 of 0 because there's no base register, only scaled-index.
    ret

int times5(int x) { return x * 5; }
    lea     eax, [rdi + 4*rdi]
    ret

int shl10(int x) { return x<<10; }
    mov     eax, edi         # 1 uop, 0 or 1 cycle latency
    shl     eax, 10          # 1 uop, 1 cycle latency
    ret

LEA mit 2 Komponenten hat eine Latenz von 1 Zyklus und einen Durchsatz von 2 pro Takt auf neueren Intel- und AMD-CPUs. (Sandybridge-Familie und Bulldozer / Ryzen). Unter Intel ist es nur 1 Durchsatz pro Takt mit 3c Latenz für lea eax, [rdi + rsi + 123]. (Siehe auch : Warum ist der C ++ Code schneller als meine handschriftliche Versammlung für die Vermutung Collatz testen? Geht in dieser im Detail.)

Auf jeden Fall benötigt Kopieren + Verschieben um 10 eine separate movAnweisung. Bei vielen neueren CPUs ist die Latenz möglicherweise null, es werden jedoch immer noch Front-End-Bandbreite und Codegröße benötigt. ( Kann der MOV von x86 wirklich "kostenlos" sein? Warum kann ich das überhaupt nicht reproduzieren? )

Ebenfalls verwandt: Wie multipliziere ich ein Register mit 37 mit nur 2 aufeinanderfolgenden Leal-Anweisungen in x86? .

Dem Compiler steht es auch frei, den umgebenden Code so zu transformieren, dass keine tatsächliche Verschiebung erfolgt oder er mit anderen Operationen kombiniert wird .

Zum Beispiel if(x<<1) { }könnte ein verwendet werden and, um alle Bits außer dem hohen Bit zu überprüfen. Auf x86 würden Sie eine testAnweisung wie test eax, 0x7fffffff/ jz .falseanstelle von verwenden shl eax,1 / jz. Diese Optimierung funktioniert für jede Schichtanzahl und auch für Maschinen, bei denen große Schichten langsam (wie Pentium 4) oder nicht vorhanden (einige Mikrocontroller) sind.

Viele ISAs verfügen über Anweisungen zur Bitmanipulation, die über das reine Verschieben hinausgehen. zB PowerPC hat viele Anweisungen zum Extrahieren / Einfügen von Bitfeldern. Oder ARM hat Verschiebungen von Quelloperanden als Teil eines anderen Befehls. (Verschiebungs- / Drehanweisungen sind also nur eine spezielle Form der moveVerwendung einer verschobenen Quelle.)

Denken Sie daran, C ist keine Assemblersprache . Achten Sie immer auf die optimierte Compilerausgabe, wenn Sie Ihren Quellcode so optimieren , dass er effizient kompiliert.