Wie stehts mit Compilern für AMD?

[pippo]

In anbetracht des anstehen Conroes frage ich mich, wie es bei AMD zur Zeit mit Compilern steht. Meines wissens ist man ja immer noch auf PGI, GCC ... angewiesen. Wird sich das in absehbarer Zeit ändern oder steht von irgendeinem Hersteller eine neue Version an?

Hab jetzt schon des öfteren gelesen, dass noch eiges Potetial im K8 schlummert, die die 20% des Conroes teilweise bei weitem übertreffen.

Eine CPU ist leider nur so gut, wie der Compiler der ihr zur Seite steht.

[Ganon]

pippo[/POST]']Hab jetzt schon des öfteren gelesen, dass noch eiges Potetial im K8 schlummert, die die 20% des Conroes teilweise bei weitem übertreffen.

Garantiert nicht. ;)

Ein "besserer" Compiler als die jetzigen holt niemals weit über 20% Mehrleistung in normalen Anwendungen ( !!! kommt mir jetzt nicht mit kleinen Mathe-Beispielen !!! ) raus.

AMD-Fans können es auch mal langsam einsehen, das Intel auch gute CPUs bauen kann und baut. Da muss man nicht mit solchen Gerüchten kommen. Klingt ja fast schon wie "damals" bei Apple. "Wenn, dann könnte der G4/G5 schneller". ;)

[BlackBirdSR]

pippo[/POST]']In anbetracht des anstehen Conroes frage ich mich, wie es bei AMD zur Zeit mit Compilern steht. Meines wissens ist man ja immer noch auf PGI, GCC ... angewiesen. Wird sich das in absehbarer Zeit ändern oder steht von irgendeinem Hersteller eine neue Version an?

Hab jetzt schon des öfteren gelesen, dass noch eiges Potetial im K8 schlummert, die die 20% des Conroes teilweise bei weitem übertreffen.

Eine CPU ist leider nur so gut, wie der Compiler der ihr zur Seite steht.

Gerade die von AMD für die SpecSuite verwendeten Compiler sind auf maximale Performance beim K8 getrimmt.
Viel mehr geht einfach nicht. Und schon gar nicht im Bereich von Conroe.
Der K8 hat einfach (wie jede CPU) viele Engpässe und Schwachstellen, die zu Performanceverlust gegenüber dem theoretischen Maximum führen. Da ist der K8L gefragt.
Intel hat beim Conroe systematisch Schwachstellen des PPro/PM entfernt.

[pippo]

@ Ganon
Das sind keine Gerüchte. Zum einen hat es unser Professer gesagt, zum anderen hab ich es im Internet gelesen. Allerdings ist das schon länger her und ich finde momentan die Quellen nicht mehr.

Dass sich das nicht auf jede Anwendung beziehen lässt, ist schon klar. Aber zum Beispiel hier (http://www.zdnet.de/news/hardware/0,39023109,2136949,00.htm) wird ja auch deutlich, was machbar ist



@ BlackBirdSR
Mir ist schon klar, dass sich sowas nicht auf alle Anwendungen bezieht. Es gibt bestimmt genug Bereiche, in denen nicht mehr viel machbar ist. Ich glaube aber nicht, dass ein Compiler der nicht speziell für eine CPU optimiert wurde, überall den letzten Rest an Performance rausholen kann.

Intel hat sicher nicht umsonst eigene Compiler mit einem verdammt guten Ruf

[AnarchX]

Wie sieht es mit der Performance unter 64bit aus, da konnte der K8 doch AFAIR auf bestimmte Einheiten zugreifen die unter 32bit nicht benutzbar waren?

[Trap]

20% Unterschied unter Compilern ist doch nix besonderes. Allerdings wäre es mal etwas besonderes, wenn ein anderer Compiler als ICC am schnellsten wäre.

ICC wird sicher keinen besonders auf AMD-CPUs optimierten Code erzeugen und solange der ICC der Compiler mit dem schnellste Code ist wird AMD gegenüber Intel sicher nicht aufholen.

[Ganon]

pippo[/POST]']@ Ganon
Das sind keine Gerüchte. Zum einen hat es unser Professer gesagt, zum anderen hab ich es im Internet gelesen. Allerdings ist das schon länger her und ich finde momentan die Quellen nicht mehr.

Wie schön das man Gerüchte meist im Internet liest. ;) Und "mein Professor" ist keine gute Quelle.

