Erster offizieller Test zum Intel Xeon (45nm) Harpertown mit 1600 FSB

StevensDE · 28.09.2007

Tecchannel hatte die Gelegenheit die neuen Intel Xeon 45nm Harpertown Server Prozessoren mit 12 MB L2 Cache und 1600 FSB zu testen.

In diesen Tests konnte sich Intels neue 45nm Prozessoren deutlich von 65nm Prozessoren absetzen und auch der neue K10 Opteron ist im Vergleich dabei.

Hier der Test:

45-nm-Quad-Core: Intels nächste Xeon-Generation Harpertown im Test
http://www.tecchannel.de/index.cfm?pid=212&pk=1729228&p=1

Ein kleines Zitat aus dem Fazit:

Intel demonstriert mit seiner 45-nm-Generation Xeon „Harpertown“ frühzeitig, dass sich der Performance-Abstand zu AMDs K10-Opterons wieder vergrößern lässt. Besonders tendenziell „schwächelnden“ Disziplinen wie sehr speicherintensiven Applikationen verschafft der Harpertown mit seinem größerem Cache und vor allem dem schnelleren FSB1600 wieder höhere Wertungen.
....
Die 3,0-GHz-Harpertowns setzen sich dagegen bei SPECfp_rate_base2006 wieder mit 16 Prozent mehr Performance von den K10-Opterons ab. Hier hilft auch die für FSB1600-Xeons notwendige Stoakley-Plattform mit. Denn neben dem für Quad-Core-Xeons optimierten Seaburg-Chipsatz mit dem 64 MByte Snoop-Filter ermöglichen die schnelleren DDR2-800-FB-DIMMs mehr Speicherbandbreite.

Hier mal ein paar Benches & Screenshots:

1. SPECint_rate_base2006

2. SPECfp_rate_base2006

3. CPU2000 Integer: SPECint_rate_base2000

4. CPU2000 Floating Point: SPECfp_rate_base2000

Für weitere Benchmarks einfach oben auf den Tecchannel Link klicken.
Dann kommt ihr zum original Review.

Quelle: Tecchannel

Mein persönliches Fazit:

Ich hätte nicht gedacht, dass Intel es schafft nochmal so viel Performance aus der aktuellen Architektur rauszuholen. 45nm, 12 MB L2 Cache bringt also doch eine ganze Menge. Zudem verbrauchen die neuen 45nm Xeon Prozessoren weniger Strom als die 65nm Varianten.

FireStar · 28.09.2007

Ich muss Dich echt mal loben, dein Post war völlig unparteiisch.

(keine Ironie)

Nur Schade, dass sie nicht den K10 mit 2,5Ghz mit testen konnten, bei den umfangreichen Benchmarks hätte mich mal die Skalierung interessiert.

annixp · 28.09.2007

Nicht schlecht :bigok:

Dann werd ich wohl doch keine Angst haben müssen nochmal auf AMD und damit verbunden DDR2 runterwechseln zu müssen :fresse:

StevensDE · 28.09.2007

annixp schrieb:
Nicht schlecht

Dann werd ich wohl doch keine Angst haben müssen nochmal auf AMD und damit verbunden DDR2 runterwechseln zu müssen

Naja, ausgeschlossen ist es noch nicht.

Ich bin ja mal hochgespannt auf die ersten Phenom X4 Benchmarks wodurch man mit OC sicher auch die Möglichkeit haben wird, mal einen Phenom X4 mit 3 GHz zu Benchen und dann bin ich ja mal wirklich hochgespannt, was der bei der Takrate an Leistung rüberbringt.

Man muss ja schon zugeben, dass der 2 GHz Opteron von AMD wirklich sehr niedrig getaktet ist. Hochgespannt bin ich in dem Vergleich auch auf die Opteron 2,5 GHz Variante, welche ja dieses Jahr noch kommen soll.

Tecchannel wird sicherlich auch dazu dann einen Vergleichsbenchmark machen und dann können wir wirklich gespannt sein.

