Leider hat AMD ihn nicht besonders gekennzeichnet wie Intel z.B. Den Northwood mit einem A/B je nach FSB. Es wird also gar nicht so einfach den Thouroghbred von einem Palmino im Handel zu unterscheiden. Hoffentlich kommt er schnell in den freien Handel. AMD wird wohl erst die OEM Kunden belifern ehe der TBred in den Endverbraucherhandel gelangt. Diese Zeit bekomme ich auch noch herum
Thouroghbred entlich da!
-
Athlonkaempfer
Thouroghbred entlich da!
Nach unzähligen verschiebungen bis zu seiner entgültigen Veröffentlichung heute ist viel Zeit vergangen. Egal, er ist seit heute da, der Thouroghbred.
Leider hat AMD ihn nicht besonders gekennzeichnet wie Intel z.B. Den Northwood mit einem A/B je nach FSB. Es wird also gar nicht so einfach den Thouroghbred von einem Palmino im Handel zu unterscheiden. Hoffentlich kommt er schnell in den freien Handel. AMD wird wohl erst die OEM Kunden belifern ehe der TBred in den Endverbraucherhandel gelangt. Diese Zeit bekomme ich auch noch herum
warte schon so lange auf den TBred da machen mir eins zwei Wochen auch nichts mehr 
Leider hat AMD ihn nicht besonders gekennzeichnet wie Intel z.B. Den Northwood mit einem A/B je nach FSB. Es wird also gar nicht so einfach den Thouroghbred von einem Palmino im Handel zu unterscheiden. Hoffentlich kommt er schnell in den freien Handel. AMD wird wohl erst die OEM Kunden belifern ehe der TBred in den Endverbraucherhandel gelangt. Diese Zeit bekomme ich auch noch herum
-
BrainMcFly
- Partikel-Strecker

- Beiträge: 912
- Registriert: 26.11.2001 01:00
- Wohnort: Leipzig
-
Michael H.W. Weber
- Vereinsvorstand

- Beiträge: 22921
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
-
Michael H.W. Weber
- Vereinsvorstand

- Beiträge: 22921
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
Aha. Also da warte ich lieber noch auf den Barton mit 512 kB "second level cache". Mehr als eine höhere Taktfrequenz hat der TBred im Vergleich zum Palomino ja nicht wirklich zu bieten (außer daß er nun endgültig Kupferkühler fordert wegen der hohen Abwärme auf kleinerer Oberfläche). Wenn ihr mich fragt, eine Fehlentwicklung, die AMD sich hätte absparen können um das eingesparte Geld zwecks wirklich innovativer Neuerungen zu investieren. Schade. 
Michael.
Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.


-
al
Ich denke hier geht es nicht darum ein verbessertes Produkt im Sinne von neuer Technik zu plazieren, sondern ein erfolgreiches Produkt weiterzuführen und Porduktionskosten zu senken. Und beides dürften sie durch Verkleinerung der Strukturen und damit bei gleicher Ausbeute verbesserter Ausnutzung der Wafer auch schaffen.
Was ich nie ganz verstanden habe ist, warum es AMD allen immer so schwer machen muss und deren Proze immer gleich tausende von Watt verbrutzeln müssen.
Ich denke auch der Barton wird nicht viel Leistungssteigerung bringen. Die DC-Projekte, die ich bisher kennen gelernt habe, haben eine sehr hohe Code-Lokalität und skalieren hauptsächlich mit dem Takt.
Was ich nie ganz verstanden habe ist, warum es AMD allen immer so schwer machen muss und deren Proze immer gleich tausende von Watt verbrutzeln müssen.
Ich denke auch der Barton wird nicht viel Leistungssteigerung bringen. Die DC-Projekte, die ich bisher kennen gelernt habe, haben eine sehr hohe Code-Lokalität und skalieren hauptsächlich mit dem Takt.
-
Velociraptor
- Stromkosten-Ignorierer

- Beiträge: 1029
- Registriert: 13.11.2001 01:00
- Wohnort: nähe Wien
-
Velociraptor
- Stromkosten-Ignorierer

