TLB-Erratum 298 nur bei Virtualisierung relevant?

[Shinzon]

Mal eine Frage am Rande: wieso stirbt eine CPU bei zu hoher RAM-Spannung? Das hat ja nichts miteinander zu tun, oder? Beeinflusst die RAM-Spannung den Prozessor-internen Speicherkontroller?

MfG

 

[kiri]

Ja, liegt am Speichercontroller. Aber ich habe meinen Phenom auch ein paar Tage mit 2,3V VDimm betrieben und da ist auch nichts passiert, ich glaube auch nicht dass das ganze schon bei 2,0V ein Problem ist, sondern erst bei 2,4V und drüber.

 

[neax]

Hi,

TLB-Erratum 298 nur bei Virtualisierung relevant?

Nein! Sonste hätte AMD nicht so reagiert und es gäbe mehr als nur einen 9600 BE.

Greetz
neax

 

[elmeg]

Hi,


Nein! Sonste hätte AMD nicht so reagiert und es gäbe mehr als nur einen 9600 BE.

Greetz
neax

man weiss in Bezug auf K10 gar nicht mehr was man glauben soll

 

[Opteron]

Wo wir aber gerade beim Phenom-Artikel von LostCircuits sind: dieser ist auch in einigen weiteren Punkten sehr lesenswert, weshalb wir ihn an dieser Stelle explizit empfehlen möchten, da er einige sehr interessante und differenzierte Analysen bereithält. Hier ein paar Kostenproben:<ul>- Ein (noch nicht erschienener) AMD Phenom 9900 mit standardmäßigen 2.6 GHz verbrauchte unerklärlicherweise bis zu 40 Prozent mehr Strom, als ein von 2.3 GHz auf 2.6 GHz übertakteter Phenom 9600 "Black Edition" mit freiem Multiplikator.
- Bei Spielen, die massiv multithreaded programmiert sind (z.B. Unreal Tournament 3 oder F.E.A.R.), lieferte sich der Phenom 9900 dank seiner nativen Quad-Core Bauweise ein Kopf an Kopf Rennen mit den schnellsten, teilweise bis zu 600 MHz höher getakteten Intel Core 2 Quad Prozessoren, während er bei singlethreaded Spielen wie Crysis oder World In Conflict, wo bei vergleichbaren IPCs der höhere Takt der Intel-CPUs ausschlaggebend war, kein Land sieht.
- Die unterschiedlichen Northbridge-Takte der verschiedenen Phenom-CPUs von 1800 MHz oder 2000 MHz, also die "Drehzahl" der Komponenten "Memory-Controller" und "L3-Cache", spielte in Sachen Performance so gut wie keine Rolle.

Zu 1: Das lässt sich durch die Verwendung anderer Transistoren erklären, da gibts welche für Niederfrequenz und wenig Leistungsverbrauch und eben die high perf. Sorte, die für ein bisschen mehr Frequenz überproportional mehr Leistung verbrät. Wenn ich mich recht erinnere, dann war das auch schon mal auf irgendeiner (AMD?) Folie drauf. Prinzipiell rentiert sich das nicht, aber nachdem Intel mit 45nm stark an der Taktschraube dreht, sieht AMD wohl keinen andren Ausweg. Das 9900er Modell wäre nach der Theorie erstmal nur das Einstiegsmodell.

Zu 2: Ist das wirklich der multihtreaded Programmierung geschuldet, oder dem Verwenden von SSE128 Befehlen, oder einem Mix aus beidem ? Ein ähnlicher Vorsprung ist mir schon früher bei einigen Spec und HPC Benches aufgefallen, da war ein 4Kern-Opteron gleichauf mit einem nagelneuen 45nm Intel XEON mit einigen 100 MHz Taktvorsprung.

Zu 3: Ist schon länger (seit 1-2 Monaten) bekannt, zumindest für diejenigen, die bei xtremsys. lesen. Dort wurde der Einfluss des NB Taktes bei den Opterons untersucht. Ab ~1,7 GHz war das Leistungsmaximum so gut wie erreicht. Man kann davon ausgehen, dass diese NB-Taktgrenze mit zunehmenden Chiptakt steigt, denn das Abflachen der Leistungskurve kann man wohl damit erklären, dass die NB genügend Daten "ranschafft" und nicht mehr von den Kernen abgenommen werden kann. Aber AMD erhöht den NB Takt ja auch ... so wie es ausschaut sogar ein bisschen zu früh.

Persönlich bin ich eher davon überrascht, da ja auch der L3 damit läuft, und man annehmen sollte, dass da mehr Takt nie verkehrt ist .. aber naja ... die Werte sind eindeutig.

ciao

Alex

 

[Drohne]

... Sie haben nur gesagt, daß sie etwas vollommen neues machen, und zwar einen nativen Quad-Core. Das ist m.E. nach vollkommen ok.

