News Dual-Core bei AMD früher als erwartet?

[TheCounter]

@msgt

Nein, das war afaik der K10 der aber ja nun nichtmehr K10 heißen soll.

Zur News:

Na ich bin gespannt wer als erstes seine DC's auf dem Markt hat bzw. präsentiert.

 

[DeeJayTomek]

Dass die Käufer noch auf das Intelgegenstück zum Athlon64 warten liegt vieleicht auch daran, dass das 64 Bit XP seltsamerweise immer noch nicht erhältlich ist. Und wenn man die 64 Bit (zumindest unter Windows) noch nicht nutzen kann, machts auch wenig sinn sich einen 64bit_Prozi zu kaufen. Also kann man auch ruhig auf den Moment(wahrscheinlich im Zeitraum wenn das 64bit XP rausgekommt ) warten bis intel was rausbringt.

Das "Intel-Gegenstück" zum Athlon 64 ist doch bereits lange vorhanden, die aktuellen Xeon-Prozessoren ("Nocona") verfügen über eine EM64T-Erweiterung und auch vom Intel Pentium IV ("Prescott") sind Modelle mit EM64T erhältlich ("F-Modelle").

Abgesehen davon schadet es sicher nichts, sich bereits jetzt einen 64 bit Prozessor zu kaufen, da ja vor allem der Athlon 64 auch beim Einsatz von 32 bit Software eine gute Figur macht, aber ich würde mir auch von einem 64 bit Betriebssystem im Desktopbereich nicht zu grosse Vorteile versprechen. Der Hauptvorteil liegt nunmal darin, auch direkt mehr als 2^32 Byte an Speicher adressieren zu können und das wird für die meisten hier nicht wirklich relevant sein. Ausserdem sind die Register bei AMD64 natürlich 64 bit breit, bei einigen Berechnungen mit 64 bit Zahlen bringt das natürlich erhebliche Vorteile, 99% der erhältichen Spiele und Programme ist darauf aber gar nicht ausgelegt. Ein wirklicher Vorteil im 64 bit ergibt sich jedoch dadurch, daß dem Athlon 64/Opteron noch 16 weitere Register zur Verfügung stehen (8 Integer, 8 ISSE), wenn der Compiler das richtig ausnutzt, bringt das schon einiges an Extraleistung.

--Thomas

 

[incurable]

Also ich erwarte wieder ein Sandkastenduell zwischen AMD und Intel, einer wird versuchen, dem anderen in die Suppe zu spucken und am Ende stellen sie beide CPUs vor, die erst 1-2 (Intel) / 3-5 (AMD) Monate später zu kaufen sind.

 

[Mortiss]

also ich hätte auch nicht gedacht, dass der Vote so klar für AMD ausfällt. Naja und gedacht hätte ich mir auch nicht, dass von K9 die Rede ist. Zumal der K7 immernoch mithalten kann. Wenn es K5, K6 (/2 /3), K7, K8 gibt, dann wird K9 nicht einfach nur so ein Name sein, sondern schon eher eine neue Technologie oder dergleichen bedeuten

Mir reicht mein K7 immernoch, bei mir läuft alles flüssig und den schnellsten K7 hab ich schon lange nicht.

 

[geisterfahrer]

Du hast zwar Recht, daß ein einzelnes Programm auf Multiprozessorsystemen nur dann schneller läuft, wenn es selber multithreaded ist, aber irgendwie wird hier dauernd unterschlagen, daß moderne Multitasking-Betriebssysteme wie Linux/Unix oder Windows NT, in fast jedem Fall von SMP-Systemen profitieren: Die laufenden Prozesse können auf die vorhandenen CPUs verteilt werden und das bringt auch "leistungshungrigen" Singlethreaded-Prozessen etwas, da sie sich die CPU auf der sie laufen, mit weniger anderen Prozessen teilen muss. Falls man zwei oder mehrere Programme parallel ausführt, die den jeweiligen Prozessor stark ausnutzen, erreicht man nahezu eine Verdopellung der Rechenleistung des Systems, beispielsweise wenn man irgendein Spiel laufen lässt und gleichzeitig irgendwelche Videos komprimiert.