Mr.QUAD [kuoat] · 28.09.2007

Das sieht wirklich sehr gut aus, ich bin auch überrascht was alleine die Stoakley-Plattform schon aus dem "alten" Xeon herausholt.
Aber auch der Cache des "Penryn" scheint den Flaschehals FSB sehr zu entlasten. Interessant wäre auch der bloße Unterschied zwischen Fully Buffered DIMM 667er und 800er. Schade dass nicht höher getaktete K10 im Vergleich zu sehen sind, wobei man ja eh nur die K10-Benches der c't ernst nehmen kann (ohne Intels Compiler-Sauerei). Mal abwarten was noch kommt.

~Benni~ · 28.09.2007

mh gibts da überhaupt noch speedstep? multi 6 is ja dann nich mehr viel...

sorry frage hat sich erledigt, 6 is weiterhin kleinster multi, was ein schwachsinn

Chrisch · 28.09.2007

FireStar schrieb:
Ich muss Dich echt mal loben, dein Post war völlig unparteiisch. (keine Ironie)

Nur Schade, dass sie nicht den K10 mit 2,5Ghz mit testen konnten, bei den umfangreichen Benchmarks hätte mich mal die Skalierung interessiert.

hier gibt es auch vergleiche mitm Opteron 2360 SE (2.5Ghz Barcelona)

http://techreport.com/articles.x/13224/1

~Benni~ schrieb:
mh gibts da überhaupt noch speedstep? multi 6 is ja dann nich mehr viel...

sorry frage hat sich erledigt, 6 is weiterhin kleinster multi, was ein schwachsinn

wieso schwachsinn? wie schon mehrfach gezeigt wurde bringt ein geringerer Takt kaum weniger
Stromverbrauch. Nur die VCore macht was aus und die kann je nach Board bis auf 1v gesenkt
werden (bzw macht das Board selbst wenn EIST / C1E aktiviert ist).

[HOT] · 28.09.2007

Mal c't Tests unter 64Bit mit SSE4.1 optimiertem Compiler abwarten

.

~Benni~ · 28.09.2007

Chrisch schrieb:
wieso schwachsinn? wie schon mehrfach gezeigt wurde bringt ein geringerer Takt kaum weniger
Stromverbrauch. Nur die VCore macht was aus und die kann je nach Board bis auf 1v gesenkt
werden (bzw macht das Board selbst wenn EIST / C1E aktiviert ist).

hätte die hoffnung das man die vcore halt noch n stück weiter senken könnte...

zum ideln reichen immernoch LOCKER 1 ghz

und das dann bei 0,8 volt oder weniger wie bei nem laptop wär geil.

F-kopp · 28.09.2007

den gibts schon länger: http://www.anandtech.com/IT/showdoc.aspx?i=3099

StevensDE · 28.09.2007

F-kopp schrieb:
den gibts schon länger: http://www.anandtech.com/IT/showdoc.aspx?i=3099

Jo, mir persönlich gefällt der Test von Tecchannel besser.

[HOT] · 29.09.2007

Der Test ist sowas von für die Tonne...

Wir setzen die SPEC-Benchmarks unter Windows Server 2003 R2 x64 praxisnah ein und kompilieren sie für das Base-Rating. Dazu verwenden wir Intel C++ 10.0 und Fortran 10.0 in der 64-Bit-Version und MS Visual Studio 2005 .NET für alle Floating-Point-Tests. Spezielle Bibliotheken für die Optimierung auf den jeweiligen Prozessor kommen nicht zum Einsatz.

Nur Intel Compiler verwendet, ohne die AMD Blockierungen rauszupatchen. Tja, so ein Mist

. Absolut nichtssagen ggü dem K10. So kann man auch nur testen, wenn man von Intel gesponsort wird

. Wer schon einen Intel Compiler einsetzt, muss genauso einen Portland oder wenigstens ein aktuelles GCC einsetzen, um überhaupt einigermassen brauchbare Vergleichswerte zu bekommen. Wenigstens hat man auf SH verzichtet.