Nun ja, so vollkommen 'neu' ist ein nativer Quad-Core nun nicht, vielleicht in der x86-Welt, aber die ist nicht der Nabel eben jener Welt. Ich meinte hinsichtlich meiner PR-Kritik auch nicht die Einführung eines nativen Quad-Cores, sondern die Angaben bezüglich Rechenleistung und Stromverbrauch. Wenn es um AMD nicht eh schon so schlecht stehen würde, müßte man sich die Mühe machen und alle gemachten Aussagen sammeln und sie gegen die heutigen Fakten stellen. Da war die Rede von 40% Mehrleistung bei gleichem Takt gegenüber dem Konkurrenten, da waren Versprechungen einer nie dagewesenen Leistungssteigerung hinsichtlich Fließkommaarithmetik, da wurde die dezentrale Leistungsregulierung der Kerne hervorgehoben, ein beschleunigtes Speicherinterface und und und. Die sogenannten 'Experten' rechneten hoch, daß AMDs Barcelona ca. 10 % hinter Intels Integer-Leistung hinterherhinken werde, aber bis zu 30% vor deren Fließkommaleistung. Bei gleichem Takt versteht sich. Tatsache ist, daß bei AMD niemals der 'Vergleichspartner' genannt wurde, ein juristischer Winkelzug, den man erst heute versteht. Reiht man die Ereignisse und Veröffentlichungen chronologisch aneinander, kann damals nur der alte auf der Netburst-Architektur basierende XEON gemeint sein, der in der Tat bei gleichem Takt einem K10 hinterherhinkt. Wirklich hinterfragt hat das niemand und jeder hat das gesehen, was er oder sie gerne sehen wollten. Sollte AMD sich den Todesstoß mit dieser 'Aktion' versetzt haben, dann sollte sich jeder einmal vorstellen, er wäre bei dem Unternehmen beschäftigt. Diese bittere Pille ist schwer zu schlucken, fürchte ich.

AMD beanspruchte über drei Jahre hinweg die Führung im Serverbereich und in der Tat wurden Dank NUMA Architektur und integriertem Speichercontroller die Opteron-CPUs diesem Anspruch gerecht. Der Serversektor, in dem Highend auf ganzer Linie und nicht nur partiell am PEG gefordert ist, zeigte, wo die Leistungstärken stecken - und vor allem wo die der Konkurrenz zu suchen waren. Wie kann es aber nun sein, daß eben jene als veraltet geltende und gescholtene Architektur (FSB) durch eine applizierte neue Kernarchitektur der angeblich überlegenen AMD Architektur das Wasser abgräbt? Diese Frage kann ich nicht beantworten, wage aber eine Analyse: für meinen Teil halte ich den FSB für eine Kastration eines Computers, gerade wenn es mehr als einen CPU-Sockel oder mehr als eine CPU zu bedienen gilt. Wir alle kennen zur Genüge die Schwächen des FSB. Jetzt frage ich mich aber, wie gut Intels Technik sein muß und welches Potential in ihr stecken mag, wenn sie mit diesem Oldtimer die klar überlegene Konzeption der AMD Opteron/Athlon64 Systeme konterkarieren kann? Diese Frage beschäftigt mich zutiefst. Was passiert erst, wen ein 45 nm Penryn 'echter' Quadcore mit einem oder gar zwei integrierten Speichercontrollern auf CSI gepflanzt wird? Schon jetzt sagt Intel, daß CSI deutlich (!) schneller sein wird als AMDs Hypertransport (wobei auch hier zu bemerken ist: es wird nicht gesagt ob HT 1.0, 2.0 oder gar HT 3.0). Und hier soll auch die Träumerei enden (eher Albträumerei).
Schon jetzt läßt Intel den Markt seine Monopolstellung spüren: meiner Ansicht nach werden die FSB1333 Penryns wegene eines Bugs nun verschoben, aber Intel spricht davon, daß es keinen Grund gäbe, ohne ernsthafte Konkurenz neue Produkte auf den Markt zu bringen. Wenn AMD nun als innovativer Kontrahent wegfiele, wäre das nicht gut. Außer der CELL CPU gibt es eigentlich ansonsten nicht wirklich eine Alternative ...

 

[tomturbo]

@Drohne:

Ganz einfach mit brute force geht alles mal.
Irgendwann mal ist auch das "intelligenteste" Design unterlegen. Man muss nur genug Hubraum nachlegen.

Wenn Du das nicht verstehst ...

lg
__tom

 

[Drohne]

@tom

... nur das diesmal eben nicht ordentlich 'Hubraum' nachgelegt wurde (sprich: sinnlos an der Taktgeberschraube nach oben gedreht), sondern die Konkkurenz intelligent an einer Stelle Innovation hat walten lassen. Die andere Seite der Medaille, nämlich FSB, ist bislang unbeachtet geblieben.

Die Welt schönlügen kann man auch, aber wo bleibt dann bitteschön die Objektivität? Ich ziehe nicht gerne den Hut vor Intel, aber in diesem Falle hat es das Unternehmen geschafft, mit einem 'schlampigeren' Design (sprich: zwei Dual-Core zu einem Quad-Core zusammengeklebt und über FSB anbinden) weitaus effizienter mit einer wohldefinierten Menge Strom umzugehen! Man mag natürlich nun GEODE oder C7 ins Felde führen, allerdings setze ich einen gewissen Leistungsschwellwert voraus.
.
EDIT :
.

Zu 2: Ist das wirklich der multihtreaded Programmierung geschuldet, oder dem Verwenden von SSE128 Befehlen, oder einem Mix aus beidem ? Ein ähnlicher Vorsprung ist mir schon früher bei einigen Spec und HPC Benches aufgefallen, da war ein 4Kern-Opteron gleichauf mit einem nagelneuen 45nm Intel XEON mit einigen 100 MHz Taktvorsprung.

Der in vielen SPEC-Benches und im HPC Bereich beobachtete Vorsprung der Opteron-CPUs ist auf deren wesentlich besseres Speicherinterface bei mehr als einem Sockel zurückzuführen. Wie in einem äußerst interessanten Artikel in c't einmal hierzu zu lesen war, scheinen 8 oder gar 16 XEON-Kerne auf 2 oder vier Sockeln einfach keinen Daten mehr über den voll ausgelasteten FSB zu erhalten und können dann einfach nicht mehr schneller rechnen! Da vor allem die nicht multiskalare FPU von hohen Speicherbandbreiten und geringen Latenzen profitiert, ist dieser Effekt natürlich bei speicherlastigen Tests/Benchmarks am deutlichsten.