Die meisten wollen aber lieber Performance bei einer Anwendung (z.B. ein Computerspiel) und da bringt Dual Core bei nicht angepassten Anwendungen nur minimalistisch etwas, weil ein paar Hintergrundprozesse die vielleicht 5% verbraten auf der anderen CPU laufen, zudem fallen ein paar lästige Kontextwechsel weg.
Grafikengines zu parallesieren wird bestimmt ein Spaß für die Programmierer.. Eine beinahe Verdoppelung durch Dual Core CPUs kann ich mir nicht vorstellen, dass die Spieleprogammierer das hinkriegen. Mir persönlich soll es egal sein - kompilieren geht mit Dual Core quasi doppelt so schnell. Aber bis die Teile erschwinglich sind, wird sowieso noch viel Zeit verstreichen.

Ein wirklicher Vorteil im 64 bit ergibt sich jedoch dadurch, daß dem Athlon 64/Opteron noch 16 weitere Register zur Verfügung stehen (8 Integer, 8 ISSE), wenn der Compiler das richtig ausnutzt, bringt das schon einiges an Extraleistung.

Was dann aber wieder größtenteils dadurch aufgefressen wird, das die Register 64 Bit breit sind. Unterm Strich werden aber die meisten Anwendungen minimal schneller.

Is doch Schnuppe wenn B=f(A)... A wurde ja schon ausgerechnet und in den Cache (oder wohin auch immer) geschrieben. Eben dieser Schreibvorgang wär vielleicht noch ein Bremsfaktor, aber sonst seh ich kein Problem.

Na toll, dann berechnet CPU 1 A, CPU 2 macht in der Zeit nichts, dann wird das leistungsintensiv das Ergebnis zur CPU 2 transferiert, die berechent B, CPU 1 macht hingegen nichts. Unterm Strich langsamer durch den CPU-Wechsel... Der meiste existierende Progamme sind nunmal so, das sie nichts parallel berechnen lassen, weshalb sie dann eben auch nur auf einer CPU laufen.

 

[xcycle]

@xcycle

Da bringst du nun aber so einige sachen völlig durcheinander! habe es aber dort auch schon im Forum gepostet. ;-)

mfg

cumec

Habe den Artikel dort auf diesen hier bezogen, jetzt wo du es sagst wird mir einiges klarer

 

[Queen]

Sind die neuen Prozzis denn zur Markteinführung gleich für Desktop-Systeme zu haben oder gibts die erstmal nur im Serverbereich? Und was sollen die kosten - weiß dazu zufällig jemand?

Evtl. würde es sich ja auch im Hinblick auf noch fehlende DDR2-Unterstützung seitens AMD lohnen, noch etwas zu warten.


Bye,

 

[DeeJayTomek]

Die meisten wollen aber lieber Performance bei einer Anwendung (z.B. ein Computerspiel) und da bringt Dual Core bei nicht angepassten Anwendungen nur minimalistisch etwas,

Ob es sich für Computerspiele lohnt ein SMP-System zu verwenden, würde ich auch bezweifeln.

weil ein paar Hintergrundprozesse die vielleicht 5% verbraten auf der anderen CPU laufen, zudem fallen ein paar lästige Kontextwechsel weg.

Wenn man sich die durchschnittliche Windows-Installation von $COMPUTERKIDDIE anschaut, dann sind das sicher schon mehr als 5%, mit dem ganzen Gerümpel was da oft im Hintergrund läuft (Virenscanner, Personal "Firewall", ein paar Trojaner und Adware... ;-)
Und so wie einige hier drauf sind, wären die sicher auch mit 5% mehr FPS in $LIEBLINGSSHOOTER auch schon glüclklich. ;-)

Grafikengines zu parallesieren wird bestimmt ein Spaß für die Programmierer..