pippo[/POST]']
Dass sich das nicht auf jede Anwendung beziehen lässt, ist schon klar. Aber zum Beispiel hier (http://www.zdnet.de/news/hardware/0,39023109,2136949,00.htm) wird ja auch deutlich, was machbar ist

Wie ich sagte will ich keine Mathe-Sachen haben. Da ist klar, das man da teils viel machen kann. Ich will richtige Anwendungen. Das da ist Fortran. Das ist nur für "Normalsterbliche" Recht uninteressant.

Denn bei "normalen" Anwendungen (Objektorientierung, Notifications, dynamisches Binden etc. pp.) sind die Compiler-Unterschiede recht gering, bis auf ein paar "Hot-Spots".

edit:
Siehe auch die ganzen SIMD-libc. Alle haben in ihren Tests teilweise X-fache Performance gegenüber den normalen libcs. Aber benutzt man diese dann in "normalen" Anwendungen, ist der Performance-Vorteil im einstelligen % Bereich.

[BlackBirdSR]

AnarchX[/POST]']Wie sieht es mit der Performance unter 64bit aus, da konnte der K8 doch AFAIR auf bestimmte Einheiten zugreifen die unter 32bit nicht benutzbar waren?

nein.
Er kann nur auf doppelt so viele Register für SSE/2 und Integerrechnungen zurückgreifen.
Das bringt aber auch keine 20% :)

[Ganon]

BlackBirdSR[/POST]']Das bringt aber auch keine 20% :)

pippo redet übrigens von weit über 20%. ;)

[Gast]

Trap[/POST]']ICC wird sicher keinen besonders auf AMD-CPUs optimierten Code erzeugen und solange der ICC der Compiler mit dem schnellste Code ist wird AMD gegenüber Intel sicher nicht aufholen.
Athlons werden vom ICC sogar gezielt benachteiligt, nicht umsonst wird die CPUID-Abfrage des ICC bei SPEC-Benchmarks der c’t vorher rausgepatcht.

[Avalox]

AMD fördert zwei Compiler Bauer.

PathScale schon lange. Allerdings Linux only

Nun seit kurzen aber auch Portland Group PGI Compiler; alle möglichen OS mit K8 Optimierungen

[(del)]

Welche Firma, geschweige Hobbyisten, kompiliert schon mit ICC?

Wer kann mir denn sagen mit was zB. Fear, Nero6, TotalCommander und der Catalyst kompiliert sind? =)

[Bokill]

Avalox[/POST]']AMD fördert zwei Compiler Bauer.

PathScale schon lange. Allerdings Linux only

Nun seit kurzen aber auch Portland Group PGI Compiler; alle möglichen OS mit K8 Optimierungen Na ja sooo kürzlich auch nicht ... ich hatte bei P3D mal einen Thread zu AMD gewogenen Kompilern angefangen, der düfte 2003 angefangen worden sein, schon sehr früh war da auch die Portland Group drinne.

1. Das "Problem" ist, dass Intel nun mal wirklich prima Kompiler baut, und
2. die gesamte x86 Software-Industrie bis vor ziemlich 3 Jahren kaum ein Grund sah, auch mal für andere Chips, als für Intel CPUs zu schreiben und zu optimieren. Da kämpfen andere CPU Designs grundsätzlich gegen an, ob nun idt (nun bei VIA) einstmals mit deren Winchip, Cyrix (nun bei VIA), Transmeta (die jetzt auch nur noch röcheln), und AMD (die nun seit 3 Jahren ein eigenes Biotop mit AMD64 pflegen).