Wie ich schon schrieb, multithreaded Software gibt es im UNIX-/OpenSource Bereich mehr als genug und sie hat einen durchaus sehr hohen Reifegrad erreicht, inkl. die kommerziellen Compiler. Und bei dieser sind eben diese ominösen Vorteile, die man bei einem 'Spiel' gesehen haben will, nicht beobachtbar. Und nicht nur bei einer Applikation, nein, es ist durch die Bank weg der Fall!

Nach allem was bisher getestet und veröffentlicht wurde, inklusive SPEC Tests, ist der Leistungsgewinn durch die auf 128 Bit verbreiterten Datenpfade bei AMD eher ein Papiertiger. Sind die Datenpfade bei Intel nicht schon seit der Einführung der C2D-Architektur 128 Bit breit gewesen?

Zu 3: Ist schon länger (seit 1-2 Monaten) bekannt, zumindest für diejenigen, die bei xtremsys. lesen. Dort wurde der Einfluss des NB Taktes bei den Opterons untersucht. Ab ~1,7 GHz war das Leistungsmaximum so gut wie erreicht. Man kann davon ausgehen, dass diese NB-Taktgrenze mit zunehmenden Chiptakt steigt, denn das Abflachen der Leistungskurve kann man wohl damit erklären, dass die NB genügend Daten "ranschafft" und nicht mehr von den Kernen abgenommen werden kann. Aber AMD erhöht den NB Takt ja auch ... so wie es ausschaut sogar ein bisschen zu früh.

Mmmhh, das würde mich auch sehr interessieren, hast Du den Link dazu? Interessant ist gewiß zu sehen wie die Sättigung erreicht wird und wer im Kern bzw. in den Kernen die Sättigung verursacht.

Persönlich bin ich eher davon überrascht, da ja auch der L3 damit läuft, und man annehmen sollte, dass da mehr Takt nie verkehrt ist .. aber naja ... die Werte sind eindeutig.

Eindeutig hinsichtlich was? Der L3 ist, nur nebenbei bemerkt, recht mager bemessen und hat recht hohe Latenzen verglichen mit den Stepping-F3 X2 AMD64 CPUs. Deshalb wäre ich sehr interessiert an der Auflage dieses Eindeutigkeitsbeweises.

Grüßle,
D.

 

[Gast18122012]

Für mich ist schwer verständlich, wieso ein AMD/ATI Chipdesign in 55 nm mehr Energie verbrät als ein 65 nm oder 90 nm Chipset der Konkurrenz....

Tun sie das? Ich dachte sie sind energiesparend? Ich glaub du meinst die Crossfireversion, und die ist bei NVIDIA auch alles andere als energiesparend. PCIe 2.0 dürfte auch seinen Teil beitragen.

RISC CPUs, wie zum Beispiel die seelige Alpha AXP, waren einfach schon vor 15 Jahren architektonisch soweit wie Intel oder AMD es heute sind - aber an Tote erinnert man sich nicht gerne.

Naja, ich glaub so einfach ist das nicht. Intel hatte langezeit einen Markteinteil an die 90%. Wenn deren Ingenieure gedacht hätten dass sich RISC so einfach auf Windows-ConsumerPCs einsetzen lassen hättens sie es wohl gemacht. Außerdem sind moderne X86er CPUs durch zahlreiche Erweiterungen (MMX, 3DNOW, SSE...) schon längst eine Mischform aus CISC und RISC. Und das bei voller Abwärtskompatibilität - was wohl am Markt wichtiger war.
Außerdem sollte es zu denken geben dass Apple beim wechsel von der PowerPC-Architektur (RISC) zu X86 ein vielfaches an Leistung gewonnen hat.

 

[cpuoverload]

- Bei Spielen, die massiv multithreaded programmiert sind (z.B. Unreal Tournament 3 oder F.E.A.R.), lieferte sich der Phenom 9900 dank seiner nativen Quad-Core Bauweise ein Kopf an Kopf Rennen mit den schnellsten, teilweise bis zu 600 MHz höher getakteten Intel Core 2 Quad Prozessoren, während er bei singlethreaded Spielen wie Crysis oder World In Conflict, wo bei vergleichbaren IPCs der höhere Takt der Intel-CPUs ausschlaggebend war, kein Land sieht.

Das ist natürlich der Hammer, dass der Phenom bei richtigen multithreaded Games so abgeht - und die beste Nachricht seit langem.

Immerhin bei AMD SEHR viel Entwicklungsaufwand in die Tatsache geflossen, dass dieser Quad ein "nativer" ist, somit ist die CPU vielleicht gar nicht wirklich schwächer, als die Intel Quads, sondern seiner Zeit einfach zu weit vorraus...?

Da der Trend überall Richtung multithreaded geht und Dual Cores bei Neu PCs schon Standard sind (und in 1,5 Jahren die Quads), kann es sich durchaus noch für AMD auszahlen, die schwierige Audgabe angegangen zu sein, auch was das Know How für künftige CPUs oder gar 8-Cores angeht.
(Wobei ich keine Zweifel hege, dass Intel native Quads nicht auch konstruiert bekommt, vielleicht sogar schon in irgendeinem Entwicklungszentrum dran ist)

Nur schade dass man im Serverbereich K10 nicht ausliefert, Datenbankanwendungen, Application Server etc.. sind ja schon länger 64Bit/Multicore Optimiert und da wäre der K10 doch DAS Teil...grr..aber das Vertrauen dort haben sie sich mit dem TLB Bug wohl erstmal gründlich versalzen.

 

