Clawhammer vs Prescott

[reunion]

Da in diesen Thread
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=75448

Das Thema Hammer vs Prescot immer mehr diskutirt wird aber nicht wirklich reinpasst mach ich mal einen neuen auf :)

Original geschrieben von -=O.C.B=-
Punkt 1. Bedingt durch die immer weiter ansteigende Bandbreite bei
Intel-CPU´s hinkt deine Rechnung imo ein wenig. Der Prescott wird
recht schnell auf PSB 1066 gehievt von Intel. Der Vorteil der Pro/Mhz
Leistung verringert sich dadurch immer mehr. Wie man aktuell am neuen
P4(PSB800) gerade sehen kann.


Der A64 wird automatisch mit jeder Takterhöhung auch der Speichkontroller höher getacktet was bedeutet das auch bei AMDdie Latenzen und damit die pro mhz Leistung steigt. Und dann wäre da ja noch der 64-bit Modus der früher oder später sicherlich auch eine Rolle spielen wird (Man hört 30% höhere Leistung allein durch 64-bit!).

Punkt 2. Der AMD-64 tritt nunmal nicht mehr gegen den P4-Northwood
an - Er wird gegen den Prescott ran müssen. Und dieser hat neben
einem nochmals grösseren L2 auch einen vergrösserten und optimierten
L1-Cache.


Das ist schon Richtig nur bezweifle ich das dadurch soviel Leistung wie bei willametta(ka wie man das schreibt) freiwird, da dieser eideutig zu wenig Speicher hatte(mit dem winzigen L1 und den auch relativ kleinen L2).

Punkt 3. Rein von der Archtektur her wird Intel in 90nm auch bis 5ghz
kommen. Da dürfte nicht das Prob liegen.


Ja die Frage ist nur wann ???
Der Prescot soll ja Anfangs auch nur mit 3,4 ghz starten und erst im 2. Halbjahr 2004 über 4ghz kommen. Außerdem wäre ich mir nicht so sicher ob der Prescot wirklich noch 2003 kommen wird. Denn 100mio Transistoren verpackt in 90nm dürfte auch kein Spaziergang werden.


Punkt 4. AMD muss erstmal ein akzeptables "Yield" der CPU hinkriegen.
Solange das nicht der Fall ist wird die CPU nicht gerade günstig sein
(können).


Soweit einverstanden :)

Punkt 5. KO-Kriterium dürfte für AMD der Patent-Austausch sein. Wenn
Intel es für nötig hält lunchen sie eine eigene CPU mit AMD´s 64-bit
Erweiterung. Die Möglichkeit haben sie - Und wie AMD sich nicht davor
scheut SSE/SSE2 einzusetzen wird es Intel ebensowenig - Wenns not-
wendig werden sollte.
;)

Nur stellt sich die Frage ob Intel bereit ist AMD-Technologie zu verwenden und zum anderen ist das auch nicht mal in 2 Tagen eigebaut sondern wird auch eine zeit dauert. Und übrigens: Es wird nötig sein :)

mfg
reu

[BlackBirdSR]

Der A64 wird automatisch mit jeder Takterhöhung auch der Speichkontroller höher getacktet was bedeutet das auch bei AMDdie Latenzen und damit die pro mhz Leistung steigt. Und dann wäre da ja noch der 64-bit Modus der früher oder später sicherlich auch eine Rolle spielen wird (Man hört 30% höhere Leistung allein durch 64-bit!).

Der Speichercontroller mag mit höherem CPU-takt ebenfalls schneller getaktet werden, aber ich würde nicht darauf zählen, dass die absoluten Latenzen deswegen stark sinken.
Schon beim 1.8GHz Opteron sind die Latenzen extrem gering. Es dürfe hier wirklich der Speicher die größte Bremse sein. Der K8 hat vielleicht in der Verlustkurve beim Skalieren einen höheren Startwert, aber ohne schnelleren Speicher wird auch er weiter abfallen.
Besonders DDR2 ist hier so eine Art Wildcard. Wenn die Latenzen wirklich so übel sind bie gleichem Takt, dann schadet dass dem K8 nur.
Was die 30% mehr an Leistung angeght, so würde ich damit erstmal vorsichtig sein. Wenn überhaupt erreicht man diese Leistung auch nicht durch 64Bit sondern durch den 64Bit Modus welcher 8 zusätzliche Register bereitstellt.

Das ist schon Richtig nur bezweifle ich das dadurch soviel Leistung wie bei willametta(ka wie man das schreibt) freiwird, da dieser eideutig zu wenig Speicher hatte(mit dem winzigen L1 und den auch relativ kleinen L2).

Gerade der größere L1 D und Trace Cache birgt ein rießen Potential für Leistungssteigerungen. Man kann bisher nur spekulieren, aber wenn der Trace Cache und L1 D Cache ein Engpass war, dann bekommt man hier eine Menge Leistung herraus. Daneben wird der Trace Cache angeblich auch 1/3 mehr Daten ausspucken können. Das dürfte besonderns, bzw hauptsächlich dem Hyperthreadingbetrieb helfen.



Der Prescot soll ja Anfangs auch nur mit 3,4 ghz starten und erst im 2. Halbjahr 2004 über 4ghz kommen. Außerdem wäre ich mir nicht so sicher ob der Prescot wirklich noch 2003 kommen wird. Denn 100mio Transistoren verpackt in 90nm dürfte auch kein Spaziergang werden.

Nur 3.4GHz ist gut. Das ist ne ganze Menge und 4GHz im 2.H 2004 sind auch nicht übel. Der K8 dagegen wird es weit schwerer haben den Takt hochzuschrauben. Ob man Athlon64 und Prescott nun 2003 schon kaufen kann ist unbekannt. Aber Vorgestellt werden wohl Beide noch in diesem Jahr. Daneben hört man so unbestätigte Gerüchte, dass Intels Yields beim 90nm Prozess wirklich exzellent sind.

Nur stellt sich die Frage ob Intel bereit ist AMD-Technologie zu verwenden und zum anderen ist das auch nicht mal in 2 Tagen eigebaut sondern wird auch eine zeit dauert. Und übrigens: Es wird nötig sein

Wenn Intel wirklich auf AMDs Zug aufspringt und eine Erweiterung für x86 plant, dann ist diese schon fertig und in den CPUs enthalten. Das ganze Gelaber um Yamhill war ja nicht umsonst.
Allerdings sieht es immer mehr danach aus, dass Intel gar nicht vor hat 64Bit x86 CPUs auf den Markt zu bringen.
Für was sonst, würde man dem Itanium2 einen Softwarelayer schreiben welcher diesem eine Performance eines 1.5GHz XeonMP erreichen lässt.

[reunion]

Original geschrieben von BlackBirdSR
Der Speichercontroller mag mit höherem CPU takt schneller getaktet werden, aber ich würde nicht darauf zählen, dass die absoluten Latenzen deswegen stark sinken.
Scheon beim 1.8GHz Opteron sind die Latenzen extrem gering. Es dürfe hier wirklich der Speicher die größte Bremse sein. Der K8 hat vielleicht in der Verlustkurve beim Skalieren einen höheren Startwert, aber ohne schnelleren Speicher wird auch er weiter abfallen.
Besonders DDR2 ist hier so eine art Wildcard. Wenn die Latenzen wirklich so übel sind bie gleichem Takt, dann schadet dass dem K8 nur.
Was die 30% mehr Leistung angeght, so würde ich damit erstmal vorsichtig sein. Wenn überhaupt erreicht man diese Leustung auch nicht durch 64Bit sondern durch den 64Bit Modus welcher 8 zusätzliche Register bereitstellt.


Das der Speicher vermutlich mehr bremst als die Latenzen ist schon klar, nur hört man zum einen immer wieder Gerüchte das auch den A64 früher oder später ein Dual-Channel Speicherinfach bekommt und zum anderen muss AMD nicht jedesmal den FSB erhöhen und einen neuen Chipsatzt rausbringen wenn ein höher getackteter Speicher rauskommt sondern eine einfaches Bios Update vermutlich genügen wird.
Die 30% Mehrleistung wurden soweit ich weiß von Epic bei einer 64-bit version von UT2003 unter Linux bestätigt.



Gerade der größere L1 D und Trace Cache brigt eine reißen Potential für leistungssteigerungen. Man kann bisher nur spekulieren, aber wenn der Trace Cache und L1 D Cache eine Bremse war, dann bekommt man hier ne Menge Leistung herraus. Daneben wird der Trace Cache angeblich auch 1/3 mehr Daten ausspucken können. Das dürfte besonderns, bzw hauptsächlich dem Hyperthreading betrieb helfen.


Es besteitet auch keiner das der Prescot scheller sein wird nur glaub ich maximal in einer größenordnung von 10% bei gleichen Takt und nicht so wie bei wilametta 20% und mehr.



Nuzr 3.4GHz ist gut. Das ist ne ganze Menge und 4GHz im 2.H 2004 sind auch nicht übel. Der K8 dagegen wird es weit schwerer haben den Takt hochzuschrauben. Ob man Athlon64 und Prescott nun 2003 schon kaufen kann ist unbekannt. Aber Vorgestellt werden wohl beide noch in diesem Jahr. Daneben hört man so unbestätigte Gerüchte, dass Intels Yields beim 90nm Prozess wirklich exzellent sind.


da kann ich nur meine Rechnug nochmal Posten :)

Laut PCGH ist der A64 bei einer Auflösung von 1024x769x32 genau 33% scheller als der p4 200mhz fsb northwood mit canterwood-mainboard.

Wenn der A64 jetzt mit 2ghz startet umd man die 33% mehr mhz mal Faktor ~2 rechnet hat man ca. die mhz die der p4 braucht um gleich schnell zu sein.(da 10% mehr Takt ca. 5% mehr Leistung bringt)

2000+660x2=3360
2400+800x2=4000
2800+925x2=4650
3000+990x2=4980
usw.
Das würde bedeuten wenn Amd wie geplant ende 2004 bei 3ghz stehen würde Intel bereits 5ghz brauchen würde um paroli bieten zu können!
Nicht zu vergessen der zu dieser Zeit berits erhältliche DDRII/600 der auch nochmal einiges an Leistung bringen wird.

Wenn dann der A64 irgendwann wirklich noch ein Dual-Channel Speicherinfache bekommt bringt das sicherlich auch nochmal 10% Leistung.(Womit man die erhöhte mhz Leistung der Prescot ausgleichen könnte)




Wenn Intel wirklich auf AMDs Zug aufspringt und eine Erweiterung für x86 plant, dann ist diese schon fertig und in den CPUs entahlten. Das ganze Gelaber um Yamhill war ja nicht umsonst.
Allerdings sieht es immer mehr danach aus, dass Intel gar nich vor hat 64Bit x86 CPUs auf den Markt zu bringen.
Für was sonst, würde man dem Itanium2 einen Softwarelayer schreiben welcher diesem eine Performance eines 1.5GHz XeonMP erreichen lässt.

Ich glaube das Intel so oder so ein Problem hat:

Wenn man auf den AMD Zug aufspringt hat das das schon oft diskutierte Problem mit der AMD Technologie.
Wenn nicht hatt man gegen AMD64 eigendlich nichts entgegenzusetzten
den ein reiner 64-bit Prozessor wie der von dir angesprochene Itanium2 würde bedeuten das sämtliche heute verwendete Software inkompatibel wäre und nicht mehr bzw nur noch sehr langsam verwendet werden könnte. Während AMD weiterhin sowohl 64 als auch 32 und 16-bit voll in Hardware unterstützt und daruch klar scheller wäre!

mfg
reu

[BlackBirdSR]

Das der Speicher vermutlich mehr bremst als die Latenzen ist schon klar, nur hört man zum einen immer wieder Gerüchte das auch den A64 früher oder später ein Dual-Channel Speicherinfach bekommt und zum anderen muss AMD nicht jedesmal den FSB erhöhen und einen neuen Chipsatzt rausbringen wenn ein höher getackteter Speicher rauskommt sondern eine einfaches Bios Update vermutlich genügen wird.

naja, das hat Alles nichts mit der Latenzsituation zu tun.
UT2003 mag 30% mehr Leistung gewinnen, aber ist jetzt ein Ergbnis schon eine Studie?



Laut PCGH ist der A64 bei einer Auflösung von 1024x769x32 genau 33% scheller als der p4 200mhz fsb northwood mit canterwood-mainboard.
Wenn der A64 jetzt mit 2ghz startet umd man die 33% mehr mhz mal Faktor ~2 rechnet hat man ca. die mhz die der p4 braucht um gleich schnell zu sein.(da 10% mehr Takt ca. 5% mehr Leistung bringt)

2000+660x2=3360
2400+800x2=4000
2800+925x2=4650
3000+990x2=4980
usw.
Das würde bedeuten wenn Amd wie geplant ende 2004 bei 3ghz stehen würde Intel bereits 5ghz brauchen würde um paroli bieten zu können!
Nicht zu vergessen der zu dieser Zeit berits erhältliche DDRII/600 der auch nochmal einiges an Leistung bringen wird.

Wenn dann der A64 irgendwann wirklich noch ein Dual-Channel Speicherinfache bekommt bringt das sicherlich auch nochmal 10% Leistung.(Womit man die erhöhte mhz Leistung der Prescot ausgleichen könnte)


Das mag stimmen (auch wenn ich auf den PCGH Test gar nichts geben würde). Aber wo steht, dass Intel Probleme hat ihre CPUs höher zu takten? dass sie nicht mit Téjas bereits die nächsten Neuerungen bringen etc. Ich sehe da kein größeres Problem für Intel aufgrund dessen man zurückfallen würde. Meiner Meinung nach, kann AMD jetzt jeden Bonus dringen brauchen den man dem A64 verschaffen kann.
Man ist nicht ohne einen Preis zu zahlen über 1 Jahr zu spät auf dem Markt.


Ich glaube das Intel so oder so ein Problem hat:

Wenn man auf den AMD Zug aufspringt hat das das schon oft diskutierte Problem mit der AMD Technologie.
Wenn nicht hatt man gegen AMD64 eigendlich nichts entgegenzusetzten
den ein reiner 64-bit Prozessor wie der von dir angesprochene Itanium2 würde bedeuten das sämtliche heute verwendete Software inkompatibel wäre und nicht mehr bzw nur noch sehr langsam verwendet werden könnte. Während AMD weiterhin sowohl 64 als auch 32 und 16-bit voll in Hardware unterstützt und daruch klar scheller wäre!



Ob Intel nun auf den AMD Zug aufspringt leitet sich endgültig nur von der Marktsituation ab.
Und wenn Intel es schafft, die IA64 in den x86 Markt zu drücken, der unbedingt mehr als 32bit x86 Flat adressierung braucht, dann braucht man keine 64Bit x86 CPU.
Und der versprochene x86 Level eines 1.5GHZ XeonMP ist auch nicht wirklich übel für eine IA64 CPU.

Ich weiss eigentlich gar nicht auf was du hinaus willst. Wenn Intel es schafft IA64 runterzudrücken dann braucht man keinen AMD Weg gehen. Schafft man es nicht (was ich denke), dann hat man sicherlich schon vorgebaut, und probiert es eben später nocheinmal mit IA64 - wenn überhaupt.
Beide Wege wird Intel nicht gleichzeitig gehen, und momentan scheint man sich für den IA64 Weg entschieden zu haben.

Lass uns einfach mal sehen was Téjas bringt. Dort will man ja Gerüchteweise noch mehr Änderungen zum NW einbauen als beim Prescott bisher der Fall.

[reunion]

Original geschrieben von BlackBirdSR
naja, das hat Alles nichts mit der Latenzsituation zu tun.
UT2003 mag 30% mehr Leistung gewinnen, aber ist jetzt ein Ergbnis schon eine Studie?

Naja wenn es bei UT2003 wirklich die besagten 30% bringt warum soll es dann woanders weniger bringen ??? Und das die Latenzen mit DDRII Speicher größer werden ist schon klar nur gilt das auch für Intel! Denn schließlich mussen die ja auch auf DDRII wechseln.


Das mag stimmen (auch wenn ich auf den PCGH Test gar nichts geben würde). Aber wo steht, dass Intel Probleme hat ihre CPUs höher zu takten? dass sie nicht mit Téjas bereits die nächsten Neuerungen bringen etc. Ich sehe da kein größeres Problem für Intel aufgrund dessen man zurückfallen würde. Meiner Meinung nach, kann AMD jetzt jeden Bonus dringen brauchen den man dem A64 verschaffen kann.
Man ist nicht ohne einen Preis zu zahlen über 1 Jahr zu spät auf dem Markt.


Am Anfang wird es AMD vermutlich schwer haben mit 2ghz gegen den Prescot etwas entgegenzusetzten aber wenn dann schön langsam die ersten 64-bit Programme sowie DDRII Speicher rauskommt wird der A64 automatisch schneller werden ohne das AMD irgendwas machen muss.

[BlackBirdSR]

Naja wenn es bei UT2003 wirklich die besagten 30% bringt warum soll es dann woanders weniger bringen Und das die Latenzen mit DDRII Speicher größer werden ist schon klar nur gilt das auch für Intel! Denn schließlich mussen die ja auch auf DDRII wechseln.

