C+ Performance. Verarbeitung Gleitkommazahlen und/oder Ganzzahlen

[Schlosi (Gast)]

Hallo,

kennt jemand Werte oder zumindest eine theoretische Tendenz wie die 
Performanceunterschiede von Datentypen sind? Natürlich hängt das von 
Faktoren wie Hardware usw ab aber gehen wir mal von einem aktuellen 
"normalen Computer" mit einer 64-Bit-Architektur aus bei einem C++ 
Programm.

unsigned int
int
float
double

Wie sind in etwa die prozentualen Performanceunterschiede der genannten 
Datentypen nur mal so als Anhaltspunkt?, konnte leider nichts finden.

ps: interessant wären darüber hinaus auch die Unterschiede wenn 
Rechnungen mit nicht nur gleichen sondern unterschiedlichen Datentypen 
stattfinden zB Rechnungen:

integer mit integer
vs
integer mit double
vs
double mit double

Grüße

[Jim M. (turboj)]

Schlosi schrieb:
> Natürlich hängt das von
> Faktoren wie Hardware usw ab aber gehen wir mal von einem aktuellen
> "normalen Computer" mit einer 64-Bit-Architektur aus bei einem C++
> Programm.

Auf einem aktuellen 64-bitter mit vernünftiger FPU hast Du Probleme die 
Unterschiede vernünftig zu messen.

Denn Code für double und int macht i.d.R. nicht 100%ig dasselbe.

Und: "Einfache" Berechnungen sind oftmal schneller als die zugehörigen 
Speicherzugriffe.

[Nase (Gast)]

Schlosi schrieb:
> interessant wären darüber hinaus auch die Unterschiede wenn
> Rechnungen mit nicht nur gleichen sondern unterschiedlichen Datentypen
> stattfinden
Die gibt es eigentlich nicht.
Wenn einer der Operanden ein Gleitkommatyp ist, dann wird der anderen 
auch zu einem solchen erweitert.

[Heiko L. (zer0)]

Da zB gcc Code gerne vektorisiert:
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#

[tictactoe (Gast)]

Soweit ich mich erinnere, stechen nur diese Operationen hervor:

Integer-Multiplikation ist tendenziell langsamer als 
Floatingpoint-Multiplikation.

Floatingpoint-Division ist noch langsamer, also vermeiden wenn geht.

Integer-Division ist der Horror (belegt die ganze Integer-Pipeline für 
Dutzende von Cycles, sodass der Core keine andere Operation parallel 
dazu machen kann, nicht mal ein anderer Hyperthread).

Das ist zumindest die Richtlinien, nach denen ich Code schreibe. Aber 
ich lasse mich gerne eines besseren belehren.

[Carl D. (jcw2)]

tictactoe schrieb:
> Soweit ich mich erinnere, stechen nur diese Operationen hervor:
>
> Integer-Multiplikation ist tendenziell langsamer als
> Floatingpoint-Multiplikation.
Wieso sollte da ein Unterschied bestehen, beide haben 64Bit Mantisse, 
float muß noch zusätzlich mit den Exponenten hantieren.
*)1..7 Clks für Int/Float

> Floatingpoint-Division ist noch langsamer, also vermeiden wenn geht.
*)10..40 Clks

> Integer-Division ist der Horror (belegt die ganze Integer-Pipeline für
> Dutzende von Cycles, sodass der Core keine andere Operation parallel
> dazu machen kann, nicht mal ein anderer Hyperthread).
*)15..40 Clks

> Das ist zumindest die Richtlinien, nach denen ich Code schreibe. Aber
> ich lasse mich gerne eines besseren belehren.
Wichtiger als Int oder Float ist das Layout der Daten, denn ein Zugriff 
auf den Hauptspeicher kostet 109..150 Clks *)

*) http://ithare.com/infographics-operation-costs-in-cpu-clock-cycles/
 Ja, diese Übersicht ist von September 2016, manches könnte inzwischen 
schneller sein. Speicher aber eher nicht.

[Rolf M. (rmagnus)]

Carl D. schrieb:
>> Das ist zumindest die Richtlinien, nach denen ich Code schreibe. Aber
>> ich lasse mich gerne eines besseren belehren.
> Wichtiger als Int oder Float ist das Layout der Daten, denn ein Zugriff
> auf den Hauptspeicher kostet 109..150 Clks *)

Das scheint mir recht wenig. Das angehängte Bild stammt von einer 
Präsentation eines Kernel-Entwicklers von 2002. Damals hatten die 
Prozessoren noch keine 3 Cache-Ebenen, was mich vermuten lässt, dass 
Hauptspeicher-Zugriffe inzwischen noch erheblich mehr Takte brauchen.

[Carl D. (jcw2)]

Rolf M. schrieb:
> Carl D. schrieb:
>>> Das ist zumindest die Richtlinien, nach denen ich Code schreibe. Aber
>>> ich lasse mich gerne eines besseren belehren.
>> Wichtiger als Int oder Float ist das Layout der Daten, denn ein Zugriff
>> auf den Hauptspeicher kostet 109..150 Clks *)
>
> Das scheint mir recht wenig. Das angehängte Bild stammt von einer
> Präsentation eines Kernel-Entwicklers von 2002. Damals hatten die
> Prozessoren noch keine 3 Cache-Ebenen, was mich vermuten lässt, dass
> Hauptspeicher-Zugriffe inzwischen noch erheblich mehr Takte brauchen.

Abgesehen von meinem "9 statt 0"-Vertipper:
2002 hatte man fast die selben CPU-Taktfrequenzen wie heute (nur damals 
eher zum Heizen als zum Rechnen). Sollten also 
Speicher/Speicherinterface in den 14 Jahren nicht um den Faktor 2 besser 
geworden sein, wäre ich enttäuscht
;-)

[Adder (Gast)]

http://www.agner.org/optimize/instruction_tables.pdf