[tomturbo]

Naja, ich glaub so einfach ist das nicht. Intel hatte langezeit einen Markteinteil an die 90%. Wenn deren Ingenieure gedacht hätten dass sich RISC so einfach auf Windows-ConsumerPCs einsetzen lassen hättens sie es wohl gemacht. Außerdem sind moderne X86er CPUs durch zahlreiche Erweiterungen (MMX, 3DNOW, SSE...) schon längst eine Mischform aus CISC und RISC. Und das bei voller Abwärtskompatibilität - was wohl am Markt wichtiger war.
Außerdem sollte es zu denken geben dass Apple beim wechsel von der PowerPC-Architektur (RISC) zu X86 ein vielfaches an Leistung gewonnen hat.

Intel tat das nicht, weil sich mit 90% Marktanteil ein Fehldesign wie x86 auch so von selbst verkaufte.
Intel hat es, wie eben jetzt auch, nicht notwendig die Finger krumm zu machen.
Aber der integrierte Speicherkontroller und die serielle Verbindung nach außen (kam beides in die x86 Welt von AMD) haben ihnen zumindest so viel Angst eingejagt, dass sie jetzt auch auf dieses Design umschwenken (siehe Roadmap)
Es kam in den letzten Jahren zu keiner Innovation von Intel (maximal Fehlgriffe wie RDRAM und FBDIMM)

Und es war kein Problem Windows auf andere Architekturen zu bringen, dafür hatten die NT 4 Entwickler schon gesorgt.
NT 4 gab es für x86, Power, Alpha und MIPS.
Das Problem waren nur die Hersteller von Software die in ihrer Bequemlichkeit einfach nur X86 Software rausbrachten.
DEC hatte das damals mit der FX32 Software gelöst die 32 bit Software auf der 64bit Alpha Architektur laufen ließ und dabei ondemand sogar in 64bit Code "umwandelte" sodass die Software bei einem weiteren Aufruf schneller wurde.

lg
__tom

 

[rkinet]

Von allen architektonischen Vorteilen, die AMD seinem Konkurrenten Intel beim K8L oder K10 entgegenstellte, ist keiner so recht zum Punkten gekommen, weder der native Quad-Core noch der wesentlich bessere Speichercontroller (dessen Pluspunkte scheinbar verpuffen, wenn man sich querbeet die Tests ansieht).

Auch sehe ich nicht wirklich den 'enormen' Vorteil des nunmehr 128 Bit breiten Datenpfades zu AMDs FPU (hierauf legte ich noch vor 6 Monaten meine größten Hoffnungen!).

Ich sage nur 'Outsourcing der Barcelona-Entwicklung nach Indien'.
Als Fred Weber ging hat H.Ruiz einfach gemütlich alles nach indien verlagert und HighTech-Träume laufen lassen. In Gedanken dann täglich die nvidia o. ATI-Aquisition durchgespielt und den ganzen Technikkram zur Seite gedrückt. Ok, noch sein Hobby 'Opterone zu Dell', was ja auch geklappt hat, aber aktuell ohne performante Opterone ausliefern zu können.

Mittlerweile pfeiffen es die Spatzen von den Dächern, daß AMD das Kapital durch die Finger rinnt. Es wäre nichts ehrenrühriges dabei, auf einem gut besuchten Event für Klarheit mit allgemein zugänglichen Bugfixes, Snippets oder Compiler-Errata zu sorgen, die Fachwelt ist ausreichend kompetent, um sich ein Urteil bilden zu können!

AMD wird eben vom Patriachen H.Ruiz unterdrückt und ist ein mediales Horrokabinet.
Sein Nachfolger wird zwar an der Börse beobachtet, aber mehr auch nicht http://marketwatch-cnet.com.com/Dir...e=pt&part=marketwatch-cnet&tag=feed&subj=news

Daß ein ganz offensichtlich verkorkster Chipsatz Ursache der miesen Leistung ist?
AMD hat es versäumt für Serverchipsätze zu sorgen und hat sich stattdessen wie ein Blatt im Wind in die Abhängigkeit von nVidia und Broadcom begeben.

Der Einfluß der Chipsätze ist beim Opteron gering.
Aber der fehlende ATI/AMD Serverchipsatz ist Armutszeugnis angesichts einer $5,5 Milliarden ATI Aquisistion vor nun 1,5 Jahren.

Der Blick an die Börse offenbart keine guten Zeichen! Widersprüchliches aus der PR-Abteilung AMDs und dann jene aus der brodelnden Gerüchteküche (z.B. hinsichtlich des neuen R700 Chipsatzes), das Hickhack und Verwirrspiel um das Erratum 298, die wahren Ursachen und Auswirkungen desselbigen, keine offiziellen Stellungnahmen ... dem gemeinen Kunden kann es egal sein, wir werden uns nur ob dessen, was wir erhofft haben, gramen, aber was ist denn zum Beispiel mit den Ankündigungen großer Hardwarehersteller, die im Frühjahr Blade-Server auf K10-Opteronbasis mit einem Sockel anbieten wollten (Kuma oder so genannt?). Man hört nichts mehr! Und genau das wären aber die geldgebenden Kühe für AMD. Deshalb ahne ich nichts Gutes.

Im Moment höre ich aus den Rechenzentrenabteilung für Beschaffung nur eines: Wir kaufen Xeons (wenn Neuanschaffungen anstehen).

Der Mann an der AMD-Spitze ist 62 Jahre und hat seine Schäfchen im trockenen.

Solange aber der Beinahe-Rentner H.Ruiz auf Zeit noch AMD leitet sind wirkliche Änderung der Außenpräsentation von AMD kaum zu erwarten.
Die Marketing-Abteilung bei AMD hat ja im Sommer 2007 schon gekündigt, noch Fragen ?