Weil UT2003 vielleicht etwas mehr an AMD64 angepasst wird als so manch anderes Projekt?
Zudem musst du dich selbst fragen, in welchen Fällen UT2003 durch die CPU únd nicht durch den Grafikchip gebremst wird. Ich spiele schon lange kein Botmatch mehr. Und Internetspiele sind eigentlich eher durch den Grafikspeicher sowie die Grafikleistung meiner Grafikkarte limitiert.

Mag ja gut sein, dass Spiele hier und da mal etwas Gewinnen, aber ich denke nicht dass dies die Norm sein wird, da sich dazu erstmal ein Win64 für den Desktop verbreiten muss und auch die CPU Basis groß genug sein muss um soetwas zu rechtfertigen. Darauf können wir wohl noch etwas warten. Was denkst du?

Intel wird mit DDR2 weniger Probleme haben. Der P7 hat schon früher mit höheren latenzen gekämpft und sein agressives Prefetching führt in vielen Fällen auch darum herum.
Der K8 dagegen zieht fast den gesamen Performancevorteil gegenüber dem K7 durch die niedrigere Latenz zum Speicher. DDR2 dürfte dem K8 zu Beginn mehr schaden als helfen.
Zumal du eines zu vergessen scheinst. schnellerer Speicher macht die CPUs nicht magisch schneller, sondern ist wirkt eigentlich nur der fallenden Saklierung entgegen.
Ich denke nicht dass wir so schnell immer höher getakteten DDR2 Speicher sehen werden, als dass der K8 großartig davonziehen könnte hinsichtlich Bandbreite.

Am Anfang wird es AMD vermutlich schwer haben mit 2ghz gegen den Prescot etwas entgegenzusetzten aber wenn dann schön langsam die ersten 64-bit Programme sowie DDRII Speicher rauskommt wird der A64 automatisch schneller werden ohne das AMD irgendwas machen muss.


siehe oben.
ich denke, der K8 im Desktopmarkt steht und fällt mit seiner 32Bit Leistung und seiner Taktrate.
DDR2 und 64Bit sind da eigentlich sekundäre Faktoren.

[-=O.C.B=-]

Original geschrieben von BlackBirdSR
ich denke, der K8 im Desktopmarkt steht und fällt mit seiner 32Bit Leistung und seiner Taktrate.
DDR2 und 64Bit sind da eigentlich sekundäre Faktoren.

ACK! Und die dürfte nicht ausreichen um einen Prescott auch nur
annährend in die Schranken zu verweisen. Tolle Technik die leider
ein wenig zu spät den Markt erreicht.

[Richthofen]

Original geschrieben von BlackBirdSR
naja, das hat Alles nichts mit der Latenzsituation zu tun.

Ob Intel nun auf den AMD Zug aufspringt leitet sich endgültig nur von der Marktsituation ab.
Und wenn Intel es schafft, die IA64 in den x86 Markt zu drücken, der unbedingt mehr als 32bit x86 Flat adressierung braucht, dann braucht man keine 64Bit x86 CPU.
Und der versprochene x86 Level eines 1.5GHZ XeonMP ist auch nicht wirklich übel für eine IA64 CPU.


Intel kann den IA64 nicht in den Desktop Markt drücken.
Das dreifache an Transistoren und somit bei gleichem Fertigungsprozess fast die 3fache Die Fläche.
Ein ziemlich teurer Spass.
Für den Desktop Markt schonmal nicht brauchbar, da sie so etwas nicht zu normalen Preisen verkaufen können.
Wenn sie es denoch tun wirds Zeit für die Kartellbehörden einzugreifen und zu schaun ob hier kostendeckend gearbeitet wird oder die Marktbeherrschende Stellung ausgenutzt wird einen Konkurenten tot zu dumpen.

Und auf AMD64 aufspringen, können sie zwar tun, aber dann wars das mit der Marktbeherrschenden Stellung. Dann wäre AMD am Zuge und könnte Intel in jeder Hinsicht bei der Weiterentwicklung behindern, so dass die das wertvolle Zeit kostet.

"
siehe oben.
ich denke, der K8 im Desktopmarkt steht und fällt mit seiner 32Bit Leistung und seiner Taktrate.
DDR2 und 64Bit sind da eigentlich sekundäre Faktoren.
"

Sehe ich nicht so. Aufgabe der Medien und OEMs wird es sein 64 Bit als das Non plus Ultra zu vermarkten, weil 64 Bit mehr als 32 Bit ist.
Es ist der Weg in die Zukunft und wenn Intel das im Desktop Markt nicht bietet, ist es nur fair wenn sie dafür bisserl bluten so einfach ist das.
Kann ja nicht schaden wenn sie nur noch 60 bis 65% Marktanteil haben. Das muss reichen :)

[reunion]

Original geschrieben von -=O.C.B=-
ACK! Und die dürfte nicht ausreichen um einen Prescott auch nur
annährend in die Schranken zu verweisen. Tolle Technik die leider
ein wenig zu spät den Markt erreicht.

Stimmt schon der jetztige Clawhammer ist viel zu spät dram aber das heißt nicht zwangsläufig das auch die nachfolgenden Modelle sich verspäten. Zum Beispiel wird bereit wenige Monate nach dem Clawhammer der San Diego(glaub zumindest das der so heißt) rauskomen der sowieso nicht früher gekommen wäre weil der 90nm Prozess forher sowieso nicht bereitgestanden gewesen wäre! Immerhin will AMD bereit Ende 2004 die 3ghz Schallmauer durchbrechen (hab das zumindest mal irgendwo gelesen) wo Intel "erst" bei 4ghz stehen wird(laut Roadmap).
Und da durfte der A64 bereits durch Dual-Channel Speicherinfance DDRII Speicher(deutlich höhere Taktraten) durch die mhz erhöhung auch eine noch kürzere Latenz zum Speicher haben und außerdem dürften da auch die ersten 64-bit "Programme" bereitstehen. Meiner Ansicht nach wird da Intel deutlich mehr als 4ghz brauchen um entgegenzuhalten.

mfg
reu

[reunion]

Original geschrieben von Richthofen
Kann ja nicht schaden wenn sie nur noch 60 bis 65% Marktanteil haben. Das muss reichen :)

:D :D :D

[Muh-sagt-die-Kuh]

Original geschrieben von Richthofen
Intel kann den IA64 nicht in den Desktop Markt drücken.
Das dreifache an Transistoren und somit bei gleichem Fertigungsprozess fast die 3fache Die Fläche.IA64 ist eine ISA, der Itanium II eine Implementation dieser ISA...klar, IA64 Binärcode ist eben etwas umfangreicher, das bedeutet aber nicht viel mehr als das Intel noch etwas wartet bis es IA64 für den Desktop gibt....nämlich solange bis man einen Fertigungsprozess hat, der ca 3 MB L3 Cache auf einer für Desktop CPUs üblichen DIE Größe unterbringen kann. Und solange sollte IA32 noch durchhalten können.Ein ziemlich teurer Spass.
Für den Desktop Markt schonmal nicht brauchbar, da sie so etwas nicht zu normalen Preisen verkaufen können.Mit solchen Aussagen würde ich mich zurückhalten wenn ich die genauen Stückkosten nicht kenne.Sehe ich nicht so. Aufgabe der Medien und OEMs wird es sein 64 Bit als das Non plus Ultra zu vermarkten, weil 64 Bit mehr als 32 Bit ist.Was Medien und OEMs sagen ist den meisten Entwicklern vollkommen egal, für eine neue Plattform wird ohne speziellen Anreiz erst dann entwickelt wenn diese weit genug verbreitet ist, ansonsten stimmt das Kosten/Nutzen Verhältnis einfach nicht.

Ob es dir passt oder nicht, der Athlon 64 wird an seiner 32 bit Leistung gemessen werden.Es ist der Weg in die Zukunft und wenn Intel das im Desktop Markt nicht bietet, ist es nur fair wenn sie dafür bisserl bluten so einfach ist das.
Kann ja nicht schaden wenn sie nur noch 60 bis 65% Marktanteil haben. Das muss reichen :) Intel hat HyperThreading, ein meiner Meinung nach, sehr schönes Feature das sofort einsetzbar ist, relativ viel bringt und mit dem Prescott noch verbessert wird....wie siehts denn beim Athlon 64 mit SMT aus? ;)

[GloomY]

Original geschrieben von Richthofen
Intel kann den IA64 nicht in den Desktop Markt drücken.
Das dreifache an Transistoren und somit bei gleichem Fertigungsprozess fast die 3fache Die Fläche.
Ein ziemlich teurer Spass.
Für den Desktop Markt schonmal nicht brauchbar, da sie so etwas nicht zu normalen Preisen verkaufen können.Richtig, das ist ein sehr wichtiges Argument.
Die Performance bei EPIC CPUs ist sehr auf Cache Misses anfällig. Daher braucht man gute Hitrates, ergo auch große Caches, was den Prozessor unglaublich teuer macht. Hier ist es kaum möglich eine low- oder mid-Cost Version zu produzieren, ohne die Performance viel zu stark zu verschlechtern.
IA-64 ist für den Desktopmarkt einfach nicht geeignet, zumindest nicht, bis die angesprochenen 3 MB L2 Cache problemlos auf einen Die zu günstigen Kosten untergebracht werden können. Davon sind wir aber noch ein gutes Stückchen entfernt.

Ansonsten möchte ich doch mal auf die Sache mit der Bandbreite eingehen (die im Opteron Thread auch angesprochen wurde). So wie's aussieht, hat der Clawhammer nur ein single Channel Speicherinterface. Natürlich wäre Dual Channel besser, keine Frage. Aber wie schlimm ist dieser Verzicht wirklich?
Hier möchte ich vor allem mal daran erinnern, dass der P4 bei der gleichen Anwendung deutlich mehr Bandbreite braucht bzw. verbraucht verglichen mit dem Athlon / Hammer. Die Hitrate der beiden Caches des P4s ist schlechter und die Line Size ist größer. Daraus resultieren öftere Zugriffe auf den RAM, wobei bei jedem Zugriff mehr Daten gelesen/geschrieben werden (müssen). Hier gibt es also einen deutlich höhereren Verbrauch an Bandbreite, wobei die beiden Plattformen genau das gleiche machen.
Eigentlich ist es schon recht erstaunlich, wie gut ein Barton mit nF2 gegen P4 mit Canterwood in Streaming Anwendung davonkommt, besonders wenn man bedenkt, dass die zur Verfügung stehende Bandbreite gerade mal halb so groß ist. Der P4 dominiert hier, aber von dopelter Performance Dank doppelter Bandbreite ist hier weit und breit nichts zu sehen.
Der Athlon hat auch längst nicht so viel beim Umstieg von SDR auf DDR Speicher profitiert, wie es der P4 getan hat (die P4 Ergebnisse mit SDR SDRAM waren ja fatal). Analog dazu behaupte ich mal, dass es mit einem zweiten Speicherkanal beim Clawhammer ebenfalls nicht zu all zu großen Gewinnen gekommen wäre. Ausserdem senkt die Vergrößerung des L2 Caches beim Clawhammer den Verbrauch der realen Bandbreite, da hiermit ja auch die Hitrate der Caches zunimmt, was zu weniger Zugriffen auf den Hauptspeicher führt. Das gilt natürlich auch für den Prescott, aber der hat ja eh genug Bandbreite.

Was die meisten Anwendungen angeht, so behaupte ich mal, dass diese ab einer gewissen Grundbandbreite gesättigt sind. Wenn von der Bandbreite mehr vorhanden ist, dann beschleunigt das nur noch recht wenig, da andere Einflüsse (Latenz, CPU-Geschwindigkeit) hier deutlich stärker limitieren. Ausnahmen sind hier natürlich Streaming Anwendungen, die ja prinzipiell bandbreitenlimitiert sind.

Das alles bringt mich zum Schluss, dass der "Verlust" des zweiten Speicherkanals für den Clawhammer doch nicht so fatal ist, wie es auf den ersten Blick vielleicht aussehen mag. Der Clawhammer wird bei Streaming Anwendungen sicher keinen Stich gegen den P4 machen, das ist sonnenklar. Was aber die anderen Anwendungen betrifft, so vermute ich mal, dass der Bandbreitenvorteil des Prescotts nicht all zu viel ausmachen wird.

Das bringt mich zu einem weiteren Punkt. CPUs werden bekanntermaßen vom Speicher ausgebremst. Wenn es aber nicht die Bandbreite ist, was ist es dann? Die Antwort kann nur Latenz heißen. Und gerade hier hat der Hammer ja seine Vorteile.
Wenn ich mir die Ergebnisse des Cachemem Tests von z.B. nForce2 und Opteron angucke und in diesem Zusammenhang jemand behauptet, dass der nForce2 ja schon fast die Latenzen des Opterons schafft, dann kann ich nur herzlich lachen. Sowas ist eine Behauptung ohne Belege. Dabei sprechen die Zahlen von hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=976171#post976171), hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=983882#post983882) und hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=968277#post968277) eher dagegen. Betrachtet man diese ein wenig (z.B. die 4k Steps, 32MB Blocks Size Werte) und rechnet ein wenig mit den Takten herum, dann kommt folgendes dabei heraus:

Kurgans nF2 2-2-2 Timing: 2142 MHz, 221 MHz Speichertakt, Messung: 190 CPU Clocks -> 19,6 RAM-Takte für Zugriff
MOB nF2 ?-?-? Timing: 1533 MHz, 133 MHz Speichertakt, Messung: 207 CPU Clocks -> 17,9 RAM-Takte für Zugriff
Opteron ?-?-? Timing: 1400 MHz, 133 MHz Speichertakt (reg), Messung: 161 CPU Clocks -> 15,3 (14,3) RAM-Takte für ZugriffDie Zahl in Klammern ist das Ergebnis minus eins, da der Opteron registered RAM benutzt, welches immer (mindestens) einen Takt langsamer ist. Wenn man nur die Effizienz des Speicherzugriffs bewerten will, so stehen einmal 19,6 und 17,9 Takte beim nForce2 da und einmal 14,3 Takte beim Opteron. Das ist doch ein recht großer Unterschied.

Ich denke, hier liegen u.A. die wirklichen Stärken des Hammers. Ob das gegen den Prescott reicht, kann man zum jetzigen Zeitpunkt noch nicht sagen, weil einfach noch vergleichsweise wenig Informationen seitens Intel vorhanden sind.

[BlackBirdSR]

Original geschrieben von GloomY
Richtig, das ist ein sehr wichtiges Argument.
Die Performance bei EPIC CPUs ist sehr auf Cache Misses anfällig. Daher braucht man gute Hitrates, ergo auch große Caches, was den Prozessor unglaublich teuer macht. Hier ist es kaum möglich eine low- oder mid-Cost Version zu produzieren, ohne die Performance viel zu stark zu verschlechtern.
IA-64 ist für den Desktopmarkt einfach nicht geeignet, zumindest nicht, bis die angesprochenen 3 MB L2 Cache problemlos auf einen Die zu günstigen Kosten untergebracht werden können. Davon sind wir aber noch ein gutes Stückchen entfernt.


es geht auch nicht um den Desktopmarkt, sondern Workstation und Server.
Da hat mich Richthofen einfach falsch (gelesen) verstanden.

[Gast]

Original geschrieben von Muh-sagt-die-Kuh
Intel hat HyperThreading, ein meiner Meinung nach, sehr schönes Feature das sofort einsetzbar ist, relativ viel bringt und mit dem Prescott noch verbessert wird....wie siehts denn beim Athlon 64 mit SMT aus? ;) [/SIZE]

SMT wird möglicherweise bereits im A64 enthalten sein.
Jan Gütter hat erst vor kurzem gesagt, dass der A64 den P4 übertreffen wird.
Ebenfalls gab es von AMD vor kurzem ein Statement, welches besagt, dass der endgülgite A64 ein future haben wird, was bisher in den Samples deaktiviert war.

Was genau das nun ist kann man nur spekulieren, ich jedenfalls glaube dass es SMT sein wird

[-=O.C.B=-]

Original geschrieben von reunion
Stimmt schon der jetztige Clawhammer ist viel zu spät dram aber das heißt nicht zwangsläufig das auch die nachfolgenden Modelle sich verspäten. Zum Beispiel wird bereit wenige Monate nach dem Clawhammer der San Diego(glaub zumindest das der so heißt) rauskomen der sowieso nicht früher gekommen wäre weil der 90nm Prozess forher sowieso nicht bereitgestanden gewesen wäre! Immerhin will AMD bereit Ende 2004 die 3ghz Schallmauer durchbrechen (hab das zumindest mal irgendwo gelesen) wo Intel "erst" bei 4ghz stehen wird(laut Roadmap).
Und da durfte der A64 bereits durch Dual-Channel Speicherinfance DDRII Speicher(deutlich höhere Taktraten) durch die mhz erhöhung auch eine noch kürzere Latenz zum Speicher haben und außerdem dürften da auch die ersten 64-bit "Programme" bereitstehen. Meiner Ansicht nach wird da Intel deutlich mehr als 4ghz brauchen um entgegenzuhalten.

mfg
reu

