Fließkommazahl oder Ganzzahl schneller zu berechnen ?

[supermuckl]

Hallo.
Ich habe mir Gedanken darüber gemacht, was bei mathematischen Funktionen am schnellsten vom Prozessor verarbeitet werden kann.
Wenn ich z.B. zwei mit single deklarierte Variablen multipliziere oder sonstwas damit veranstalte und das ganze dann mit 2 integer Variablen wiederhole, was wird dann schneller sein ?

wie siehts ausserdem mit den Größen der Typen aus? braucht 32bit mehr Zeit als 16bit ?
bei 64 <-> 32 bit würde ich jetzt behaupten, das ein 32bit Prozessor bei 64Bit ca das doppelte an Zeit braucht. Aber wie sieht es zwischen 16 und 32bit aus? oder 4 und 8 bit ? was ist schneller bzw ist es gleichschnell ?

Ich arbeite halt grad an einem game, wo ich viele Variablen in mehreren Schleifen durch die Mangel dreh. Und da wäre es sinnvoll zu wissen, ob ich nun alles in single machen soll, da es evtl irgendwie schneller berechnet wird durch SSE2 oder sonstwas für CPU Techniken oder ob ich auch mal nen integer verwenden kann, ohne schlechtem Gewissen, das meine Schleife die da was multipliziert o.ä. dadurch langsamer wäre.

Ausführliche Informationen sind erwünscht :)

vielen Dank schonmal.

[Hansa]

Zitat:

Zitat von supermuckl

...Ausführliche Informationen sind erwünscht :)

...können aber nicht geliefert werden. So was sind Erfahrungswerte, die auf konkreten Bedingungen aufbauen müssen, um diese Sachen genau zu analysieren. Oder das Ergebnis von Testreihen, die eventuell lange laufen müssen. Da kommst du nicht drum rum. 8)

[nailor]

im allgemeinen ist beim prozessor (CPU) der integer-teil schneller als die FloatingPoint unit. auf einem 32bit system sollten int16 nicht merklich schneller verarbeitet werden als int32. bei int64 gibt's (gab's) zumindest bei delphi große probleme.
die GPU (also die grafikkarte) ist auf kommazahlen optimiert und fühlt sich im allgemeinen ans bein gepinkelt, wenn man mit integern arbeiten will, also hier genau andersrum als bei der CPU.

[dizzy]

Grundsätzlich gilt erst einmal: Integer ist das schnellste, da immer genau so breit wie die Register, und die ALU ist schnell. Deshalb verwendet man z.T. bei sehr zeitkritischen Programmen anstelle von Floats sogenannte Festkommazahlen, die zwar Nachkommastellen haben, aber dessen gesamte Arithmetik auf Integern abgebildet wird. (Frag mich nicht wie man das im Detail macht - aber es ist imho nicht soooo schwer ;))

Floats: Single ist schneller als Double ist schneller als Extended. Aber Single ist schon langsamer als Integer (alles bezogen auf einfache Rechenoperationen +, -, etc.). Nun kommen so nette Ausnahmen dazu wie MMX/SSE(2). Mit MMX lassen sich Integer parallel verarbeiten. Das setzt aber voraus, dass die Problemlogik überhaupt erst einmal dazu geeignet ist parallelisiert zu werden. Eine einfach Addition bleibt eine einfach Addition. Will man aber 3 oder 4 davon in ähnlicher Weise machen, dann kann MMX schneller sein. Manko: MMX nutzt den FPU-Registerstack, und somit muss, sofern auch mit Floats geabrbeitet wird, dieser erst gesichert werden, dann der Modus gesetzt werden, und zum Ende wieder alles zurück. Also lohnt sich der Einsatz von MMX erst dann, wenn du ein parallelisierbares Problem hast, und dieses oft hinterenander, so dass du nicht immer die FPU umschalten musst.
Es kann je nach Problem aber trotz vielem Umschalten einen Vorteil erbringen. Es ist nur sehr individuell.

SSE ist für die Parallelisierung von Rechnungen mit Singles, und SSE2 mit Double, und es gelten die gleichen Umstände wie für MMX. Aber diese 3 unterscheiden sich nicht NUR durch den Datentyp, sondern bieten auch unterschiedliche Methoden. Dazu wäre es sinnvoll sich mal die IA32-Specs durchzulesen, um abschätzen zu können wo eine echte Ersparnis möglich wäre.


Ich selbst habe bisher noch keine der o.g. Erweiterungen eingesetzt, einfach weil mir der Lernaufwand bisher zu groß war. Im Zuge von .NET macht es aber auch keinen Sinn mehr sich damit zu beschäfigen, da der .NET-Compiler ohnehin versucht an geeigneten Stellen die verfügbaren Features wie MMX einzusetzen. (Dennoch bin auch ich an leicht verständlichen Anfänger-Tutorials dazu interessiert :))

Gruss,
Fabian

[skyobserver]

Thema MMX, SSE, SSE2, SSE3...