Vielleicht ist der Zusammenbruch des Aktienkurses und die Wertberichtigung bzgl. ATI Anlaß genug H.Ruiz bald in Rente zu schicken.
Beim jetzigen Kurs sind auch Investoren kaum noch aufzutreiben und für Investitionen müsste AMD praktisch die halbe Firma (diluted shares) verhökern.
Vielleicht geschieht doch noch das 'Wunder' und AMD verkauft endlich ATI.
Dann ginge praktisch auch H. Ruiz (als neuer ATI CEO ? ) und AMD könnte wieder schwarze Zahlen schreiben.

 

[tomturbo]

Nur weil man es 1000 mal schreibt wird es deswegen nicht richtiger rkinet.

Das ewige Herumgemeckere mit immer den gleichen persönlichen Aversionen gegen Ruiz und Indien nerven gewaltig.

Tu' uns den Gefallen und HÖR ENDLICH AUF DAMIT und beschränke Dich auf Deine sinnvollen Beiträge.
Wir haben's schon kapiert, dass Du Ruiz und Indien nicht magst.

lg
__tom

 

[Drohne]

Intel tat das nicht, weil sich mit 90% Marktanteil ein Fehldesign wie x86 auch so von selbst verkaufte.
Intel hat es, wie eben jetzt auch, nicht notwendig die Finger krumm zu machen.
Aber der integrierte Speicherkontroller und die serielle Verbindung nach außen (kam beides in die x86 Welt von AMD) haben ihnen zumindest so viel Angst eingejagt, dass sie jetzt auch auf dieses Design umschwenken (siehe Roadmap)

... und nicht zu vergessen: Dual-Cores! AMDs Athlon64 hatte im Grunde das Design schon seit drei Jahren mit an Bord, ohne daß es genutzt wurde. Und: AMD konnte auch zeigen, daß auch andere Designs durchaus Überlebenschance in einer sonst von Intels Methusalemarchitektur Überlebenschancen hatte, wie zum Beispiel ein anderer Sockel - und dazu gehörten naturlich auch die Beneficien wie serielle Kopplung und Speichercontroller on Chip. Aber alleine das Design der HT-Links ist schon ziemlich 'alt', man denke nur an die Transputer von Inmos. Obwohl sich schon vor 20 Jahren ein solches Design der Intel-Architektur als überlegen erwies, hat Intel nichts getan, um auf dem x86-Sektor Ähnliches einzuführen. Wohl weil sie 90% Marktanteile besaßen/besizten und eine gewisse Abhängigkeit der Kundschaft bestand/besteht.

AMD hat im Serverbereich gezeigt, wie man viele CPUs aus der x86 Welt zu einem großen SMP System zusammenbringt. Der Kunde sieht, was machbar ist und sieht, daß Intel es nicht bietet. Der Markt 'wollte' es, nein, er 'brauchte' diese Innovation. Nicht umsonst strudelten so viele Serverkunden zu AMD 'rüber.

Es kam in den letzten Jahren zu keiner Innovation von Intel (maximal Fehlgriffe wie RDRAM und FBDIMM)

... oh ja, RAMBUS ... schnell, teuer, ein Jahr gelebt und viel geld in den Sand gesetzt. FB-DIMMs werden jetzt auch bei SUN eingesetzt, ich glaube schon, daß diese Technik bei Bedarf nach großen Speichermengen schon eine Existenzberechtigung hat. Vor allem aber lassen sich noch Steigerungen durch Verbreiterung des Datenpfades bei diesen Dimm-Typen erzielen. Der Stromhunger ist eine Folge dieser potentiellen Option, die man aber nicht über- , wohl aber kritisch bewerten sollte.

Und es war kein Problem Windows auf andere Architekturen zu bringen, dafür hatten die NT 4 Entwickler schon gesorgt.
NT 4 gab es für x86, Power, Alpha und MIPS.
Das Problem waren nur die Hersteller von Software die in ihrer Bequemlichkeit einfach nur X86 Software rausbrachten.
DEC hatte das damals mit der FX32 Software gelöst die 32 bit Software auf der 64bit Alpha Architektur laufen ließ und dabei ondemand sogar in 64bit Code "umwandelte" sodass die Software bei einem weiteren Aufruf schneller wurde.

lg
__tom

Also, erinnere ich mich recht, dann war NT 3 gar eine gemeinsame Entwicklung von MS und DEC mit einem OSF/1-typischen Kernellayout. DEC hatte Großes mit der Alpha vor, schoß sich aber mit der Schmalspur-Billigversion der CPU selber ins Knie. NT 4 hat vieles von NT 3 aufgegeben, man munkelte irgendwas von Strittigkeiten zwischen MS und DEC. MS hat es binnen weniger Jahre mit NT 4 geschafft, UNIX und gar Mainframes zu deklassieren - mit Marktmacht, Versprechungen und weiß der Teufel noch alles. Nicht Techniker oder Informatiker entschieden, was zum Beispiel bei der Lufthansa ins Kelsterbacher Rechenzentrum kam, nein, das waren Manager, Juristen und andere 'Profis'. Die Herren, die von 'Sales', 'Profit' und dergleichen in schlimmstem Pseudo-Angelsächsisch blubbern und wichtig tun (und dabei Probleme haben, eine einzige Gleichung wirklich richtig aufzuschreiben und sie zu differenzieren oder gar integrieren). Aber hier weiche ich ab, Verzeihung.

