Warum sind die schnellen Integer-Typen schneller als die anderen Integer-Typen?

Question 1

In ISO/IEC 9899:2018 (C18) heißt es unter 7.20.1.3:

7.20.1.3 Schnellste Ganzzahltypen mit minimaler Breite

1 Jeder der folgenden Typen bezeichnet einen ganzzahligen Typ, der normalerweise am schnellsten ist²⁶⁸⁾ unter allen Integer-Typen zu operieren, die mindestens die angegebene Breite haben.

2 Der typedef-Name int_fastN_t bezeichnet den schnellsten vorzeichenbehafteten ganzzahligen Typ mit einer Breite von mindestens N. Der Typedef-Name uint_fastN_t bezeichnet den schnellsten vorzeichenlosen ganzzahligen Typ mit einer Breite von mindestens N.

3 Folgende Typen werden benötigt:

int_fast8_t, int_fast16_t, int_fast32_t, int_fast64_t,
uint_fast8_t, uint_fast16_t, uint_fast32_t, uint_fast64_t

Alle anderen Arten dieses Formulars sind optional.

²⁶⁸⁾ Es ist nicht garantiert, dass der angegebene Typ für alle Zwecke am schnellsten ist; Wenn die Implementierung keinen klaren Grund hat, einen Typ einem anderen vorzuziehen, wählt sie einfach einen ganzzahligen Typ aus, der die Vorzeichen- und Breitenanforderungen erfüllt.

Es wird jedoch nicht angegeben, warum diese “schnellen” Integer-Typen schneller sind.

Warum sind diese schnellen Integer-Typen schneller als die anderen Integer-Typen?

_{Ich habe die Frage mit C++ getaggt, da die schnellen Integer-Typen auch in C++17 in der Header-Datei von vorhanden sind cstdint. Leider gibt es in ISO/IEC 14882:2017 (C++17) keinen solchen Abschnitt über ihre Erklärung; Ich hatte diesen Abschnitt anderweitig im Fragetext implementiert.}

Hinweis: In C werden sie in der Header-Datei von deklariert stdint.h.

Question 2

Stellen Sie sich eine CPU vor, die nur 64-Bit-Arithmetikoperationen ausführt. Stellen Sie sich nun vor, wie Sie eine vorzeichenlose 8-Bit-Addition auf einer solchen CPU implementieren würden. Es würde notwendigerweise mehr als eine Operation erfordern, um das richtige Ergebnis zu erzielen. Auf einer solchen CPU sind 64-Bit-Operationen schneller als Operationen auf anderen ganzzahligen Breiten. In dieser Situation alle Xint_fastY_t könnte vermutlich ein Alias vom Typ 64 Bit sein.

Wenn eine CPU schnelle Operationen für schmale Integer-Typen unterstützt und somit ein breiterer Typ nicht schneller ist als ein schmalerer, dann Xint_fastY_t wird (sollte) kein Alias des breiteren Typs sein, als notwendig ist, um alle Y-Bits darzustellen.

Aus Neugier habe ich die Größen auf einer bestimmten Implementierung (GNU, Linux) auf einigen Architekturen überprüft. Diese sind nicht bei allen Implementierungen auf derselben Architektur gleich:

┌────╥───────────────────────────────────────────────────────────┐
│ Y  ║   sizeof(Xint_fastY_t) * CHAR_BIT                         │
│    ╟────────┬─────┬───────┬─────┬────────┬──────┬────────┬─────┤
│    ║ x86-64 │ x86 │ ARM64 │ ARM │ MIPS64 │ MIPS │ MSP430 │ AVR │
╞════╬════════╪═════╪═══════╪═════╪════════╪══════╪════════╪═════╡
│ 8  ║ 8      │ 8   │ 8     │ 32  │ 8      │ 8    │ 16     │ 8   │
│ 16 ║ 64     │ 32  │ 64    │ 32  │ 64     │ 32   │ 16     │ 16  │
│ 32 ║ 64     │ 32  │ 64    │ 32  │ 64     │ 32   │ 32     │ 32  │
│ 64 ║ 64     │ 64  │ 64    │ 64  │ 64     │ 64   │ 64     │ 64  │
└────╨────────┴─────┴───────┴─────┴────────┴──────┴────────┴─────┘

Beachten Sie, dass, obwohl Operationen auf den größeren Typen schneller sein können, solche Typen auch mehr Platz im Cache beanspruchen und ihre Verwendung daher nicht unbedingt zu einer besseren Leistung führt. Außerdem kann man nicht immer darauf vertrauen, dass die Implementierung überhaupt die richtige Wahl getroffen hat. Wie immer ist das Messen für optimale Ergebnisse erforderlich.

Screenshot der Tabelle für Android-Benutzer:

^{(Android hat keine Box-Zeichnungszeichen in der Mono-Schriftart – ref)}

Question 3

Sie sind es nicht, zumindest nicht zuverlässig.

Die schnellen Typen sind einfach Typedefs für reguläre Typen, es liegt jedoch an der Implementierung, wie sie definiert werden. Sie müssen mindestens die gewünschte Größe haben, können aber auch größer sein.

Es ist wahr, dass auf einigen Architekturen einige Integer-Typen eine bessere Leistung aufweisen als andere. Zum Beispiel früh ARM Implementierungen hatten Speicherzugriffsanweisungen für 32-Bit-Wörter und für vorzeichenlose Bytes, aber sie hatten keine Anweisungen für Halbwörter oder vorzeichenbehaftete Bytes. Die Halbwort- und Signed-Byte-Befehle wurden später hinzugefügt, aber sie haben immer noch weniger flexible Adressierungsoptionen, weil sie in den freien Codierungsraum geschoben werden mussten. Darüber hinaus arbeiten alle aktuellen Datenverarbeitungsanweisungen auf ARM mit Wörtern, sodass es in einigen Fällen erforderlich sein kann, kleinere Werte nach der Berechnung zu maskieren, um korrekte Ergebnisse zu erhalten.

Es gibt jedoch auch die konkurrierende Sorge um den Cache-Druck, selbst wenn mehr Anweisungen erforderlich sind, um einen kleineren Wert zu laden/speichern/verarbeiten. Der kleinere Wert kann immer noch besser abschneiden, wenn er die Anzahl der Cache-Fehlschläge reduziert.

Die Definitionen der Typen auf vielen gängigen Plattformen scheinen nicht durchdacht zu sein. Insbesondere moderne 64-Bit-Plattformen neigen dazu, 32-Bit-Ganzzahlen gut zu unterstützen, aber die „schnellen“ Typen sind auf diesen Plattformen oft unnötigerweise 64-Bit.

Darüber hinaus werden Typen in C Teil der ABI der Plattform. Selbst wenn also ein Plattformanbieter feststellt, dass er dumme Entscheidungen getroffen hat, ist es schwierig, diese dummen Entscheidungen später zu ändern.

Ignorieren Sie die “schnellen” Typen. Wenn Sie sich wirklich Sorgen um die Integer-Leistung machen, vergleichen Sie Ihren Code mit allen verfügbaren Größen.

Question 4

Die schnellen Typen sind nicht schneller als alle anderen Integer-Typen – sie sind es tatsächlich identisch zu einem “normalen” Integer-Typ (sie sind nur ein Alias für diesen Typ) — welcher Typ zufällig am schnellsten einen Wert von mindestens so vielen Bits hält.

Es ist nur plattformabhängig die Ganzzahltyp Jeder schnelle Typ ist ein Alias für.