Von Dual-Channel wird der A-64 imo nicht so gewaltig profetieren
wie das beim P4/Prescott der Fall ist. Naja und die Latenzen sind
eh verdammt gering - Auch jetzt beim Opteron. Ob da noch so viel
zu holen ist? Wie Glomy schrieb liegt das Hauptprob für AMD bei
den Streaming-Anwendungen. Intel hat recht früh die Zeichen der
Zeit erkannt und seine Architektur darauf abgestimmt - AMD muss
nun zuschauen, wie sie Stück für Stück an Boden verlieren. Auf
eine baldige Verfügbarkeit von 64-bit Software würde ich nur im
OpenSource Bereich setzen. Man kann hier denke ich zurecht Ver-
gleiche zu MMX/SSE/SSE2 ziehen - Bis diese Befehlserweiterungen
genutzt wurden ging einiges an Zeit ins Land...Mit AMD´s
64-bit Erweiterung wirds nicht anders sein. Auch wird wird mit
Sicherheit abgewartet bis eine genügend grosse Installationsbasis
vorhanden ist. Ansonsten kann man kaum Produkte gewinnbringend
entwickeln/vertreiben...

[Exxtreme]

Original geschrieben von Richthofen
Sehe ich nicht so. Aufgabe der Medien und OEMs wird es sein 64 Bit als das Non plus Ultra zu vermarkten, weil 64 Bit mehr als 32 Bit ist.

So sieht's aus.

Und 64-Bit-Software wird wirklich sehr schnell verfügbar sein, Stichwort: Linux. Da die Sourcen und Compiler verfügbar sind, ist es im Endeffekt nur ein Compiler-Switch. Ich denke, daß innerhalb weniger Wochen die wichtigsten Linux-Anwendungen in einer 64-Bit-Version zu haben sein werden.

[GloomY]

Original geschrieben von BlackBirdSR
es geht auch nicht um den Desktopmarkt, sondern Workstation und Server.
Da hat mich Richthofen einfach falsch (gelesen) verstanden. Wie? Ich denke es geht um Clawhammer und Prescott, also doch Desktopsysteme.
Deine Vermutung, dass IA64 eventuell in den Desktopmarkt reinkommt, hat Richthofen und daanch ich als nicht verkäuflich eingestuft. Es ging schon immer um den Desktop.
Original geschrieben von Muh-sagt-die-Kuh
IA64 ist eine ISA, der Itanium II eine Implementation dieser ISA...klar, IA64 Binärcode ist eben etwas umfangreicher128 Bit für drei Befehle, puh....
Original geschrieben von Muh-sagt-die-Kuh
das bedeutet aber nicht viel mehr als das Intel noch etwas wartet bis es IA64 für den Desktop gibt....nämlich solange bis man einen Fertigungsprozess hat, der ca 3 MB L3 Cache auf einer für Desktop CPUs üblichen DIE Größe unterbringen kann. Und solange sollte IA32 noch durchhalten können.Also wir sind jetzt gerade mal bei etwa 100 Mio. Transistoren (Opteron) angelangt, inklusiv 1 MB Cache, welche etwas mehr als die Hälfte des Dies einnimmt.
Nicht zu vergessen, dass der Itanium stark superskalar ist (das ist ja gerade der Sinn hinter EPIC), also neben dem großen Cache auch noch viel Platz für die vielen Funktionseinheiten auf dem Die braucht.

Ich würde mal schätzen, dass man hier etwa die vierfache Anzahl an Transistoren auf dem Die benötigt wird, um Prozessor plus 3 MB Cache dort unterzubringen. Laut Moores Gesetz wird das also wahrscheinlich noch 3 Jahre dauern.
Ob Intel bis dahin noch mit IA-32 auskommt, ist imho fraglich.
Original geschrieben von Muh-sagt-die-Kuh
Ob es dir passt oder nicht, der Athlon 64 wird an seiner 32 bit Leistung gemessen werden.Die erste Version sicher. Wie es danach aussieht, hängt u.a. auch vom Support der Betriebssysteme und Compiler ab.

[-=O.C.B=-]

Original geschrieben von Exxtreme
So sieht's aus.

Und 64-Bit-Software wird wirklich sehr schnell verfügbar sein, Stichwort: Linux. Da die Sourcen und Compiler verfügbar sind, ist es im Endeffekt nur ein Compiler-Switch.

Nur wollen die meisten User immernoch ihr geliebtes Windoof +
MS-Office haben. Von den Gamern rede ich gar ned erst...;)


Ich denke, daß innerhalb weniger Wochen die wichtigsten Linux-Anwendungen in einer 64-Bit-Version zu haben sein werden.
Was sollen das für Progs sein? Ein Browser oder Mail-Client auf
einem 64-bit OS wird mich kaum glücklicher machen. Das dürften
dann doch eher die Entwicklerwerkzeuge sein...Und wieviele User
die nutzen...

[-=O.C.B=-]

Original geschrieben von Richthofen
Sehe ich nicht so. Aufgabe der Medien und OEMs wird es sein 64 Bit als das Non plus Ultra zu vermarkten, weil 64 Bit mehr als 32 Bit ist.
Es ist der Weg in die Zukunft und wenn Intel das im Desktop Markt nicht bietet, ist es nur fair wenn sie dafür bisserl bluten so einfach ist das.
Kann ja nicht schaden wenn sie nur noch 60 bis 65% Marktanteil haben. Das muss reichen :)

Nur gibt es keinen der sie dafür so gut bezahlt wie Intel es nunmal
tut/kann. Von daher wird 64-bit auf dem Desktop kaum gehyped werden.
Und ne Killer-Applik für 64-bit sehe ich im Desktop-Bereich auch
nicht. Bedingt durch die riesige Anzahl an Büro-PC´s wird sich da
am Markanteil auch kaum etwas verändern. Hier setzen die OEM´s auf
altbewährtes und sind zu dem an doch meist längerfristige Abnahme-
verträge gebunden. In Zeiten von eher sinkenden/stagnierenden Ab-
satzzahlen siehst für AMD imo eher düster aus! Wenn die ned nen
wirkliches gutes Yield hinbekommen dann...Intel streicht Quartal für
Quartal Gewinne ein. Bei AMD ist man froh wenn die Zahlen mal nicht
ganz so rot sind...

[Muh-sagt-die-Kuh]

Original geschrieben von Exxtreme
So sieht's aus.

Und 64-Bit-Software wird wirklich sehr schnell verfügbar sein, Stichwort: Linux. Da die Sourcen und Compiler verfügbar sind, ist es im Endeffekt nur ein Compiler-Switch. Ich denke, daß innerhalb weniger Wochen die wichtigsten Linux-Anwendungen in einer 64-Bit-Version zu haben sein werden. Solange man keinen inline-Assembler benutzt ist es in den meisten Fällen wirklich nur ein Compilerswitch, bei Linux also kein größeres Problem (mal abgesehen davon, dass 64 bit GCC Compilate teils langsamer laufen als 32 bit Versionen und dass es für 32 bit den hochoptimierten Intel Compiler gibt, für x86-64 aber nicht).

Mit kommerzieller Software ist das anders, wie genau hab ich oben schon beschrieben.

[Muh-sagt-die-Kuh]

Original geschrieben von Gast
SMT wird möglicherweise bereits im A64 enthalten sein.
Jan Gütter hat erst vor kurzem gesagt, dass der A64 den P4 übertreffen wird.
Ebenfalls gab es von AMD vor kurzem ein Statement, welches besagt, dass der endgülgite A64 ein future haben wird, was bisher in den Samples deaktiviert war.

Was genau das nun ist kann man nur spekulieren, ich jedenfalls glaube dass es SMT sein wird Pressesprecher reden viel wenn der Tag lang ist ;)

SMT beim Athlon 64 halte ich nicht für wahrscheinlich....wieso sollte man einer Desktop CPU etwas geben, was die Server Versionen nicht haben (und wo es noch sinnvoller wäre)?

[Muh-sagt-die-Kuh]

Original geschrieben von GloomY
Also wir sind jetzt gerade mal bei etwa 100 Mio. Transistoren (Opteron) angelangt, inklusiv 1 MB Cache, welche etwas mehr als die Hälfte des Dies einnimmt.
Nicht zu vergessen, dass der Itanium stark superskalar ist (das ist ja gerade der Sinn hinter EPIC), also neben dem großen Cache auch noch viel Platz für die vielen Funktionseinheiten auf dem Die braucht.Dafür spart man sich aufwendige Scheduler, da es sich um ein in-order Design handelt....insgesamt ist der eigentliche Core sogar recht schlank.

Bei aktuellen x86 Designs ist der Platzbedarf der Funktionseinheiten im Vergleich zu Decodern, Schedulern und Register-Renamern fast schon vernachlässigbar ;)
Ich würde mal schätzen, dass man hier etwa die vierfache Anzahl an Transistoren auf dem Die benötigt wird, um Prozessor plus 3 MB Cache dort unterzubringen. Laut Moores Gesetz wird das also wahrscheinlich noch 3 Jahre dauern.Möglich...wobei ich 2 MB L3 auch noch für leistungsmässig tolerabel halten...und das ist schon früher machbar.Die erste Version sicher. Wie es danach aussieht, hängt u.a. auch vom Support der Betriebssysteme und Compiler ab. Richtig, deshalb muss der Athlon 64 einen ziemlich großen Marktanteil erreichen damit auch für die Entwickler ein Anreiz besteht für diese Architektur zu entwickeln.

[BlackBirdSR]

Original geschrieben von GloomY
Wie? Ich denke es geht um Clawhammer und Prescott, also doch Desktopsysteme.
Deine Vermutung, dass IA64 eventuell in den Desktopmarkt reinkommt, hat Richthofen und daanch ich als nicht verkäuflich eingestuft. Es ging schon immer um den Desktop.


wir treffen uns schon noch irgendwo :)

ich meinte nicht dass IA-64 in den Desktopmarkt gedrückt wird, das hat Richthofen erfunden.
Vielmehr rede ich vin IA-64 im Server und Workstationmarkt. Deshalb auch der obige Post, da Richtihofen aus diesem eben mal schnell den x86 Desktopmarkt gemacht hat.

ich fühle mich als zu unrecht unter die Kettensäge gestellt :chainsaw:

[Exxtreme]

Original geschrieben von -=O.C.B=-
Nur wollen die meisten User immernoch ihr geliebtes Windoof +
MS-Office haben. Von den Gamern rede ich gar ned erst...;)
Für's Office brauchste keine 64-Bit-CPU. Ausserdem ist bei MS-Office auch die 16-Bit-Leistung wichtig. ;)
Original geschrieben von -=O.C.B=-
Was sollen das für Progs sein? Ein Browser oder Mail-Client auf
einem 64-bit OS wird mich kaum glücklicher machen. Das dürften
dann doch eher die Entwicklerwerkzeuge sein...Und wieviele User
die nutzen...
Sehe ich auch so. Aber wie Richthofen schon sagte, die psychologische Wirkung dürfte nicht ganz ohne sein.

[Gast]

Original geschrieben von Muh-sagt-die-Kuh
Pressesprecher reden viel wenn der Tag lang ist ;)

SMT beim Athlon 64 halte ich nicht für wahrscheinlich....wieso sollte man einer Desktop CPU etwas geben, was die Server Versionen nicht haben (und wo es noch sinnvoller wäre)?

Weil es beim Launch des Opteron vielleicht noch nicht ausgereift war ? Wäre eine möglichkeit.
Ich kann mir gut vorstellen, dass AMD das hier beim 2Ghz Opteron aktiviert und zusammen mit dem A64 veröffentlicht.

[BlackBirdSR]

Original geschrieben von Gast
Weil es beim Launch des Opteron vielleicht noch nicht ausgereift war ? Wäre eine möglichkeit.
Ich kann mir gut vorstellen, dass AMD das hier beim 2Ghz Opteron aktiviert und zusammen mit dem A64 veröffentlicht.

durchaus möglich, aber unwahrscheinlich.

[Gast]

Also, Apple tritt nun in den 64 Bit Markt, wenn ihr denkt das intel sich auf 32 Bit zurücklehnen kann vergeßt es Billi wird es auch freuen Wie sagt er doch so gerne(it must look like a mac) und IBM drückt den 64-Bit PowerPC somit auch in den Massen Markt

Wir dann wohl so ausschauen
AMD 50% im Desktop 64 Bit Segment
Apple 50% im Desktop 64 Bit Segment
Branchen Primus 0

Nee das geht gar überhauptnicht dann können sie die Bude gleich dicht machen wäre genauso sinnvoll

[ShadowXX]

@Exxtreme


Original geschrieben von Exxtreme

--------------------------------------------------------------------------------
Original geschrieben von -=O.C.B=-
Was sollen das für Progs sein? Ein Browser oder Mail-Client auf
einem 64-bit OS wird mich kaum glücklicher machen. Das dürften
dann doch eher die Entwicklerwerkzeuge sein...Und wieviele User
die nutzen...
--------------------------------------------------------------------------------


Sehe ich auch so. Aber wie Richthofen schon sagte, die psychologische Wirkung dürfte nicht ganz ohne sein.

Nur wird AMD Probleme haben diese 'psychologische Wirkung' überhaupt in Gang zu setzen, wenn am Anfang eine Killerapplikation/Game fehlt!!!

Und damit meine ich (und wie ich gelesen habe auch andere) nicht ein 64-Bit Windows incl. 64-Bit I-Explorer, 64-Bit Bluescreens und 64-Bit Sicherheitslücken....

Und nur über Linux wird AMD keine CPUs in grösseren Stückzahlen verkaufen...

zu UT2003: ich glaube nicht das EPIC mit den 33% eine allemeine Steigerung der Performance gemeint hat, sondern mehr wie ati/nv eine Steigerung um 33% in bestimmten Scenarien...

J.S.Shadow

[Gast]

Ja und!
Mmx, 3dnow, isse ,sse2, sse3 wurde sofort komplett und von jedem unterstützt, es hat 300% mehr Leistung sofort in jeder Anwendung gebrach, und beschleunigt das inet und ersetzt den dsl Anschluß da der nicht genug Bandbreite hat und die latenz zu hoch ist!

Schonmal aufgefallen das es egal ist, siehe grakarten und
dirctx 9! Jetzt sind Al die tollen directx9 Effekte endlich in Siedler freigeschaltet, es lohnt wieder zu zocken bei nie dagewesener Grafik Pracht endlich können sie Siedler genießen.

Ob was und wann ist egal Hauptsache! Hauptsache er hat was das sich besser vermarkten läßt. Das klappt ja nun schon seit Anbeginn unserer Ära!

[Muh-sagt-die-Kuh]

Original geschrieben von Gast
Wir dann wohl so ausschauen
AMD 50% im Desktop 64 Bit Segment
Apple 50% im Desktop 64 Bit Segment
Branchen Primus 0

Nee das geht gar überhauptnicht dann können sie die Bude gleich dicht machen wäre genauso sinnvoll Was du hier machst, ist verschiedene (fast) disjunkte Märkte in einer Statistik zu vermischen (x86 und Mac)...mal abgesehen davon ist das reine Spekulation.

Wieso intel dann gleich dich machen kann entzieht sich auch meinem Blickfeld.

[Muh-sagt-die-Kuh]

Original geschrieben von Exxtreme
Für's Office brauchste keine 64-Bit-CPU. Ausserdem ist bei MS-Office auch die 16-Bit-Leistung wichtig. ;)Für die meisten UNIX Commandline Tools braucht man auch keine 64 bit ;)

[GloomY]

Original geschrieben von BlackBirdSR
wir treffen uns schon noch irgendwo :)

ich meinte nicht dass IA-64 in den Desktopmarkt gedrückt wird, das hat Richthofen erfunden.
Vielmehr rede ich vin IA-64 im Server und Workstationmarkt. Deshalb auch der obige Post, da Richtihofen aus diesem eben mal schnell den x86 Desktopmarkt gemacht hat.

ich fühle mich als zu unrecht unter die Kettensäge gestellt :chainsaw: Entschuldigung, ich wollte dich nicht unter die Kettensäge stellen. :)

Irgendwie haben wir etwas aneinander vorbeigeredet :|
Original geschrieben von ShadowXX
zu UT2003: ich glaube nicht das EPIC mit den 33% eine allemeine Steigerung der Performance gemeint hat, sondern mehr wie ati/nv eine Steigerung um 33% in bestimmten Scenarien...Ich meine mich zu erinnern, dass die Leistungssteigerung doch recht beachtlich war.
Imho hat Valve doch auch eine x86-64 Version von ihrem CS Server für Linux herausgebracht, wenn ich mich nicht irre.

Update: http://www.counter-strike.net , zweite News. Valve spricht hier von "30% clock-for-clock gain" :)

[BlackBirdSR]

Original geschrieben von GloomY
Entschuldigung, ich wollte dich nicht unter die Kettensäge stellen. :)

Irgendwie haben wir etwas aneinander vorbeigeredet :|
Ich meine mich zu erinnern, dass die Leistungssteigerung doch recht beachtlich war.
Imho hat Valve doch auch eine x86-64 Version von ihrem CS Server für Linux herausgebracht, wenn ich mich nicht irre.

Update: http://www.counter-strike.net , zweite News. Valve spricht hier von "30% clock-for-clock gain" :)

kein Problem.

Aber was diese 64Bit Spiele :bäh: angeht: Machen diese extra 8 Register bei Spielen so viel aus? Wir haben Spec Benches mit 64bit COmpilern gesehen und das Ergebnis war eher bunt gemischt.

[Bokill]

Eine kleine Klarstellung, bitte nennt die CPU`s wie sie heissen!
AMD CPU`s Athlon64/Opteron!