Wir hatten diverse Alpha Workstations im Labor, heiße Maschinen, vor allem unter OSF/1 eine Wonne! Die C- und Fortran Compiler holten viel aus der Architektur.
Auf den kleineren Desktopsystemen war NT anfangs kein Problem, die SRM-Konsole ein wenig gewöhnungsbedürftig für einige meiner Kollegen, die bislang nur das PC-BIOS kannten, aber auch zu bewältigen. Irgendwann aber bleib die Software aus, Microsoft hat dann auch die Weiterentwicklung von Office abgekündigt - quasi das Todesurteil für Windows auf Alpha. Der 32-Bit Konverter/Emulator konnte leider nicht alles ausführen und blähte naturgemäß die konvertierte Software auf (32 Bit versus 64 Bit Pointer, heute eigentlich kein Thema, Speicher ist billig, 8 GB problemlos als Standard bezahlbar, aber damals waren 256 MB RAM ein Segen, der mit vielen tausend DM bezahlt werden mußte).

Nun ja, DEC ist mit der Alpha nicht die erste Innovation, die wegen Mißwirtschaft und Höhenrausch tief fiel und sich dabei das Genick gebrochen hat. DEC war binnen eines guten Jahres liquidiert. Im Hinblick auf AMD sollte man sich das stets in Erinnerung halten. Geht AMD unter, was ich durchaus für realistisch halte, nachdem was jetzt so passierte, wäre Intel wieder da, wo sie immer hinwollten, nämlich alleine an der Spitze. Diese Situation wäre für alle Bereiche der EDV unerträglich. Diktum der Technik, des Preises und der Leistung. Leider ist es heutzutage so, daß kaum noch ein bundesdeutsches Unternehmen Risikokapital erhält, um die ausländische CPU-Dominanz aufzubrechen, oder um zumindest lizenziert in Eigenregie etwas Intel-Kompatibles zu bauen (alleine dieses Präfix zu kompatibel ist schon gallefördernd). Aber das nur nebenbei und ohne wirklichen Ernst.

Summa summarum scheint eine Hoffnung nicht erfüllt worden zu sein, die mit dem Jahre 2003 eine Form annahm.
Hat AMD nicht im letzten Jahr einen hochrangigen Entwickler aus dem Itanium-II Team abgeworben und teuer eingekauft? Was macht dieser denn jetzt?

Zum Schluß noch ein eher nicht ernstgemeinten Gedanken ...
Was wäre denn, wenn AMD Ende 2008 in Konkurs geht, Intel den Entwicklerstamm übernimmt und fortan ab 2009 den Itanium-II als günstige Server-Version mit 32-Bit Befehlserweiterung einführte? AMD hat es ja umgekehrt hinbekommen, 64 Bit Designs in die 32 Bit Architektur zu integrieren ...

 

[tomturbo]

Titanium bitte niiiicht
Nichtmal die Alpha Engineers können offensichtlich diese EPIC Einbahnstraße retten.

Ich denke aber nicht dass es zu einer Schließung von AMD kommt, denn sonst hätte Intel mehr als je zuvor die Kartellbehörden im Genick.
Was sie sicher vermeiden wollen.
So waren ja auch die Anfänge von AMD, als Intel noch Geld dort reingesteckt hat.
Sicher nicht ohne Hintergedanken.

lg
__tom

 

[Bobo_Oberon]

... Zum Schluß noch ein eher nicht ernstgemeinten Gedanken ...
Was wäre denn, wenn AMD Ende 2008 in Konkurs geht, Intel den Entwicklerstamm übernimmt und fortan ab 2009 den Itanium-II als günstige Server-Version mit 32-Bit Befehlserweiterung einführte? AMD hat es ja umgekehrt hinbekommen, 64 Bit Designs in die 32 Bit Architektur zu integrieren ...

