AMD auf dem Weg zum Earnings-Crossover mit Intel (Seite 2344)
eröffnet am 21.04.06 19:39:20 von
neuester Beitrag 22.04.24 09:04:17 von
neuester Beitrag 22.04.24 09:04:17 von
Beiträge: 30.442
ID: 1.055.324
ID: 1.055.324
Aufrufe heute: 90
Gesamt: 2.790.030
Gesamt: 2.790.030
Aktive User: 0
ISIN: US0079031078 · WKN: 863186 · Symbol: AMD
153,72
USD
+1,30 %
+1,98 USD
Letzter Kurs 19:02:17 Nasdaq
Neuigkeiten
Künstliche Intelligenz: Strategische Expansion: KI-Highflyer Nvidia verstärkt sich mit zwei Zukäufen 18:27 Uhr · wallstreetONLINE Redaktion |
Advanced Micro Devices Aktien jetzt im kostenlosen Demokonto handeln!Anzeige |
17:00 Uhr · BNP Paribas Anzeige |
24.04.24 · wallstreetONLINE Redaktion |
24.04.24 · BNP Paribas Anzeige |
Werte aus der Branche Halbleiter
Wertpapier | Kurs | Perf. % |
---|---|---|
10,870 | +43,03 | |
154,18 | +27,52 | |
5.010,00 | +25,09 | |
20,400 | +20,00 | |
1,0000 | +19,23 |
Wertpapier | Kurs | Perf. % |
---|---|---|
42,00 | -9,68 | |
16,780 | -12,01 | |
7,5000 | -12,02 | |
3,3050 | -17,58 | |
13,590 | -22,56 |
Beitrag zu dieser Diskussion schreiben
Antwort auf Beitrag Nr.: 28.323.414 von Dresdenboy am 16.03.07 10:39:00@Matthias
Jonnyguru und SuperSix klingen zwar nicht unbedingt vertrauenerweckend, aber ich warte eigenlich schon eine Weile auf etwas derartiges: Auf Intels Guerilla-Marketing mit gezielten Indiskretionen kann man ja nicht anders reagieren als selbst gezielte Indiskretionen in die Welt zu setzen. Früher hat man soleches Zeug über andere Kanäle transportiert, aber seit der inq sich aus Latrinenpatrolen der Foren speist ist es völlig gleichgültig wo und von wem es gepostet wird.
K.
Jonnyguru und SuperSix klingen zwar nicht unbedingt vertrauenerweckend, aber ich warte eigenlich schon eine Weile auf etwas derartiges: Auf Intels Guerilla-Marketing mit gezielten Indiskretionen kann man ja nicht anders reagieren als selbst gezielte Indiskretionen in die Welt zu setzen. Früher hat man soleches Zeug über andere Kanäle transportiert, aber seit der inq sich aus Latrinenpatrolen der Foren speist ist es völlig gleichgültig wo und von wem es gepostet wird.
K.
Infos zu den Diesizes der neuen GPUs/IGPs: http://forum.beyond3d.com/showthread.php?t=39676
"...RV610 is 7.7x10.7mm, or ~82mm² on 65nm...
...RV630 is 13.3x11.5mm, or ~153mm² on 65nm...
...G86 is 11.5x10mm, or ~115mm² on 80nm...
...MCP73 is ~135mm² on 80nm(?)...
All of these measurements have an error margin of, most likely, less than 5%..."
Und 690G misst nur rund 50mm² (on 80nm?)
Wie gehabt: die Chipsets für Intel-Boards scheinen aufgrund des noch nötigen Ram-Controllers nicht nur mehr Energie aufzunehmen, sondern auch entsprechend größer in der Diesize zu sein.
"...RV610 is 7.7x10.7mm, or ~82mm² on 65nm...
...RV630 is 13.3x11.5mm, or ~153mm² on 65nm...
...G86 is 11.5x10mm, or ~115mm² on 80nm...
...MCP73 is ~135mm² on 80nm(?)...
All of these measurements have an error margin of, most likely, less than 5%..."
Und 690G misst nur rund 50mm² (on 80nm?)
Wie gehabt: die Chipsets für Intel-Boards scheinen aufgrund des noch nötigen Ram-Controllers nicht nur mehr Energie aufzunehmen, sondern auch entsprechend größer in der Diesize zu sein.
Antwort auf Beitrag Nr.: 28.329.573 von hope2 am 16.03.07 15:53:44@Hope
Huh? Hat Krsna nicht erst gestern von outperform zu marketperform
runtergenommen?
K.
Huh? Hat Krsna nicht erst gestern von outperform zu marketperform
runtergenommen?
K.
Antwort auf Beitrag Nr.: 28.322.278 von Dresdenboy am 16.03.07 09:38:23@Mattthias
oder er hofft, dass der Compiler da etwas machen kann.
Dazu hat man mir vor längerer Zeit die Vorstellung empfohlen das sei so etwa wie mit babelfish-Übersetzungen. Man kann sie nehmen, aber sie sind recht holprig. Manchmal kann man sie direkt verwenden, meist muss man das lange mit den flags feilen damit sie schneller werden als der urspüngliche Code. Für ein Ergebnis in der Nähe des besten Code sei es in der Tat so wie Du es beschrieben hast: Man muss die Konzeption der Applikation neu entwerfen.
K.
oder er hofft, dass der Compiler da etwas machen kann.
Dazu hat man mir vor längerer Zeit die Vorstellung empfohlen das sei so etwa wie mit babelfish-Übersetzungen. Man kann sie nehmen, aber sie sind recht holprig. Manchmal kann man sie direkt verwenden, meist muss man das lange mit den flags feilen damit sie schneller werden als der urspüngliche Code. Für ein Ergebnis in der Nähe des besten Code sei es in der Tat so wie Du es beschrieben hast: Man muss die Konzeption der Applikation neu entwerfen.
K.
Antwort auf Beitrag Nr.: 28.322.278 von Dresdenboy am 16.03.07 09:38:23@Mattthias
Das Problem sind hier die Ströme...(100A max für Barcelona?)
Für den VRM eher mehr. Aber das teilt sich durch die Stromversorgungs-Pins, wenn meine dürftigen Grundlagen der Stromologie anwendbar sind. Mehr als etwas einstelliges in Ampere pro pin scheint man nicht aufs package zu kriegen, sonst bräuchte es nicht soviele Stromversorgungs-Pins. Damit ist der Saft noch nicht im die, ich mehme an pro pad kriegt man weniger als ein Ampere rein.
Für kleinere Stromfresser kann die Spannung dagegen auf dem Package generiert werden. Jo, das wären dann diejenigen die aus VDDNB gemacht werden. Falls das gepostete Blockbild die Dinge darstellt wie sie liegen würde VDDNB im die moduliert. Aber das könnte eine Überinterpretation einer vereinfachten PR-Darstellung sein. Kurz gesagt reicht das Wenige dass ich dazu weiss hinten und vorne nicht um abschätzen zu können was nur auf dem package und was granular im die geht. Wahrscheinlich geht beides, dann läuft es auf mulivariate Optimierung hinaus die weit ins Eingemachte geht. (Wäre eine reizvolle Herausforderung.Lächeln)
Bei der Spannungsversorgung der Cores ist zu berücksichtigen dass VDD nicht konstant, sondern abhängig vom höchsten powerstate eines Core ist - jedenfalls wenn man davon ausgeht dass man die bisherige Praxis beibehält. Variable Eingangssspannungen passend für die powerstates anderer Cores zu modulieren ist etwas weniger trivial als konstante Eingangsspannungen, aber nicht schwierig genug dass ich es den Entwickern bei AMD nicht zutrauen würde.
Ich folge Werner soweit dass der Unterschied zu weiterer Modulation für jeden powerstate jedes Core zwar nicht vernachlässigbar, aber auch nicht gross genug ist dass man ihn sofort braucht (mir ist wieder eingefallen wo ich die Idee her habe. Danach neige ich zur Annahme dass die circuitry dafür im design drin ist aber erst in späteren Revisionen zum Einsatz kommt wenn der Prozessfortschritt es erlaubt und der Effekt mit dem scaling grösser wird.)
K.
Das Problem sind hier die Ströme...(100A max für Barcelona?)
Für den VRM eher mehr. Aber das teilt sich durch die Stromversorgungs-Pins, wenn meine dürftigen Grundlagen der Stromologie anwendbar sind. Mehr als etwas einstelliges in Ampere pro pin scheint man nicht aufs package zu kriegen, sonst bräuchte es nicht soviele Stromversorgungs-Pins. Damit ist der Saft noch nicht im die, ich mehme an pro pad kriegt man weniger als ein Ampere rein.
Für kleinere Stromfresser kann die Spannung dagegen auf dem Package generiert werden. Jo, das wären dann diejenigen die aus VDDNB gemacht werden. Falls das gepostete Blockbild die Dinge darstellt wie sie liegen würde VDDNB im die moduliert. Aber das könnte eine Überinterpretation einer vereinfachten PR-Darstellung sein. Kurz gesagt reicht das Wenige dass ich dazu weiss hinten und vorne nicht um abschätzen zu können was nur auf dem package und was granular im die geht. Wahrscheinlich geht beides, dann läuft es auf mulivariate Optimierung hinaus die weit ins Eingemachte geht. (Wäre eine reizvolle Herausforderung.Lächeln)
Bei der Spannungsversorgung der Cores ist zu berücksichtigen dass VDD nicht konstant, sondern abhängig vom höchsten powerstate eines Core ist - jedenfalls wenn man davon ausgeht dass man die bisherige Praxis beibehält. Variable Eingangssspannungen passend für die powerstates anderer Cores zu modulieren ist etwas weniger trivial als konstante Eingangsspannungen, aber nicht schwierig genug dass ich es den Entwickern bei AMD nicht zutrauen würde.
Ich folge Werner soweit dass der Unterschied zu weiterer Modulation für jeden powerstate jedes Core zwar nicht vernachlässigbar, aber auch nicht gross genug ist dass man ihn sofort braucht (mir ist wieder eingefallen wo ich die Idee her habe. Danach neige ich zur Annahme dass die circuitry dafür im design drin ist aber erst in späteren Revisionen zum Einsatz kommt wenn der Prozessfortschritt es erlaubt und der Effekt mit dem scaling grösser wird.)
K.
Antwort auf Beitrag Nr.: 28.322.278 von Dresdenboy am 16.03.07 09:38:23@Mattthias
Aber genauere Tests werden erst mit einem Barcelona möglich, da derzeit keine unabhängige Taktung möglich ist, sondern nur Tricks wie HLT oder Core-Deaktiverung zur Verfügung stehen.
Ich nehme an dass man von aussen an die Settings der einzelnen Barcelona-Cores auch nicht leicht drankommt. Es geht wahrscheinlich, aber nur ein paar Dutzend Leute wissen wie.
Ich vermute der Hintergrund der aufgeworfenen Fragen bedarf der Erläuterung. Im Kern geht es nämlich um die beliebtesten Forderungen
1. Höhere Takte!
2. Mehr Dualcore!
Ich versuche es mal ausführlicher. Das K8-Dualcore-dfm hat folgendes Dilamma drin:
1) Jedes DC-Produkt ist auf den Takt des Cores mit den limitierenden Charakteristika beschränkt.
2) Dualcore-Dies werden u.a. deshalb als Single-Core-Produkt konfektioniert weil zwar beide beide Cores funktionieren aber ein Dual-Core-Produkt auf einen Takt limitiert wäre mit dem es weniger erlösen würde als das SC-Produkt mit dem Takt des besseren Core.
Sowas kann man machen wenn man einen überlegenen Prozess hat - und den haben sie in 90nm. Wie weit er trägt werden wir sehen - das kommt u.a. darauf an ob Revision F nicht nur die cache-yields anhebt (davon kann man aufgrund der dfm-Änderungen ausgehen) sondern auch die Variabilität reduziert und damit den \"slack\" des designs verringert, den sweetspot der bins noch ein gutes Stück nach oben bringt und den sweetspot der wattage noch ein Stück runterbringt. Ich erwarte in jederlei Hinsicht etwas. Schon weil ich die Jungs nicht für dämlich genug halte die Strategie auf der sie sind zu fahren wenn sie etwas anderes erwarten würden.
Die obigen Überlegungen zum feature-slack stehen aber auch im Hintergrund stirnrunzelnder Kommentare zum Barcelona: Das Dilemma wirkt dort stärker, weil die Variabilität von node zu node grösser wird - und damit die Streuung der Charakteristika der einzelnen Cores. Ich gehe zuversichtlich davon aus dass AMD ein pfiffiges Konzept mit Hand und Fuss in der Schublade hat um das Dilemma aufzulösen oder wenigstens zu entschärfen. Wenn nicht wäre der Intelsche Kommentar ein monolythisches quad-core-design in 65 nm sei Selbstmord nämlich nicht ohne Weiteres von der Hand zu weisen.
K.
Aber genauere Tests werden erst mit einem Barcelona möglich, da derzeit keine unabhängige Taktung möglich ist, sondern nur Tricks wie HLT oder Core-Deaktiverung zur Verfügung stehen.
Ich nehme an dass man von aussen an die Settings der einzelnen Barcelona-Cores auch nicht leicht drankommt. Es geht wahrscheinlich, aber nur ein paar Dutzend Leute wissen wie.
Ich vermute der Hintergrund der aufgeworfenen Fragen bedarf der Erläuterung. Im Kern geht es nämlich um die beliebtesten Forderungen
1. Höhere Takte!
2. Mehr Dualcore!
Ich versuche es mal ausführlicher. Das K8-Dualcore-dfm hat folgendes Dilamma drin:
1) Jedes DC-Produkt ist auf den Takt des Cores mit den limitierenden Charakteristika beschränkt.
2) Dualcore-Dies werden u.a. deshalb als Single-Core-Produkt konfektioniert weil zwar beide beide Cores funktionieren aber ein Dual-Core-Produkt auf einen Takt limitiert wäre mit dem es weniger erlösen würde als das SC-Produkt mit dem Takt des besseren Core.
Sowas kann man machen wenn man einen überlegenen Prozess hat - und den haben sie in 90nm. Wie weit er trägt werden wir sehen - das kommt u.a. darauf an ob Revision F nicht nur die cache-yields anhebt (davon kann man aufgrund der dfm-Änderungen ausgehen) sondern auch die Variabilität reduziert und damit den \"slack\" des designs verringert, den sweetspot der bins noch ein gutes Stück nach oben bringt und den sweetspot der wattage noch ein Stück runterbringt. Ich erwarte in jederlei Hinsicht etwas. Schon weil ich die Jungs nicht für dämlich genug halte die Strategie auf der sie sind zu fahren wenn sie etwas anderes erwarten würden.
Die obigen Überlegungen zum feature-slack stehen aber auch im Hintergrund stirnrunzelnder Kommentare zum Barcelona: Das Dilemma wirkt dort stärker, weil die Variabilität von node zu node grösser wird - und damit die Streuung der Charakteristika der einzelnen Cores. Ich gehe zuversichtlich davon aus dass AMD ein pfiffiges Konzept mit Hand und Fuss in der Schublade hat um das Dilemma aufzulösen oder wenigstens zu entschärfen. Wenn nicht wäre der Intelsche Kommentar ein monolythisches quad-core-design in 65 nm sei Selbstmord nämlich nicht ohne Weiteres von der Hand zu weisen.
K.
JMP Securities upgraded shares of Advanced Micro Devices Inc (NYSE: AMD) to Market Outperform from Market Perform following checks that indicate the company's next-generation "Barcelona" quad-core server chip and next-generation low-power mobile PC processor chip is exhibiting excellent power, performance, scalability, and price/performance characteristics at key OEM customers.
Gruß hope2
Gruß hope2
Antwort auf Beitrag Nr.: 28.326.733 von neubiene^^^^ am 16.03.07 13:33:44Mit der offiziellen Aussage, dass die Opterons maximal 95W TDP haben, relativiert sich der Wahrheitsgehalt der vielzitierten Tabelle aus #6938, #6925 und #6897. Ich gehe davon aus, dass der Rest der Tabelle, wenn überhaupt, dann nur zufällig stimmt. MfG
@ linux4me
und mit jeder Grafikgeneration steckt ein Fünkchen mehr Wahrheit hinter dem Spruch
und mit jeder Grafikgeneration steckt ein Fünkchen mehr Wahrheit hinter dem Spruch
Künstliche Intelligenz: Strategische Expansion: KI-Highflyer Nvidia verstärkt sich mit zwei Zukäufen 18:27 Uhr · wallstreetONLINE Redaktion · Advanced Micro Devices |
17:00 Uhr · BNP Paribas · Advanced Micro DevicesAnzeige |
24.04.24 · wallstreetONLINE Redaktion · Advanced Micro Devices |
24.04.24 · dpa-AFX · Advanced Micro Devices |
24.04.24 · wallstreetONLINE Redaktion · Advanced Micro Devices |
22.04.24 · wallstreetONLINE Redaktion · Advanced Micro Devices |
22.04.24 · wallstreetONLINE Redaktion · Advanced Micro Devices |
21.04.24 · Dr. Hamed Esnaashari · Adobe |