Man kann bemerken, dass immerhin Solaris 10 parallel auf SPARC CPUs und dem K8 parallel entwickelt wurde. So etwas konnte AMD bislang kaum sagen, dass ein Betriebssystem von Grund auf frisch mit deren CPUs entwickelt wurde. Die Unterstützung seitens Microsoft war da gegnüber doch recht halbherzig. Wie lange war der Microsoft-Mediaplayer blind gegenüber den 3DNow/SSE Extensions bei der AMD K6/K7 Familie?

MFG Bobo(2006)

[HellHorse]

BessereHälfte[/POST]']Welche Firma, geschweige Hobbyisten, kompiliert schon mit ICC?
Gentoo User :D

[Trap]

Zu vielen open-source Video-/Audiocodecs gibt es Seiten die ICC-Compilate anbieten.

[Coda]

BessereHälfte[/POST]']Wer kann mir denn sagen mit was zB. Fear, Nero6, TotalCommander und der Catalyst kompiliert sind? =)
Mit ziemlicher Sicherheit alle mit dem Microsoft-Compiler. VC++ 2005 ist auch gar nicht so schlecht was Optimierung angeht.

[Matti@work]

der Total-Commander wird afair mit Delphi erzeugt

[Mastermind]

Moment mal. Ich hoffe diese allgemeine Fragen passen hier rein.

Aber soll das etwa heißen, dass die Firmen sich bei der Softwareherstellung für einen Compiler entscheiden müssen und dieser immer auf einen bestimmten Prozzie optimiert ist?

Gibt es auch "allgemeine" Compliler?

Wenn ein Compiler nicht auf möglichst schnellen Code optimiert ist, worauf denn dann?

Gibt es die Möglichkeit so zu compilieren bzw. gibt es solche Compiler, die Software so kompilieren, dass sie beim Start erkennt welche CPU im PC ist und sich dann so einstellt, dass sie darauf optimiert läuft und so aus jeder ihr bekannten CPU das Meiste an Leistung rausholt? Denn eigentlich wäre so ein Vorgehen das einzig sinnvolle und logische!

[pippo]

Imho kannst du auf 2 Dinge optimieren: kleine Dateien oder schnellen Code

[Coda]

Mastermind[/POST]']Aber soll das etwa heißen, dass die Firmen sich bei der Softwareherstellung für einen Compiler entscheiden müssen und dieser immer auf einen bestimmten Prozzie optimiert ist?
Nö.

Mastermind[/POST]']Gibt es auch "allgemeine" Compliler?
Ja.

Mastermind[/POST]']Wenn ein Compiler nicht auf möglichst schnellen Code optimiert ist, worauf denn dann?
Kleinen Code oder schnelle Kompilierzeit.

Mastermind[/POST]']Gibt es die Möglichkeit so zu compilieren bzw. gibt es solche Compiler, die Software so kompilieren, dass sie beim Start erkennt welche CPU im PC ist und sich dann so einstellt, dass sie darauf optimiert läuft und so aus jeder ihr bekannten CPU das Meiste an Leistung rausholt? Denn eigentlich wäre so ein Vorgehen das einzig sinnvolle und logische!
Ja. Aber du überschätzt die Auswirkung einer CPU-spezifischen Optimierung ziemlich.

[StefanV]

Coda[/POST]']
Ja. Aber du überschätzt die Auswirkung einer CPU-spezifischen Optimierung ziemlich.
Naja, kommt auf die CPU an ;)
Bei einer 'normalen Standard CPU' (=alles außer Netburst) bringt sowas sicher nicht mehr allzuviel, nur bei Netburst kann das was bringen...

[Coda]

Auch dort wird das keine 20%+ ggü. generischer maximaler Optimierung bringen im Normalfall.

K8 und Conroe mögen so ziemlich den gleichen Code gerne.

[StefanV]

Coda[/POST]']Auch dort wird das keine 20%+ ggü. generischer maximaler Optimierung bringen im Normalfall.

