Auf Basis einer kleinen IM-Diskussion frage ich nun:

Mit welchem der beiden Datentypen ist auf x86-Prozessoren die höhere Performance zu erwarten? Oder sind sie gar identisch?

//edit: es geht um C/C++, kann aber gerne auch lowlevel sein.
//edit: es geht um die overall-performance; addition, subtraktion, multiplikation, division
Aus dem Bauch heraus würde ich Int sagen. Da dieser Datentyp doch viel Simpler aufgebaut ist und er weniger Speicher benötigt.
moin

Andererseits gibt es in modernen Prozessoren auch extra Einheiten zur Berechnung von floats, meine ich.
Aber tendieren wuerde ich auch zu int.

aco
Ich denke aufgrund dessen das ein Float in eine andere Einheit muss um berechnet zu werden, und die Rechenoperation viel komplizierter ist als Binär zu addieren, subtrahieren, multiplizieren oder dividieren ist ein Int definitiv performancestärker.
acoolon schriebAndererseits gibt es in modernen Prozessoren auch extra Einheiten zur Berechnung von floats, meine ich.
Die ALUs von GPUs sind auf Floats hin optimiert. Ich glaube, die können intern noch nichtmal Integers darstellen.
Ich habe gerade mal ein simplen "benchmark" für die Addition gemacht mit folgenden Programmen:
#include <limits.h>
int main() {
    int i;
    float ret;
    for (i=0; i<INT_MAX; i++) {
        ret += i;
        ret = 0;
    }
}
für floats und

#include <limits.h>
int main() {
    int i;
    int ret;
    for (i=0; i<INT_MAX; i++) {
        ret += i;
        ret = 0;
    }
}
für ints.
Das ergebnis (mehrmals getestet es kam immer ungefähr das gleiche raus):
~/tmp >time ./int

real    0m45.297s
user    0m45.050s
sys     0m0.017s
~/tmp >time ./float

real    0m9.446s
user    0m9.436s
sys     0m0.003s
Edit: getestet auf einem AMD Athlon X2 BE-2400.
Auch ich habe auf einem Athlon64 3200+ unter 32bit einen kleinen Benchmark geschrieben.
Version 1: Addition; noch mit deutlichen Diskrepanzen zwischen Int und Float
Version 2 dagegen ist auf einmal in etwa im selben Bereich; ich vermute dass es durch das Mischen von Float und Int kommt. Da der Bench lustigerweise schneller ist, wenn andere Programme laufen, glaub ich aber nicht an das Ergebnis

Allerdings muss man wohl beachten, dass man mit Floats noch ganz andere Mnemonics nutzen kann - SSE, 3Dnow mal nur so als Beispiel; Untergrund- (Demo-) Lektüre sagt folgendes:
Gleitkommazahlen sind somit ideal, wenn oft skaliert (= SHL/SHR), multipliziert oder dividiert werden muß. Für Additionen und Subtraktionen sind sie Ganzzahlen und Festkommazahlen mit gleicher Bitzahl unterlegen.

//edit
Ich hab mal Portix' Benchmark überarbeitet:

http://nopaste.info/c395ef068f.html (Vorsicht; 3 Dateien).

Wenn man SSE und SSE2 nutzt kommt folgendes bei raus:
[pmedia@aberdeen intmark]$ ./bench.sh
Int benching

real 0m3.011s
user 0m2.936s
sys 0m0.000s
Float benching

real 0m2.002s
user 0m1.953s
sys 0m0.003s
Ohne SSE/SSE2 dagegen:
[pmedia@aberdeen intmark]$ ./bench.sh
Int benching

real 0m3.027s
user 0m2.940s
sys 0m0.000s
Float benching

real 0m3.018s
user 0m2.933s
sys 0m0.003s
(Nachwievor auf Athlon64 3200+)
sobald das ganze nicht O0 compiliert sondern O2 gibt es keinen unterschied mehr

intO1

real 0m1.297s
user 0m1.293s
sys 0m0.000s
intO2

real 0m0.001s
user 0m0.000s
sys 0m0.000s

floatO1

real 0m1.388s
user 0m1.310s
sys 0m0.013s
floatO2

real 0m0.001s
user 0m0.000s
sys 0m0.000s
Wahrscheinlich weil dann die schleife wegoptimiert wird? 😉
Moin,

ihr braucht keinen Benchmark, schaut einfach in die Assembler Instructions Sets und vergleicht die Anzahl an Takte für das Rechnen mit Integern und Fließkomma-Zahlen. Wo ihr die Assembler Befehle findet, weiß ich nicht. Den Benchmark würde ich, wie allen anderen auch, nicht trauen. Nicht persönlich gemeint, sorry. 😉

Grundsätzlich gibt es ADD für integer und FADD für floats, ich vermute beide Befehle brauchen dieselbe Anzahl an Takten und sind somit gleich schnell. Ich habe aber wenig Interesse an dem Thema und möchte nicht nach einer Tabelle suchen, in denen zusätzlich zu den Befehlen noch die Anzahl an Takten steht. Ob bei der x86-Architektur noch etwas mehr reinspielt, weiß ich allerdings nicht.
Bei 8-Bittern wie z.B. den ATmega findet man die Assembler Instructions Sets auf der Atmel-Seit recht schnell und einfach. Die x86 sind eine ziemlich große Ecke aufwendiger und die Intel-Seite ist deswegen ziemlich undurchsichtig.
Eine Idee wäre noch, mit GNU Assembler (*kopfkratz* NASM glaube ich) und Assembler rum zu probieren bzw. dessen Instruction Sets durch zu ackern, ob der Aufwand nötig ist, liegt in eurem Ermessen.

cu

P.S.: Hier noch ein paar Links zum Stöbern.
http://www.arl.wustl.edu/~lockwood/class/cs306/books/artofasm/toc.html
http://www.intel.com/products/processor/manuals
http://en.wikipedia.org/wiki/X86_assembly_language#Manuals
Schade dass sandpile.org da keine Tabellen hat für. Zumindest find ich keine.

NASM != GASM