Kompiler für AMD64 am 07.Juli?
- Ersteller jensibensi
- Erstellt am
jensibensi
Admiral Special
Passend zu der <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1057134457">Meldung</a> der optimierten Bibliotheken, erschien beim <a href="http://www.theinquirer.net/?article=10292" target="b">Inquirer</a> ein Artikel über einen "Compiler für AMD64", offensichtlich für 64 bit Applikationen. Dieser Compiler soll verspätet am oder vor dem 7. Juli erscheinen. Er wurde von der Portland Group entwickelt.
Er soll enorme Performanceschübe bringen, allein durch ein recompilieren der Software, die Rede ist von unglaublichen 375% beim Spec Floating Point Benchmark. Wenn da mal jemandem nur nicht die Kommastelle verrutscht ist.
Er soll enorme Performanceschübe bringen, allein durch ein recompilieren der Software, die Rede ist von unglaublichen 375% beim Spec Floating Point Benchmark. Wenn da mal jemandem nur nicht die Kommastelle verrutscht ist.
na, das ist wohl eine deutliche fehlinterpretation: der perfomance-gewinn von 32 auf 64bit ist lange nicht so groß. vielmehr der unterschied von compiler 4.1 auf version 5.0 bringt es bereits bei 32bit...
so muss ich wohl ein P4 kaufen!
Jedenfalls war das Echo zum Opteronstart teilweise so.
AMD jedenfalls feilte seit geraumer Zeit an Optimierungen im Softwaresektor. Die Portlandgroup ist jedenfalls schon länger am Feilen.
Intel bekommt nun auch von der Softwareseite etwas Druck, na ja ein wenig.
Bis jetzt zeigt der Opteron noch nicht seine wahre Leistungsfähigkeit, die Frage lautet wann endlich die richtige Software auf den Markt kommt, nicht mehr ob!
Das ist wohl der entscheidende Unterschied zu 3DNow! und der Software, die 3DNow! kaum unterstützte.
Jedenfalls war das Echo zum Opteronstart teilweise so.
AMD jedenfalls feilte seit geraumer Zeit an Optimierungen im Softwaresektor. Die Portlandgroup ist jedenfalls schon länger am Feilen.
Intel bekommt nun auch von der Softwareseite etwas Druck, na ja ein wenig.
Bis jetzt zeigt der Opteron noch nicht seine wahre Leistungsfähigkeit, die Frage lautet wann endlich die richtige Software auf den Markt kommt, nicht mehr ob!
Das ist wohl der entscheidende Unterschied zu 3DNow! und der Software, die 3DNow! kaum unterstützte.
jensibensi
Admiral Special
Sollte der neue 2.0 GHz Opteron wirklich am 06.Juli kommen, wäre es schon ein seltsamer Zufall, daß der Kompiler ebenfalls "am 07.Juli oder früher" erscheinen sollte. Vielleicht bereitet AMD einen großen Paukenschlag vor.
Vielleicht, vielleicht ob ihr Recht habt oder nicht... so ist das halt bei Gerüchten.
Ciao Jensibensi
Registered
Vice Admiral Special
- Mitglied seit
- 12.07.2002
- Beiträge
- 757
- Renomée
- 7
Wäre geil wenn sie dann gleich noch SMT mit einbauen. Vielleicht haben sie ja das Patent von IBM ? Wer weiß!
Bin ja schon gespannt ob der Compiler wirklich soviel bringen wird, dass wär ja ( Sledge ) Hammergeil
Bin ja schon gespannt ob der Compiler wirklich soviel bringen wird, dass wär ja ( Sledge ) Hammergeil
Original geschrieben von Registered
Wäre geil wenn sie dann gleich noch SMT mit einbauen. Vielleicht haben sie ja das Patent von IBM ? Wer weiß!
Bin ja schon gespannt ob der Compiler wirklich soviel bringen wird, dass wär ja ( Sledge ) Hammergeil
Wer will den SMT mit 1,1 CPUs wenn man ECHTES SMP bekommen kann?
Registered
Vice Admiral Special
- Mitglied seit
- 12.07.2002
- Beiträge
- 757
- Renomée
- 7
Bringen würds aber trotzdem was 
Und wenn es der Opteron bekommt, wird es der Athlon64 sicher auch bekommen und dass ist ja das schöne daran Wenn sie erst über Intels HT lästern, wäre ihre Version also besser 
Und wenn es der Opteron bekommt, wird es der Athlon64 sicher auch bekommen und dass ist ja das schöne daran
Wenn sie erst über Intels HT lästern, wäre ihre Version also besser Ich finde es schön, dass andere ebenfalls eine blühende Phantasie haben, aber wenn so etwas eingeführt wird bei AMD dann erst mit dem vagen K9; Windhund.
Patente dazu könnte AMD selber dazu haben, http://www.chip-architect.com
von Hans de Vries, der hatte ja schon einige nette Spekulationen.
AMD wird auch sicherlich den Begriff HT vermeiden, der P4 musste so etwas haben, der Hammer nicht direkt. Intern ist ja auch schon eine Schnittstelle für einen zweiten Hammer, wieso 2 CPU`s vortäuschen, wenn 2 echte CPUs möglich sind?
AMD kann ja etwas geizen mit dem Cache und dafür mehr Rechenpower hineinbacken, das Konzept vom Opteron/Athlon64 ist ja bedeutend weniger cachehungrig.
Patente dazu könnte AMD selber dazu haben, http://www.chip-architect.com
von Hans de Vries, der hatte ja schon einige nette Spekulationen.
AMD wird auch sicherlich den Begriff HT vermeiden, der P4 musste so etwas haben, der Hammer nicht direkt. Intern ist ja auch schon eine Schnittstelle für einen zweiten Hammer, wieso 2 CPU`s vortäuschen, wenn 2 echte CPUs möglich sind?
AMD kann ja etwas geizen mit dem Cache und dafür mehr Rechenpower hineinbacken, das Konzept vom Opteron/Athlon64 ist ja bedeutend weniger cachehungrig.
Registered
Vice Admiral Special
- Mitglied seit
- 12.07.2002
- Beiträge
- 757
- Renomée
- 7
AMD hat aber eine SMT möglichkeit für den Athlon64 freigelassen. Es wurde nur definitiv für den K7 ausgeschlossen und laut AMD soll der Athlon64 ja noch ein besonderes, bisher nicht freigeschaltetes Future haben
man, ich kann es nicht mehr hören.
einfach nur seinen wünschen und hoffnungen folgen funktioniert schon bei frauen nicht 
, aber in der technik, bei cpus noch viel weniger ![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
...man sollte doch mal argumente zur kenntnis nehmen, die gegen ht beim hammer sprechen.na ja, wenn du recht behältst entschuldige ich mich und gebe dir gleich zwei eis
Zuletzt bearbeitet:
Man könnte doch genauso den Kompiler für die Hammerfamilie so auffassen, denn bald werden die Athlon 64 auf den Markt; in die Wildnis entlassen. Zufällig fast zeitgleich mit dem Erscheinen des KOSTENLOSEN? Kompilers?!?!
Registered
Vice Admiral Special
- Mitglied seit
- 12.07.2002
- Beiträge
- 757
- Renomée
- 7
Ach ich weiß nicht, das hat sich mehr so nach nem Hardwarefuture angehört.
@ Treverer:
Was spricht denn dagegen ? Habe ehrlich gesagt bisher noch nichts derartiges gehört.
Auf deine Eis komme ich ggf. zurück, wobei ich keine Hoffnungen darauf setzte. Ich wollte SMT nur als möglichkeit ansprechen, da es ja von AMD offen gelassen wurde
@ Treverer:
Was spricht denn dagegen ? Habe ehrlich gesagt bisher noch nichts derartiges gehört.
Auf deine Eis komme ich ggf. zurück, wobei ich keine Hoffnungen darauf setzte. Ich wollte SMT nur als möglichkeit ansprechen, da es ja von AMD offen gelassen wurde
CoolerMaster
Grand Admiral Special
Wer arbeitet denn an einem Sonntag? Und der Athlon 262 mit 2GHz soll am Samstag kommen?
ncp_EasyChiller
Vice Admiral Special
ERNÜCHTERUNG ... die 375% sind nicht beim Spec-fp-Wert - sonder nur in einem Teilbech der suite!!!!!
Nachzuguggen HIER
aber immerhin ne Verbesserung auch in den meisten anderen Teilbenches!
ich glaub dem neustem Itanium wird AMD damit zumindest im SPEC-fp-Wert noch nicht das Wasser reichen können - auch mit dem 2GHz'er Opteron nicht! ... aber nen ganzes Stück rankommen dürften sie mit dem neuen Compiler und dem 2GHerzer schon!
Nachzuguggen HIER
aber immerhin ne Verbesserung auch in den meisten anderen Teilbenches!
ich glaub dem neustem Itanium wird AMD damit zumindest im SPEC-fp-Wert noch nicht das Wasser reichen können - auch mit dem 2GHz'er Opteron nicht!
... aber nen ganzes Stück rankommen dürften sie mit dem neuen Compiler und dem 2GHerzer schon!
Zuletzt bearbeitet:
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Hier die Grafik:
Zu HT: Was spricht dagegen? Oder was könnte der AMD Representant sonst gemeint haben? Einen Compiler würde ich nicht als Feature bezeichnen
Zu HT: Was spricht dagegen? Oder was könnte der AMD Representant sonst gemeint haben? Einen Compiler würde ich nicht als Feature bezeichnen
Original geschrieben von mtb][sledgehammer
Hier die Grafik:
Zu HT: Was spricht dagegen? Oder was könnte der AMD Representant sonst gemeint haben? Einen Compiler würde ich nicht als Feature bezeichnen
Sehr interssant wäre doch auch zu wissen, wie ein herkömmlicher Inter ICC7 (oder wie auch immer) Compiler im Vergleich zum 4.1er oder 5.0er von Portland abschneidet.... Also ob Portland da nur aufgeholt oder ÜBERholt hat..
na ja.. time will tell..
Knife
Commodore Special
Es ist irgendwie noch amüsant, wie wild herumspekuliert wird, von einer Maus ein Elefant modeliert wird... Obschon das das Beste (IMHO) was man im Moment machen kann, ist einfach nur abwarten und dann gegebenenfalls staunen/seufzen. Auf jeden Fall die Erwartungen nicht zu hoch setzen, da die Enttäuschung umso härter ausfällt. Die Freude bei übertreffen der Erwartung aber auch um so höher ist... Aber lasst euch jetzt nicht von mir demoralisieren, denn auch ich erwarte die neue Hammerplattform und deren Goodis und Features mit grosser Spannung
Mensch wäre ein Dual Hammer System, mit Dualcore/Die ein Traum
hehe
H.a.n.d.
Knife
Mensch wäre ein Dual Hammer System, mit Dualcore/Die ein Traum
heheH.a.n.d.
Knife
Original geschrieben von mtb][sledgehammer
Hier die Grafik:
[...]
Zu HT: Was spricht dagegen? Oder was könnte der AMD Representant sonst gemeint haben? Einen Compiler würde ich nicht als Feature bezeichnen
Ohne entsprechenden Compiler ist aber jedes neue Feature wertlos.
Also SMT würde sich beim Hammer wohl net lohnen - der Decoder schafft es die Architektur komplett auszulasten, was beim P4 ja nicht der Fall war.
Aber das mit dem Compiler klingt richtig schön - 375% ist denke ich auch noch im Bereich des Möglichen, immerhin wurde bisher der Intel Compiler genutzt - und der P4 mag den Code völlig anders als der K7/K8. Auch wenn (und das hat die Erfahrung gezeigt) der K7 so ziemlich alles gut frisst ist da noch ordentlich Potential da.
PS In der C't stand grad was über den Power5 - DualCore mit SMT, also 4 Virtuelle CPUs auf einer einzelnen Platine 8)
Damit wäre ein DualSystem doch ein Spaß, oder?
*
Der Artikel steht auch bei den News...
Aber das mit dem Compiler klingt richtig schön - 375% ist denke ich auch noch im Bereich des Möglichen, immerhin wurde bisher der Intel Compiler genutzt - und der P4 mag den Code völlig anders als der K7/K8. Auch wenn (und das hat die Erfahrung gezeigt) der K7 so ziemlich alles gut frisst ist da noch ordentlich Potential da.
PS In der C't stand grad was über den Power5 - DualCore mit SMT, also 4 Virtuelle CPUs auf einer einzelnen Platine 8)
Damit wäre ein DualSystem doch ein Spaß, oder?
*
Der Artikel steht auch bei den News...
Zuletzt bearbeitet:
@Desti:
Dies ist nicht richtig. Es gibt genügend Features, die zur Performancesteigerung beitragen, ohne daß man die Software neu übersetzen muss ! Nur ein Beispiel: Eine Vergrößerung eines Puffers, Caches etc.
Diese Features sind mit Sicherheit nicht wertlos und einen Compiler brauchts dazu gar nicht.
Gruß,
Ramius
Dies ist nicht richtig. Es gibt genügend Features, die zur Performancesteigerung beitragen, ohne daß man die Software neu übersetzen muss ! Nur ein Beispiel: Eine Vergrößerung eines Puffers, Caches etc.
Diese Features sind mit Sicherheit nicht wertlos und einen Compiler brauchts dazu gar nicht.
Gruß,
Ramius
Siehe zb. 386er <-> 586er. Besseres Pipelining, Data Prefetching, eine Superskalare Architektur, Out of Order Execution... ohne einen neuen Compiler zu benutzen.
Der Seti Text Client ist übrigens immernoch für dem 386er compiliert... bei neuen Befehlssätzen braucht man aber natürlich einen neuen Compiler.
Der Seti Text Client ist übrigens immernoch für dem 386er compiliert... bei neuen Befehlssätzen braucht man aber natürlich einen neuen Compiler.
mtb][sledgehammer
Grand Admiral Special
Solange man mit größeren Caches oder mehr Speicherbandbreite eine höhere Performance erreicht, sind IMO die Funktionseinheiten nicht ausgelastet. Oder andersherum gesagt: nur wenn die Funktionseinheiten noch nicht komplett ausgelastet sind, kann man durch einen verbesserten Daten und Befehlsstrom (bessere Caches/Speicherbandbreite) die Performance steigern. Das heißt (wen sie nicht ausgelastet sind) sie warten auf Befehle aus dem Speicher, und genau an diesem Punkt wirkt SMT. Ohne Verzögerung werden die Befehle von Thread B bearbeitet, solange Thread A nur warten kann.
ThreadB will ja auch Bandbreite haben. Da kommen die Befehle ja nicht aus dem Nichts.
Lohnen tut sich SMT wenn ein Thread nur (oder großteils) die ALU und der andere die FPU auslastet oder sich die genutzten Funktionseinheiten unabhängig voneinander nutzen lassen.
Durch besseren Speicherdurchsatz etc. lässt sich praktisch immer die Geschwindigkeit steigern, SMT kommt zum Zuge wenn die Ausführungszeit der Befehle recht lange ist... und da hat der K7/K8 wenig Probleme wohingegen der P4 ja extra ziemlich lange braucht.
Lohnen tut sich SMT wenn ein Thread nur (oder großteils) die ALU und der andere die FPU auslastet oder sich die genutzten Funktionseinheiten unabhängig voneinander nutzen lassen.
Durch besseren Speicherdurchsatz etc. lässt sich praktisch immer die Geschwindigkeit steigern, SMT kommt zum Zuge wenn die Ausführungszeit der Befehle recht lange ist... und da hat der K7/K8 wenig Probleme wohingegen der P4 ja extra ziemlich lange braucht.
