Intel Nehalem Dual-Core - SuperPI Benchmark
- Ersteller mike-007
- Erstellt am
Hallo!
Habe bei xtreview zufällig die folgenden Intel Nehalem Benchmarks gefunden:
http://xtreview.com/addcomment-id-4208-view-Intel-Nehalem-benchmark.html
Ich kann allerdings auch nicht sagen, ob diese Benchmarks echt sind....
Ich würde es Intel (jetzt nach der Vorstellung des Intel Atom) durchaus zutrauen, dass sie beim Nehalem die IPC nocheinmal fast verdoppelt haben.
Was ich allerdings für sehr seltsam halte, ist der FSB von 444MHz. Das können ja keine 1333MHz Quad pumped sein.... (Es könnte aber durchaus sein, dass es sich bei diesen 1333MHz um die CSI-Link Taktfrequenz handelt)
MfG.
Habe bei xtreview zufällig die folgenden Intel Nehalem Benchmarks gefunden:
http://xtreview.com/addcomment-id-4208-view-Intel-Nehalem-benchmark.html
Ich kann allerdings auch nicht sagen, ob diese Benchmarks echt sind....
Ich würde es Intel (jetzt nach der Vorstellung des Intel Atom) durchaus zutrauen, dass sie beim Nehalem die IPC nocheinmal fast verdoppelt haben.
Was ich allerdings für sehr seltsam halte, ist der FSB von 444MHz. Das können ja keine 1333MHz Quad pumped sein.... (Es könnte aber durchaus sein, dass es sich bei diesen 1333MHz um die CSI-Link Taktfrequenz handelt)
MfG.
Zuletzt bearbeitet:
rkinet
Grand Admiral Special
http://www.pcgameshardware.de/?article_id=608102
Es gäbe viele Gründe für das besonders hohe Ergebnis.
Einer davon liegt sicherlich bei einer Überarbeitung Fließkommafähigkeiten des Nehalem.
gruffi
Grand Admiral Special
Aber keine, die der Wahrheit entsprechen. Selbst wenn die x87 Leistung verdoppelt werden würde, was praktisch vollkommen unrealistisch ist, da Nehalem ja immer noch auf der 4-fach superskalaren Core2 Architektur basiert, bedeutet das noch lange nicht, dass SuperPi auch doppelt so schnell läuft. Alleine schon die Tatsache, dass hier scheinbar exakt die doppelte IPC Leistung gegenüber dem Core2 erreicht wird, sollte einen stutzig machen.
![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
Ich denke eher, dass Nehalem vor allem dort, wo HTT zum tragen kommt, einen deutlichen Vorsprung zum Core2 rausholen kann. Ansonsten wird die IPC Verbesserung überschaubar bleiben.
Das ganze ist übrigens schon etwas älter und nichts weiter als ein schlechter Fake (http://www.nordichardware.com/news,7328.html). Es gab genauso Screens, wo Nehalem bei wenig Takt weit über 100 Sekunden für 1M gebraucht hat. Also eher P3 Niveau. Halte ich aber genauso für unglaubwürdig.
SuperPi ist sowieso ein denkbar ungünstiger CPU Benchmark. x87 ist tot und nebenbei werden noch einige andere Sachen mitgemessen, wie zB Festplattenzugriffe. Also einfach mal abwarten. Wenn es um FP Leistung geht, ist SSE sowieso weitaus interessanter und relevanter.
gruffi
Grand Admiral Special
Eine skalare 80 Bit Pipeline, die seinerzeit als Erweiterung für die x86 Architektur eingeführt wurde, um Gleitkomma Befehle auszuführen, und heute nur noch für Kompatibilität zu gebrauchen ist. Das waren zuerst Zusatzchips, später wurde das dann direkt in die CPU integriert. x87 ist mittlerweile praktisch bedeutungslos, da Gleitkommaberechnungen über SSE durchgeführt werden. Dort sind nicht nur skalare, sondern auch vektorisierte (packed, SIMD) Berechnungen möglich. Unter x86-64, also im Long Mode, ist x87 Code afaik auch nicht mehr verwendbar.
Der mathematische Koprozessor (FPU Floating Point Unit)
Beim 486-SX konnte dieser x87 Chip nachträglich dazugesteckt werden. Es handelte sich dabei allerdings nur um einen 486-DX der als FPU arbeitet....
Seit dem Pentium ist die FPU standardmäßig in der CPU integriert.
MfG.
Zuletzt bearbeitet:
Bobo_Oberon
Grand Admiral Special
- Mitglied seit
- 18.01.2007
- Beiträge
- 5.045
- Renomée
- 190
Der 486 hatte standardmässig eine FPU drin, das war einer der wesentlichen Vorzüge des 486 gegenüber dem 386.
Richtig ist aber, dass der i486 SX eine deaktivierte FPU hatte, so dass mit einem FPU-"Upgrade" dieser nachgerüstet werden konnte. Dieser "Upgrade" war faktisch eine 486 DX-CPU (keine reine x87-FPU-Einheit) ... Das hatte Intel aber etwas anders nach aussen hin kommuniziert.
Unter x86-64 im Long Mode ist die x87 ISA auch nutzbar. Microsoft hatte sich aber entschlossen unter x86-64 die x87 ISA nicht mehr zu nutzen. Unter Linux kann nach wie vor beides genutzt werden unter 64 Bit. AMD selber empfiehlt aber die SSE-Instruktionen zu nutzen.
MFG Bobo(2008 )
Zuletzt bearbeitet:
andr_gin
Grand Admiral Special
- Mitglied seit
- 12.06.2003
- Beiträge
- 3.052
- Renomée
- 24
- Standort
- St. Pölten (60km westlich von Wien)
1.) Ich verstehe nicht, warum manche Leute immer irgendwelche Ergebnisse ins Netz stellen, obwohl man in 1 Minute feststellen kann, dass es sich um einen Fake handelt. Steht ja sogar ganz groß und fett da, wo man die Prüfziffer validieren kann und dann sollte man eigentlich gleich feststellen, dass da in großer, roter Schrift "Incorrect" steht. Wie war das. Ich erwarte mir, dass der Lügner beim Lügen mindestens so viel Arbeit hat, wie ich beim Glauben
2.) Es wird nicht grundsätzlich alles über SSE ausgeführt. SSE ist dazu da, um 4 gleiche 32 Bit Operationen bzw. 2 64Bit Operationen in einem Takt zu erledigen, wenn diese gleich hintereinander folgen. Das optimiert der Compiler z.B. so:
Das kann er optimieren auf:
float summe1,summe2,summe3,summe4,summe,b,c;
for(int i=0;i<1000;i+=4)
{
summe1+=b+c;
summe2+=b[i+1]+c[i+1];
summe3+=b[i+2]+c[i+2];
summe4+=b[i+3]+c[i+3];
}
summe = summe1+summe2+summe3+summe4;
Da kann er dann SSE benutzen und gleich 4 Additionen in einem Schwung ausführen.
Wenn einfach nur viel Fließkomma eingesetzt wird, aber das so verschachtelt ist, dass es unoptimierbar ist z.B.:
float *a,temp;
for(int i=0;i<1000;i++)
{
temp+=a;
if(temp<0)
temp*=-1;
}
Da kommst du mit SSE nicht weit (zumindest sehe ich keine mögliche Optimierung).
SuperPI ist zum größten Teil unoptimierbar. Es gab einmal Versionen mit SSE2 bzw. SSE3 Optimierung (SSE ist hier sowieso sinnlos), aber der Unterschied war im Bereich von 2-3% (getestet mit einem Athlon 64).
3.) Das, was bei SuperPI bremst, sind gar nicht unbedingt die Recheneinheiten in der CPU, sondern mehr der Speicherzugriff. Das ist der Grund, warum der Core 2 Duo so viel schneller ist. Das ist einfach der große L2 Cache. Bei 2MB ist er eh gleich einmal ein Stück langsamer, aber immer noch schnell. Außerdem zählt ja nicht nur der Zugriff auf den RAM, sondern auch der auf den Cache. Das fällt nur sehr selten auf, weil der Cache mit der CPU hochgetaktet wird und so direkt zur IPC der CPU zählt. Alleine wenn Daten aus dem L1 Cache geladen werden müssen, dann dauert das 3 Takte, was in der heutigen Zeit, wo pro Takt schon einige Operationen ausgeführt werden müssen schon einige Zeit ist. Die einzige Möglichkeit das zu verkürzen ist, indem man mehr Register verwendet, die aber nur bei 64Bit zur Verfügung stehen. Das ist auch das Geheimnis der Performancesteigerung bei 64Bit Software. 64Bit Integer sieht man ja eher selten (gerade bei der Adressierung).
Wenn mehr oder weniger Random Reads auf den L2 Cache ausgeführt werden, dann ist das noch schlimmer und bei nur 32KB Daten im Cache passiert das schon sehr schnell, da die Daten ja auch nicht Byteweise, sondern nur in gewissen Blöcken (um die 64 Byte) in den L1 Cache geladen werden müssen.
Generell ist der Anteil der Berechnungen an der Gesamtzeit außerhalb von wissenschaftlichen Berechnungen mit vielen Fließkomma Divisionen relativ gering. Da ist der Speicherzugriff bzw. das Pointer Handling wesentlich mehr.
Nur einmal als grober Anhaltspunkt:
int shift1=... //fette Berechnung (einmal ausgeführt)
int shift2=..//andere fette Berechnung
...
int shift8=...
unsigned char *temp=...//andere Berechnung
int max=...//wieder andere Berechnung
for(int i=0;i<max;i++)
{
temp&=0x12;
temp+=shift1;
temp&=0x34;
temp+=shift2;
...
temp&=0x56;
temp+=shift2;
}
Für 2 Zeilen in der Schleife:
temp&=0x12;
temp+=shiftx;
braucht er mit allen Compiler Optimierungen ca. 3 Takte bei einem Core2Duo, obwohl dieser locker 2-3 Befehle in einem Takt durchführen kann. Shift ist über 100 Byte, also macht er Random Reads auf den L2 Cache.
Wirklich berechnet wird nur:
AND
ADD
Alles andere sind Load und Store Operationen.
Dies ist übrigens ein Beispiel, wo die ganze Pointer Rechnerei auf ein Minimum reduziert wurde. Bei aktueller Software hat man oft auch folgende Konstrukte:
if(this->_parent->_children[this->_parent->_fillfactor-1] < this->_left->_parent->_children[this->_left->_parent->_fillfactor-1])
//Code für Linker Teilbaum kleiner
else
//Code für Rechter Teilbaum kleiner
Wenn man die if-Bedingung zerlegt, kommt man auf ca. folgendes (groß geschrieben heißt Konstante aus der struct Definition, Syntaxfehler möge man mir vergeben
):
this->_parent->_fillfactor-1:
*(*(this+PARENT)+FILLFACTOR)-1 //nenne ich einmal x
this->_parent->_children[x]:
(*(this+PARENT))+CHILDREN+x
Das ganze dann noch einmal für den anderen Teilbaum
Wenn man Glück hat, ist der Compiler so intelligent, dass er einiges nicht doppelt berechnet, sondern in den Cache lädt, wenn dieser annimmt, dass sich die Strukturen nicht überlagern (asume no pointer aligning).
Wenn man ein Pech hat, dann wird das aber wirklich 1:1 ausgeführt und man hat nur Load und Store Operationen plus manchmal ein ADD.
Aus Erfahrung kann ich sagen, dass man Fließkomma Operationen eher selten braucht. Von 50/50 kann hier absolut nicht die Rede sein. Fließkomma braucht man nur, wenn man wirklich etwas berechnet und keinen Ablauf programmiert und wenn man die Kommastellen auch braucht (auch eher selten). Ich würde das Verhältnis auf ca. 90/10 schätzen. In den meisten meiner Programme ist die einzige Fließkommaoperation beim Umwandeln von Bytes in MB für die Anzeige.
Ansonsten zu 90% nur Addition, Load, Store, logisches Und, manchmal eine Multiplikation und ganz selten eine Division. Das sieht man eh beim Penryn. Der kann mehr als doppelt so schnell dividieren, aber ist nur 5% schneller und das kommt vom größeren Cache.
Fließkommaleistung ist nur wichtig, wenn man etwas mathematische/physikalisches mit vielen Wurzeln hat bzw. Operationen wie sin,cos etc. das auf Wurzeln basiert.
4.) Wissen wir überhaupt sicher, ob SuperPI wirklich mit Fließkomma Operationen arbeitet, oder das nur mit Integer emuliert. Bei Fließkomma hat man ja immer eine begrenzte Genauigkeit und da man nicht mehr als 64Bit vordefiniert hat, wird das emulieren schwer. Bei Integer kann man ziemlich leicht einen 128Bit Integer draus machen wenn man das Carry Bit nutzt. Bei Fließkomma wüsste ich nicht, dass es da Befehle gibt, mit denen man sagen kann, dass jetzt alles nur Mantisse ist. Es ist mir eh nicht ganz geheuer, wie die es schaffen, Multiplikationen durchzuführen, ohne dass der Aufwand quadratisch mit der Anzahl der Stellen ansteigt.
2.) Es wird nicht grundsätzlich alles über SSE ausgeführt. SSE ist dazu da, um 4 gleiche 32 Bit Operationen bzw. 2 64Bit Operationen in einem Takt zu erledigen, wenn diese gleich hintereinander folgen. Das optimiert der Compiler z.B. so:
Code:
float summe,*a,*b;
for(int i=0;i<1000;i++)
{
summe+=a[i]+b[i];
}Das kann er optimieren auf:
float summe1,summe2,summe3,summe4,summe,b,c;
for(int i=0;i<1000;i+=4)
{
summe1+=b+c;
summe2+=b[i+1]+c[i+1];
summe3+=b[i+2]+c[i+2];
summe4+=b[i+3]+c[i+3];
}
summe = summe1+summe2+summe3+summe4;
Da kann er dann SSE benutzen und gleich 4 Additionen in einem Schwung ausführen.
Wenn einfach nur viel Fließkomma eingesetzt wird, aber das so verschachtelt ist, dass es unoptimierbar ist z.B.:
float *a,temp;
for(int i=0;i<1000;i++)
{
temp+=a;
if(temp<0)
temp*=-1;
}
Da kommst du mit SSE nicht weit (zumindest sehe ich keine mögliche Optimierung).
SuperPI ist zum größten Teil unoptimierbar. Es gab einmal Versionen mit SSE2 bzw. SSE3 Optimierung (SSE ist hier sowieso sinnlos), aber der Unterschied war im Bereich von 2-3% (getestet mit einem Athlon 64).
3.) Das, was bei SuperPI bremst, sind gar nicht unbedingt die Recheneinheiten in der CPU, sondern mehr der Speicherzugriff. Das ist der Grund, warum der Core 2 Duo so viel schneller ist. Das ist einfach der große L2 Cache. Bei 2MB ist er eh gleich einmal ein Stück langsamer, aber immer noch schnell. Außerdem zählt ja nicht nur der Zugriff auf den RAM, sondern auch der auf den Cache. Das fällt nur sehr selten auf, weil der Cache mit der CPU hochgetaktet wird und so direkt zur IPC der CPU zählt. Alleine wenn Daten aus dem L1 Cache geladen werden müssen, dann dauert das 3 Takte, was in der heutigen Zeit, wo pro Takt schon einige Operationen ausgeführt werden müssen schon einige Zeit ist. Die einzige Möglichkeit das zu verkürzen ist, indem man mehr Register verwendet, die aber nur bei 64Bit zur Verfügung stehen. Das ist auch das Geheimnis der Performancesteigerung bei 64Bit Software. 64Bit Integer sieht man ja eher selten (gerade bei der Adressierung).
Wenn mehr oder weniger Random Reads auf den L2 Cache ausgeführt werden, dann ist das noch schlimmer und bei nur 32KB Daten im Cache passiert das schon sehr schnell, da die Daten ja auch nicht Byteweise, sondern nur in gewissen Blöcken (um die 64 Byte) in den L1 Cache geladen werden müssen.
Generell ist der Anteil der Berechnungen an der Gesamtzeit außerhalb von wissenschaftlichen Berechnungen mit vielen Fließkomma Divisionen relativ gering. Da ist der Speicherzugriff bzw. das Pointer Handling wesentlich mehr.
Nur einmal als grober Anhaltspunkt:
int shift1=... //fette Berechnung (einmal ausgeführt)
int shift2=..//andere fette Berechnung
...
int shift8=...
unsigned char *temp=...//andere Berechnung
int max=...//wieder andere Berechnung
for(int i=0;i<max;i++)
{
temp&=0x12;
temp+=shift1;
temp&=0x34;
temp+=shift2;
...
temp&=0x56;
temp+=shift2;
}
Für 2 Zeilen in der Schleife:
temp&=0x12;
temp+=shiftx;
braucht er mit allen Compiler Optimierungen ca. 3 Takte bei einem Core2Duo, obwohl dieser locker 2-3 Befehle in einem Takt durchführen kann. Shift ist über 100 Byte, also macht er Random Reads auf den L2 Cache.
Wirklich berechnet wird nur:
AND
ADD
Alles andere sind Load und Store Operationen.
Dies ist übrigens ein Beispiel, wo die ganze Pointer Rechnerei auf ein Minimum reduziert wurde. Bei aktueller Software hat man oft auch folgende Konstrukte:
if(this->_parent->_children[this->_parent->_fillfactor-1] < this->_left->_parent->_children[this->_left->_parent->_fillfactor-1])
//Code für Linker Teilbaum kleiner
else
//Code für Rechter Teilbaum kleiner
Wenn man die if-Bedingung zerlegt, kommt man auf ca. folgendes (groß geschrieben heißt Konstante aus der struct Definition, Syntaxfehler möge man mir vergeben
):this->_parent->_fillfactor-1:
*(*(this+PARENT)+FILLFACTOR)-1 //nenne ich einmal x
this->_parent->_children[x]:
(*(this+PARENT))+CHILDREN+x
Das ganze dann noch einmal für den anderen Teilbaum
Wenn man Glück hat, ist der Compiler so intelligent, dass er einiges nicht doppelt berechnet, sondern in den Cache lädt, wenn dieser annimmt, dass sich die Strukturen nicht überlagern (asume no pointer aligning).
Wenn man ein Pech hat, dann wird das aber wirklich 1:1 ausgeführt und man hat nur Load und Store Operationen plus manchmal ein ADD.
Aus Erfahrung kann ich sagen, dass man Fließkomma Operationen eher selten braucht. Von 50/50 kann hier absolut nicht die Rede sein. Fließkomma braucht man nur, wenn man wirklich etwas berechnet und keinen Ablauf programmiert und wenn man die Kommastellen auch braucht (auch eher selten). Ich würde das Verhältnis auf ca. 90/10 schätzen. In den meisten meiner Programme ist die einzige Fließkommaoperation beim Umwandeln von Bytes in MB für die Anzeige.
Ansonsten zu 90% nur Addition, Load, Store, logisches Und, manchmal eine Multiplikation und ganz selten eine Division. Das sieht man eh beim Penryn. Der kann mehr als doppelt so schnell dividieren, aber ist nur 5% schneller und das kommt vom größeren Cache.
Fließkommaleistung ist nur wichtig, wenn man etwas mathematische/physikalisches mit vielen Wurzeln hat bzw. Operationen wie sin,cos etc. das auf Wurzeln basiert.
4.) Wissen wir überhaupt sicher, ob SuperPI wirklich mit Fließkomma Operationen arbeitet, oder das nur mit Integer emuliert. Bei Fließkomma hat man ja immer eine begrenzte Genauigkeit und da man nicht mehr als 64Bit vordefiniert hat, wird das emulieren schwer. Bei Integer kann man ziemlich leicht einen 128Bit Integer draus machen wenn man das Carry Bit nutzt. Bei Fließkomma wüsste ich nicht, dass es da Befehle gibt, mit denen man sagen kann, dass jetzt alles nur Mantisse ist. Es ist mir eh nicht ganz geheuer, wie die es schaffen, Multiplikationen durchzuführen, ohne dass der Aufwand quadratisch mit der Anzahl der Stellen ansteigt.
Ich vermute mal, dass SuperPI Integerberechnungen durchführt oder einfach per Fakultät bestimmte Berechnungen durchführt. Und zwar mit Ganzzahlen. Das könnte auch erklären, wieso der P4 mit 3,73GHz so schnell dabei gewesen ist. Also einfach immerwieder 20000! mal im WinCalculator eingeben und das kommt etwa aufs Selbe raus von der Zeit einer Iteration bei 1M. Könnte dann aber auch eine Fließkoomaberechnung sein. Kann mich nicht genau erinnern was meine Dozentin dazu meinte, ob das float oder integer war.
MfG, Paule
MfG, Paule
Hmmmm....wäre mal interessant zu wissen, mit welcher Methode SuperPI die Kreiszahl berechnet...die 2 Methoden die ich kenne, kann man zmd. mit natürlichen Zahlen (Integer) berechnen.
Edit: Das sollte aber in den Spekulationsteil
Zuletzt bearbeitet:
andr_gin
Grand Admiral Special
- Mitglied seit
- 12.06.2003
- Beiträge
- 3.052
- Renomée
- 24
- Standort
- St. Pölten (60km westlich von Wien)
Der Algorithmus ist ja bekannt:
Die Frage ist nur, wie die Multiplikationen bzw. Divisionen (Wurzel basiert auf Division) ausgeführt werden, ohne dass der Aufwand quadratisch ansteigt.
*2 bzw. /2 ist ja kein Problem. Das ist nur ein Shift. Fürs quadrieren, gibt es vielleicht auch noch einen Trick, aber beim Dividieren (/4t) bzw. Multiplizieren (b*sqrt
) weiß ich nicht, wie man das löschen könnte.
Dass der Aufwand nicht quadratisch ansteigt, sieht man ja sehr gut bei 1M vs. 4M. Das steigt nur logarithmisch bzw. vielleicht logarithmisch zum Quadrat.
Bei 1M und < 1s für eine Iteration bei 3GHz kommt man nur auf 3K Takte pro Dezimalstelle, also ca. 1K Takte pro Binärstelle.
1.) Initial value:
a=1
b=1/sqrt(2)
t=1/4
x=1
2.)
y=a
y=(a+b)/2
b=b*sqrt
t=t-x(y-a)²
x=x*2
3.) Ergebnis:
PI=(a+b)²/(4t)
Die Frage ist nur, wie die Multiplikationen bzw. Divisionen (Wurzel basiert auf Division) ausgeführt werden, ohne dass der Aufwand quadratisch ansteigt.
*2 bzw. /2 ist ja kein Problem. Das ist nur ein Shift. Fürs quadrieren, gibt es vielleicht auch noch einen Trick, aber beim Dividieren (/4t) bzw. Multiplizieren (b*sqrt
) weiß ich nicht, wie man das löschen könnte.Dass der Aufwand nicht quadratisch ansteigt, sieht man ja sehr gut bei 1M vs. 4M. Das steigt nur logarithmisch bzw. vielleicht logarithmisch zum Quadrat.
Bei 1M und < 1s für eine Iteration bei 3GHz kommt man nur auf 3K Takte pro Dezimalstelle, also ca. 1K Takte pro Binärstelle.
gruffi
Grand Admiral Special
Nein, das ist nicht richtig. Wie ich schon sagte, SSE beinhaltet genauso skalare Befehle. SSE hat die x87 FPU mittlerweile vollständig abgelöst und bietet darüber hinaus SIMD, was ja der Vorsatz für SSE war. Neue Anwendungen sollten wirklich kein x87 mehr benutzen. x86-64 CPUs sind sowieso SSE2 inklusive. Das ist zB auch ein Grund, warum AMD beim K10 keine Änderungen an der FPU vorgenommen und lediglich die SSE Pipeline überarbeitet hat.
Es gibt den Quellcode zu SuperPi? Das würde mich mal interessieren. Hast du einen Link dazu? Normal nutzt SuperPi ja kein SSE, da die Anwendung schliesslich von 1995 ist.
Deine Bemerkung zu SSE ist zudem unlogisch. SSE2 ist praktisch SSE für 64 Bit Gleitkomma. SSE ist also genauso sinnvoll oder sinnlos zur Optimierung wie SSE2, je nachdem, ob die Berechnung für 32 oder 64 Bit Genauigkeit durchgeführt werden soll.
Das ist vollkommen richtig, bekommen aber einige Leute gar nicht mit. Bei wenig Nachkommastellen, zB 16K, hat der K8 eine ähnliche Taktleistung wie der Core2. Je mehr das wird, umso mehr kommt der L2 zum tragen. Und hiervon hat der Core2 nicht nur mehr, sondern die Effizienz ist auch höher. Hier wird sich wohl auch der inklusive L1 Cache bemerkbar machen.
SuperPi basiert auf dem Gauss-Legendre Algorithmus. Die Stellen werden dann sicherlich über FFT berechnet. Und ja, SuperPi verwendet jede Menge x87 Instruktionen. Aber wie du schon sagst, relativ zur Gesamtlaufzeit ist das eher ein geringer Teil.
Wie gesagt, FFT.
Da gibt es keinen Trick. Quadrieren ist nichts anderes als x*x.
Zuletzt bearbeitet:
andr_gin
Grand Admiral Special
- Mitglied seit
- 12.06.2003
- Beiträge
- 3.052
- Renomée
- 24
- Standort
- St. Pölten (60km westlich von Wien)
Aber schneller wird es dadurch nicht, wenn man noch auf die Ergebnisse der letzten Operation warten muss.
Ich nehme einfach an, dass die einfach das ganze mit dem Hex Editor bearbeitet haben. So riesig ist die exe ja nicht, dass das so unmöglich wäre. Die haben einfach mit dem Debugger geschaut, welche Codezeilen am Öftesten ausgeführt werden und dann dort geschaut, ob sie etwas optimieren können.
Bei 16K wird der K8 von seinem größeren L1 Cache profitieren, während der Core2 schon über den L2 Cache gehen muss. Bei steigender Länge wird der Core2 aber immer schneller, bis halt auch ihm der Cache ausgeht und dann ist der Unterschied wieder eher kleiner.
Ok dann ist FFT anscheinend der Weg zum Erfolg. Mir ist das mathematisch leider etwas zu abstrakt. Immer wenn es in die Summen und Integrale geht und weniger um Hausverstand, dann steige ich meistens aus.
[/QUOTE]
gruffi
Grand Admiral Special
Darum geht es auch nicht. Ausschliesslich auf SSE zu setzen, bringt einem konsistente SISD/SIMD Verarbeitung. Was im Endeffekt weniger Overhead bedeutet. Schneller als x87 müssen skalare SSE Instruktionen auch nicht sein, Hauptsache dadurch entsteht kein Nachteil.
Da kommt aber nix gescheites bei raus. Man muss den Quellcode schon komplett neu übersetzen. Es ist ja nicht einfach damit getan, x87 Instruktionen durch SSE Instruktionen zu ersetzen. Da kommt noch weit mehr hinzu, zB Speicherausrichtung oder Compileroptimierungen.