mr.dude · 29.09.2007

[HOT] schrieb:
Nur Intel Compiler verwendet, ohne die AMD Blockierungen rauszupatchen.

Ich denke nicht, dass der ICC "AMD Blockierungen" hat. Er optimiert für Intel Architekturen nur einfach besser. Ich halte solche Tests auch für aussagekräftiger, wenn sie mit einem "neutralen" Compiler durchgeführt werden, z.B. dem GCC.

[HOT] · 29.09.2007

AMD Prozessoren werden im Intel Compiler definitiv über die CPUID blockiert:
http://www.heise.de/ct/07/20/019/

Anandtech und einige andere der mit dem Barcelona beglückten Websites sind in der Kürze der Zeit dem Prozessor jedoch zumeist nur mit alter Software oder mit Kompilaten des Konkurrenten Intel zu Leibe gerückt, die den neuen Chip recht stiefmütterlich behandeln. Das gilt vor allem dann, wenn man die diskriminierende CPUID-Abfrage des Intel-Compilers nicht herauspatcht. Sonst führt nämlich der Compiler bei einigen Benchmarks bestimmte Optimierungen, etwa die Autovektorisierung, einfach nicht aus. Wir haben daher lieber zu den von AMD empfohlenen Compilern der Portland Group gegriffen, deren neueste 7.1-Betaversion schon den Barcelona samt seiner SSE4a-Befehle unterstützt.

Es ist doch logisch, dass, wenn man einen Intel Compiler für den ganzen Test verwendet, nur Mist für AMD CPUs dabei rauskommt...

Mondrial · 29.09.2007

StevensDE schrieb:
Mein persönliches Fazit:

Ich hätte nicht gedacht, dass Intel es schafft nochmal so viel Performance aus der aktuellen Architektur rauszuholen. 45nm, 12 MB L2 Cache bringt also doch eine ganze Menge. Zudem verbrauchen die neuen 45nm Xeon Prozessoren weniger Strom als die 65nm Varianten.

Es ist recht wenig Mehrperformance wenn man das in die Interpretation mit einbeziehen würde:

StevensDE schrieb:
Ein kleines Zitat aus dem Fazit:

Intel demonstriert mit seiner 45-nm-Generation Xeon „Harpertown“ frühzeitig, dass sich der Performance-Abstand zu AMDs K10-Opterons wieder vergrößern lässt. Besonders tendenziell „schwächelnden“ Disziplinen wie sehr speicherintensiven Applikationen verschafft der Harpertown mit seinem größerem Cache und vor allem dem schnelleren FSB1600 wieder höhere Wertungen.
....
Die 3,0-GHz-Harpertowns setzen sich dagegen bei SPECfp_rate_base2006 wieder mit 16 Prozent mehr Performance von den K10-Opterons ab. Hier hilft auch die für FSB1600-Xeons notwendige Stoakley-Plattform mit. Denn neben dem für Quad-Core-Xeons optimierten Seaburg-Chipsatz mit dem 64 MByte Snoop-Filter ermöglichen die schnelleren DDR2-800-FB-DIMMs mehr Speicherbandbreite.

mr.dude · 29.09.2007

[HOT] schrieb:
AMD Prozessoren werden im Intel Compiler definitiv über die CPUID blockiert:
http://www.heise.de/ct/07/20/019/

Also dass Intel für die eigenen CPUs besser optimiert als für die der Konkurrenz, kann man sich eigentlich denken. Aber sollte die cpuid Geschichte stimmen, haut mich das echt aus den Socken. Shame on you, Intel. Da muss man zu jedem Benchmark ja noch wissen, ob die Anwendung mit dem ICC kompiliert wurde. :eek:

Mich würde mal interessieren, woher die c't das weiss. Haben die die Assembler Listings studiert oder was?

Mondrial schrieb:
Es ist recht wenig Mehrperformance wenn man das in die Interpretation mit einbeziehen würde:

Naja, ob 0-10% Mehrleistung pro Takt für einen Shrink wenig oder viel ist, lass ich jetzt mal aussen vor. Das kann jeder selbst entscheiden. Für mich ist eher entscheidend, dass Intel nach wie vor schnelle Recheneinheiten hat, die gesamte Infrastruktur aber hinten und vorne AMD nichts entgegenzusetzen hat. Wenn man alleine durch Cache und FSB Steigerungen einen Leistungszuwachs bis in den zweistelligen Prozentbereich verbuchen kann, ist einfach etwas am Konzept faul.

[HOT] · 29.09.2007

mr.dude schrieb:
Also dass Intel für die eigenen CPUs besser optimiert als für die der Konkurrenz, kann man sich eigentlich denken. Aber sollte die cpuid Geschichte stimmen, haut mich das echt aus den Socken. Shame on you, Intel. Da muss man zu jedem Benchmark ja noch wissen, ob die Anwendung mit dem ICC kompiliert wurde.
Mich würde mal interessieren, woher die c't das weiss. Haben die die Assembler Listings studiert oder was?

Das hat Tradition. Ohne Intel CPUID bekommt man für keine CPU die Optimierungen des Compilers ab. Das war schon immer so, schon zu P2 vs. K6 Zeiten. Meist wird aber nicht der Intel Compiler verwendet, das ist nur für wirklich performancekritische Serveranwendungen interessant. Die SPEC repräsentiert eine Referenz, die unter optimalen Bedingungen das meisten aus den CPUs rausholt, um eine reale Vergleichsgrundlage zu haben. Deswegen wird auch kein Compiler dafür vorgeschrieben, sondern nur empfohlen. Ein Kompilat mit Intel Compiler hat keine Aussagekraft für AMD CPUs, das ist nunmal so.
Normale Software (z.B. Spiele) wird aus Kompatibilitätsgründen mit Standardcompilern, vor allem mit VC++ Compilern von M$ kompiliert. Hier gibt es wenige spezifische Optimierungen, hier ist immernoch SSE2 Standard.

[...]

StevensDE · 29.09.2007

Bitte lasst den Thread nicht in einen Krieg ausbrechen.

Ich habe den Thread eigentlich so aufgebaut, dass man über die Leistungssteigerung der Core 2 Xeon´s gegenüber den Harpertown Xeons diskutieren kann.

Ich finde 5-10% schon eine ganze Menge, dafür dass es die selbe Architektur ist. Von daher lassen wir am besten den K10 mal aussen vor. Dafür gibt es ja den K10 Thread.

Danke für euer Verständnis.

Mondrial · 29.09.2007

StevensDE schrieb:
Ich finde 5-10% schon eine ganze Menge, dafür dass es die selbe Architektur ist. Von daher lassen wir am besten den K10 mal aussen vor. Dafür gibt es ja den K10 Thread.

Mit höherem FSB, mehr Cache und schnellerem Speicher...nicht wirklich beeindruckend...

mr.dude · 29.09.2007

[HOT] schrieb:
Das hat Tradition. Ohne Intel CPUID bekommt man für keine CPU die Optimierungen des Compilers ab.

Eher weniger. Mittels cpuid erhält man ja eigentlich nur Informationen zur CPU, also Hersteller, Stepping, Support für Befehlssatzerweiterungen, usw. Das hat auf Optimierungen erst mal keinen direkten Einfluss und hindert keinen Compiler daran, diese durchzuführen. Selbst wenn eine CPU z.B. kein SSE unterstützt, kann ich eine Anwendung dahingehend trotzdem optimieren. Dann kommt zur Laufzeit eben eine Hardware Exception, was Betriebssysteme i.d.R. mit der Terminierung des Prozesses quittieren. Daher würde mich einfach mal interessieren, wie c't zu der Aussage kommt. Entweder sie haben Einblick in den ICC Quellcode, was ich mir kaum vorstellen kann. Oder sie schauen sich eben die Assembler Listings genau an. Ich hatte den ICC zwar noch nicht in den Händen, nehme aber mal an, der hat entsprechende Optionen, welche zu erzeugen.

