3. Sinn und Zweck von int

Sinn und Zweck von int

  • C

    SeppJ schrieb:

    Klarer Sieg für int. Wer Spaß hat, kann ja noch ein paar Dummy-chars in die structs einsetzen, um das Alignment und Padding zu testen.

    Kommt das nur mir so vor oder sind die Laufzeiten und Ergebnisse für "mit Foo" und "10x mit Foo" sehr nahe beieinander? Ich hab' zwar keine Ahnung, was deine Funktion eigentlich berechnet, aber zumindest bei der Laufzeit hätte ich da größere Abweichungen erwartet.

    0
  • Mod

    CStoll schrieb:

    SeppJ schrieb:

    Klarer Sieg für int. Wer Spaß hat, kann ja noch ein paar Dummy-chars in die structs einsetzen, um das Alignment und Padding zu testen.

    Kommt das nur mir so vor oder sind die Laufzeiten und Ergebnisse für "mit Foo" und "10x mit Foo" sehr nahe beieinander? Ich hab' zwar keine Ahnung, was deine Funktion eigentlich berechnet, aber zumindest bei der Laufzeit hätte ich da größere Abweichungen erwartet.

    😕 Hast du eine Stelle nicht mitgezählt? Es ist doch fast perfekt ein Faktor 10! Eine bessere Bestatigung kann ich mir gar nicht vorstellen, dass die Funktion das macht was sie soll.

    edit: Oder meinst du, dass du größere Schwnakungen erwartest? Wieso? Ich messe CPU-Zeit, nicht Realzeit.

    0
  • C

    SeppJ schrieb:

    CStoll schrieb:

    SeppJ schrieb:

    Klarer Sieg für int. Wer Spaß hat, kann ja noch ein paar Dummy-chars in die structs einsetzen, um das Alignment und Padding zu testen.

    Kommt das nur mir so vor oder sind die Laufzeiten und Ergebnisse für "mit Foo" und "10x mit Foo" sehr nahe beieinander? Ich hab' zwar keine Ahnung, was deine Funktion eigentlich berechnet, aber zumindest bei der Laufzeit hätte ich da größere Abweichungen erwartet.

    😕 Hast du eine Stelle nicht mitgezählt? Es ist doch fast perfekt ein Faktor 10! Eine bessere Bestatigung kann ich mir gar nicht vorstellen, dass die Funktion das macht was sie soll.

    Sorry, mein Fehler *brille putzen geht*. Eventuell solltest du die Ausgabe besser formatieren, so daß man den Unterschied leichter erkennen kann 😉

    (PS: Hat die Berechnung eigentlich einen praktischen Nutzen oder geht es nur darum, dort möglichst viele verschiedenen Ganzzahl-Operationen zu kombinieren?)

    0
  • *

    volkard schrieb:

    Warum widersprichst Du hier?

    Die Behauptung "Sowohl auf 32 Bit, als auch auf 64 Bit ist int 4 Byte lang und long long 8 Byte." ist falsch. Die ISO Norm garantiert nur, daß ein int mindestens 16Bit groß ist. Mehr wird dazu in der ISO Norm nicht garantiert. Von einem 32Bit oder 64Bit Modus ist in der ISO Norm keine Rede. Aber selbst wenn man von den üblichen Betriebssystemen ausgeht stimmt Deine Aussage auch nicht, denn es gibt dort ILP64 Modi.

    0
  • Mod

    CStoll schrieb:

    (PS: Hat die Berechnung eigentlich einen praktischen Nutzen oder geht es nur darum, dort möglichst viele verschiedenen Ganzzahl-Operationen zu kombinieren?)

    Letzteres. Wobei ich Division vermieden habe, denn wenn man das ohne Plan macht, dann tendieren die Ergebnisse dazu, gegen 0 zu konvergieren. Zumindest ist nun festgestellt, dass bei modernen CPUs 64 und 32 Bit Register ungefähr gleich schnell sind und bei älteren Modellen die 32 Bit Teile schneller sein können (eventuell emulieren die modernen CPUs einfach die 32 Bit, aber das ist Spekulation).

    Ich habe übrigens mal den Effekt von Packing und Alignment ausprobiert. Zumindest bei diesem Programm mach Misalignment keinen Unterschied. Das liegt aber wohl daran, dass alles in einem kleinen Loop stattfindet, so dass die Werte sowieso die ganze Zeit in Prozessorregistern stehen.

    0
  • A

    Übrigens, es gibt Systeme (C64x DSPs von Texas Instruments oder Blackfin DSPs von Analog Devices), auf denen ein sizeof(long) gleich 5 ist. Ja, 40 Bit breit. Normale Register sind 32 Bit breit und sizeof(int) ist 4 und es gibt 40 Bit breite Register für "multiply accumulate" o.ä. Operationen.

    0
  • 3

    int ist kurz zu schreiben. Das ist ein Grund ihn zu verwenden.

    0

  • SeppJ schrieb:

    Zumindest ist nun festgestellt, dass bei modernen CPUs 64 und 32 Bit Register ungefähr gleich schnell sind und bei älteren Modellen die 32 Bit Teile schneller sein können (eventuell emulieren die modernen CPUs einfach die 32 Bit, aber das ist Spekulation).

    Das liegt einfach daran, dass "die älteren Teile" keine 64 Bit Befehle haben, und daher 64 Bit Operationen aus 32 Bit Operationen zusammenstückeln müssen. Dass das langsamer ist sollte jetzt keinen wundern.
    Auch ein i7 ist mit 32 Bit Code bei 64 Bit Berechnungen viel langsamer als bei 32 Bit Berechnungen. Oder als mit 64 Bit Code bei 64 Bit Berechnungen.
    Ist jetzt irgendwie keine Überraschung.

    Oder hab' ich dich falsch verstanden?

    0
  • Mod

    hustbaer schrieb:

    Oder hab' ich dich falsch verstanden?

    Ich glaube ja. Das Ergebnis war:

    • Alter 64 Bit Prozessor (Core 2 Duo):

    • 32 Bit Befehlssatz:

    • 32-Bit Berechnungen sind viel schneller als 64-Bit, ca. Faktor 4

    • 64 Bit Befehlssatz:

    • 32-Bit Berechnungen sind deutlich schneller als 64-Bit, ca. Faktor 2

    • Moderner 64-Bit Prozessor (i7):

    • 32 Bit Befehlssatz:

    • 32-Bit Berechnungen sind viel schneller als 64-Bit, ca. Faktor 4

    • 64 Bit Befehlssatz:

    • 32-Bit Berechnungen sind ziemlich genau gleich schnell wie 64-Bit, ca. Faktor 1

    Diese Faktoren sind ziemlich exakt. Da ich mir nicht vorstellen kann, dass so Zahlen wie 1, 2 und 4 zufällig Zustande kommen, nehme ich mal an, dass da mehr dahinter steckt.

    Der Faktor 4 ist irgendwie intuitiv. Man hat in einem Fall 2 Werte mit 32-Bit, und im anderen 2x2 Werte zu je 32-Bit. Wenn die Rechnungen linear in der Größe der beiden Eingaben sind (es sind ziemlich triviale Operationen, daher ist dies gut möglich), hat man einen Faktor 4.

    Aber irgendetwas haben sie gemacht, dass entweder der 32-Bit Teil des Core 2 sehr viel besser ist als der 64-Bit Teil, oder der 32-Bit Teil des i7 genauso "schlecht" ist wie der 64-Bit Teil. Ich tippen auf letzteres. Möglicherweise ist beim i7 alles 64-Bit und der Core 2 hatte noch eine reine 32-Bit Untereinheit. Aber ohne die Optimierungsrichtlinien von Intel durchzulesen (worauf ich keine Lust habe), wird man das wohl nicht sicher rausfinden.

    0
  • V

    Also ich hatte das Gefühl:
    Addition und Subtraktion geht in allen Größen in einem Takt.
    Multiplikation dauert um so länger, je breiter die Operanden, aber ist nicht wild. Hatte man einen AMD64, hatte man mit #define FASTMUL das gesagt, nämlich daß der Prozessor die integer-Miltiplikation in 6 oder 8 Takten durchrotzen kann. Intel schneckte da ab. Ich gehe davon aus, daß Intel inzwischen aufgeholt hat.
    Bei der Integer-Division ist noch kein Land in Sicht. Größere Operanden brauchen deutlich mehr Zeit.

    0
Anmelden zum Antworten