Instruktionssatz für AMD`s neue CPUs in 64Bit AMD64, alle anderen Mischformen sind schlicht falsch!

Is nur ne kleine Bitte!

BlackBirdSR, hatte sicher nicht mehr die Zeit zur Belehrung.
BlackBirdSR ist einer der wenigen vor Ort, der die korrekten Bezeichnungen wählt!

PS. Auch Codenamen sind Ok und eindeutig! BlackBirdSR verwendete diese Codenamen einige Male, K8, Clawhammer etc.

PPS. Ich liebe den Genitiv!

[GloomY]

Original geschrieben von Bokill
Eien kleine Klarstellung, bitte nennt die CPU`s wie sie heissen!
CPU`s Athlon64/Opteron! Dir ist aber schon bekannt, dass einen offiziellen Namen und einen Codenamen gibt? Daher ist Clawhammer äquivalent zu Athlon64, Sledgehammer zu Opteron. Warum soll man nur die offiziellen Namen verwenden, wenn man sich z.T. mit den Codenamen sehr viel präziser ausdrücken kann? Ich erinnere hier nurmal an die 5 verschiedenen Celeron Modelle ;) Ok, beim Hammer (ja, damit ist die Menge aller Prozessoren gemeint, bei denen der Teilstring "Hammer" im Codenamen zu finden ist) ist das nicht wirklich notwendig. Es kann imho aber auch nicht schaden.
Original geschrieben von Bokill
Instruktionssatz für AMD`s neue CPU`s in 64Bit AMD64, alle anderen Mischformen sind schlicht falsch!Wo ist denn deiner Meinung nach der Unterschied zwischen "x86-64" und der von dir vertretenen Bezeichnung "AMD64" ?
Original geschrieben von Bokill
BlackBirdSR, hatte sicher nicht mehr die Zeit zur Belehrung.Ich glaube nicht, dass er umbedingt belehrt hätte...

Ach ja, eine kleine Bitte an dich: Lies' dir mal das hier (http://members.aol.com/apostrophs/) mal durch ;)

Original geschrieben von BlackBirdSR
Aber was diese 64Bit Spiele :bäh: angeht: Machen diese extra 8 Register bei Spielen so viel aus? Wir haben Spec Benches mit 64bit COmpilern gesehen und das Ergebnis war eher bunt gemischt. Der einzigste Nachteil bei 64 Bit Code ist die geringere Code-Dichte, weil die Pointer einfach doppelt so groß sind.
Vielleicht hat die SPEC Suite besonders viele davon?

Ansonsten sehe ich aber bei einem Programm wie den oben genannten Spielen schon eher die Möglichkeit, zu optimieren. Hier kann man bestimmte Codestücke gezielt durch besseren Code ersetzen. Im Gegensatz zur SPEC Suite, die man nur durch den Compiler jagt, kennt man ja hier das eigentliche Programm und auch das eigentliche Problem, welches das Programm löst.
Ich glaube nicht, dass man mal eben +30% herausbekommt, indem man einfach einen anderen Compilerswitch verwendet. Da war sicher gezielte Optimierung des Quellcodes angesagt.

[betasilie]

Original geschrieben von GloomY
Dir ist aber schon bekannt, dass einen offiziellen Namen und einen Codenamen gibt? Daher ist Clawhammer äquivalent zu Athlon64, Sledgehammer zu Opteron. Warum soll man nur die offiziellen Namen verwenden, wenn man sich z.T. mit den Codenamen sehr viel präziser ausdrücken kann? Ich erinnere hier nurmal an die 5 verschiedenen Celeron Modelle ;) Ok, beim Hammer (ja, damit ist die Menge aller Prozessoren gemeint, bei denen der Teilstring "Hammer" im Codenamen zu finden ist) ist das nicht wirklich notwendig. Es kann imho aber auch nicht schaden.
Wo ist denn deiner Meinung nach der Unterschied zwischen "x86-64" und der von dir vertretenen Bezeichnung "AMD64" ?
Ich glaube nicht, dass er umbedingt belehrt hätte...

Ach ja: Eine Kleine Bitte an dich: Lies' dir mal das hier (http://members.aol.com/apostrophs/) mal durch ;)
Full Ack.
Athlon64 ist die unpräzise Bezeichnung, denn der Clawhammer wird nur der erste Athlon64 sein und über diesen wird ja u.a. diskutiert.

...Und wenn Du den Link nicht gepostet hättest, wäre ich derjenige gewesen. ;)

[Endorphine]

Es war schon immer praktischer, die IC-Codenamen zu verwenden. Marketingbezeichnungen werden vom Hersteller so verwandt, wie es wirtschaftlich Sinn macht. Bei Diskussionen geht es aber im Regelfall um die Technik und da ist ein Codename wesentlich genauer.

Auch wenn "Athlon64" statt "Clawhammer" der offizielle Begriff ist - exakter ist hier letzteres :)

Und AMD64/AA64 sollte man imo auch nebeneinander verwenden können. Der Begriff "IA16/32/64" wird wirklich schon seit langem verwendet, "AA64" fügt sich dort sehr gut ein und leuchtet sofort ein. "AMD64" ist wieder nur eine Marketingbezeichnung.

Generell hat Bokill aber natürlich irgendwo Recht - die offiziellen Bezeichnungen sind "Athlon 64" und "AMD64". Üblich ist aber bei Fachdiskussionen aus verschiedenen Gründen anderers :)

p.s. So wie eben auch "PC2700" nur eine Marketingbezeichnung ist, obwohl "DDR333 SDRAM Module/DIMM" die korrekte offizielle Bezeichnung wäre *Gloomystichel* ;)

[BlackBirdSR]

wo ist mein Post hin? da steht nur noch ein halber Quote?!?
naja.. pech gehabt

[strauch]

Original geschrieben von reunion Es besteitet auch keiner das der Prescot scheller sein wird nur glaub ich maximal in einer größenordnung von 10% bei gleichen Takt und nicht so wie bei wilametta 20% und mehr.

Der Prescott wird im Verhältnis schneller sein als der Northwood zum Wilamette. Der einzige Unterschied zwischen Wilamette und Northwood lag im verdoppelten L2 Cache. Beim Prescott wird der L1 Cache, der Trace Cache und der L2 Cache vergrößert und dazu kommen noch weitere SSE Befehle und zuguter letzt wird das HyperThreading noch verbessert. Insgesamt also ne ganze Menge, was mich zu dem Schluss kommen lässt das der Prescott doch deutlich mehr zulegen wird, als der Northwood.

[Endorphine]

Original geschrieben von strauch
Der einzige Unterschied zwischen Wilamette und Northwood lag im verdoppelten L2 Cache. Noe.

http://www.3dcenter.org/images/2003/02-21_bild1.jpg

Ausserdem greift hier wieder mal das Gesetz des abnehmenden Ertrages - je ausgefeilter eine Architektur schon ist, um so weniger Effekt haben weitere Verbesserungen.

[Bokill]

Codenamen sind Ok, aber zum Teil werden Schöpfungen wie A6ß und anderes Zeugs verwendet. Dies will ich gar nicht nennen, da sonst sich der falsche Krempel einprägt, wenn jemand alte Begriffe nimmt ist dies ja auch eindeutig, dagegen habe ich nichts,...

aber diese krausen Eigengewächse sind fürchtbar, denn so kann man manchmal ziemlich danebenraten, wenn zB. von Instruktionen die Rede ist aber ständig von einer CPU geschrieben wird!

... gekillt...

...gekillt...


Zu den Codenamen habe ich nichts weiter gesagt!

...gekillt...

...In meinen Augen Codenamen völlig in Ordnung, da diese sogar wesentlich eindeutiger sind!


Und AMD64/AA64 sollte man imo auch nebeneinander verwenden können. Der Begriff "IA16/32/64" wird wirklich schon seit langem verwendet, "AA64" fügt sich dort sehr gut ein und leuchtet sofort ein. "AMD64" ist wieder nur eine Marketingbezeichnung

Ich denke die Sprachregelungen von Endorphine sind da schon besser, zumal er sicherlich meine Hauptaussage mit Nebensatz und nicht geschriebenen Satz, vollständig verstanden hat.
Jedenfalls hat er A6x vermieden
:D :D

[BlackBirdSR]

Original geschrieben von Bokill
Codenamen sind Ok, aber zum Teil werden Schöpfungen wie A64 und anderes Zeugs verwendet. Dies will ich gar nicht nennen, da sonst sich der falsche Krempel einprägt, wenn jemand alte Begriffe nimmt ist dies ja auch Eindeutig, dagegen habe ich nichts,...

aber diese krausen Eigengewächse sind fürchtbar, denn so kann man manchmal ziemlich danebenraten, wenn zB. von Instruktionen die Rede ist aber ständig von einer CPU geschrieben wird!

ich weiss nicht ganz wo das Problem bei A64 liegt.
Aus Thoroughbred und Thunderbird wurden ja auch Tbird und Tbred.

Ansonsten hast du schon recht. Dann eben MPU statt CPU :)

[Bokill]

ich weiss nicht ganz wo das Problem bei A64 liegt.
Aus Thoroughbred und Thunderbird wurden ja auch Tbird und Tbred.

Ansonsten hast du schon recht. Dann eben MPU statt CPU


Genau da haben wir das Problem!
Meinst du mit dem Begriff die CPU oder den Instruktionssatz? Dieser Mischmasch lässt beides zu!

Bei Codenamen, die dann verkürzt, Popularisiert werden, ist wenigstens eine eindeutige Zuordnung möglich!

MPU ist mir bisher nicht über den Weg gelaufen, CentralProzessingUnit CPU ist, denke ich, ebenso eindeutig und allgemein verständlich.

BlackBirdSR, erzähl doch mal was MPU bedeutet, dann können wir alle noch etwas lernen!
:D

[BlackBirdSR]

Original geschrieben von Bokill
Genau da haben wir das Problem!
Meinst du mit dem Begriff die CPU oder den Instruktionssatz? Dieser Mischmasch lässt beides zu!

Bei Codenamen, die dann verkürzt, Popularisiert werden, ist wenigstens eine eindeutige Zuordnung möglich!

MPU ist mir bisher nicht über den Weg gelaufen, CentralProzessingUnit CPU ist, denke ich, ebenso eindeutig und allgemein verständlich.

BlackBirdSR, erzähl doch mal was MPU bedeutet, dann können wir alle noch etwas lernen!
:D

AMD64 ist den meisten leuten eh nicht geläufig. Also kann man das wirklich mit dem Befehlssatz verwechseln?!?..
Nagut überredet.

MPU steht für Main Processing Unit (meinetwegen auch Microprocessor Unit, oder Micro Processing Unit ;) ), und ist der allgemeinere Term für die zentralen Rechenknechte. Einige Leute in der Industrie sehen eben gar nicht gerne wie manche mit CPU umgehen.

[Endorphine]

BPU steht für Bokill Processing Unit... :bäh:

[Tiamat]

Original geschrieben von strauch
Der Prescott wird im Verhältnis schneller sein als der Northwood zum Wilamette. Der einzige Unterschied zwischen Wilamette und Northwood lag im verdoppelten L2 Cache. Beim Prescott wird der L1 Cache, der Trace Cache und der L2 Cache vergrößert und dazu kommen noch weitere SSE Befehle und zuguter letzt wird das HyperThreading noch verbessert. Insgesamt also ne ganze Menge, was mich zu dem Schluss kommen lässt das der Prescott doch deutlich mehr zulegen wird, als der Northwood.

Das glaub ich aber ehrlich gesagt auch.Der Unterschied vom Willamette (400Mhz FSB) zum Northwood(400Mhz FSB) betrug ja grad mal 7-15%.Wer glaubt das beim Prescott max.10% rausspringen unterschätzt Intel ein wenig ;)

[zeckensack]

Original geschrieben von BlackBirdSR
Das mag stimmen (auch wenn ich auf den PCGH Test gar nichts geben würde). Aber wo steht, dass Intel Probleme hat ihre CPUs höher zu takten? dass sie nicht mit Téjas bereits die nächsten Neuerungen bringen etc. Ich sehe da kein größeres Problem für Intel aufgrund dessen man zurückfallen würde.

<...>

Lass uns einfach mal sehen was Téjas bringt. Dort will man ja Gerüchteweise noch mehr Änderungen zum NW einbauen als beim Prescott bisher der Fall. Neulich beim Frauenarzt:
"Sie sind seit fünf Jahren verheiratet?"
"Ja."
"Sie sind Jungfrau ..."
"Ja. Wissen Sie, mein Mann arbeitet bei Intel. Er sitzt jeden Abend auf der Bettkante, und erzählt mir wie toll es sein wird."

Sorry, aber der passte hier einfach so wunderbar rein.
Nimm's bitte nicht persönlich, denn so ist es nicht gemeint ;)

[BlackBirdSR]

Original geschrieben von zeckensack
Neulich beim Frauenarzt:
"Sie sind seit fünf Jahren verheiratet?"
"Ja."
"Sie sind Jungfrau ..."
"Ja. Wissen Sie, mein Mann arbeitet bei Intel. Er sitzt jeden Abend auf der Bettkante, und erzählt mir wie toll es sein wird."

Sorry, aber der passte hier einfach so wunderbar rein.
Nimm's bitte nicht persönlich, denn so ist es nicht gemeint ;)

Es war etwas schwer den richtigen Grinser dazu zu finden :bäh2:

ich nehms sicher nicht ernst,
Ich sehe ja ein dass es vielleicht etwas zu stark in Richtung "Boah Intel" geht.
Allerdings ist es nicht leicht den schmalen Grat zwischen AMD und Intel zu finden. Besonders wenn man eigentlich auf AMD steht, das aber nichts zur Sache tun darf.

Also, ja ich habs verstanden. :schmor:

[GloomY]

Original geschrieben von Endorphine
p.s. So wie eben auch "PC2700" nur eine Marketingbezeichnung ist, obwohl "DDR333 SDRAM Module/DIMM" die korrekte offizielle Bezeichnung wäre *Gloomystichel* ;) Mehr als Behaupten und deine Behauptungen wiederholen kannst du aber auch nicht, oder?

Es ist schon Recht interessant, dass du in dem Thread, den ich extra rausgesplittet habe, damit man die Sache ausdiskutieren kann, verstummt bist, aber hier dann wieder mit deinen Märchen anfängst...
Original geschrieben von Bokill
Codenamen sind Ok, aber zum Teil werden Schöpfungen wie A6ß und anderes Zeugs verwendet.Das ist mir bisher noch bei niemandem aufgefallen.
Original geschrieben von Bokill
Dies will ich gar nicht nennen, da sonst sich der falsche Krempel einprägt, wenn jemand alte Begriffe nimmt ist dies ja auch eindeutig, dagegen habe ich nichts,...

aber diese krausen Eigengewächse sind fürchtbar, denn so kann man manchmal ziemlich danebenraten, wenn zB. von Instruktionen die Rede ist aber ständig von einer CPU geschrieben wird!

GloomY machst du das mit ABSICHT?Sag' mir doch mal bitte konkret, was du mir vorwirfst.
Ich verwende als Prozessorbezeichnung den offiziellen Namen und den Codenamen (welche du beide für Ok hälst). Was die Instruktionen angeht, so nehme ich gerne "x86-64" (Einwände?).
Original geschrieben von zeckensack
Neulich beim Frauenarzt:
"Sie sind seit fünf Jahren verheiratet?"
"Ja."
"Sie sind Jungfrau ..."
"Ja. Wissen Sie, mein Mann arbeitet bei Intel. Er sitzt jeden Abend auf der Bettkante, und erzählt mir wie toll es sein wird."

Sorry, aber der passte hier einfach so wunderbar rein.
Nimm's bitte nicht persönlich, denn so ist es nicht gemeint ;) Ich finde die Analogie recht passend (und konnte mir ein Lachen nicht verkneifen :D)

[Bokill]

Einige Beispiele für die krausen Wortschöpfungen:
Reunion:
Der A64 wird automatisch mit jeder Takterhöhung auch der Speichercontroller höher getaktet was bedeutet das...

Reunion:
...immer wieder Gerüchte das auch den A64 früher oder später ein Dual- Channel Speicherinterface bekommt...

Reunion:
...Laut PCGH ist der A64 bei einer Auflösung von 1024x769x32 genau 33% schneller als der p4 200mhz fsb northwood mit canterwood-mainboard.
Wenn der A64 jetzt mit 2ghz startet...

Muh-sagt-die-Kuh war so freundlich schon kurz zu erzählen, was IA64 bedeutet:

IA64 ist eine ISA, der Itanium II eine Implementation dieser ISA...klar, IA64 Binärcode ist eben etwas umfangreicher, das bedeutet aber nicht viel mehr als das Intel noch etwas wartet bis es IA64 für den Desktop gibt....nämlich solange bis man einen Fertigungsprozess hat, der ca 3 MB L3 Cache auf einer für Desktop CPUs üblichen DIE Größe unterbringen kann. Und solange sollte IA32 noch durchhalten können.

Gast:
SMT wird möglicherweise bereits im A64 enthalten sein.
Jan Gütter hat erst vor kurzem gesagt, dass der A64 den P4 übertreffen wird.
Ebenfalls gab es von AMD vor kurzem ein Statement, welches besagt, dass der endgültige A64 ein feature haben wird, was bisher in den Samples deaktiviert war.

-=O.C.B=-:
Vom Dual- Channel wird der A-64 imo nicht so gewaltig profitieren
wie das beim P4/Prescott der Fall ist

Gast:
...dass AMD das hier beim 2Ghz Opteron aktiviert und zusammen mit dem A64 veröffentlicht.


War nur ein Auszug, jedoch war mit der Kurzbenennung A6ß eigentlich immer die CPU gemeint, leider kann der unbedarfte Leser diese Kurzbenennung schnell mit dem Instruktionssatz AMD64 durcheinanderbringen.
Muh-sagt-die-Kuh war so freundlich schon eine kleine Klaestellung zu bringen, was ein Instruktionssatz ist und was die CPU ist, zur Nutzung des Instruktionssatzes.

Ich gebe zu ich habe mich etwas knapp ausgedrückt, sollte ja auch nur eine Bemerkung am Rande sein. Ich stellte jedoch die Bezeichnungen: AMD CPU`s Athlon64/Opteron , 64Bit AMD64 besonders hervor.
Mit der Bemerkung