Im Normalfall sicher, kann aber auch sein, das das nicht so ist und mehr bringen kann.

Coda[/POST]']
K8 und Conroe mögen so ziemlich den gleichen Code gerne.
Bei klassischen Architekturen ist das eh egal, was für einen Code man denen vorsetzt, viel machts nicht aus.

Ich würd sogar noch weiter gehen und behaupten, das alles außer Netburst gern die gleichen Optimierungen gern hat.

[BlackBirdSR]

Viel mehr Leistung bleibt oftmals beim Programmierer selbst hängen.
Kein Compiler könnte das noch rausholen, was da oft an Optimierungen ausgelassen wird.

Allerdings ist das zeitlich einfach nicht mehr möglich. Die wenigsten Firmen haben das Geld und die Zeit dafür.
In vielen Fällen bringen SSE/2 Optimierungen kaum Vorteile, kosten aber Zeit.
Also lässt man sie weg oder führt nur rudimentäre Optimierungen ein.
Anderen Funktionen geht es ähnlich, wodurch sich der Verlust am Ende aufsummiert.

Der Final Code wird mitunter von Leuten erstellt, die mit dem eigentlichen Entwicklungsteam gar nichts gemein haben, und sich nicht um spezielle Optimierungen kümmern.

Andere sind froh, wenn der Code überhaupt halbwegs anständig läuft. Man muss sich nur die Bugorgien von Spielen wie Titan-Quest oder BF2 ansehen. Wer hat da noch Zeit für Optimierungen?

[Coda]

StefanV[/POST]']Im Normalfall sicher, kann aber auch sein, das das nicht so ist und mehr bringen kann.
Sehr sehr unwahrscheinlich. Netburst mag zwar z.B. langsam beim Shiften bzw. Multiplizieren (vor Prescott) sein, aber das ist nicht das Hauptproblem an dem Ding.

StefanV[/POST]']Bei klassischen Architekturen ist das eh egal, was für einen Code man denen vorsetzt, viel machts nicht aus.
Blödsinn.

StefanV[/POST]']Ich würd sogar noch weiter gehen und behaupten, das alles außer Netburst gern die gleichen Optimierungen gern hat.
Mag schon sein, aber auch nur weil es sonst nicht mehr viel Auswahl gibt.

[(del)]

Coda[/POST]']Mit ziemlicher Sicherheit alle mit dem Microsoft-Compiler
Meine Rede. Der behandelt AMD und Intel weitgehend gleich.

VC++ 2005 ist auch gar nicht so schlecht was Optimierung angeht.
Ist er auch nicht, aber ich nehme schwer an, daß der erst nach dem SP1 "vom Markt" angenommen wird. Ich hab schon soviele der 'nur per Email' Hotfixes dafür gesehen. Und nicht wenige davon beseitigten "slowdowns" des Kodes. Und auch danach, wer wird schon die Spiele mit "-O2 -GALFT -GS- -Gs -Zc:wchar_t- -fp:fast -arch:SSE" kompilieren :cool:

@Matti
Würde mir die Schuhe ausziehen (Delphi) Normalerweise erkenn ich Delphi-Proggis schon beim Start :mad:

[ShadowXX]

BessereHälfte[/POST]']
@Matti
Würde mir die Schuhe ausziehen (Delphi) Normalerweise erkenn ich Delphi-Proggis schon beim Start :mad:

Der TotalCommander ist 100%ig in Delphi programmiert:

While Windows 64 is able to run 32-bit programs Total Commander should run as usual without limitations.

Currently a 64-bit version of Total Commander is not available.

That is because Borland has not yet published a Delphi 64-bit version nor is a 64-bit compiler available. That were a pre-condition because Total Commander is programmed in Delphi.

http://www.ghisler.ch/wiki/index.php/Total_Commander_for_Windows_XP_64-bit

[Coda]

BessereHälfte[/POST]']wer wird schon die Spiele mit "-O2 -GALFT -GS- -Gs -Zc:wchar_t- -fp:fast -arch:SSE" kompilieren
Die meisten mit -Ox und stattdessen ohne SSE...