Da trägt die Grafikkarte eh die Hauptlast der Arbeit und das ganze lässt sich ziemlich ordentlich parallelisieren.

Eine beinahe Verdoppelung durch Dual Core CPUs kann ich mir nicht vorstellen, dass die Spieleprogammierer das hinkriegen.

Ich auch nicht, vor allem ist ja auch die Grafikkarte zum grossen Teil der limitierende Faktor, aber da geht der Trend ja auch schon zur Parallelisierung.

Mir persönlich soll es egal sein - kompilieren geht mit Dual Core quasi doppelt so schnell.

Ich arbeite sehr häufig auf grösseren SMP-Maschinen und vor allem wenn mehrere Benutzer gleichzeit drauf arbeiten, freut man sich über jeden Prozessor mehr. :-)

Was dann aber wieder größtenteils dadurch aufgefressen wird, das die Register 64 Bit breit sind. Unterm Strich werden aber die meisten Anwendungen minimal schneller.

Die Logik kann ich jetzt nicht ganz nachvollziehen: Die zusätzlichen Register stehen eh nur im 64 bit Modus zur Verfügung und dort müssen sie natürlich auch 64 bit breit sein. Warum sollte das die Leistung "auffressen"? Der Prozessor kann doch (im Gegensatz zu 32 bit CPUs) 64 Bit in einem Schritt aus dem Register lesen, bzw. schreiben.

--Thomas

 

[Austin1]

jedes mal das selbe. finde ich gut ;-) hoffe das amd gewinnt!
um so mehr schwung im markt umso bessere preise ;-)

 

[EddyX01]

Mal abwarten bis es raus kommt, dann kann man auch durch Test zeigen welche Performance und Leistung wirklich Dual-Core bringt. Aber Dual-Core wird in ferner Zukunft noch eine wichtige Rolle spielen, das steht fest !

 

[EddyX01]

Sind die neuen Prozzis denn zur Markteinführung gleich für Desktop-Systeme zu haben oder gibts die erstmal nur im Serverbereich? Und was sollen die kosten - weiß dazu zufällig jemand?

Evtl. würde es sich ja auch im Hinblick auf noch fehlende DDR2-Unterstützung seitens AMD lohnen, noch etwas zu warten.


Bye,

Momentan sieht es AMD so, dass keine großen Perfroamnce schübe durch DDR2 mit den Athlon Prozessoren auftauchen (hier dann 64 bit..). Natürlich ist DDR2 die erweiterte Technik aber ist momentan nicht wirklich im Stadium, das es im gegensatz zu DDR mehr Leistung bringt. Bald wird aber AMD sicher umsteigen. Im jetzigen moment halt nicht!!!

 

[geisterfahrer]

Die Logik kann ich jetzt nicht ganz nachvollziehen: Die zusätzlichen Register stehen eh nur im 64 bit Modus zur Verfügung und dort müssen sie natürlich auch 64 bit breit sein. Warum sollte das die Leistung "auffressen"? Der Prozessor kann doch (im Gegensatz zu 32 bit CPUs) 64 Bit in einem Schritt aus dem Register lesen, bzw. schreiben.

Aber der Athlon 64 braucht länger für das Verarbeiten von 64 Bit Registern (in der c't stand was von 5 statt 3 Schritten bei einer Multiplikation), außerdem sei der Teilzugriff auf ein Register auch nicht umbedingt schnell, weshalb man nicht umbedingt versuchen sollte eine 8 Bit Variable für ein Schleifeniterator die meinentwegen nur fünfmal durchlaufen werden soll, sondern gleich eine 64Bit Integer Variable nehmen sollte (stand alles in der c't, ich kenne mich mit Prozessoren nicht so sehr aus, also: Korrektur erwünscht!). Dadurch wird Speicher verschwendet, der Transfer dauert länger zzgl. der langsameren Berechnung. Und diese Nachteile im 64 Bit Modus werden dadurch ausgeglichen, das im 64Bit Modus eben mehr Register zur Verfügung stehen. Ohne die zusätzlichen Register wäre also der 64 Bit Modus in den allermeisten Fällen langsamer. Wären die zusätzlichen Register im 32 Bit Modus verfügbar, wär's schön schnell, aber dem ist nunmal nicht so und da kommt nun der Satz mit dem Performance auffressen ins Spiel. Hab mich vorhin wirklich ein bisschen blöde ausgedrückt (diesmal auch nicht umbedingt viel besser...)

 