BlackBirdSR ist einer derjenigen vor Ort, der die korrekten Bezeichnungen wählt!

Ging automatisch meine Stellungnahme zu Codenamen ein, denn BlackBirdSR wählte den ganzen Fundus aus, auch Codenamen wie K8, Hammer, Athlon64.
Normalerweise schätze ich dich so ein, dass du die Korrekten Begriffe wählst und andere Kommentare genau durchliest.

Daher war dein Kommentar zu den Codenamen unnötig,da dies OT ist, jedenfalls hart am Rande.

Insofern war das nochmalige Nachfragen:

Wo ist denn deiner Meinung nach der Unterschied zwischen "x86-64" und der von dir vertretenen Bezeichnung "AMD64" ?

... nicht hilfreich, da durch meinen Kurzhinweis:

BlackBirdSR, wie auch Endorphine, Gloomy sind zum Beispiel diejenigen vor Ort, welche die korrekten Bezeichnungen wählen!

Für mich klar war, wie meine Stellung zu Codenamen ist, durch Lesen der Postings von
BlackBirdSR hätte jeder dies nachvollziehen können.
Offensichtlich hat dies keiner für nötig gehalten, Endorphine ausgenommen, der jedoch so frei war ebenso die Kettensäge zu schmieren, jedoch für eine geringere Schnitttiefe plädierte.
Das Anschmeißen und nochmalige Ölen der Kettensäge nehme ich dir etwas übel, da du sonst sehr scharfsinnig nachfragst und kommentierst.

Ich bin auch kein Schiedsrichter zum korrekten Umgang von Codenamen, mein Einwand richtet sich gegen missverständliche Namen, die vor allem Neulinge verwirren können.

PS. Wie BlackBirdSR, verwendest du GloomY die ganze Vielfalt an Namen, dies ist gut so, in diesem Punkte unterscheiden wir uns keinesfalls.

Zur Klarstellung:
Wo ist denn deiner Meinung nach der Unterschied zwischen "x86-64" und der von dir vertretenen Bezeichnung "AMD64" ?

x86-64 war die historische Benennung des AMD 64Bit Instruktionssatzes, AMD64 ist jetzt der offizielle Marketinggeblubbername. Was das Marketinggeblubber angeht stimme ich mit Endorphine in den Chor ein.
X86-64 ist für mich ein historischer Begriff, wenn jemand AA64 dazu gesagt hätte, hätte ich sicherlich nichts geschrieben. Der Einwand von Endorphine war demnach vollkommen in Ordnung, da herrscht kein Dissense.

Meiner Meinung nach sind schon genügend Worte gewechselt worden, der Thread nannte sich ja Clawhammer vs Prescott, nicht welcher Begriff ist falsch: A64 oder Athlon64?

PS. Etwas Gift und Galle wurde entfernt zur besseren Lesbarkeit.

[GloomY]

Original geschrieben von Bokill
Beispiele für die krausen Wortschöpfungen:
Reunion:

Reunion:

Reunion:Schön, drei Mal Reunion und Null Mal GloomY. Oder bin ich für die Fehler anderer verantwortlich?
Original geschrieben von Bokill

Muh-sagt-die-Kuh war so freundlich schon kurz zu erzählen, was IA64 bedeutet:


Gast:

-=O.C.B=-:

Gast:

War nur ein Auszug, jedoch war mit der Kurzbenennung A6ß eigentlich immer die CPU gemeint, leider kann der unbedarfte Leser diese Kurzbenennung schnell mit dem Instruktionssatz AMD64 durcheinanderbringen.Ich bin auch für klare namentliche Trennung unterschiedlicher Begriffe, aber auch hier gilt: Was geht das mich an? Wo habe ich denn den Therm "A64" oder ähnliches verwendet? Jetzt fühl ich mich zu Unrecht unter die Kettensäge gestellt...
Original geschrieben von Bokill
Muh-sagt-die-Kuh war so freundlich schon eine kleine Klaestellung zu bringe was ein Instruktionssatz ist und was die CPU ist zur Nutzung des Instruktionssatzes.