So`n schöner Text, aber die Itanium-Pointe verwässert die Aussage.

Die ersten Itaniums hatten ja in Hardware x86-Unterstützung, die war aber so langsam, dass die Emulation mit einem speziellen Intel-Tool schneller war, als die x86-Hardware im Itanium. Abgesehen davon, dass x86 keine Bedeutung beim Itanium hat, ist es also gar nicht mehr notwendig eine "x86-Erweiterung" zu implementieren.

Topic:
Äh, ich verstehe die Meldung nicht. Schon früh wurde doch berichtet (Heise + Co.), dass der TLB-Bug vor allem gerne mit hoher Datenlast bei der Virtualisierung auftritt.

Das ist ja das Probem, dass die Server-OEMs nun gar nicht so schnell die AMD-Milchkuh einsetzen können. Bei der Analystenkonferenz im Dezember 2007 erzählt ja AMD, dass so teure K10-Dice sich deswegen lohnen, weil der Server- /Workstationmarkt bereit sei die hohen Einstandspreise zu zahlen.

Zu Dumm nur, dass eben dieser Markt derzeit die K10 Opterons nicht nimmt und auf Bugfixing-Jagt geht. Der erhoffte hohe Marge bleibt aus, und was noch schlimmer ist, es ist derzeit doch nicht so schnell bislang eine Meldung zum B3-Stepping lanciert worden.

Cray, Sun, IBM, HP dürften AMD deswegen ganz schön laut in den Ohren hängen

MFG Bobo(2007)

 

[Desti]

Intel tat das nicht, weil sich mit 90% Marktanteil ein Fehldesign wie x86 auch so von selbst verkaufte.
Intel hat es, wie eben jetzt auch, nicht notwendig die Finger krumm zu machen.
Aber der integrierte Speicherkontroller und die serielle Verbindung nach außen (kam beides in die x86 Welt von AMD) haben ihnen zumindest so viel Angst eingejagt, dass sie jetzt auch auf dieses Design umschwenken (siehe Roadmap)
Es kam in den letzten Jahren zu keiner Innovation von Intel (maximal Fehlgriffe wie RDRAM und FBDIMM)

[...]

OnDie Memory Controller, OnDie Graphic Controller, onDie Audio Codec, onDie PCI Controller wurde alles bereits 1997 in einen x86 Core reingefummelt, nur halt nicht von AMD.

 

[tomturbo]

OnDie Memory Controller, OnDie Graphic Controller, onDie Audio Codec, onDie PCI Controller wurde alles bereits 1997 in einen x86 Core reingefummelt, nur halt nicht von AMD.

Meinst Du SOC Systeme?

Die haben ja nicht wirklich ne Marktbedeutung, oder?

Wie siehts dort mit 64bit aus?

lg
__tom

 

[Bobo_Oberon]

OnDie Memory Controller, OnDie Graphic Controller, onDie Audio Codec, onDie PCI Controller wurde alles bereits 1997 in einen x86 Core reingefummelt, nur halt nicht von AMD.

Tjo ... Das waren noch Cyrix-Zeiten ...

Wobei IBM früh schon an serielle Links dachte (Microchannel), Intel schon früh den Timna mit integriertem Rambus-Speicherkontroller NICHT herausbrachte ...

@tomturbo
Wieviel Marktanteil hat 64 Bit bei Windows Vista?

Gemessen in Stückzahl dürften SoC sehr bedeutsam sein, wenngleich da auch ARM, MIPS und andere Architekturen dort ein Wort mitreden ... zu dumm nur, dass dort die Margen niedriger sind, als mit x86-Chips.

MFG Bobo(2008)

 

[tomturbo]

Gemessen in Stückzahl dürften SoC sehr bedeutsam sein, wenngleich da auch ARM, MIPS und andere Architekturen dort ein Wort mitreden ... zu dumm nur, dass dort die Margen niedriger sind, als mit x86-Chips.

Zu dumm nur, dass Windows Vista 64bit auf ARM nicht läuft.
Oh zu dumm nur, dass die SOC Systeme keine wirklich vernünftigen Taktfrequenzen haben, sodass man zb. HD-DVD schauen kann.
Zu dumm nur, dass SOC Systeme keine ordentlichen 3D Grafikkarten haben.
Zu dumm nur, dass Boards von SOC Systemen oft ein vielfaches von "normalen" Boards kosten.

zu dumm nur .... dass man SOC Systeme nicht mit PC's vergleichen kann

lg
__tom

 

[SPINA]

Zu dumm nur, dass Windows Vista 64bit auf ARM nicht läuft.

Vielleicht kommt die 64-Bit Unterstüzung noch mit Windows Mobile 7/8/9.x. Aber nachdem Intel seine XScale (ARM-v5TE) Prozessorserie nicht mehr weiterentwickelt, wird wohl auch die Windows Mobile Entwicklung ins Stocken geraten, denn wenn sich schon der Branchenriese aus diesem Geschäftsfeld verabschiedet, sind PocketPCs wohl endgültig als Nischenprodukt abgestempelt. Demnächst wird deren Aufgabengebiet wohl vollständig von Mobiltelefonen und Subnotebooks übernommen werden.

 

[Bobo_Oberon]

Zu dumm nur, dass Windows Vista 64bit auf ARM nicht läuft.
Oh zu dumm nur, dass die SOC Systeme keine wirklich vernünftigen Taktfrequenzen haben, sodass man zb. HD-DVD schauen kann.

Wozu auch, wenn mit einem angepassten MIPS nur wenige MHz dafür reichen

Zu dumm nur, dass SOC Systeme keine ordentlichen 3D Grafikkarten haben.

Tja, 3D aufm Handy ist es nun mal nicht ganz so leistungsfähig, wie aufm Desktop ...

Zu dumm nur, dass Boards von SOC Systemen oft ein vielfaches von "normalen" Boards kosten.

High Tech Handy kosten nun mal ... aber auch Set Top Boxen lassen sich schlecht vergleichen, da viele davon per Vertrag nur mit`m Sternchen-Europreis verkauft werden ... 8)

zu dumm nur .... dass man SOC Systeme nicht mit PC's vergleichen kann ...

Ein SoC macht nichts anderes, was ein PC auch machen kann, nur optimiert auf Kosten und/oder Kompaktheit und/oder [gewünschte Eigenschaft hier eintragen].

MFG Bobo(2008 )

 

[Nero24]

Mal kurz Back 2 Topic

Für alle, die es interessiert (ohne Anspruch auf journalistische Korrektheit, da ich weder Quelle noch Details nennen darf )
Es ist wohl so, dass die Aussage von Michael Schuette in die richtige Richtung geht, aber nicht ganz korrekt ist. Vielmehr soll es wohl so sein, dass das Erratum 298 in einer virtualisierten Umgebung überhaupt erst entdeckt wurde. Hier soll es wohl auch unter den genannten Umständen (Hardware-Virtualisierung und dauerhaft hohe Last auf allen 4 Kernen) reproduzierbar sein. Genauere Untersuchungen sollen dann ergeben haben, dass der Fehler theoretisch auch in normaler, also nicht virtualisierter Umgebung auftreten könnte. Allerdings soll es in der Praxis noch nicht gelungen sein ihn dort jemals zu provozieren. Allein aufgrund der theoretischen Wahrscheinlichkeit soll AMD sicherheitshalber auf den TLB-BIOS-Fix bestanden haben, auch in einer nicht virtualisierten Umgebung.

 

[Drohne]

Mal kurz Back 2 Topic