Thorsti · 29.09.2007

Mondrial schrieb:
Mit höherem FSB, mehr Cache und schnellerem Speicher...nicht wirklich beeindruckend...

Doch, dass IST beeindruckend.
Wie Intel es schafft, mit vergleichsweise geringen Mitteln mehr Performance aus dem Core zu holen. Meinen Respekt. :bigok:

[HOT] · 29.09.2007

mr.dude schrieb:
Eher weniger. Mittels cpuid erhält man ja eigentlich nur Informationen zur CPU, also Hersteller, Stepping, Support für Befehlssatzerweiterungen, usw.

Die CPUID beinhaltet eine HerstellerID, die der Hersteller der CPU mitgibt. Bei Intel ist das z.B. "geniuintel". Und der Compiler fragt exakt die ID ab um zu entscheiden, ob Optimierungen zulässig sind oder eben nicht.

Das hat auf Optimierungen erst mal keinen direkten Einfluss und hindert keinen Compiler daran, diese durchzuführen. Selbst wenn eine CPU z.B. kein SSE unterstützt, kann ich eine Anwendung dahingehend trotzdem optimieren. Dann kommt zur Laufzeit eben eine Hardware Exception, was Betriebssysteme i.d.R. mit der Terminierung des Prozesses quittieren. Daher würde mich einfach mal interessieren, wie c't zu der Aussage kommt. Entweder sie haben Einblick in den ICC Quellcode, was ich mir kaum vorstellen kann. Oder sie schauen sich eben die Assembler Listings genau an. Ich hatte den ICC zwar noch nicht in den Händen, nehme aber mal an, der hat entsprechende Optionen, welche zu erzeugen.

Die c't/ix kommt durch jahrelange Tests mit Compilern zu der Erfahrung. Es ist nunmal so, dass der Intel Compiler nach der CPUID entscheidet, ob Optimierungen zulässig sind oder der Compiler im "kompatibilitätsmudus" läuft. Es ist möglich die ID rauszupatchen, so dass man auch mit AMD CPUs brauchbaren Code bekommt, der sich nicht nur auf Standard IA32 Code beschränkt.
Einiges zum dazu:
http://www.swallowtail.org/naughty-intel.html
http://techreport.com/discussions.x/8547

Die Vorgehensweise von Intel ist sogar Teil des Kartellverfahren bei der EU gegen Intel.

dröfl · 29.09.2007

Mondrial schrieb:
Mit höherem FSB, mehr Cache und schnellerem Speicher...nicht wirklich beeindruckend...

ich finds super

F-kopp · 29.09.2007

[HOT] schrieb:
Die CPUID beinhaltet eine HerstellerID, die der Hersteller der CPU mitgibt. Bei Intel ist das z.B. "geniuintel". Und der Compiler fragt exakt die ID ab um zu entscheiden, ob Optimierungen zulässig sind oder eben nicht.

Die c't/ix kommt durch jahrelange Tests mit Compilern zu der Erfahrung. Es ist nunmal so, dass der Intel Compiler nach der CPUID entscheidet, ob Optimierungen zulässig sind oder der Compiler im "kompatibilitätsmudus" läuft. Es ist möglich die ID rauszupatchen, so dass man auch mit AMD CPUs brauchbaren Code bekommt, der sich nicht nur auf Standard IA32 Code beschränkt.
Einiges zum dazu:
http://www.swallowtail.org/naughty-intel.html
http://techreport.com/discussions.x/8547

Die Vorgehensweise von Intel ist sogar Teil des Kartellverfahren bei der EU gegen Intel.

Richtig.
was mr. Dude da geschrieben hat, stimmt nicht!

Der ****** ist so einfach umzusetzen:

Code:

int edx;
	int ebx;
	int ecx;
	  union {
	    int i[4];
	    char c[16];
	  } u;

	  __asm__ ("cpuid"
		   : "=b" (ebx), "=d" (edx), "=c" (ecx)
		   : "a" (0));

	  u.i[0] = ebx;
	  u.i[1] = edx;
	  u.i[2] = ecx;
	  u.i[3] = 0;



    wxString scpu;
    scpu.Printf("%s ", u.c );

if(scpu != "AuthenticAMD")
{
  //Funktionsaufruf der Autovektorisierung
}

mr.dude · 29.09.2007

F-kopp schrieb:
Richtig.
was mr. Dude da geschrieben hat, stimmt nicht!

Wohl kaum. Hast du meinen Beitrag überhaupt verstanden? Glaub mir, ich kenne mich damit sicherlich besser aus als du. Btw, unterstützt der ICC überhaupt AT&T Syntax? :fresse:

Ich streite [HOT]'s Aussage ja auch nicht ab. Dass Intel auch hier zu fiesen Tricks greift, wundert mich absolut nicht. Mich würde nur mal interessieren, wie c't zu der Erkenntnis kommt.

edit:
Ah ok, ich sehe gerade bei [HOT]'s Links, da werden Assembler Listings des Debuggers analysiert. Vermutlich bezieht sich die c't auf solche Quellen oder hat ähnliche Analysen gemacht.

F-kopp · 30.09.2007

mr.dude schrieb:
Wohl kaum. Hast du meinen Beitrag überhaupt verstanden? Glaub mir, ich kenne mich damit sicherlich besser aus als du. Btw, unterstützt der ICC überhaupt AT&T Syntax?

Ich streite [HOT]'s Aussage ja auch nicht ab. Dass Intel auch hier zu fiesen Tricks greift, wundert mich absolut nicht. Mich würde nur mal interessieren, wie c't zu der Erkenntnis kommt.

edit:
Ah ok, ich sehe gerade bei [HOT]'s Links, da werden Assembler Listings des Debuggers analysiert. Vermutlich bezieht sich die c't auf solche Quellen oder hat ähnliche Analysen gemacht.

Sry meine Augen waren gereitzt.
Ich hab da was anderes gelesen, als da stand.

So wie HOT auf das erste Zitat reagiert hat, sah es so aus, als ob du bestreiten würdest, dass man mit CPUID die Daten über Hersteller usw. bekommt.

Ob ICC das ünterstützt, weis ich nicht.
Aber man kann auch inline asm für den Intel verwenden.
sieht dann nur so aus:

Code:

#include <iostream>

int main()
{
    char vendor_string[13];
    vendor_string[12] = 0;

    __asm xor  eax, eax   
    __asm cpuid

    __asm mov   dword ptr vendor_string[0], ebx
    __asm mov   dword ptr vendor_string[4], edx
    __asm mov   dword ptr vendor_string[8], ecx
   
    std::cout << vendor_string << std::endl;


}

mr.dude · 30.09.2007

F-kopp schrieb:
So wie HOT auf das erste Zitat reagiert hat, sah es so aus, als ob du bestreiten würdest, dass man mit CPUID die Daten über Hersteller usw. bekommt.

Nein. Ich fand den Satz nur seltsam:

[HOT] schrieb:
Ohne Intel CPUID bekommt man für keine CPU die Optimierungen des Compilers ab.

Mir ist immer noch nicht ganz klar, was er damit meinte. Was ist denn "Intel CPUID"?

F-kopp schrieb:
Ob ICC das ünterstützt, weis ich nicht.

Hehe, die Frage war eher rhetorisch. Es sah einfach nur komisch aus, Code für einen Intel Compiler und dann nicht mal Asm Intel Syntax.

Milchtrinker · 30.09.2007

Mal ganz ehrlich, wo soll denn ein riesen Leistungssprung herkommen? Durch mehr Cache, einen höheren FSB und neuen Speicher bekommt man eben keine neue Super-CPU, wenn man es realistisch betrachtet. Immerhin kann jetzt der Takt weiter gesteigert werden, wobei der K10 mit steigenden Taktraten vermutlich schnell aufschließen wird, nicht zuletzt dank der guten Skalierung. Aber da lassen wir uns mal überraschen.
Hinzugefügter Post:

mr.dude schrieb:
Mir ist immer noch nicht ganz klar, was er damit meinte. Was ist denn "Intel CPUID"?

Grob gesagt kann die Software durch die Abfrage die Zusatzfunktionen des Prozessors wie Befehlssätze á la SSE nutzen. Siehe auch den Wikipedia-Artikel.

StevensDE · 30.09.2007

Milchtrinker schrieb:
Mal ganz ehrlich, wo soll denn ein riesen Leistungssprung herkommen? Durch mehr Cache, einen höheren FSB und neuen Speicher bekommt man eben keine neue Super-CPU, wenn man es realistisch betrachtet. Immerhin kann jetzt der Takt weiter gesteigert werden, wobei der K10 mit steigenden Taktraten vermutlich schnell aufschließen wird, nicht zuletzt dank der guten Skalierung. Aber da lassen wir uns mal überraschen.

Ich sehe das ähnlich. Was Intel mit 45nm an Verbesserungen gemacht hat (SSE4, 1333/1600 FSB, mehr Cache) ist an sich eine gute Sache.

Die haben die ohnehin schon sehr gute Core 2 Architektur weiter ausgebaut.
Das muss man erst einmal festhalten.

Wegen der Intel Compiler Geschichte: Der Intel Compiler ist eine super Sache. Dabei geht es Intel zu 100% Sicherheit nicht darum um Benchmarks zu gewinnen. Es gibt sehr viele große IT Konzerne die ihre Software selbst schreiben. Wenn man dann die eigene Software auf den Prozessor optimiert kann man eine höhere Performance erzielen und das kommt den Kunden ja sehr entgegen. Es gibt ja sehr viele Konzerne die Software schreiben und diese dadurch an ihre Server Prozessoren anpassen können.

Von daher verstehe ich nicht, warum hier der Intel Compiler so schlecht gemacht wird.

AMD könnte ja auch einen eigenen Compiler schreiben und diesen seinen Kunden anbieten. Das ist jedem CPU Hersteller selbst überlassen.

mr.dude · 30.09.2007

Milchtrinker schrieb:
Grob gesagt kann die Software durch die Abfrage die Zusatzfunktionen des Prozessors wie Befehlssätze á la SSE nutzen. Siehe auch den Wikipedia-Artikel.

Keine Sorge, mir ist schon klar, was "CPUID" ist. Nur nicht, was [HOT] mit dem Satz, speziell "Intel CPUID" meinte.

StevensDE schrieb:
Von daher verstehe ich nicht, warum hier der Intel Compiler so schlecht gemacht wird.

AMD könnte ja auch einen eigenen Compiler schreiben und diesen seinen Kunden anbieten. Das ist jedem CPU Hersteller selbst überlassen.

Naja, letztendlich ist der ICC Intels geistiges Eigentum und sie können damit machen was sie wollen. Es wirft trotzdem kein gutes Licht auf Intel. Mal wieder. Und wenn sie Kunden vorenthalten, dass für AMD CPUs weniger optimiert wird, und das scheint teilweise drastische Auswirkungen zu haben, um diese zu täuschen, dann ist das nichts anderes als Wettbewerbsverzerrung. Mich würde es echt nicht wundern, wenn sie neben den Knebelverträgen dafür extra noch einen auf'n Deckel bekommen.

Erster offizieller Test zum Intel Xeon (45nm) Harpertown mit 1600 FSB

Banned

Enthusiast

Enthusiast

Banned

Neuling

Neuling

Legende

Enthusiast

Neuling

Semiprofi

Banned

Enthusiast

Urgestein

Enthusiast

Urgestein

Urgestein

Enthusiast

Banned

Urgestein

Urgestein

Neuling

Enthusiast

Semiprofi

Semiprofi

Urgestein

Semiprofi

Urgestein

Enthusiast

Banned

Urgestein

Ähnliche Themen