Ich gebe zu ich habe mich etwas knapp ausgedrückt, sollte ja auch nur eine Bemerkung am Rande sein. Ich stellte jedoch die Bezeichnungen: AMD CPU`s Athlon64/Opteron , 64Bit AMD64 besonders hervor.
Mit der Bemerkung

Ging automatisch meine Stellungnahme zu Codenamen ein, denn BlackBirdSR wählte den ganzen Fundus aus, auch Codenamen wie K8, Hammer, Athlon64.Du sagst, dass BlackbirdSR die einzig richtigen Begriffe verwendet. Jetzt muss ich raussuchen, was er verwendet, damit ich weiss, wie deine Antwort aussieht...
Ausserdem hat BlackbirdSR bis zu diesem Zeitpunkt nicht viel über ISAs erzählt (einmal IA64). Zudem hat er auf Seite eins ebenfalls "A64" verwendet. Und da soll ich jetzt rausfinden, welcher Meinung du nun bist...-> Toll.

Kannst du nicht einfach sagen, was du denkst, dann können wir (besonders ich) uns eine Menge Arbeit ersparen.
Original geschrieben von Bokill
Normalerweise schätze ich dich so ein, dass du die Korrekten Begriffe wählst und andere Kommentare genau durchliest.
Daher war dein Kommentar zu den Codenamen vollkommen überflüssig, ja schädlich, da dies OT ist, jedenfalls hart am Rande.Oh, was ist denn an einer erneuten Nachfrage "schädlich" ? Das musst du mir jetzt mal erklären...
Original geschrieben von Bokill
Insofern war das nochmalige Nachfragen:

So überflüssig wie ein Kropf, da durch meinen Kurzhinweis:

Für mich klar war, wie meine Stellung zu Codenamen ist, durch Lesen der Postings von BlackBirdSR hätte jeder dies nachvollziehen können.

Offensichtlich hat dies keiner für nötig gehalten, Endorphine ausgenommen, der jedoch so frei war ebenso die Kettensäge zu schmieren, jedoch für eine geringere Schnitttiefe plädierte.
Das Anschmeißen und nochmalige Ölen der Kettensäge nehme ich dir übel, da du sonst sehr scharfsinnig nachfragst und kommentierst.

Ich bin auch kein Schiedsrichter zum korrekten Umgang von Codenamen, mein Einwand richtet sich gegen missverständliche Namen, die vor allem Neulinge verwirren können.

PS. Wie BlackBirdSR, verwendest du GloomY die ganze Vielfalt an Namen in diesem Punkte unterscheiden wir uns keinesfalls.Aha. Und warum machst du mir dann einen Vorwurf, wenn du genau so handelst? ???
Original geschrieben von Bokill
Zur Klarstellung:

x86-64 war die historische Benennung des AMD 64Bit Instruktionssatzes, AMD64 ist jetzt der offizielle Marketinggeblubbername. Was das Marketinggeblubber angeht stimme ich mit Endorphine in den Chor ein.Sie wird aber immer noch auf z.B. www.x86-64.com (http://www.x86-64.org/about) verwendet. Das ist eine Seite von u.a. AMD.

Übrigends würde ich dir empfehlen, dich doch bitte an deine eigene Nase zu fassen und ersteinmal deine Fehltritte zu korrigieren, bevor du anderen an den Karren fährst...

[BlackBirdSR]

Was hat das Alles mit mir zu tun?

Ich muss zugeben, ich bin nicht gerade der Hellste, und mir fällt es ausserordentlich schwer überhaupt zu kapieren um was es bei den ganzen Quotes und Antworten dazu geht.
Ehrlichgesagt weiss ich nicht ob ich jetzt der Böse bin, sich Gloomy und BoKill nur nicht leiden können oder ich mich für irgendwas entschuldigen soll.

können wir das so klären, dass es auch jemand versteht der etwas länger braucht?

[GloomY]

Original geschrieben von BlackBirdSR
Was hat das Alles mit mir zu tun?

Ich muss zugeben, ich bin nicht gerade der Hellste, und mir fällt es ausserordentlich schwer überhaupt zu kapieren um was es bei den ganzen Quotes und Antworten dazu geht.
Ehrlichgesagt weiss ich nicht ob ich jetzt der Böse bin, sich Gloomy und BoKill nur nicht leiden können oder ich mich für irgendwas entschuldigen soll.Nein, du kannst nichts dafür. Mach' dir mal keine Sorgen. Bokill hat nur erwähnt, dass du seiner Meinung nach die richtigen Bezeichnungen benutzt.
Damit hat er zum Ausdruck bringen wollen, dass er z.B. die Bezeichnung "x86-64" nicht mag, was ich nicht gleich verstanden habe. Ich bin nämlich auch nicht immer so schnell, dass ich um drei Ecken denken kann ;)

Ich denke, dass es inhaltlich nicht besonders große Diskrepanzen gibt. Was mich aber etwas geärgert hat, war der Stil von Bokill. Wenn ich was falsch mache, dann kann mich gerne korrigieren, aber meine Postings als "vollkommen überflüssig, ja schädlich" abzutun, halte ich nicht für die richtige Wortwahl...
Original geschrieben von BlackBirdSR
können wir das so klären, dass es auch jemand versteht der etwas länger braucht? Nein, das wäre ja langweilig *eg* :D

[Bokill]

Wird es nicht langsam lächerlich GloomY?

Natürlich bist du nicht für die Fehler anderer verantwortlich!

GloomY ich habe sogar positiv vermerkt, dass auch du weitestgehenst die Codenamen/Markennamen verwendest, wenn du nicht mal für dieses kleine Lob empfänglich bist, sondern sogar die "Fehler" anderer persönlich nimmst, dann tut es mir Leid.

Schade ist es weiter, dass der Thread Prescott vs Clawhammer durch Animositäten inhaltlich geschädigt wird.

Es wäre doch hübsch wenn die bisherigen Schreiber diesen Disput im Hinterkopf haben und dann in eigener Verantwortung die Bezeichnungen nach eigenen Gutdünken verwenden.

Ich bin Überzeigt davon, dass entweder eine Übereinkunft getroffen wird, wie der Athlon64 intern genannt wird, oder aber es wird sogar konsequent der jeweilige Codename verwendet.

Ich schlage vor, dass Kettenöl einzupacken, die "Arbeitsmaschine" in den Schuppen zu stellen und sich dem eigentlichen Thema zu stellen.

Dafür bieten sich in der letzten Zeit viele Gelegenheiten zur Diskussion.
Alleine schon die Frage ob AMD mit SSE2 und später eigenständigen Erweiterungen herauskommt ist eine nette Frage.
Wenn AMD Erfolg hat mit dem Einführen des AMD64, kann es doch auch möglich sein eigenständige Erweiterungen zu SSE2 einzuführen.
Denn Intel versteht es meisterhaft ihre SSE- Einheit weiter aufzubohren unsd marktgerecht zu serviren. Mit dem Tejas im Hintergrund ist dann SSE4 zu erwarten, wie zuvor der Prescott SSE3 an Bord hat.
Laut Intel soll jedoch SSE3 vollständig kompatibel zu SSE2 sein. AMD wird dadurch jedoch gezwingen im Kielwasser von Intel zu fahren (eigentlich nichts neues), und dies in einem Moment der gewisse Unabhängigkeit verspricht!

Dazu kommt noch die Kompilerfrage, die AMD heute teilweise gelöst hat, die Tools sind nicht so weit entwickelt, wie die von Intel, jedoch kann AMD erstmals auf eigene Tools verweisen inklusive einiger Bibliotheken zu Mathematischen Funktionen.

Kompilerfrage:
http://www.theinquirer.net/?article=10292
Bibliotheken zu Mathematiscne Funktionen.
http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~72345,00.html
Auf deutsch:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?category=1&id=1057134457

[Bokill]

BlackBirdSR kann wirklich nicht dafür, ich zitierte ihn nur zu gerne, da wir auf P3D schon diverse Postings austauschten. Auch sein Stil und Inhalt ist immer bemerkenswert, Inhaltlich bin ich ziemlich nahe am Standpunkt von BlackBirdSR und GloomY, jedenfalls was die verwendung von Codenamen angeht.

Mir persönlich ist es ziemlich Wurst ob x86-64 oder AMD64, mich regte nur der Begriff A64 auf, zu diesem Begriff gibt es keine Wurzel!
Umgangssprachlich wird im Forum offensichtlich der Clawhammer/Athlon64 damit gemeint,
Leider ist dieser CPU- Hobbybegriff optisch nahe zum offiziellen Marketingbegriff zum Instruktionssatz AMD64

Der grösste Treppenwitz ist, dass der Fehdehandschuh von jemanden aufgegriffen wird, der diesen umgangssprachlichen Lapsus selber kaum begeht (Fehler machen wir alle mal).

[BlackBirdSR]

Original geschrieben von Bokill
BlackBirdSR kann wirklich nicht dafür, ich zitierte ihn nur zu gerne, da wir auf P3D schon diverse Postings austauschten. Auch sein Stil und Inhalt ist immer bemerkenswert, Inhaltlich bin ich ziemlich nahe am Standpunkt von BlackBirdSR und GloomY, jedenfalls was die verwendung von Codenamen angeht.

Mir persönlich ist es ziemlich Wurst ob x86-64 oder AMD64, mich regte nur der Begriff A64 auf, zu diesem Begriff gibt es keine Wurzel!
Umgangssprachlich wird im Forum offensichtlich der Clawhammer/Athlon64 damit gemeint,
Leider ist dieser CPU- Hobbybegriff optisch nahe zum offiziellen Marketingbegriff zum Instruktionssatz AMD64

Der grösste Treppenwitz ist, dass der Fehdehandschuh von jemanden aufgegriffen wird, der diesen umgangssprachlichen Lapsus selber kaum begeht (Fehler machen wir alle mal).

ich weiss gar nicht was ihr an mir findet...
ich weiss auch nichtmal warum da CPU Guru bei meinem Avatar steht.
Mein Stil ist sicherlich nicht bemerkenswert, und der Inhalt versucht halt mit einigen Leuten mitzuhalten.

Ansonsten hast du recht, A64 ist vielleicht ein ziemlich dummer fauler Begriff. Ginge es nach mir würden wir noch über Clawhammer und Sledgehammer reden. Aber wenn man ein paar mal A64 liest, bürgert sich das auch ein.
Nagut, ich denke ich weiss wenigstens warum es geht.. wenn ich auch nicht verstehe wie das so eskalieren konnte :sulkoff:

[Pinhead]

könnt ihr langsam mal wieder zum eigentlichen Tread zurückkommen...

da bekommt man ja Kopfschmerzen :freak:

[GloomY]

Original geschrieben von Bokill
Wird es nicht langsam lächerlich GloomY?

Natürlich bist du nicht für die Fehler anderer verantwortlich!

GloomY ich habe sogar positiv vermerkt, dass auch du weitestgehenst die Codenamen/Markennamen verwendestWo denn? Ich habe eigentlich eher das Gegenteil gesehen. Du hast es ja mittlerweile editiert, aber imho stand da dass die krausen Eigengewächse furchtbar sind und die Frage warum ich das so benutze. Imho war das eine Kritik. Wenn du damit ein Kompliment aussprechen wolltest, dann war das aber nicht so zu erkennen.
Original geschrieben von Bokill
BlackBirdSR kann wirklich nicht dafür, ich zitierte ihn nur zu gerne, da wir auf P3D schon diverse Postings austauschten. Auch sein Stil und Inhalt ist immer bemerkenswert, Inhaltlich bin ich ziemlich nahe am Standpunkt von BlackBirdSR und GloomY, jedenfalls was die verwendung von Codenamen angeht.

Mir persönlich ist es ziemlich Wurst ob x86-64 oder AMD64, mich regte nur der Begriff A64 auf, zu diesem Begriff gibt es keine Wurzel!
Umgangssprachlich wird im Forum offensichtlich der Clawhammer/Athlon64 damit gemeint,
Leider ist dieser CPU- Hobbybegriff optisch nahe zum offiziellen Marketingbegriff zum Instruktionssatz AMD64Volle Zustimmung :) Ab jetzt bin ich auch Mitglied der "Kein 'A64' als Abkürzung verwenden"-Fraktion ;)

Und beim Rest (Namen äquivalent zu Codenamen; AMD64 äquivalent zu x86-64) sind wir ja anscheinend auch gleicher Meinung :)

[Bokill]

Ich sehe, wir beide sind bemüht das Wasser zu beruhigen, dies ist auch gut so.:)
Was ist denn deine Meinung zur verfeinerung des SSE2 Instruktionsseitenwagens, inklusive der spekulativen Spinnerreien zu AMD von mir?
Da gab es ja auch einen netten Link dazu:
SSE Technology in New Intel Prescott Processors
http://www.xbitlabs.com/articles/cpu/display/prescott-sse.html

[-=O.C.B=-]

Original geschrieben von Bokill
Ich sehe, wir beide sind bemüht das Wasser zu beruhigen, dies ist auch gut so.:)
Was ist denn deine Meinung zur verfeinerung des SSE2 Instruktionsseitenwagens, inklusive der spekulativen Spinnerreien zu AMD von mir?
Da gab es ja auch einen netten Link dazu:
SSE Technology in New Intel Prescott Processors
http://www.xbitlabs.com/articles/cpu/display/prescott-sse.html

Zu deiner "spekulativen Spinnerei" hab ich mal ne Frage:

Hat AMD überhaupt das Recht eigene Instruktionen bei SSE einzufügen?
Geht der betreffende Patenaustausch so weit? Ich dachte es verhält
sich hierbei wie mit der 64-bit Erweiterung von AMD...Intel kann/darf
sie nutzen aber nicht verändern/erweitern...

[Kakarot]

Original geschrieben von -=O.C.B=-
Hat AMD überhaupt das Recht eigene Instruktionen bei SSE einzufügen?Geht der betreffende Patenaustausch so weit? Ich dachte es verhält
sich hierbei wie mit der 64-bit Erweiterung von AMD...Intel kann/darf
sie nutzen aber nicht verändern/erweitern...

Ja, das Recht hat AMD.
Bei INTEL heißt die 64Bit Implementierung Yamhill und wurde auch von INTEL entwickelt, was exakt dahinter steckt weiß man nicht genau, imo wird es aber bereits im Prescott integriert sein, wenn auch deaktiviert, vielleicht aktiviert man es ja bereits für den LGA-S775 Prescott.
Mehr zu Yamhill hier:http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=62101

[Leonidas]

kleine Intel-Roadmap (letztes Update 21.01.2004)


Q1/2004
Prescott
90nm
2.8 GHz - 3.4 GHz
Sockel 478
FSB800
1 MB Level2
16 kB Level1 Daten
12000 MicroOps Trace
PNI = Prescott New Instructions
verlängerte Pipeline: 30 anstatt 20 Stufen
Yamhill vermutlich deaktiviert an Bord


Q2/2004
Prescott
3.6 GHz - 4.0 GHz (oder mehr)
Sockel 775
(ansonsten gleich)


Anfang 2005
Tejas
90nm
4.4 GHz - 5.2 GHz
Sockel 775
FSB800
1 MB Level2
24 kB Level1 Daten
16 kb Level1 Instructions (gab es vorher nicht beim P4)
16000 MicroOps Trace
TNI = Tejas New Instructions
Enhanced HyperThreading
Yamhill vermutlich aktiviert


Ende 2005
Tejas
65nm
ca. 5.6 GHz - 9.2 GHz <--- an dieser Stelle wird Intel scheinbar in kurzer Zeit massiv an Takt zulegen
FSB1066
(ansonsten gleich)


irgendwann 2006 oder 2007
Nehalem
65nm
9.6 GHz
FSB1066
*generell neue Architektur*


irgendwann 2006 oder 2007
Nehalem
10.2 GHz - ?
FSB1200
(sonstige Daten unbekannt, aber wahrscheinlich gleich zum FSB1066 Nehalem)

[Kakarot]

Original geschrieben von Leonidas
kleine Intel-Roadmap

Nen paar neuere Infos bzgl. Yamhill?

[Leonidas]

Original geschrieben von Kakarot
Nen paar neuere Infos bzgl. Yamhill?




Leider nein. Aber es scheint wohl ab Prescott drin zu sein in der CPU - womöglich auf Vorrat. Wird es gebraucht, aktiviert man es - und ansonsten nicht.

[mapel110]

http://www.chip.de/news/c_news_10641320.html
hier steht nochmal dassselbe. hat chip.de wohl gleiche info quelle :)

[Leonidas]

Original geschrieben von mapel110
http://www.chip.de/news/c_news_10641320.html
hier steht nochmal dassselbe. hat chip.de wohl gleiche info quelle :)


Nö, die schreiben nur von der VR-Zone ab, ohne eine Quelle zu nennen.

[Bokill]

Is das Abkommen von Intel und AMD eigentlich irgendwo legal vollständig im Netz?
Ich vermute, dass nicht alles öffentlich ist.
Wenn AMD tatsächlich gezwungen ist auf die SSE Änderungen zu warten und Intel womöglich doch, ihr nicht existentes, Projekt Yamhill doch erscheint, dann sind beide Firmen wie Pech und Schwefel verbunden, weil und obwohl sie Konkurrenten sind!

[BlackBirdSR]

Original geschrieben von Bokill
dann sind beide Firmen wie Pech und Schwefel verbunden, weil und obwohl sie Konkurrenten sind!

das sind sie doch jetzt schon seit Jahren.

[pippo]

@ Leonidas

Dass Intel ende 2005 bei 9,2Ghz sein wird, waage ich mehr als zu bezweifeln. Warten wir doch erstmal, ob und wie gut sie den Prescott produzieren können

[Gast]

Original geschrieben von pippo
@ Leonidas

Dass Intel ende 2005 bei 9,2Ghz sein wird, waage ich mehr als zu bezweifeln. Warten wir doch erstmal, ob und wie gut sie den Prescott produzieren können

Du hast diese Roadmap scheinbar falsch verstanden!
z.B: Nehmen Wir dem Prescott, da er in ein paar Monaten da ist, ok?
Wenn er rauskommt startet er erst bei 3,2 GHz und nicht mit 3,6 GHz, ok?
Ich habe mal in (Klammern) die Daten geschrieben!:

Q4/2003
Prescott
90nm
3.2 GHz(Q4/2003) - 3.6 GHz(Q1/2004)
Sockel 478
FSB800
1 MB Level2
16 kB Level1 Daten
12000 MicroOps Trace
PNI = Prescott New Instructions

Q2/2004
Prescott
3.6 GHz(Q2/2004) - 4.x GHz(Mitte/2005)
Sockel 775

Mitte/Ende 2005
Tejas
65nm
ca. 5.6 GHz(Mitte/Ende 2005) - 9.2 GHz(Ende 2006) <--- an dieser Stelle wird Intel scheinbar in kurzer Zeit massiv an Takt zulegen
FSB1066

Also INTEL wird Ende 2005 erst bei 5,6 GHz sein und nicht wie Du geschrieben hast bei 9,2 GHz.

Das ist immerhin ein Taktunterschied von 3,6 GHz!!!
Aber das INTEL innerhalb eines Jahres den Takt um 3,6 GHz erhöht finde ich auch komisch, im Moment gibt es gar keinen 3,6 GHz Prozessor!
Mal sehen wie hoch die Konkurrenz (AMD) dann sein wird ;-)

[Bokill]

Der P4 hat doch einige Funktionseinheite, die derzeit schon mit doppelter Taktfrequenz laufen!
Intel wird "lediglich" weitere Funktionseinheiten (L1 Cache?) hochdrehen und schon sind sie bei phantastischen Marktgerechten hohen Taktfrequenzen, ob dann allerdings ebenso die Rechenleistung steigt wage ich zu bezweifeln.

Schon alleine weil es sicherlich sinnvoll ist, sich nicht allzusehr von der bisherigen Rechenleistung zu entfernen. So "verspeisen sie ein Teil ihrer Zukunft".

Der andere Grund ist, dass die bisherigen Recheneinheiten sowieso noch nicht so ausbalanciert sind, wie beim Athlon.
Was nützt ein doppelt schneller Cache wenn die Recheneinheiten nicht hinterherkommen?
Er nützt schon etwas, aber es wird nicht der volle Leistungsgewinn erzielt!

[zeckensack]

Original geschrieben von Bokill
Der P4 hat doch einige Funktionseinheite, die derzeit schon mit doppelter Taktfrequenz laufen!Nein, hat er nicht. Die 'double pumpedness' der ALUs ist ein Implementationsdetail, aber für den Durchsatz irrelevant.
Auf keinen Fall läuft in einem 2GHz P4 irgendwas mit 4GHz.

[BlackBirdSR]

Original geschrieben von zeckensack
Nein, hat er nicht. Die 'double pumpedness' der ALUs ist ein Implementationsdetail, aber für den Durchsatz irrelevant.
Auf keinen Fall läuft in einem 2GHz P4 irgendwas mit 4GHz.

hast du ein paar Details wie das Taktsignal da läuft?
Ich dachte bisher, dass es gepuffert wird und dann ab diesem Puffer mit doppelter Frequenz an die ALUs sowie AGUs geht, welche auch auf doppelter Frequenz arbeiten.

[Gast]

Ich glaube ehr das dort ne art ddr verwant wird! und ab ner gewissen geschwindigkeit des prozessors braucht man HT weil nicht genug nachgeliefert wird meint das die cpu zu viele wartezyklen hat um mit daten versorgt zu werden

[Leonidas]

Original geschrieben von Gast
Du hast diese Roadmap scheinbar falsch verstanden!
z.B: Nehmen Wir dem Prescott, da er in ein paar Monaten da ist, ok?
Wenn er rauskommt startet er erst bei 3,2 GHz und nicht mit 3,6 GHz, ok?


Jup. Genauso meinte ich das.

[zipper]

Eine frage 64bit fürt doch nur dazu das man mehr speicher adressieren kann?

Zudem wenn epic unreal total pentium 4 optimieren würde käme wohl auch mehr performace heraus

Bis der Desktop Hammer kommt (und mittlerweile heißt das mitte-ende 2003) ist der Prescott da. Gegen den muß der Hammer antreten und der kommt mit 1-2MB Cache, Hyperthreading, SSE3, double pumped FPUs und einer optimierten Netburst Architektur daher.
Der Hammer ist nix als ein aufgebohrter Athlon mit ein paar 64bit Befehlen und integriertem Speicherinterface

[reunion]

Original geschrieben von zipper
Eine frage 64bit fürt doch nur dazu das man mehr speicher adressieren kann?



Nein es bringt definitiv auch mehr Performance!

Zudem wenn epic unreal total pentium 4 optimieren würde käme wohl auch mehr performace heraus

Bis der Desktop Hammer kommt (und mittlerweile heißt das mitte-ende 2003) ist der Prescott da. Gegen den muß der Hammer antreten und der kommt mit 1-2MB Cache, Hyperthreading, SSE3, double pumped FPUs und einer optimierten Netburst Architektur daher.
Der Hammer ist nix als ein aufgebohrter Athlon mit ein paar 64bit Befehlen und integriertem Speicherinterface


1. Er kommt mit 1mb Cache nicht 1-2.
3. "Der Hammer ist nix als ein aufgebohrter Athlon mit ein paar 64bit Befehlen und integriertem Speicherinterface".
2. ...und verdopeltem L2-Cache :)
Das bringt um einiges mehr Leistung als du glaubst!

[zipper]

Original geschrieben von reunion
Nein es bringt definitiv auch mehr Performance!



1. Er kommt mit 1mb Cache nicht 1-2.
3. "Der Hammer ist nix als ein aufgebohrter Athlon mit ein paar 64bit Befehlen und integriertem Speicherinterface".
2. ...und verdopeltem L2-Cache :)
Das bringt um einiges mehr Leistung als du glaubst!

1. ok
2. tja was der doppelte l2 bringt sieht man ja am tbred zu barton
3. ich schätze das einzige performace plus wir durch das integrierte Speicherinterface erzielt (am Anfang)
4. Wird sich zeigen

[GloomY]

Original geschrieben von BlackBirdSR
hast du ein paar Details wie das Taktsignal da läuft?
Ich dachte bisher, dass es gepuffert wird und dann ab diesem Puffer mit doppelter Frequenz an die ALUs sowie AGUs geht, welche auch auf doppelter Frequenz arbeiten. Das ergibt eigentlich auch keinen Sinn, wenn man sich die Pipeline anschaut. Die Dauer für die Ausführung (also da wo die "double pumped" ALUs zum Einsatz kommen) ist eine Stufe. Was bringt es dann, wenn man dort nach einem halben Takt schon fertig ist, der Rest der Pipeline aber erst nach einem ganzen?
Original geschrieben von Gast
Ich glaube ehr das dort ne art ddr verwant wird! und ab ner gewissen geschwindigkeit des prozessors braucht man HT weil nicht genug nachgeliefert wird meint das die cpu zu viele wartezyklen hat um mit daten versorgt zu werden Wenn die CPU zu wenig Daten hat, dann hilft Hyperthreading kein bisschen weiter.
Original geschrieben von zipper
Zudem wenn epic unreal total pentium 4 optimieren würde käme wohl auch mehr performace herausHaben sie doch, wenn ich mich nicht irre. Mark Reign hat doch mal was diesbezüglich verlauten lassen...
Original geschrieben von zipper
Bis der Desktop Hammer kommt (und mittlerweile heißt das mitte-ende 2003) ist der Prescott da. Gegen den muß der Hammer antreten und der kommt mit 1-2MB Cache, Hyperthreading, SSE3, double pumped FPUs und einer optimierten Netburst Architektur daher.
Der Hammer ist nix als ein aufgebohrter Athlon mit ein paar 64bit Befehlen und integriertem Speicherinterface ... und mindestens 5 weiteren internen Änderungen, die du nicht aufgezählt hast. btw: Von double Pumped FPUs ist bisher imho beim Prescott auch nicht die Rede...

[zipper]

Original geschrieben von GloomY
... und mindestens 5 weiteren internen Änderungen, die du nicht aufgezählt hast. btw: Von double Pumped FPUs ist bisher imho beim Prescott auch nicht die Rede...

ok ich meinte eigenlich quad pumped was eigentlich ja nichts neues ist aber gut für die bandbreite.

Die besseren Argumente sind eh bessere Sprungvorhersage und der grössere L1

[GloomY]

Original geschrieben von zipper
ok ich meinte eigenlich quad pumped was eigentlich ja nichts neues ist aber gut für die bandbreite.Ich nehme an, du meinst das Busprotokoll. Das ist aber nichts neues beim Prescott. Das hat der Northwood auch schon, sogar schon der Williamette.
Original geschrieben von zipper
Die besseren Argumente sind eh bessere Sprungvorhersage und der grössere L1 Das ist wohl wahr...

[BlackBirdSR]

Original geschrieben von GloomY
Das ergibt eigentlich auch keinen Sinn, wenn man sich die Pipeline anschaut. Die Dauer für die Ausführung (also da wo die "double pumped" ALUs zum Einsatz kommen) ist eine Stufe. Was bringt es dann, wenn man dort nach einem halben Takt schon fertig ist, der Rest der Pipeline aber erst nach einem ganzen?


frag doch nicht immer Sachen von denen ich keine Ahnung habe :bäh:

die double Pumped ALUs (2 an der Zahl) sind in der Lage einen der wenigen passenden Befehle in 0.5 Takten abzuarbeiten. Es sind anscheinend auch keine vollständigen ALUs. (Carry Save Adder)

Die Scheduler arbeiten auch bei doppelter Frequenz und spucken 2 µOps pro dp ALU aus. µOp1 wird direkt ausgeführt, Nr2 0.5 Takte später. der P4 könnte also 4 Integer µOps pro Takt abarbeiten, aber das ist nur theoretisches Maximum :bonk:

Man kann dadurch eine Menge simpler Funktionen schnell ausführen, und auch 2 abhängige µOps in einem Takt durchziehen.
Aber natürlich gibt es da auch eine Menge Kompromisse und Kleingedrucktes. Darum gibt es die "slow" ALU ;).

Intels dp ALUs sind sicher sehr interessant, aber es ist kein gegenstück zu 4 echten ALUs, oder gar 2. Dafür sind sie schnell.


naja, irgendwie so läuft das wohl.

[GloomY]

Original geschrieben von BlackBirdSR
frag doch nicht immer Sachen von denen ich keine Ahnung habe :bäh:

die double Pumped ALUs (2 an der Zahl) sind in der Lage einen der wenigen passenden Befehle in 0.5 Takten abzuarbeiten. Es sind anscheinend auch keine vollständigen ALUs. (Carry Save Adder)Jetzt redest du wieder von was, wovon ich keine Ahnung habe ;)
Mir sind nur Carry-Rippl- und Carry-look-ahead-Addierer bekannt...
Original geschrieben von BlackBirdSR
Die Scheduler arbeiten auch bei doppelter Frequenz und spucken 2 µOps pro dp ALU aus. µOp1 wird direkt ausgeführt, Nr2 0.5 Takte später. der P4 könnte also 4 Integer µOps pro Takt abarbeiten, aber das ist nur theoretisches Maximum :bonk:Du meinst, dass der P4 so eine Art SIMD mit zwei Befehlen macht. Aber das kann ich mir wiederrum nicht vorstellen, weil z.B. die Register Rename Stufe auch nur mit dem normalen Takt läuft. Nach dieser ist doch überhaupt erst festgelegt, mit welchen Registern die Operation stattfindet. Wenn man nun zwei Befehle in einem Takt ausführen wollte, bräuchte man ja auch zwei Quell- und zwei Zielregister. Und ob die Rename Stufe hier wirklich jeweils zwei davon zur Verfügung stellt, bezweifel ich.
Das läuft alles darauf hinaus, dass man die komplette Pipeline doppelt taktet oder einfach taktet und doppelt auslegt. Intel hat aber imho immer nur von den ALUs gesprochen, von mehr nicht.

Vielleicht kann Zeckensack sich hier auch mal äußern. Er hat ja schon behauptet, dass hier gar nichts doppelt so schnell wie normal läuft und dass das ganzen nur eine implementationsspezifische Sache ist.

[BlackBirdSR]

Original geschrieben von GloomY
Jetzt redest du wieder von was, wovon ich keine Ahnung habe ;)
Mir sind nur Carry-Rippl- und Carry-look-ahead-Addierer bekannt...


Du meinst, dass der P4 so eine Art SIMD mit zwei Befehlen macht. Aber das kann ich mir wiederrum nicht vorstellen, weil z.B. die Register Rename Stufe auch nur mit dem normalen Takt läuft. Nach dieser ist doch überhaupt erst festgelegt, mit welchen Registern die Operation stattfindet. Wenn man nun zwei Befehle in einem Takt ausführen wollte, bräuchte man ja auch zwei Quell- und zwei Zielregister. Und ob die Rename Stufe hier wirklich jeweils zwei davon zur Verfügung stellt, bezweifel ich.
Das läuft alles darauf hinaus, dass man die komplette Pipeline doppelt taktet oder einfach taktet und doppelt auslegt. Intel hat aber imho immer nur von den ALUs gesprochen, von mehr nicht.

Vielleicht kann Zeckensack sich hier auch mal äußern. Er hat ja schon behauptet, dass hier gar nichts doppelt so schnell wie normal läuft und dass das ganzen nur eine implementationsspezifische Sache ist.

Ja, da gibt es ein paar Addiererformen die ich auch nicht gesehen habe. Mal sehen ob ich dazu was finden kann.

Die Register File kann man entweder doppelt Takten, oder doppelt porten. Ersteres wird ja in diesem Thread angezweifelt, letzteres würde die RF nicht gerade klein machen.

Intel spricht allerdings von einer Rapid Execution ENGINE. Also der RegisterFile, der AGU(oder doch nicht?) und den ALUs. Alle (sollten) laufen auf doppeltem Takt, und das sind (?) ca 9 Pipelinestufen.

Wird etwas dauern dazu Belege zu finden. Vielleicht lebt aber jemand in den Intel Dokumenten und findet es schneller!?!

Ist ein doofes Thema, weil Intel dazu kaum Informationen rausrückt.
Zeckensack ist aber der Erste den ich sehe, der Intel das mit der doppelten Frequenz nicht abnimmt.

[zeckensack]

Sorry, beweisen kann ich das auch nicht. Ich beziehe mich auf Hans de Vries (http://www.chip-architect.com/news/2003_04_20_Looking_at_Intels_Prescott_part2.html#No double frequency building blocks used yet), den ich für eine recht glaubwürdige Quelle halte.

[BlackBirdSR]

Original geschrieben von zeckensack
Sorry, beweisen kann ich das auch nicht. Ich beziehe mich auf Hans de Vries (http://www.chip-architect.com/news/2003_04_20_Looking_at_Intels_Prescott_part2.html#No double frequency building blocks used yet), den ich für eine recht glaubwürdige Quelle halte.

ok, das heisst doch aber nur, dass sowohl Scheduler als auch RF nicht double pumped sind.
Die fast-ALUs aber sehr wohl.

oder habe ich was überlesen?

[Bokill]

Ich lasse mich ungerne als Lügner hinstellen, darum noch der Hinweis:
Pentium 4: In Depth
Copyright (C) 2000 by Darek Mihocka
President and Founder, Emulators Inc.
Updated December 30, 2000
Übersetzt ins Deutsche von D'Espice mit freundlicher Genehmigung des Authors

Vorwort...
Ich weiß bis jetzt noch nicht was mich dazu bewogen hat den Text zu übersetzen.... war es der Irrsinn? Der beginnende Altersschwachinn? Ich mein, mit 20 Jahren wird man halt schon langsam mal alt...

viele weitere Seiten weiter...

...Es scheint so, als Intel beim Pentium 4 ein ähnliches Konzept wie auch beim Itanium verwendet – Der Prozessor soll weniger Optimierungsarbeit leisten. Dies soll von nun an Aufgabe des Programmierers sein. Eine Idee, die der des RISC – Prinzips entspricht. Nur dummerweise ist Intel hier ein wenig zu weit gegangen. Sie haben den Prozessor verkrüppelt, und wollen die Mängel nun auf rigorise Art und Weise mit höherem Takt wiedergutmachen.
Nur leider funktioniert das so nicht. Ein Benchmark nach dem anderen bescheinige dem mit 1,5 Ghz getakteten Pentium 4 eine niedrigere Performance als die eines Athlon 900, in manchen Fällen sogar langsamer als ein auf 533 Mhz getakteter Celeron, und in ganz seltenen Fällen sogar langsamer als ein Pentium 200.
Intel hat aber trotzdem eine handvoll neuer Konzepte und Ideen im Pentium 4 verwirklicht. Die zwei ALUs (=Integereinheiten, Arithmetical logic Unit), welche die einfachen Integer – Operationen durchführen laufen doppelt so schnell wie der Prozessor selber. Der Prozessor ist also theoretisch in der Lage 6 Milliarden Integer – Berechnungen pro Sekunde durchzuführen. Aber wie ich weiter unten erkläre werde ist das Limit viel weiter unten, und nicht höher als beim Pentium III oder Athlon.
Eine zweite Idee klingt um einiges vielversprechender: Das Konzept des „Trace Cache“. Der Pentium 4 besitzt keinen L1 Code Cache mehr. Er puffert nicht den Code, um ihn dann immer und immer wieder anzuwenden, sondern puffert das Ergebnis des Decoders. Er puffert also die Micro – Ops. Klingt sehr gut. Leider ist auch hier in der Realtät kein Geschwindigkeitsvorteil gegenüber L1 – Cache von 8KB Größe zu holen, und gegenüber den 64KB L1 – Code Cache des Athlons verliert der Pentium 4 eindeutig.
Die Benchmarks
Wie Tom's Hardware letzten Monat berichtete ist der Pentium 4 elendigst gegen den Athlon untergegangen, wenn es um MPEG4 – Encoding geht. Erst als Intel's Ingenieure den Code des entsprechenden Programmes etwas abänderten und optimierten, war der Pentium 4 plötzlich schneller als der Athlon. Ein kleiner Nebeneffekt des neuen Codes: Auch auf dem Athlon lief er wesentlich schneller ab als zuvor, wenn auch nicht so schnell wie auf dem Pentium 4. Dies belegt, wie jämmerlich der Code beim ersten Test geschrieben war.
Wie auch immer, aber hier bestätigt sich Intel's Konzept, das Software – Entwickler sich nun absolut selbstständig um die Optimierung ihres Codes kümmern müssen, wenn sie wollen das ihr Programm auf dem Pentium 4 einen Geschwindigkeitsvorteil gegenüber einem Athlon erzielt. Aber leider haben wir nicht alle das Glück einen Intel – Ingenieur neben uns stehen zu haben, der uns Schritt-für-Schritt an der Tür mal eben zeigt wie man den Code umschreibt. Wenn man jetzt auch noch bedenkt...


Das Doku war irgendwann mal im Netz und liegt seither als rtf bei mir rum.

...Ich möchte auch auf eine excellente Website hinweisen, die ich selber seit Jahren lese. Http://x86.org – über diese habe ich viele der Informationen aus diesem Review. Die Site wird beinahe jeden Tag aktualisiert, und bietet die neuesten technischen Informationen aus dem Hause Intel...

Viel Spass beim Suchen.

[BlackBirdSR]

Original geschrieben von Bokill
Ich lasse mich ungerne als Lügner hinstellen, darum noch der Hinweis:
Pentium 4: In Depth
Copyright (C) 2000 by Darek Mihocka
President and Founder, Emulators Inc.
Updated December 30, 2000
Übersetzt ins Deutsche von D'Espice mit freundlicher Genehmigung des Authors

viele weitere Seiten weiter...


Das Doku war irgendwann mal im Netz und liegt seither als rtf bei mir rum.

Viel Spass beim Suchen.

dass die ALUs mit doppeltem CPU Takt laufen bezweifle ich ja gar nicht
Ich war nur der Meinung das dies auch für die AGU gilt (als Teil der Integer ALU) und der RegisterFile.
Aber anscheinend ist dies nicht der Fall.

Die beiden FastAlus sind allerdings auch keine vollständigen ALUs und arbeiten auch nur bei ganz speziellen Kombinationen.
Laut Intel ist dies sehr oft der Fall, aber das gilt wohl nur für schwer optimierten P4 Code. Das kennen wir ja schon.

[Bokill]

@BlackBirdSR:
Dass sich immer die falschen Personen angesprochen fühlen?!?

@zeckensack:

Nein, hat er nicht. Die 'double pumpedness' der ALUs ist ein Implementationsdetail, aber für den Durchsatz irrelevant.
Auf keinen Fall läuft in einem 2GHz P4 irgendwas mit 4GHz.


Speziell für zeckensack war der Auszug: "Pentium 4: In Depth" gedacht!


Der P4 hat doch einige Funktionseinheite, die derzeit schon mit doppelter Taktfrequenz laufen!
Intel wird "lediglich" weitere Funktionseinheiten (L1 Cache?) hochdrehen und schon sind sie bei phantastischen Marktgerechten hohen Taktfrequenzen, ob dann allerdings ebenso die Rechenleistung steigt wage ich zu bezweifeln.

Schon alleine weil es sicherlich sinnvoll ist, sich nicht allzusehr von der bisherigen Rechenleistung zu entfernen. So "verspeisen sie ein Teil ihrer Zukunft".

Dies letzte Zitat sollte andeuten, dass Intel wohl sehr "schnell" eine Marketingerechte Mhz- Zahl herausbringen kann. Meiner Meinung nach ist der Tejas ein ganz heisser Kandidat dafür, der Prescott ist lediglich ein sehr gut aufgebohrter P4 mit den gewünschten Leistungssteigerungen, ich spekuliere dass 5- 10 % Mehrleistung zu einem gleichgetakteten derzeitigen Top P4 herausspringen. (Bin leider nicht so mit den derzeitigen Codenamen bewandert Northwood/Williamette?!?)

[BlackBirdSR]

Original geschrieben von Bokill
@BlackBirdSR:
Dass sich immer die falschen Personen angesprochen fühlen?!?

@zeckensack:


Speziell für zeckensack war der Auszug: "Pentium 4: In Depth" gedacht!

war eher ein Versuch den Ton des Posts etwas abzuleiten.
Denn das klang schon etwas krass von dir, es so darzustellen, als würde man dich als Lügner bezeichnen.

Zbag hat nur seine Aufassung dazu gepostet. Ich glaube nicht dass er gesagt hat, dass du lügen würdest.
Naja ein misslungener Versuch eben ;)

Den Pentium4 In Depth Artikel würde ich übrigens nur noch in ganz spziellen Fällen ansprechen. Er beinhaltet für heutige Zeiten einfach zu viele , sagen wir unglücklich ausgedrückte Terme und so einige Fehlerhafte Parts

[Endorphine]

Ists nicht herzlich egal, wie Intel es anstellt, dass die ALUs einen Durchsatz von 2 Operationen pro Takt schaffen? Es wäre nur technisch interessant, wie Intel das anstellt (doppelter Takt wirds wohl kaum sein), aber für die Praxis ists wohl eher weniger relevant.

Da das wohl ein Geheimnis von Intel ist werden wir das wohl auf absehbare Zeit nicht erfahren, es sei denn, jemand hat man zu viel Zeit und kramt mal ganz tief in den US-Patentarchiven.

[BlackBirdSR]

Original geschrieben von Endorphine
Ists nicht herzlich egal, wie Intel es anstellt, dass die ALUs einen Durchsatz von 2 Operationen pro Takt schaffen? Es wäre nur technisch interessant, wie Intel das anstellt (doppelter Takt wirds wohl kaum sein), aber für die Praxis ists wohl eher weniger relevant.

Da das wohl ein Geheimnis von Intel ist werden wir das wohl auf absehbare Zeit nicht erfahren, es sei denn, jemand hat man zu viel Zeit und kramt mal ganz tief in den US-Patentarchiven.

In U.S. patent 6,023,182 Intel discloses a clock buffering circuit that, among other things, generates an out put clock at twice the frequency of the input clock using one shot pulse generators triggered on both the rising and falling edges of the input clock. This circuit can be dropped down anywhere on a microprocessor to drive a functional block such as an ALU at twice the rate of the globally distributed processor clock. The advantage of this scheme is that it avoids the formidable challenge of generating and distributing both a regular clock and a double frequency clock

[Endorphine]

Original geschrieben von BlackBirdSR
In U.S. patent 6,023,182 Intel discloses a clock buffering circuit that, among other things, generates an out put clock at twice the frequency of the input clock using one shot pulse generators triggered on both the rising and falling edges of the input clock. This circuit can be dropped down anywhere on a microprocessor to drive a functional block such as an ALU at twice the rate of the globally distributed processor clock. The advantage of this scheme is that it avoids the formidable challenge of generating and distributing both a regular clock and a double frequency clock Thx :)

Uffza, das ist wieder starker Tobak: High gain pulse generator circuit with clock gating - United States Patent 6,023,182 (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,023,182.WKU.&OS=PN/6,023,182&RS=PN/6,023,182) Wer hat Lust, sich da durchzuarbeiten? :)

[BlackBirdSR]

Original geschrieben von Endorphine
Thx :)

Uffza, das ist wieder starker Tobak: High gain pulse generator circuit with clock gating - United States Patent 6,023,182 (http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1=6,023,182.WKU.&OS=PN/6,023,182&RS=PN/6,023,182) Wer hat Lust, sich da durchzuarbeiten? :)

wenn du jemanden findest der das macht, Glückwunsch :)

Ich hasse NAND Gatter und Transfergates (von Letzteren war aber auf den ersten Blick keines zu sehen *g*).
Vielleicht schau ich mir das morgen mal an, wenn ich die Nase voll habe vom Lüftungsschacht bauen. Abwechslung muss sein *g*

[Bokill]

So langsam bekomme ich Respekt vor dem P4 Ansatz, dahinter steckt eine gewisse perfide Genialität, die Rechenleistung reichte für alle Anwendungen schon damals aus.
Aber für Streaminganwendungen und Multimedia ist das Konzept wirklich gut.
Zugleich war ebenso das Marketing wichtig, um eben die besagten Megahertz herauszuquetschen, SSE schreit ja danach.
Der P4 Artikel "Pentium 4: In Depth" ist sehr parteiisch und hat die Tragweite der Hochtaktbarkeit vernachlässigt. Mit den besagten Nachteilen ist dieser Artikel aber immer noch eine Empfehlung wert.

Witzig ist, dass AMD und Intel für sich jeweils ihre Architektur beständig weiterentwickeln. leider sind diese Konzepte DIAMETRAL, es wird immers schwieriger die beiden Familien gerecht zu vergleichen.

Auch die nächsten Jahre werden geprägt durch den P4 und dem K7/K8 bei 32Bit.

[BlackBirdSR]

Original geschrieben von Bokill
So langsam bekomme ich Respekt vor dem P4 Ansatz, dahinter steckt eine gewisse perfide Genialität, die Rechenleistung reichte für alle Anwendungen schon damals aus.
Aber für Streaminganwendungen und Multimedia ist das Konzept wirklich gut.
Zugleich war ebenso das Marketing wichtig, um eben die besagten Megahertz herauszuquetschen, SSE schreit ja danach.
Der P4 Artikel "Pentium 4: In Depth" ist sehr parteiisch und hat die Tragweite der Hochtaktbarkeit vernachlässigt. Mit den besagten Nachteilen ist dieser Artikel aber immer noch eine Empfehlung wert.

Witzig ist, dass AMD und Intel für sich jeweils ihre Architektur beständig weiterentwickeln. leider sind diese Konzepte DIAMETRAL, es wird immers schwieriger die beiden Familien gerecht zu vergleichen.

Auch die nächsten Jahre werden geprägt durch den P4 und dem K7/K8 bei 32Bit.

Wahnsinn und Genialität liegen nicht umsonst so nah beisammen ;)
K7/8 und P7 sind sicher beides zu gleich, jeder auf seine spezielle Art und Weise.

[Desti]

Original geschrieben von Bokill
[...]
Aber für Streaminganwendungen und Multimedia ist das Konzept wirklich gut.
[...]

Ich würde es lieber sehen, wenn man dies Multimediazeugs mal vernünftig auf spezialisierte Chips, sprich Graka und Sound, auslagert.

[Bokill]

Kleiner Vorgeschmack zur Leistungsfähigkeit des Athlon64, und dies bei einem 32Bit OS.
Die verdoppelten Register für SSE und Integer kommen hierbei noch nicht zum tragen!
Zwar wird zweikanalig der Speicher angasprochen, jedoch ist aber immer noch nicht zu 100 % sicher ob das Speicherinterface 128Bit breit angesteuert wird!

In meinen Augen der erste wirklich gute systematische Benchmarktestpark.

Der Hammer hat jedenfalls verdammt gut in den Spielebenchmark abgeschnitten und dies bei einer Taktfrequenz von nur 1,8 Ghz!
http://www.xbitlabs.com/articles/cpu/display/opteron-1.html

ASUS SK8N + AMD Opteron 144: Unirocessor Workstation on AMD Opteron and NVIDIA nForce3 Professional

Category: CPU
by Ilya Gavrichenkov
07/21/2003 | 05:53 PM

AMD Opteron based platforms become more and more popular. We tested a workstation featuring ASUS SK8N mainboard based on NVIDIA nForce3 Pro 150 chipset and one AMD Opteron processor working at 1.8GHz. The whole lot of benchmarks in comparison with AMD Athlon XP and Intel Pentium 4 are included.

[-=O.C.B=-]

Original geschrieben von Bokill
Der Hammer hat jedenfalls verdammt gut in den Spielebenchmark abgeschnitten und dies bei einer Taktfrequenz von nur 1,8 Ghz!


Tjo und die anderen Tests/Benches waren imo nicht so berauschend...

[Bokill]

Tjo und die anderen Tests/Benches waren imo nicht so berauschend

Genau!; und Spielebenchmarks sind heutzutage ja auch wirklich unwichtig, wer spielt denn auch heutzutage!

Das ist ja der Witz von meinen Posting gewesen!

[Endorphine]

So berauschend ist die 32-Bit Performance in dem Test aber nicht. Und der Vergleich mit 2 Desktop-CPUs ist IMHO auch fragwürdig :|

Ich hätte lieber einen Vergleich Opteron vs. Xeon gesehen. Itanium² wäre auch interessant.

[Bokill]

Zumindest wird hier ein Vorgeschmack eines Athlon 64 geliefert, mich erstaunen wirklich die unerwartet gute Ergebnisse der Spielebenches.
Die anderen Benches sind ja auch zwischen mittelmässig (vergleichbar der Leistung eines AthlonXP mit gleicher Taktfrequenz) bis erstaunlich gut. Der Benchmark zum Entpacken für gepackte Dateien ist jedenfalls solch ein überragender Bench!

Aber was konnte man denn auch erwarten? Der Hammer hat in einigen Bereichen kaum hinzugewonnen, die FPU Einheit ist vermutlich praktisch gleich, bei Benches die Vorwiegend die FPU fordern werden so gut wie keine Fortschritte zu sehen sein.
Bei Spielen dachte ich jedenfalls, dass die FPU kaum Schub geben wird, jedoch schreien moderne Spiele wohl doch massig nach Bandbreite und kurzer Latenz.
Deswegen meine Überraschung!

Und wie gesagt dies ist ein Bench bei einem 32Bit OS, bei denen liegen die verdoppelten Register für Integer und SSE derzeit noch brach. Dort scheint demnach noch Luft zu liegen!
Die FPU- Einheit wird aber keine neue Revolution liefern, dort blieb es bei der alten Registergrösse!

PS. An Endorphine, ist angekommen!:D

[BlackBirdSR]

Original geschrieben von Bokill
[b]Die FPU- Einheit wird aber keine neue Revolution liefern, dort blieb es bei der alten Registergrösse!

Die hat AMD auch nicht großartig verändert.
Man versorgt sie jetzt besser mit Befehlen/Daten und hat hier und da ein paar Optimierungen vorgenommen.
Aber aus dem AMD Dokumenten geht eigentlich deutlich hervor;
wenn man keine 80Bit Präzision braucht, sollte man doch gefälligst Skalar SSE2 bzw SIMD nutzen. Wobei natürlich Skalar SSE2 vorzuziehen sein, da dort der P4 nicht mithalten kann.

[Endorphine]

SSE2 ist schon ein Fortschritt, auf jeden Fall. Damit profitieren Athlon 64 und Opteron von P4-Optimierungen.

Nur schade, dass kein Benchmark gegen den neuen 3,06 GHz Xeon DP mit 1 MB L3-Cache gefahren wurde. Das wäre wohl die eigentliche Konkurrenz für nen schnellen Uniprozessor Opteron.

Auch wäre es interessant, wie sich die das Fehlen der SMT-Fähigkeit beim Opteron auf den Durchsatz populärer Serveranwendungen (Oracle DB, IBM DB, MS SQL Server etc.) auswirkt.

Irgendwie zeichnet es sich aus meiner Sicht derzeit ab, dass AMD es im 32-Bit Bereich recht schwer haben wird gegen den Xeon. An die FP-Performance eines Itanium² wird der Opteron wohl kaum herankommen. Es sei denn, das zu lösende Problem sprengt die gängigen Cachegrössen. Dann könnte ein SMP Opteron-System von der Speicherbandbreiten-Skalierung mit der Anzahl der Wege profitieren.

Edit:
p.s. Bokill, bitte überdenke doch mal deine Textbetonungsstrategie. Weniger wäre da mehr.

[Bokill]

GamePC und Xeon DP
http://www.gamepc.com/labs/view_content.asp?id=xeon3061MB&page=1

More Cache For The Masses : Intel’s New 3.06GHz/1MB Xeon DP
Author : Chris Connolly Date : 7/22/2003

Irgendwie bereitet mir GamePC Magenschmerzen, aber sie haben schon diverse Benches auch vom AthlonMP und Opteron, deswegen scheint es reizvoll auch diesen Test zu nennen.
Witzig ist aber, dass auf Profi- CPU`s zum Teil Daddel Programme laufen aber ganz nett.