Für alle, die es interessiert (ohne Anspruch auf journalistische Korrektheit, da ich weder Quelle noch Details nennen darf )
Es ist wohl so, dass die Aussage von Michael Schuette in die richtige Richtung geht, aber nicht ganz korrekt ist. Vielmehr soll es wohl so sein, dass das Erratum 298 in einer virtualisierten Umgebung überhaupt erst entdeckt wurde. Hier soll es wohl auch unter den genannten Umständen (Hardware-Virtualisierung und dauerhaft hohe Last auf allen 4 Kernen) reproduzierbar sein. Genauere Untersuchungen sollen dann ergeben haben, dass der Fehler theoretisch auch in normaler, also nicht virtualisierter Umgebung auftreten könnte. Allerdings soll es in der Praxis noch nicht gelungen sein ihn dort jemals zu provozieren. Allein aufgrund der theoretischen Wahrscheinlichkeit soll AMD sicherheitshalber auf den TLB-BIOS-Fix bestanden haben, auch in einer nicht virtualisierten Umgebung.

In den von benutzten Rechenzentren laufen mitlerweile einige unserer Mehrkernsysteme/Server (bis vor einem Monat ausschließlich AMD Opteron basiert) mit virtuellen Maschinen - das ist für Entwicklungen eine sehr gute Sache. Wir hätte sofort die langsamsten Maschinen (1,8 GHz) mit 2,0 GHz Barcelonas ausgetauscht. Und nun stelle man sich vor was passiert wäre, wenn hier alle Systeme still stünden, weil sie einen Bug haben ...

Andererseits setzen wir auf der überwiegenden Mehrheit unserer Server keine kostspieliegen Server-CPUs ein, sondern die meist gleich schnellen, aber billigeren Mainstreamprozessoren. Intel wie AMD garantieren bei Server-CPUs lediglich die längere Verfügbarkeit, aber keine höhere Leistung oder ganz besonders hohe Ausfallsicherheit oder Zuverlässigkeit! In manchen Produktionszyklen, die der Gewinnsteigerung oder Verzweiflung entspringen, haben Mainstream- oder Serverprozessoren lediglich andere Namen aber identische Interna, das war bei Intel im Bereich der P III CPUs eine Weile so, bei den P4/Xeons ebenfalls und bei AMD waren die letzten 1-Sockel Opteronen nicht von den Mainstream-CPUs zu unterscheiden. Unter diesem Aspekt wären vermutlich sehr viele Phenom-CPUs in kleineren 1-Sockel-Servern verschwunden. Und hier hätte ich meinen Arsch verwettet, daß davon nicht wenige virtualisiert arbeiten würden! Wenn der Fehler im Phenom also bei Virtualisierung zutage tritt, ist das unter den genannten Aspekten eine ernstzunehmende Sache. Der Kinder-PC Markt spielt dabei eine marginale Rolle. Es geht um Regressforderungen und viel Geld ...

 

[larsbo]

Mal kurz Back 2 Topic

Für alle, die es interessiert (ohne Anspruch auf journalistische Korrektheit, da ich weder Quelle noch Details nennen darf )
Es ist wohl so, dass die Aussage von Michael Schuette in die richtige Richtung geht, aber nicht ganz korrekt ist. Vielmehr soll es wohl so sein, dass das Erratum 298 in einer virtualisierten Umgebung überhaupt erst entdeckt wurde. Hier soll es wohl auch unter den genannten Umständen (Hardware-Virtualisierung und dauerhaft hohe Last auf allen 4 Kernen) reproduzierbar sein. Genauere Untersuchungen sollen dann ergeben haben, dass der Fehler theoretisch auch in normaler, also nicht virtualisierter Umgebung auftreten könnte. Allerdings soll es in der Praxis noch nicht gelungen sein ihn dort jemals zu provozieren. Allein aufgrund der theoretischen Wahrscheinlichkeit soll AMD sicherheitshalber auf den TLB-BIOS-Fix bestanden haben, auch in einer nicht virtualisierten Umgebung.

jetzt erst zufällig gelesen, aber das ist doch mal interessant. So eine Insider-Info ist doch mal wichtig. Also wäre die richtige Entscheidung PR-Mäßig eigentlich gewesen, den Phenom ohne Virtualisierung, aber dafür auch als 9700 auszuliefern. Aber zum Auslieferungszeitpunkt war ja offensichtlich auch für AMD das ganze noch nicht völlig klar, sonst kann man sich den Stopp vom 9700 und das dümmliche Gerede von einem Fehler, der bei zu hoher Taktfrequenz auftritt, wirklich nicht erklären. Fehler, die vielleicht theoretisch auftreten könnten, aber auch nach ausgiebigen Tests nicht in real-life, geschweige denn mit echtem Anwendungscode, die gibts in den Errata-Listen reichlich. Warum AMD das ganze jetzt nicht einfach auch mal ganz offiziell sagt, ist mir auch ein Rätsel.


Zu Drohnes Meinungen zum Phenom nur kurz: grundsätzlich Zustimmung. Allerdings sehen die Spec_rateFP Werte für den K10 im Vergleich zur Intel-Konkurrenz recht gut aus wenn ich mich da an die c´t Messungen erinnere, bei gleichem Takt schlägt der K10 da die C2-Architektur deutlich (war aber glaub ich auch zwei Sockel-Systeme, was nochmal günstig ist für AMD, single-socket könnte noch anders aussehen). Nur single-thread siehts echt mau aus. Weiterhin ist der K10 bei Integer bei 64bit code im Vorteil, oder sagen wir mal so, nicht mehr so im Nachteil gegenüber den Intels, weil von den zwei Integer-Einheiten im C2 nur eine 64bit kann.......