[EtA]

Nach SATA, DDR2 und PCI-E Grakas der nächste "Bringt in einigen Jahren vielleicht sogar mal in der Praxis tatsächlich spürbaren Leistungsgewinn" Furz als grosse Neuheit verkauft.
(OK, SATA spart IDE Plätze, immerhin etwas )
Nur noch sinnfreie "Neuigkeiten", die dem User eigentlich gar nichts bringen, um die ganze PC Industrie am laufen zu halten, so kommt mir das immer mehr vor.

Da könnte man direkt auf die Idee kommen erst in einigen Jahren mal wieder ein neues System zu posten, bis dahin spürt man von dem ganzen Kram dann vielleicht sogar mal was.
Und wer weiss, vielleicht gibts bis dahin sogar ein paar Spielchen und Programme die DC richtig ausnutzen

 

[infy]

amd bringt frühzeitig irgendein unausgereiftes produkt heraus, was man nicht brauchl. siehe amd64. dann wird n riesenhype gemacht und alle freuen sich

 

[HappyMutant]

@infy: Yeah, Flamewar, gibs uns dreckig.

Ich brauche wohl nicht darauf zu verweisen das Intel ebenso Dual-Core-Prozessoren rausbringt und die sehr wohl was bringen, genauso wie HT (quasi ein simulierter Dual-Core) von Intel etwas bringt. Ob jetzt die 64Bit-Erweiterung für den Homeuser (im Gegensatz zum Serverbetrieb) was bringt sei mal dahin gestellt, es läßt sich aber nicht bestreiten das Athlon64 Prozesoren einiges an Leistung bieten (gerade im Vergleich zu reinen 32Bit und eben auch zu reinen 64Bit von Intel Prozessoren) und insofern das durch den 64Bit-Hype einfach besser zur Geltung kommt

 

[Franky-Boy]

Aber Dual-Core wird in ferner Zukunft noch eine wichtige Rolle spielen, das steht fest !

Richtig, so sehe ich das auch. Ich schätze mal, dass frühestens mit dem Erscheinen der Nachfolger der aktuellen 3D Engines von Half Life 2 und Doom3/Quake4 mit einer effektiven Unterstützung von DC zu rechnen ist. Und das kann noch dauern.

Ciao Frank

 

[Bokill]

@geisterfahrer

Du führst da einige Scheinargumente ein. Nur weil der K8 64 Bit beherrscht, bedeutet es mitnichten, dass der Code durchgängig 64 Bit sein muss. Überall wo es nicht notwendig ist, kann der Code wie bisher 32 bitig sein. Was gut genug in 32 Bit ist, wird übernommen (siehe Präfixe).
Die Zeiger bleiben 64 Bit, aber der Code sieht bei 64 Bit nicht notwendigerweise so aus, dank der Bennung der Register für 64 Bit RAX und der bisherigen 32 Bit EAX. Durch ein schlichtes zusätzliche Bit genannt Prefix Register REX wird der Code gar nicht so aufgebläht.

Mit anderen Worten die Operandengrösse ist in Wirklichkeit gar nicht 64 gross. Die bleibt mit der bisherigen 32Bit Grösse vergleichbar. Lediglich ein Operandenpräfix kommt zur Unterscheidung 64/32Bit hinzu.
Durch die Speicheradressierung sind die Zeiger aber weiterhin grösser bei 64 Bit.