[GloomY]

Interesant sind die Latenzzeiten bei Cachemem: Der Opteron kommt auf 67 ns, der P4 auf 78 ns. Klingt erstmal nicht sehr berauschend für den Opteron. Wenn man jetzt aber noch einen Takt beim Zugriff beim Opteron wegrechnet, da er Registered RAM verwendet, bleiben noch 61 ns übrig (minus 6 ns, da 166 MHz Ram-Takt). Überträgt man das dann noch auf für den P4 vergleichbare Werte bei 200 MHz Takt, so kommt man auf 50,83 ns. (*) Im Gegensatz zu den 78 ns sieht das schon deutlich besser aus (über ein Drittel besser).

(*) Das ist nicht 100%ig korrekt, da die gemessene Latenz nicht die vom DRAM alleine ist, sondern die von DRAM plus Speichercontroller bzw. Transfer bis in den Cache. Dies sollte besonders beim Hammer aber sehr gering sein, daher sollte die Gesamtlatenz fast reziprok mit steigendem Takt abnehmen.

Was Overclocking angeht, muss es nicht umbedingt heissen, dass die CPU mit +9% am Ende ist, sondern es kann hier genauso auch der RAM limitieren. Dieser wird natürlich auch mitübertaktet, wenn man die Grundfrequenz anhebt. XBit Labs hätte hier mal den 166 MHz RAM auf 133 MHz heruntertakten sollen. Vielleicht wäre dann mehr aus der CPU herausgekommen...
Original geschrieben von BlackBirdSR
Die hat AMD auch nicht großartig verändert.
Man versorgt sie jetzt besser mit Befehlen/Daten und hat hier und da ein paar Optimierungen vorgenommen.Ich möchte in diesem Zusammenhang gerne nochmal hierher (http://www.chip-architect.com/news/2002_06_24_Hammers_Two_Extra_PipelineStages.html) verweisen.
Original geschrieben von Endorphine
p.s. Bokill, bitte überdenke doch mal deine Textbetonungsstrategie. Weniger wäre da mehr. Da stimme ich zu.

[Bokill]

Was habt ihr denn?:D
Die Aufmerksamkeit ist ja da!
Beim ersten Posting "Erste gute Benches Opteron/Athlon64?"

Kleiner Vorgeschmack zur Leistungsfähigkeit des Athlon64, und dies bei einem 32Bit OS.
Die verdoppelten Register für SSE und Integer kommen hierbei noch nicht zum tragen!
Zwar wird zweikanalig der Speicher angasprochen, jedoch ist aber immer noch nicht zu 100 % sicher ob das Speicherinterface 128Bit breit angesteuert wird!

In meinen Augen der erste wirklich gute systematische Benchmarktestpark.

Der Hammer hat jedenfalls verdammt gut in den Spielebenchmark abgeschnitten und dies bei einer Taktfrequenz von nur 1,8 Ghz!


bin ich wieder in den Senf gedrückt worden! Der Benchmarkpark war gut aufgebaut und zeigte ungewöhnlich gute unerwartete Spielebenches, was war der Kommentar dazu:

Tjo und die anderen Tests/Benches waren imo nicht so berauschend...


Deswegen wollte ich speziell auf einen bestimmten Punkt hinweisen. Den Spielen!

PS. Immer wieder gut den Artikel "AMD's Hammer's two extra Pipeline Stages" zu verlinken! gefällt mir!
:)