- Beiträge: 1029
- Registriert: 13.11.2001 01:00
- Wohnort: nähe Wien
noch bisschen info
http://www.pcwelt.de/tests/hardware-tes ... ige/24120/
und
http://www.tomshardware.com/cpu/02q2/020610/index.html
http://www.pcwelt.de/tests/hardware-tes ... ige/24120/
und
http://www.tomshardware.com/cpu/02q2/020610/index.html
There is no place like 127.0.0.1
--------------------
--------------------
-
Athlonkaempfer
AMD verwendet schon seit dem Palmino kein Keramik mehr. Der Träger ist jezt Organisch wie bei Intel. Er hat die Abkürzung OPGA.BrainMcFly hat geschrieben:doch, es ist ganz einfach, soviel ich weiss ist der Keramikkörper grün
AMD hat schon grüne Palminos gefertigt. Der erste Zuliferer lieferte nur Das Material für die braunen OPGA's. Sie haben dann noch einen weiteren Zuliferer aufgenommen, seitdem gibt es die grünen. Beim Palmino soll es jezt hauptsächlich Prozzesoren mit dem grünen OPGA geben, aber nicht ausschließlich. Zu den verschiedenen trägern gibt es einige Gerüchte im Web. Es wird behauptet die grünen Träger wären stabiler. Ob da was drann ist weis ich nicht.
-
Velociraptor
- Stromkosten-Ignorierer

- Beiträge: 1029
- Registriert: 13.11.2001 01:00
- Wohnort: nähe Wien
-
Michael H.W. Weber
- Vereinsvorstand

- Beiträge: 22921
- Registriert: 07.01.2002 01:00
- Wohnort: Marpurk
Das mit der Weiterführung eines erfolgreichen Produkts bei reduzierten Produktionskosten (falls dem so ist) ist tatsächlich einzusehen.al hat geschrieben:Ich denke hier geht es nicht darum ein verbessertes Produkt im Sinne von neuer Technik zu plazieren, sondern ein erfolgreiches Produkt weiterzuführen und Porduktionskosten zu senken. Und beides dürften sie durch Verkleinerung der Strukturen und damit bei gleicher Ausbeute verbesserter Ausnutzung der Wafer auch schaffen.
Ich denke auch der Barton wird nicht viel Leistungssteigerung bringen. Die DC-Projekte, die ich bisher kennen gelernt habe, haben eine sehr hohe Code-Lokalität und skalieren hauptsächlich mit dem Takt.
Die dc-Projekte, die mich interessieren, nutzen vor allem die FPU. Das ist auch der Grund, warum Intel-CPUs grundsätzlich "keine Schnitte" gegen AMDs Durons/TBirds/Palominos haben und haben werden - auch bei teilweise deutlich höheren Taktfrequenzen. Daraus leite ich ab, daß die CPU-Architektur der maßgebliche Faktor für die Effizienz bei DIESEN dc Projekten ist und "erst" in zweiter Linie die CPU-Taktfrequenz eine Geige spielt. Was ich im Augenblick nicht abschätzen kann, ist, wie stark die Architektur/Größe des "second level caches" eine Rolle spielt. Da habe ich einfach zu wenig Ahnung, möchte aber vermuten/hoffen, daß diese eine SEHR große Rolle spielt, erspart/reduziert es doch den (vergleichsweise langsamen) RAM-Zugriff, oder? Und wenn das so ist, erwarte ich vom Barton, daß er meinem Knecht beim Einschalten die Haube hochfliegen läßt und den Intels mal wieder gebührlich die Rücklichter zeigt.
Michael.
Fördern, kooperieren und konstruieren statt fordern, konkurrieren und konsumieren.