Ich habe eine Assembler-Prozedur geschrieben um ein Bild aufzuhellen.
Dazu muß man nur auf die einzelnen Farbanteile jedes Pixels einen festen
Wert aufaddieren. Nachdem ich den Code eine Woche! lang optimiert habe,
bin ich auf eine passende MMX-Funktion gestossen:

Jetzt braucht meine Prozedur nur noch 45% der Zeit!

[alzaimar]

@dizzy: Ich dachte, Extended ist der native Datentyp der FPU. Dann wäre Extended am Schnellsten... Ich habe hier mal ein Testprogramm geschrieben.

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
Var
  i : Integer;
  s : Single;
  r : Real;
  e : Extended;
  t : Cardinal;
begin
  s := 0;
  t := GetTickCount;
  For i:=1 To 1000000 do s:= s+ sin(i)*s/i;
  memo1.lines.add ('Single : '+IntToStr (GetTickCount - t)+' '+FloatToStr (s));
  r := 0;
  t := GetTickCount;
  For i:=1 To 1000000 do r := r+ sin(i)*r/i;
  memo1.lines.add ('Real : '+IntToStr (GetTickCount - t)+' '+FloatToStr (r));
  e := 0;
  t := GetTickCount;
  For i:=1 To 1000000 do e := e+ sin(i)*e/i;
  memo1.lines.add ('Extended : '+IntToStr (GetTickCount - t)+' '+FloatToStr (e));
end;

Danach wäre Extended #1, gefolgt von real, dann single. Lässt man den trigonometrischen Müll weg, ist Real#1, Extened #2. Scheint also auch auf die verwendeten Funktionen anzukommen (wer hätte das gedacht)...

Wenn Du Integer für Realzahlbrechnungen benutzen willst, dann definierst Du dir einfach willkürlich die Anzahl der Nachkommastellen. Das ist dann nicht mehr 'floating' point, sondern einfach 'fixed' point. Arithmetik. Bei den Grundrechenarten ist das völlig transparent, weil es ja egal ist, ob ich 1,2345 - 5,678 oder 12345 - 56780 rechne. Bei Division gibt es dann Probleme. Wenn ich fest 5 Dezimalstellen habe, und 2,00000 / 1,0000 rechnen will, wären das mit der fixed point Schreibweise 200000/100000=2 ==> 0,00002 . Also völliger Blödsinn. Da

[dizzy]

Zitat:

Zitat von alzaimar

@dizzy: Ich dachte, Extended ist der native Datentyp der FPU. Dann wäre Extended am Schnellsten... Ich habe hier mal ein Testprogramm geschrieben.

Ist ja nicht so, dass ich das nicht auch schon einmal getan hätte ;). Jedoch ist dort nur eine einfach Addition getestet.
\\edit: Es ist zudem noch anzumerken, dass ich damals noch nicht wusste, dass der FPU-Registerstack eigentlich 80 und nicht 64 Bit breit ist, wie ich es dort fälschlicherweise geschrieben habe ;).

@skyobserver: Genau für soetwas ist MMX entwickelt worden, und es macht - wie man sieht - bei einer solchen Aufgabe auch Sinn.

[Oxmyx]

Man sollte auch einmal erwähnen, dass solche Überlegungen das letzte sind, über das man sich in der Entwicklung eines Spiels Gedanken machen sollte. Grundrechenarten führen heutige CPUs so flitzeschnell aus, dass man sich eher auf andere Aspekte des Programms konzentrieren sollte, bevor man solche Mikro-Optimierungen betreibt.

[alzaimar]

@dizzy: Hätte mich auch gewundert, wenn Du sowas ungetestet von Dir gibst.

Hat sich schon mal jemand die Mühe gemacht, die einzelnen Funktionen zu vergleichen? Hast Du dir überhaupt die Mühe gemacht, meinen Schwachsinn zu überprüfen? Nein? Solltest Du aber, is nämlich falsch. Richtig ist, was Du gesagt hast :zwinker:

@Oxmyx: Völlig richtig. Ersten denken, dann planen, dann coden, dann testen, dann optimieren.

[dizzy]

Zitat:

Zitat von alzaimar

Hast Du dir überhaupt die Mühe gemacht, meinen Schwachsinn zu überprüfen? Nein? Solltest Du aber, is nämlich falsch. Richtig ist, was Du gesagt hast :zwinker:

Die Mühe hab ich mir erspart - ich wusste ja dass das falsch war :zwinker:

Ich hatte nur "+" getestet. Mit anderen Operationen könnte es aber eventuell noch Überraschungen geben! Am besten wäre es, wenn man seine konkrete "Formel" zeitlich ausmisst, und danach in Einzelfällen das optimale umzusetzen. Dass das nicht unbedingt wenig Aufwand sein muss, ist hoffentlich klar ;).

@Oxmyx: Vollkommen korrekt. Allerdings sind irgendwann auch die Verfahren/Konzepte ausgereizt, so dass (fast) nur noch solch eine friemelige Optimierung Besserung hervorbringt (an solch einer Stelle bin ich mit meinem aktuellen Projekt nämlich auch grad :)).