[-=O.C.B=-]

Macht es Sinn bei einer Server-CPU über deren Spieletauglichkeit
zu diskutieren? Die auf den AMD-64 abgeleitete Leistung/Performance
halte ich doch für spekulativ...;)

[Bokill]

Ich liebe Spekulationen:D

Die Frage ist halt wie realistisch dann die Spekulationen sind, offensichtlich werden aber meine Spekulationen erst genommen, zumindest stellt keiner die Leistungsfähigkeit besonders bei Spielen in Frage. Oder etwa doch?:D

[GloomY]

Original geschrieben von -=O.C.B=-
Macht es Sinn bei einer Server-CPU über deren Spieletauglichkeit
zu diskutieren? Die auf den AMD-64 abgeleitete Leistung/Performance
halte ich doch für spekulativ...;) Wieso denn? Gerade die Ähnlichkeit von Opteron und Athlon 64 sprechen doch dafür. Es wurde ja auch nur mit einem Speicherkanal gebenched (falls der Athlon 64 nur einen besitzen sollte), also was will man für die Vergleichbarkeit denn mehr? Eine CPU mit komplett gleichem Front- und Back-End, nur unterschiedlicher Speicheranbindung und Anzahl HT Links, die hier aber keine Rolle spielen dürften. Und im Vergleich Opteron mit einem Kanal und dem Athlon 64 wird letztgenannter sicher sogar noch schneller sein, weil er die bessere Speicheranbindung besitzt (200 MHz non-registered vs. 166 MHz registered).

Ausserdem hat man beim PIII-S mit Tualation Core auch keine Rücksicht genommen, dass es eigentlich eine Server CPU ist, zumindest war das die offizielle Bezeichnung von Intel.

[-=O.C.B=-]

Original geschrieben von GloomY
Wieso denn? Gerade die Ähnlichkeit von Opteron und Athlon 64 sprechen doch dafür. Es wurde ja auch nur mit einem Speicherkanal gebenched (falls der Athlon 64 nur einen besitzen sollte), also was will man für die Vergleichbarkeit denn mehr? Eine CPU mit komplett gleichem Front- und Back-End, nur unterschiedlicher Speicheranbindung und Anzahl HT Links, die hier aber keine Rolle spielen dürften. Und im Vergleich Opteron mit einem Kanal und dem Athlon 64 wird letztgenannter sicher sogar noch schneller sein, weil er die bessere Speicheranbindung besitzt (200 MHz non-registered vs. 166 MHz registered).
Das werden wir wohl erst "sehen", wenn die CPU mit samt den passenden
Mainboards auf dem Markt verfügbar ist(Athlon 64).

Ausserdem hat man beim PIII-S mit Tualation Core auch keine Rücksicht genommen, dass es eigentlich eine Server CPU ist, zumindest war das die offizielle Bezeichnung von Intel.
Hätte man aber sollen...;)

[GloomY]

Original geschrieben von -=O.C.B=-
Das werden wir wohl erst "sehen", wenn die CPU mit samt den passenden
Mainboards auf dem Markt verfügbar ist(Athlon 64).Wieso denn das? Das Mainboard bzw. der Chipsatz hat beim Hammer auf die Rechenleistung fast überhaupt keinen Einfluss mehr.
Original geschrieben von -=O.C.B=-
Hätte man aber sollen...;) Und warum? Der PIII-S wurde nicht nur von Leuten gekauft, die sich damit einen Server gebaut haben. Warum dann nicht auch mit nicht-Server typischen Anwendungen (z.B. Spielen) benchen?

Ich kenne einige Leute, die sich für ihren Primärrechner einen Tualatin geholt haben.

[Bokill]

Das werden wir wohl erst "sehen", wenn die CPU mit samt den passenden
Mainboards auf dem Markt verfügbar ist(Athlon 64)

NVIDIA sagt selber, dass die Boards für den Opteron und Athlon64 auf den gleichen Chipsatz basieren!

Also wenn dies dann immer noch zuviel Spekulation ist, dann sollte man sowieso alle spekulativen Threads meiden wie der Teufel das Weihwasser. Auch alle Zukunftsthreads sind dann zu meiden, da dort das Herz und und Kreislauf überanstrengt werden.

Allerdings gebe ich zu, dass immer noch ein gewisser Tuningspielraum da ist, aber die Richtung scheint nun doch ziemlich klar, jedenfalls brechen auch Anwendungen nicht extrem ein wenn das doppelte Speicherinterface des Opteron gefragt ist.

Im übrigen verweise ich auf einen steinalten Link, dort wurden die Latenzen und auch viele andere Aspekte der Diskussion schon berichtet und vorweggenommen, dies spricht für die damalige hervorragende Qualität!
http://www.digit-life.com/articles2/amd-hammer-family/index.html

[BlackBirdSR]

Ist doch völlig egal ob nun Opteron oder Athlon64...
Man kann eindeutig sehen, wo die Stärken und Schwächen der Architektur liegen.

Der Rest ist dann nur Detailsache die höchstens für den Endanwender wichtig ist, aber keinesfalls für unsere Diskussionen hier.

[ice cool69]

OT:

cpu experte1: du ich weiß nicht wovon du redest aber *blablatechnikgeschwafeletcetc*

cpu experte2: keine ahnung wovon du jetzt redest, ich weiß nur dass *blablanochmehrtechnikgeschwafeletcetcetc*

ehrlich gestanden versteh ich mittlerweile kein wort mehr von dem hier aber solche situationen sind einfach genial komisch. echt nich bös gemeint und lasst euch von mir nicht stören, ich fands nur irgendwie...amüsant :D

[GloomY]

Original geschrieben von ice cool69
OT:

cpu experte1: du ich weiß nicht wovon du redest aber *blablatechnikgeschwafeletcetc*

cpu experte2: keine ahnung wovon du jetzt redest, ich weiß nur dass *blablanochmehrtechnikgeschwafeletcetcetc*

ehrlich gestanden versteh ich mittlerweile kein wort mehr von dem hier aber solche situationen sind einfach genial komisch. echt nich bös gemeint und lasst euch von mir nicht stören, ich fands nur irgendwie...amüsant :D Kein Problem ;) Allerdings haben wir (also BlackbirdSR, Ich und andere) uns schon mal über deutlich schwierigere Dinge unterhalten, wo es dann wirklich so abging, dass der eine nicht genau wusste, was der andere eigentlich gemeint hat *eg*

Aber zum Glück gibt es ja Google :D

[BlackBirdSR]

Original geschrieben von ice cool69
OT:

cpu experte1: du ich weiß nicht wovon du redest aber *blablatechnikgeschwafeletcetc*

cpu experte2: keine ahnung wovon du jetzt redest, ich weiß nur dass *blablanochmehrtechnikgeschwafeletcetcetc*



um es mal vorsichtig zu sagen ;D

ich glaube du hast gerade das Grundprinzip vieler Diskussionen rund um den Globus dargestellt ;)
Sei es Technik, Politik oder Waschmittel :)

[Crazytype]

ddr 333 ist doch genauso ein marketingname wie pc800.
es müsste 166MHz-DDR-DIMMs heißen.

[GloomY]

Original geschrieben von Crazytype
ddr 333 ist doch genauso ein marketingname wie pc800.
es müsste 166MHz-DDR-DIMMs heißen. Davon abgesehen, dass du einen furchtbar alten Thread hochgeholt hast ;) :

Jein, denn DDR333 hat ja nichts mit einem Modul zu tun. Es ist eine Chip-Bezeichnung. Das 333 steht für die Datenrate. Das ist korrekt, da auf jeder Datenleitunge den Chip (theoretisch) wirklich 333 Mio. Mal pro Sekunde jeweils ein Bit verlassen kann.

Für die Spezifikation eines Moduls (man beachte den Unterschied Modul <-> Chip) reicht die Datenrate pro Pin aber nicht aus. Hier ist noch die Modulbreite, also die Anzahl der Leitungen pro Modul entscheidend. Das fehlt bei deinem Vorschlag. Ansonsten währe er vollkommen in Ordnung. :)

Ich hab' das ganze mal recht ausführlich aufgeschrieben und begründet. Leider finde ich den Thread jetzt mangels Suchfunktion nicht mehr :(

[Bokill]

Is ja nett, dass der Thread rechtzeitig wieder oben ist *g*

[Leonidas]

Nö. Thread müffelt. A64/FX Thread ist hier:
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=96031

[Gast]

Also kommt der Prescott 478 (Pentium 4) im Feb.
und der Prescott Sockel 775 im März/April oder ?

gast



:party: Viel Spass heute und ein gutes neues Jahr 2004 kommt gut rein wo auch immer :ficken:

[GloomY]

Original geschrieben von Gast
Also kommt der Prescott 478 (Pentium 4) im Feb.
und der Prescott Sockel 775 im März/April oder ?

gast



:party: Viel Spass heute und ein gutes neues Jahr 2004 kommt gut rein wo auch immer :ficken: Ich mach' den alten Thread jetzt einfach mal zu. Zum Prescott wird sowieso genügend neue Threads geben, zumal dieser Thread ja sowieso recht alt ist.