Das sind nicht wirklich IDEs.
@F-kopp
Was meinst du mit API Unterstützung? Wenn es dir nur darum geht, mit welcher IDE du den Portland nutzen kannst, so sollte das mit Visual Studio und Code::Blocks kein Problem sein. Im Gegensatz zum Portland sind die sogar kostenlos. Bei Visual Studio zumindest die Express Editionen.
OK, bei dem ganzen FP Gelaber habe ich doch glatt Lust bekommen, mal ein bisschen mit dem K8 und Core 2 zu spielen. Hat zwar nix mit dem Barca zu tun, vielleicht findet der eine oder andere es trotzdem interessant. Und eventuell kann man für den K10 auch noch einiges ableiten.
Zum Testen stehen mir zwei Systeme zur Verfügung:
AMD Athlon 64 3500+ @2,4 GHz
2 GB DDR2 667
Win XP Pro SP2 32 Bit
Intel Core 2 Duo T5500 @1,66 GHz
1 GB DDR2 667
Win Vista Home Premium 32 Bit
Dazu habe ich eine kleine Anwendung geschrieben, die einen Vergleich zwischen x87 (skalar), SSE2 (skalar) und SSE2 (packed) macht. Packed heisst hier einfach vektorisiert. Es werden 1 Mrd. Durchläufe mit jeweils 16 Vektoradditionen und 4 Double Elementen pro Vektor durchgeführt. Wenn ich Lust habe, mache ich vllt. noch die anderen Grundrechenarten sowie Single Precision. Gemessen wird logischerweise die Zeit. Bandbreite oder Cache, jeweils die Vorteile von AMD und Intel, sollten hier praktisch keine Relevanz haben. Auch der RAM ist kaum von Bedeutung. Gemessen wird also der reine Durchsatz der Recheneinheiten. Lediglich diese und der Takt haben also Auswirkungen. Zum Einsatz kommt lediglich ein Kern. Als Compiler wird folgender verwendet:
g++.exe (GCC) 4.2.1-sjlj (mingw32-2)
So, hier die nackten Zahlen (weniger = besser):
Athlon 64 3500+ @2,4 GHz
Code:
x87 = 35934 msec
SSE (scalar) = 26529 msec
SSE (packed) = 26544 msec
Intel Core 2 Duo @1,66 Ghz
Code:
x87 = 38820 msec
SSE (scalar) = 38791 msec
SSE (packed) = 28996 msec
Der Test ist natürlich vollkommen theoretischer Natur und hat mit Real World Code nichts zu tun. Die Ergebnisse finde ich trotzdem sehr interessant.
Um sie besser vergleichen zu können, rechnen wir die Werte vom K8 mal taktbereinigt um. Ich wollte ihn zwar mittels Muliplikator und HT Takt runtertakten, das BIOS hat auch mitgespielt, unter Windows hat sich trotzdem wieder der originale Multiplikator eingestellt. Mal schauen, ob ich reale Ergebnisse noch nachliefern kann.
Wie auch immer, hier jedenfalls die (theoretischen) Werte vom Athlon 64 3500+ @1,66 GHz:
Code:
x87 = 51952 msec
SSE (scalar) = 38355 msec
SSE (packed) = 38376 msec
Vergleicht man diese Werte mit dem Core 2, ergeben sich für den K8 folgende Differenzen:
Code:
x87 = -33,8%
SSE (scalar) = +1,1%
SSE (packed) - -32,3%
Ohne dem ganzen aufgrund der erwähnten Punkte Allgemeingültigkeit zu attestieren, hier sieht man eigentlich auch das Problem für AMD und warum der Core 2 heller scheint als er wirklich ist, zumindest im FP Bereich. Entweder basieren Anwendungen auf skalaren FP Berechnungen, dann wird aufgrund der Abwärtskompatibilität x87 verwendet. Oder sie werden für SIMD optimiert (SSE packed). Genau hier liegen scheinbar die Stärken des Core 2 mit über 30% Vorsprung pro Takt. Würde man nun sämtliche x87 Altlast über Bord werfen, und für FP ausschliesslich SSE verwenden, egal ob skalar oder vektorisiert, sieht die Sache schon ganz anders aus. Hier liegt selbst der K8 auf Augenhöhe mit dem Core 2 und muss lediglich in SIMD optimierten Bereichen zurückstecken.
Schauen wir nun mal zum K10. Bei dem hat sich die SSE Pipeline ja verdoppelt, also theoretisch doppelte Leistung. Rechnen wir also den SIMD Leistungsfaktor vom K8 gegenüber dem Core 2, ca. 0.75, mal 2, ergibt das ca. 1.5. Genau die 50% Mehrleistung, die man auch beim specfp beobachten konnte. Ich denke daher, dass diese Ergebnisse durchaus richtig sind, und nicht rein auf die überlegene Bandbreite zurückzuführen ist, so wie von Intel Anhängern oftmals propagiert. Für AMD kann man also nur hoffen, dass x87 so schnell wie möglich aus der Softwareentwicklung verschwindet. Für x86-64 Systeme ist Abwärtskompatibilität sowieso kein Argument, SSE(1) und SSE2 ist da praktisch inklusive. Bei skalarer SSE FP Leistung sollte sogar noch mehr als 50% Vorsprung möglich sein, rein theoretisch.
Btw, wen es interessiert, dem kann ich gerne den Quellcode (C++) oder die Binary schicken.
(achja ich
Du weisst doch, es kommt auf die Architektur an.
![Mr.QUAD [kuoat]](/community/data/avatars/m/66/66312.jpg?1577437181){kind=avatar}
Und das als Dipl.Ing.
Zum Beispiel wird dass Compiler-Thema angesprochen, so erfahren das auch Leute die noch nix davon wussten. 