[micki]

Coda[/POST]']VC++ 2005 ist auch gar nicht so schlecht was Optimierung angeht.
meiner erfahrung nach schlechter als der 2003

[Coda]

Ich nehm mal an das sind dann Spezialfälle. Im Allgemeinen würde ich schon davon ausgehen dass er besser als 2003 ist, denn der war ja nicht wirklich gut.

[BlackBirdSR]

Sun hat jetzt einen Compiler mit "Autoparallelization" benutzt. Scheint ordentlich Punkte bei Spec gebracht zu haben.
Man muss dabei aber bedenken, dass aus dem Spec-Thread plötzlich 2 Threads werden, und er dann eigentlich nicht mehr gültig ist. Zumindest ein Vergleich mit anderen Systemen, die nur 1 Thread/Kern nutzen dürfen ist wohl kaum ein faires Mittel.


The Sun Fire X4600 server, equipped with four of the fastest available AMD Opteron processors, in combination with Solaris 10 OS and Sun Studio 11 software, trumps the competition with SPECfp2000 score of 3538 and surpasses systems based on IBM's Power5+ and the most recent Intel's Core architectures.


http://www.sun.com/servers/x64/x4600/benchmarks.jsp#question1

Hier noch ein Direktvergleich:
1 Core
http://www.spec.org/osg/cpu2000/results/res2006q1/cpu2000-20060213-05607.html

2 Cores
http://www.spec.org/osg/cpu2000/results/res2006q1/cpu2000-20060213-05609.html


Ist aber sicherlich kein Anti-Hypertreading ;)

[Trap]

BlackBirdSR[/POST]']
Man muss dabei aber bedenken, dass aus dem Spec-Thread plötzlich 2 Threads werden, und er dann eigentlich nicht mehr gültig ist. Zumindest ein Vergleich mit anderen Systemen, die nur 1 Thread/Kern nutzen dürfen ist wohl kaum ein faires Mittel.
Die Regeln sind klar und IMO durchaus praxisnah: Sourcecode darf nicht verändert werden und nur 4 Compilerflags, ansonsten ist egal wie man die Punkte erreicht.

Ich find es nur richtig automatische Parallelisierung zu benutzen. Und auch sinnvoll für SPEC es zuzulassen, bringt mehr Druck für Compilerentwickler an einem wichtigen Feature zu arbeiten.

[BlackBirdSR]

Trap[/POST]']Die Regeln sind klar und IMO durchaus praxisnah: Sourcecode darf nicht verändert werden und nur 4 Compilerflags, ansonsten ist egal wie man die Punkte erreicht.

Ich find es nur richtig automatische Parallelisierung zu benutzen. Und auch sinnvoll für SPEC es zuzulassen, bringt mehr Druck für Compilerentwickler an einem wichtigen Feature zu arbeiten.

Mit dem Problem, dass sich solche Features dann ausschließlich auf Spec konzentrieren. Der erziehlte Performancegewinn fällt um ein Vielfaches höher aus, als es in der Realität zu sehen wäre.
Spec ist quasi der 3dmark der CPUs :(

[(del)]

BlackBirdSR[/POST]']Mit dem Problem, dass sich solche Features dann ausschließlich auf Spec konzentrieren. Der erziehlte Performancegewinn fällt um ein Vielfaches höher aus, als es in der Realität zu sehen wäre
Das gilt in den meisten Fällen auch für die mit IntelCompiler kompilierte SPEC-Suite. Und die RL Anwendungen.

[HellHorse]

Zu ICC vs. VS
http://www.bit-tech.net/hardware/2006/07/14/intel_core_2_duo_processors/8.html
Leider sehr wenige Informationen (Versionen, Flags, ...).

[Coda]

Welche VC++-Version war das?

[(del)]

Coda[/POST]']Welche VC++-Version war das?
Den Ergebnisen nach IMHO 7.1.