-
al
Größere Caches bringen nur etwas, wenn man im Vergleich zum Normalbetrieb (wie auch immer der aussehen mag) mehr nicht-lokale Zugriffe auf den Speicher hat. Normalerweise hat ein 1st Level Cache eine Hit-Rate von vielleicht 97%, erst für die übrigen Prozente kommt der 2nd Level Cache ins Spiel und erst wenn darin auch nix gefunden wird, setzt es reichlich Wartezyklen, bis aus dem RAM die nötogen Daten in die Caches geladen wurden.
Von der Architektur her hat haben die AMD-CPUs gegenüber den Intel-CPUs den Vorteil ihre Caches exklusive zu organisieren. D.h. Daten die im 1st Level Cache aufbewahrt werden, werden nicht noch zusätzlich im 2nd Level Cache vorgehalten. Dadurch vergrößert sich der nutzbare Cache-Bereich bei den AMDs gewissermaßen.
Was ich nicht weiß ist was genau AMD da in den Caches ablegt. Bei den Daten liegt es auf der Hand, bei Instruktionen bin ich mir nicht sicher ob es sich um (Intel-)OPCodes handelt oder bereits um dekodierte Befehle, die intern in sog. Mikro-Operationen zerlegt werden (im Grunde emuliert der Core der AMDs einen Intel-Prozessor) handelt. Ich meine letzteres wäre der Fall, womit die nutzbare Cache-Größe je nach Befehlsmix (ein CISC-Befehl wird in 1 bis x MikroOPs aufgeteilt) und Verhältnis Code zu Daten wieder schrumpft.
Die Weisheit lautet also wie so oft im Leben: Kommt drauf an.
Eine Verdopllung von Cache-Größen führt nicht a priori zu mehr Performance. Es hängt halt von der Speicherzugrifssignatur der Anwendungen ab. Dass die Cache-Größen im Laufe der zeit nach oben tendieren liegt natürlich daran dass die Anwendungen komplexer werden.
Schön ausmessen könnten wir das Ganze, wenn wir einen P3-XEON mit 512KB, 1MB und 2MB 2nd Level Cache hätten und zudem noch nen gleichschnell getakteten normalen P3. Aber ham wer leider net..
Bei DF unter Win2k bemerke ich daheim, dass mein 1.4 GHz TBird und mein 900er Celeron recht genau soweit auseinander zu liegen scheinen, wie es allein der Takt vorgibt, obwohl es sich um andere Architekturen handelt, was für mich auf einen Code schließen lässt, der fast aussschließlich mit in im 1st Level Cache eines Celeron Platz findet. Bei anderen Projekten mit größeren Datenmengen mag das anders aussehen.
Ich warte ja auch ganz gespannt auf Climateprediction.
Von der Architektur her hat haben die AMD-CPUs gegenüber den Intel-CPUs den Vorteil ihre Caches exklusive zu organisieren. D.h. Daten die im 1st Level Cache aufbewahrt werden, werden nicht noch zusätzlich im 2nd Level Cache vorgehalten. Dadurch vergrößert sich der nutzbare Cache-Bereich bei den AMDs gewissermaßen.
Was ich nicht weiß ist was genau AMD da in den Caches ablegt. Bei den Daten liegt es auf der Hand, bei Instruktionen bin ich mir nicht sicher ob es sich um (Intel-)OPCodes handelt oder bereits um dekodierte Befehle, die intern in sog. Mikro-Operationen zerlegt werden (im Grunde emuliert der Core der AMDs einen Intel-Prozessor) handelt. Ich meine letzteres wäre der Fall, womit die nutzbare Cache-Größe je nach Befehlsmix (ein CISC-Befehl wird in 1 bis x MikroOPs aufgeteilt) und Verhältnis Code zu Daten wieder schrumpft.
Die Weisheit lautet also wie so oft im Leben: Kommt drauf an.
Eine Verdopllung von Cache-Größen führt nicht a priori zu mehr Performance. Es hängt halt von der Speicherzugrifssignatur der Anwendungen ab. Dass die Cache-Größen im Laufe der zeit nach oben tendieren liegt natürlich daran dass die Anwendungen komplexer werden.
Schön ausmessen könnten wir das Ganze, wenn wir einen P3-XEON mit 512KB, 1MB und 2MB 2nd Level Cache hätten und zudem noch nen gleichschnell getakteten normalen P3. Aber ham wer leider net..
Bei DF unter Win2k bemerke ich daheim, dass mein 1.4 GHz TBird und mein 900er Celeron recht genau soweit auseinander zu liegen scheinen, wie es allein der Takt vorgibt, obwohl es sich um andere Architekturen handelt, was für mich auf einen Code schließen lässt, der fast aussschließlich mit in im 1st Level Cache eines Celeron Platz findet. Bei anderen Projekten mit größeren Datenmengen mag das anders aussehen.
Ich warte ja auch ganz gespannt auf Climateprediction.