Dadurch ist der 64 Bit Code ca. 20-25% grösser. Bei diesem Punkt setzten nun aber die zusätzlichen Integer und SSE Register ein. Dadurch dass wesentlich mehr in den Registern verbleibt, entfallen im Code diverse Zugriffe auf den Cache/Speicher das macht den Code
1. wieder kompakter, da weniger Befehle zum Sichern und Abspeichern notwendig sind.
2. Ist derzeit die Vielfalt von AMD64 Prozessoren begrenzt. Die ISA Ergänzungen auf IA32 machten vieles möglich, aber viele Sonderbefehle wurden nicht eingesetzt, da sie nicht auf allen Prozessoreen vorkamen. cmovg ist solch ein Befehl, der war im PentiumPro, drin aber Compiler nutzen nicht zwangsläufig diesen Befehl ... man will ja kompatibel bleiben ... auch hier ist demnach noch Raum für Optimierungen.

Teilzugriff auf ein Register auch nicht umbedingt schnell

Was ist ein Teilzugriff? Die Register sind die schnellsten Speicher im Prozessor, schneller geht nicht. Der L2 Cache wurde um einen Hauch verbessert in den Latenzen. Bei 32 Bit sind die Register 32 Bit breit. Bei einem 32Bit Vergleich ist der K8 praktisch nirgens langsamer als sein Kontrahent K7, aber in vielen Anwendungen schneller ...

Zudem wurde bei der SSE Einheit des K8 verfeinert, wesentlich mehr Befehle sind "direkt" -> als FastPath verdrahtet worden. AMD spricht davon, dass die Microcodierten Instructionen um 8% für Integer und 28% für Gleitkomma-Instructionen reduziert wurden.

MFG Bokill

 

[geisterfahrer]

Ich bediene mich mal schamlos aus der c't:
"Beim Laden kleinerer Daten wird bei den 64-Bittern der Rest des Registers entweder vorzeichengerecht aufgefüllt oder genullt. Bei AMD64 kann man auch kompatibel zu x86 Registerteile nachladen, ohne den Inhalt des Restes zu ändern. Das zieht dann allerdings ein ziemlich komplexes Durcheinander von Präfixen und Füllregel nach sich. Partielle Registerzugriffe haben zudem auch Nachteile, da sie nicht selten längern dauern als Vollzugriffe. Das frisst dann den Gewinn durch die bessere Cache-Ausnutzung oft mehr als auf. So schwer es einem fällt zu glauben, dass es Sinn macht, Schleifen wie "for i:= to 5" in 64 Bit auszuführen: es ist aber so!"
c't 20/2003, S.107
Da ich selber mit Assembler und erst recht nicht dessen Performance Gedanken machen musste, spare ich mir die weitere Kommentierung, da ich schlichtweg davon keine Ahnung habe. Ich hab an der Stelle einfach mal der c't den Glauben geschenkt, als ich den Artikel damals gelesen haben und da es einigermaßen als Anwort auf dein Beitrag passt..

 

[Bokill]

@geisterfahrer

Nun es kommt von 2003, mag sein dass es so ist, oder doch nicht ...

Wenn es so ist, so sollte dann solches zu programmieren tulichst vermieden werden ... gell?

Jeder Hersteller hat ja neben der Hardware auch Guidelines herausgegeben, wie man ein Optimum herausholt, bzw. was man bitte unterlassen sollte. Und bei den Compilern ist zu erwarten, dass sie solche Leistungsfresser ebenso vermeiden sollten ...

Die x86 Pfade entschlafen ja langsam auf AMD64, es hat schon seinen Grund weswegen SSE von AMD promotet wird, und die Registerbreite für die alte x87 Gleitkommaeinheit bei 8 Registern geblieben ist. Die ist nur noch aus Kompatibelitätsgründen da ...

MFG Bokill

 

[wolf-cottbus]

Ich habe für Intel gestimmt. Sie wollen alle Bereiche mit Dual-Core abdecken. AMD erstmal FX und Server, also nicht den Homuser. Deswegen macht Intel das Rennen am Anfang.

Wolf