Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?

gruffi · 17.02.2010

rkinet schrieb:
Wobei 32nm später ja auch dann sehr deutlich unter 3 GHz bleiben muß da ja schon der K10.5 in 32nm bis 25 Watt bei ca. 3 GHz benötigt.

Nein, tut er nicht. Da hast du etwas falsch verstanden. Wäre auch ziemlich seltsam, da bereits in 45 nm ein K10.5 Kern bei 3 GHz und 1,2 V nur etwa 10-15 W (Core2MaxPerf) braucht. In 32 nm sollte ein Kern also klar unter 10 W liegen.

Twodee schrieb:
und weswegen halbiert (2 INT-Cluster vs eine FPU) man dann die FPU im Bulldozer?

Wieso halbiert? Im K10 ist die FPU 1x 128-bit, im Bulldozer 2x 128-bit FMAC. Man hat die FPU Kapazität nicht halbiert, sondern vervierfacht. Und pro Kern immer noch verdoppelt. Selbst ohne explizite FMA Unterstützung seitens der Anwendung hat man keine Nachteile gegenüber dem K10.5.

Twodee schrieb:
Btw. was passiert, wenn zwei Threads jeweils eine 256Bit AVX-Instruction ausführen möchten?

Dann muss ein Thread warten, wie bei Intels Sandy Bridge auch. Die FPU in Bulldozer soll aber recht dynamisch arbeiten können. Selbst zwei AVX Instruktionen für beide Kerne eines Moduls im selben Takt sollten da nicht zum Flaschenhals werden, da das eher nicht die Regel ist.

Twodee · 17.02.2010

gruffi schrieb:
Wieso halbiert? Im K10 ist die FPU 1x 128-bit, im Bulldozer 2x 128-bit FMAC. Man hat die FPU Kapazität nicht halbiert, sondern vervierfacht. Und pro Kern immer noch verdoppelt. Selbst ohne explizite FMA Unterstützung seitens der Anwendung hat man keine Nachteile gegenüber dem K10.5.

Ich nahm an [zumindest wurde das hier im Thread erwähnt], das beim BullDozer sich je zwei Int-Kerne/Cores (wie auch immer) eine FPU teilen müßten. Daher meine Aussage mit "halbiert", weil z.b. 8 Int-Kerne, aber nur 4 FPUs. Wenn die neue FPU so stark ist dann sollte sich das ausgleichen.

Ist das Verhältnis 1x 128-bit VS. 2x 128-bit FMAC echt 1:4

(bezogen auf je Kern oder doch CPU ?)

gruffi schrieb:
Dann muss ein Thread warten, wie bei Intels Sandy Bridge auch. Die FPU in Bulldozer soll aber recht dynamisch arbeiten können. Selbst zwei AVX Instruktionen für beide Kerne eines Moduls im selben Takt sollten da nicht zum Flaschenhals werden, da das eher nicht die Regel ist.

Einleuchtend

Btw. eine andere allg Frage: Welcher Bolldozer ist mit welcher Sandy Bridge zu vergleichen? [bezogen auf Kerne/Module/HT]
.
EDIT :
.

Opteron schrieb:
Ist eine Auslastungsfrage, ob auch im schärfsten HPC Code nur 100% FPU µOps kommen, oder doch auch ein bisschen Leerlauf dabei ist. Schlechter wirds auf keinen Fall werden, davon gehen ich mal aus
Im schlechtesten Fall sollte theoretisch eigentlich immer noch soviel SpeedUp wie bei Intels Hyperthreading drin sein. Ist zumindest Pi*Daumen dann beim Teilaspekt FPU Code vergleichbar.

Also das Warum ist eigentlich klar: bestes Preis / Leistungsverhalten

ciao

Alex
P.S: FMA4 darf man bei HPC Code ebenfalls nicht vergessen
Neukompilieren muss man für 256bit AVX ja sowieso. Einziges Problem ist AMDs OpenSource Compiler ^^
Bin gespannt, wie sie den bis 2011 hinbekommen ^^

Im schlechtesten Fall dürfte HyperThr. gar nichts mehr bringen, da die FPU von einem HT-Core komplett ausgelastet sein sein sollte.

GHad · 17.02.2010

Wieso Bulldozer vs. SandyBridge?

Nachdem SB mit onDie GPU kommt und mit max. 4 Kernen ist das für mich das Konkurrenzprodukt zum Llano.

Bulldozoer muss bei Release gegen die aktuellen und bald neuen Core i7 mit 4-6 Kernen ran und später gegen die 32nm 1366er Core i7 oder dann i9 antreten, wenn die irgendwann nächstes Jahr mal kommen.

Greetz,
GHad

Twodee · 17.02.2010

Natürlich gibts (bzw. wird es geben, und zwar wenn BD kommt) SB mit 8-Kernen + HT, ohne iGPU: http://www.hardwareluxx.de/images/s...t-2011-pins-in-2011/EXPC_Intel_CPU2009Nov.png

Limit64 · 17.02.2010

Ragas schrieb:
wenn man maximale Leistung will sollte möglichst immer nur ein Fpu-intensiver Prozess auf einem Cluster arbeiten. Damit könnte man 4 Cores ohne Nachteile voll Auslasten und die anderen 4 sollten dann möglichst ohne FPU Zugriffe auskommen.

Problem ist hierbei eigentlich, ob das OS darüber Bescheid weiß und das so ausbalancieren kann, oder ob die Prozesse einfach zufällig angeordnet werden und dadurch mehr Kollisionen entstehen als notwendig wären.

Zu dem Thema gab es mal eine Studienarbeit hier an der Uni. Dabei ging es darum den Scheduler, den Migrationsmechanismus und den Frequency Scaling Mechanismus so abzuändern, dass er die "Art" der Threads/Tasks berücksichtigt. Dabei wurde die PMC (Performance Monitoring Counter) benutzt um Anzahl der INT/FP/MMX/SSE/MEM/... zu zählen und damit ein Profil (Activity Vector) jedes einzelnen Threads/Tasks zu erstellen. Die Zielsetzung war zwar nicht identisch, aber es wurde dabei z.B. auch HyperThreading erwähnt, bei dem ja ähnliche Probleme (sogar noch gravierender als hier) entstehen.

So eine Implementierung wird immer dann interessant, wenn sich mehre Kerne/CPUs die gleichen Resourcen teilen müssen.

Duplex · 17.02.2010

Liano in 32nm sollte vielleicht 20% mehr Leistung als die aktuellen vergleichbaren 45nm K10.5 haben.
Aber der Sandy Bridge wird mit Turbo/SMT viel mehr Leistung als die AMD CPUs haben, die Intel CPUs sind bei gleichem Takt schneller als AMD, das heißt die Turbo Mode bei AMD bringt nicht viel, lässt aber den Rückstand etwas weniger ausfallen.

Sandy Bridge müsste bei 4 Kernen bis zu 40% mehr Leistung ohne Turbo als ein 4 Kern K10.5 @45nm haben.

Große Erwartungen von einem K10.5 in 32nm habe ich keine, max. 20% mehr Leistung bei gleichem Takt wie Deneb. Ich bin schon gespannt wieviele Liano Produkte AMD bis Q2/2011 verkaufen wird, das kann auch schiefgehen

Bulldozer & GPU auf einem DIE mach mehr Sinn als K10 Liano, der kann dann mehrere Jahre die Leistung halten, die sind halt unterschiedliche Architekturen

Ich erwarte erst von Bulldozer große Leistungssprünge, der 4 Modul BD sollte die komplette Intel Arena vernichten.

K10 wird langweilig für mich, gibt nur noch den Thuban zu testen,sobald ich den hab, werde ich den auf 6x 3,8 Ghz @WaKü prügeln und vergleichen.

rkinet · 17.02.2010

Duplex schrieb:
Liano in 32nm sollte vielleicht 20% mehr Leistung als die aktuellen vergleichbaren 45nm K10.5 haben.
Aber der Sandy Bridge wird mit Turbo/SMT viel mehr Leistung als die AMD CPUs haben, die Intel CPUs sind bei gleichem Takt schneller als AMD, das heißt die Turbo Mode bei AMD bringt nicht viel, lässt aber den Rückstand etwas weniger ausfallen.

Der LIano wird kaum mehr Leistung je Core bringen als ein heutiger Regor. Letzterer läuft meist auf DDR2 wobei LIano mal DDR3 im Mainstream zur Verfügung haben dürfte.
Bringt bei Teillast vielleicht noch 10% mehr bei gleichem Takt.
Dazu noch 20% max. höherer Takt per 32nm/ Turbo der netto dann 10-15% Leistungszuwachs bedeutet.

Insgesamt sind also max. 25% zu erwarten vs. aktuellen Regor-Designs solange nicht 3-4 Cores auch ausgelastet werden per LIano.

Bei 'Bulldozer & GPU' dürfte etwa Performance Sandy Bridge zu erwarten sein.
Es scheint fast so als sei 'Sandy Bridge' von Intel als Direktkonkurrent dazu von Intel entworfen worden. Und AMD bringt doch nur 2011 den LIano raus.

Wobei 4 Cores beim Desktop interessant sind. Im Mobilbereich erscheint die ganze Aufrüstung bei CPU-Cores aber steigend unsinnig. Mir erscheint Dual-Core Bulldozer/ Westmere doch marktgängiger und natürlich auch sparsamer.

Opteron · 17.02.2010

Ragas schrieb:
wenn man maximale Leistung will sollte möglichst immer nur ein Fpu-intensiver Prozess auf einem Cluster arbeiten. Damit könnte man 4 Cores ohne Nachteile voll Auslasten und die anderen 4 sollten dann möglichst ohne FPU Zugriffe auskommen.

Problem ist hierbei eigentlich, ob das OS darüber Bescheid weiß und das so ausbalancieren kann, oder ob die Prozesse einfach zufällig angeordnet werden und dadurch mehr Kollisionen entstehen als notwendig wären.

Naja, Windows kommt mittlerweile ja schon ganz gut mit Intels Hyperthreading klar. Wenn AMD die 2ten Intel Cluster als SMT Cores anmeldet, dann sollte der Win Scheduler automatisch erst einmal nur 4 Kerne auslasten (wobei dann jeder seine eigene FPU hat), und der Turbo Modus dann hochtakten.
Klappt eigentlich jetzt schon ganz gut, da sehe ich deshalb keine Probleme.

Twodee schrieb:
Ist das Verhältnis 1x 128-bit VS. 2x 128-bit FMAC echt 1:4 (bezogen auf je Kern oder doch CPU ?)

Naja .. ist halt ne Milchmädchenrechnung, die höchstens im allerbesten Idealfall taugt. Wg. FMAC sollte der Bulldozer - bei angenommenen zwei 128bit Pipes - halt in einem Rutsch vier (*) 128bit µOps verarbeiten, zwei 128b Add und zwei 128b Mul. Eine 128b K10 Pipeline braucht da 4 Durchgänge.

Btw. eine andere allg Frage: Welcher Bolldozer ist mit welcher Sandy Bridge zu vergleichen? [bezogen auf Kerne/Module/HT]

Na das kann man doch jetzt noch nicht sagen, da nichts 100%ig bekannt ist.
Vermutlich hat AMD das so geplant, dass der 8 Kerne / 4 Modul Bulldozer schneller wird, und die 2/4er Version langsamer. Aber ob Intel AMD den Gefallen tut, muss sich erst noch herausstellen

Im schlechtesten Fall dürfte HyperThr. gar nichts mehr bringen, da die FPU von einem HT-Core komplett ausgelastet sein sein sollte.

Doch, selbst im schlechtesten Fall ist da immernoch was drin. Kannst Du Dich noch an Neros Versuche mit HTh beim P4 erinnern ? Das lief bei einer FPU BOINC Applikation trotzdem 30% schneller (also schneller im Sinne von mehr Durchsatz), Grund sind die Speicherlatenzen, die immer auftreten. Deswegen hat IBM und ~~Sun~~ Oracle doch sogar 4- oder sogar 8fach SMT. In den ~50++ Takten die die FPU auf Ladevorgänge aus dem RAM warten, kann ein zweiter Thread viel berechnen. Selbst bei den 4 Takten L1 Wartezeit der Nehalems, rutschen dann in 4 Takten ein ganzer Schwung µOps des 2ten Threads in die FPU Pipelines rein, die ansonsten leer wäre .. das rentiert sich immer - in jedem Fall, solange man keine brute Force single-Thread Leistung braucht. Aber das ist bei Leuten die 8++Threads auslasten ja nie der Fall.

ciao

Alex

(*) 4 µOps nach K10 Dekodierart, die Bulldozer Dec. werden 2 128b FMAC Instruktionen wohl nur in 2 MacroOps dekodieren.

gruffi · 17.02.2010

Twodee schrieb:
Ich nahm an [zumindest wurde das hier im Thread erwähnt], das beim BullDozer sich je zwei Int-Kerne/Cores (wie auch immer) eine FPU teilen müßten.

Ja, aber wie du sehen kannst, so einfach ist die Sache nicht. Dem Umstand war sich AMD natürlich bewusst. In der Präsentation von Chuck Moore beim Analyst Day sagte er zB so viel wie, dass die FPU so stark aufgebohrt wurde, dass sie von einem Kern gar nicht voll ausgelastet werden kann.

Twodee schrieb:
Ist das Verhältnis 1x 128-bit VS. 2x 128-bit FMAC echt 1:4 (bezogen auf je Kern oder doch CPU ?)

Bezogen auf die FPU selbst. 128-bit: 4 (SP FP) * 1 (Ops/Takt) = 4 SP FP Ops pro Takt, 2x 128-bit FMAC: 8 (SP FP) * 2 (Ops/Takt) = 16 SP FP Ops pro Takt. Das Verhältnis ist also 1:4. Vergleichst du es pro Kern ist das Verhältnis immer noch 1:2 zugunsten Bulldozers. Lässt du FMAC erstmal aussen vor, hast du immer noch 128-bit vs 128-bit und somit keinen Nachteil pro Kern. Das eigentlich Interessante ist aber die Arbeitsweise, also wie verarbeiten Decoder und Scheduler FP Instruktionen. Auch hier sollte Bulldozer einige Verbesserungen erhalten.

Twodee schrieb:
Btw. eine andere allg Frage: Welcher Bolldozer ist mit welcher Sandy Bridge zu vergleichen?

Da noch nicht mal klar ist, was es alles für Sandy Bridge CPUs geben wird, bisher weiss man offiziell ja nur etwas von einem 4-Kern Modell mit IGP, ist das eine ziemlich theoretische Frage. Meine Prognose ist, ein Bulldozer Modul wird von der Grösse her mit einem Sandy Bridge Kern vergleichbar sein, dabei aber mindestens 1,5 mal so viel Durchsatz liefern.

Duplex schrieb:
Liano in 32nm sollte vielleicht 20% mehr Leistung als die aktuellen vergleichbaren 45nm K10.5 haben.

Mit so viel würde ich ehrlich gesagt nicht rechnen. Auch wenn sich die Optimierungen doch etwas tiefgreifender und interessant anhören, rechne eher mit 5%, maximal vielleicht 10%. Llano mit 4 Kernen wird mit Sandy Bridge mit 4 Kernen rein von der CPU-Performance sicherlich nicht mithalten können. Aber dagegen wird er ja auch nicht direkt positioniert. Ich sehe ihn eher als Gegenspieler zu einem 2-Kerner mit Hyperthreading, also ähnlich wie momentan Propus vs Clarkdale. Sozusagen 4 Threads vs 4 Threads. Intel setzt momentan halt auf hohen Takt und SMT, AMD dagegen auf kompaktere und dafür mehr Kerne. Was einem lieber ist, kann sich jeder selbst aussuchen.

Ge0rgy · 18.02.2010

Wenn BD außerdem, wie auf einigen vorigen Seiten zusammenspekuliert, ein Hochtakt-Design ist, zumindest auf die INT-Cores bezogen, dürfte es Durchsatz wirklich satt geben.
Wobei die Konstruktion dahingehend lustig ist, dass zwei relativ "schmale" Int-Teile, sich eine Dicke FPU teilen, man hat bei der FPU also eher an der Qualität statt quantität gedreht, bei INT umgekehrt.

Man darf aber nicht vergessen dass mind. 80% int-Code ist.
Selbst bei durchoptimierter HPC-Software dürfte sich noch die eine oder andere Int-Instruktion daruntermischen, schließlich legt kaum irgendwer einen Schleifenzähler als Fließkomma-Wert aus (lässt der Compiler das überhaupt zu? *noahnung*

) und es lässt sich auch nicht zwangsläufig alles Vektorisieren.
d.h. absolut 100% FPU-Last und 0 Int dürfte quasi nicht vorkommen.
Zumal auch bei Weitem nicht jede FPU-Operation gleich 256-Bittig wird etc...
Also sollte man davon ausgehen bei extrem hoher Last dürfte der BD-Durchsatz durch den "Stau" evtl. ein kleinbisschen nachgeben, aber eher wenig dramatisch. Dafür arbeitet man wesentlich effizienter in Sachen Strom, Transistoranzahl & -fläche als wenn man 2 dicke FPUs dranlötet die in der Mehrheit der Fälle Däumchen drehen...

Hardwaretechnisch wird BD ein interessantes Konzept, da bin ich sicher. Ich mache mir eher Sorgen um die SW... GCC soll ja schon ein paar defines für AVX u.a. mit FMA bekommen haben, aber wie gut das am Ende wirklich funktioniert & BD-Optimierten Code erzeugt, wird sich zeigen müssen...

Grüßchen
ich

Ragas · 18.02.2010

Ge0rgy schrieb:
Schließlich legt kaum irgendwer einen Schleifenzähler als Fließkomma-Wert aus (lässt der Compiler das überhaupt zu? )

Na aber sicher, wenn du willst kannst du auch mit Objekten zählen .... oder mit exeptions (hat ein Kumpel (Mathematiker) an der Uni mal gebracht) *lol*

Ge0rgy schrieb:
Hardwaretechnisch wird BD ein interessantes Konzept, da bin ich sicher. Ich mache mir eher Sorgen um die SW... GCC soll ja schon ein paar defines für AVX u.a. mit FMA bekommen haben, aber wie gut das am Ende wirklich funktioniert & BD-Optimierten Code erzeugt, wird sich zeigen müssen...

Sollte auch kein Problem sein, gcc hat bis jetzt auch jedes instruction-set unterstützt. und im Zweifelsfall können die sich ein bisschen Code von AMDs freien Compiler kopieren.

Green_Ranger · 18.02.2010

Ragas schrieb:
Na aber sicher, wenn du willst kannst du auch mit Objekten zählen .... oder mit exeptions (hat ein Kumpel (Mathematiker) an der Uni mal gebracht)

Mit Exceptions zählen?
Ne Number Format Exception oder ne Index Out of Bounce Exception ist ja schnell generiert, der wahre Profi arbeitet mit wichtigen Datenbanken und SQL-Exceptions, diese exquisite Art zu programmieren sollte ich mir mal angewöhnen. Aber ich glaube, dass ich gesteinigt werden würde oder gar schlimmeres falls ich so etwas tun sollte.... *lol*

gruffi · 18.02.2010

Ragas schrieb:
Na aber sicher, wenn du willst kannst du auch mit Objekten zählen ....

Also zumindest C und C++ erlauben das nicht. Dort muss die Zählvariable einer for-Schleife einen ordinalen Typ haben. Schleifen wie do/while ohne konkrete Zählvariable erlauben natürlich auch mehr.

Twodee · 18.02.2010

Code:

class MyObject {
public:
    int MyID;
    MyObject *Next;
    
    MyObject(int ID) {
        MyID = ID;
        Next = NULL;
    };
    ~MyObject() {
        if (Next)
            delete (Next);
    };
};

void Test_MyObject() {

    int ID = 0;
    MyObject *First = new MyObject(ID++);

    MyObject *SubObject = First;
    while (ID != 10) {
        SubObject->Next = new MyObject(ID++);
        SubObject = SubObject->Next;
    };

    long ADD = 0;
   [B] for (MyObject *laufObj = First; laufObj!= NULL; laufObj=laufObj->Next) [/B]
        ADD += laufObj->MyID;
    

    delete (First);
};

Der MS-Compiler hat mit dieser For-Schleife kein Problem *chatt*

GHad · 19.02.2010

Geht auch in Java wunderbar... Muss mir nur noch ne Anwendung dafür einfallen. Auf jeden Fall eine coole Idee so zu coden, vielleicht mal beim Listen-Iterieren nächstes Mal dran denken:

Code:

	static class MyObject {
		
		private MyObject next = null;
		private final int id;
		
		public MyObject(int id) {
			this.id = id;
		}
		
		public int getId() {
			return id;
		}

		public MyObject next() {
			return next;
		}
		
		public MyObject next(MyObject next) {
			this.next = next;
			return next;
		}
		
		@Override
		protected void finalize() throws Throwable {
			if (next != null) {
				next = null;
			}
			super.finalize();
		}
		
	}
	
	public static void main(String[] args) {
		int max = 10;
		
		int i = 0;
		MyObject first = new MyObject(i++);
		
		for(MyObject filler = first; i < max; filler = filler.next(new MyObject(i++)));
		
		int adder = 0;		
		for(MyObject runner = first; runner != null; runner = runner.next()) {
			adder += runner.getId();
		}
		
		System.out.println(adder);
		first = null;
	}

Greetz,
GHad

gruffi · 19.02.2010

Twodee schrieb:
Der MS-Compiler hat mit dieser For-Schleife kein Problem

Nun ja, behauptet ja auch niemand, dass der MSC standardkonform wäre.

Zumal du hier einen Zeiger verwendest, der im Grunde auch ordinal ist. Ist halt nichts anderes als eine Speicheradresse.

Nee, ist schon richtig. Ein kurzer Aussetzer meinerseits. For-Schleifen sind in C und C++ weniger strikt und erlauben im Grunde alles Zulässige für Initialisierung, Abbruchbedingung und Ausdruck nach jedem Durchlauf, also auch Gleitkommawerte. Die switch-Anweisung war diejenige, welche nur ordinale Werte zulässt, also ganzzahlig oder Enumeration. Ist aber halt keine Schleife.

BavarianRealist · 20.02.2010

interessante Diskussion auf Semiaccurate: http://www.semiaccurate.com/forums/showthread.php?t=1226&page=32

Hier von JF-AMD zu Magny-Cours: http://www.semiaccurate.com/forums/showpost.php?p=28060&postcount=320

"...Yes, there will be new features and some core tweaks that will make the clock to clock performance higher than Istanbul. ..."

Damit gehe ich davon aus, dass vermutlich Deneb komplett durch Thuban/Zosma ersetzt werden dürfte. Dabei wird vermutlich Zosma aus teildefekten Thubans gewonnen und vermutlich nur in wenigen Varianten mit möglichst hohen Takten angeboten. Später dürfte AMD dann die günstigeren Desktop-Quads nur noch aus den billigeren Propus-Dice gewinnen, deren Takte man dann vemutlich endlich nach oben ziehen wird, womöglich wird man dann sogar auch 125Watt-Versionen von Propus anbieten, die bis dahin wohl locker 3,6Ghz machen sollten (da weniger Last ohne L3).

Und weiter von JF-AMD zu Mangy-Cours: http://www.semiaccurate.com/forums/showpost.php?p=28040&postcount=316

"...You'll see the benchmarks at launch, we don't release things early. We are in production and have been, it was right on target, possibly a day early..."

Duplex · 20.02.2010

10% mehr Lesistung durch höher getaktete Quad Cores bningen aber nicht mehr Umsatz.
Der X4 965 reicht für die K10 Genration als Top Model vollkommen aus.

kleine Leistungssprünge von 30% bei K10 gibt es nur mit 6 Core

BavarianRealist · 20.02.2010

Duplex schrieb:
10% mehr Lesistung durch höher getaktete Quad Cores bningen aber nicht mehr Umsatz...

Aber viel niedrigere Kosten für AMD, denn der Propus-Quadcore hat ein viel kleineres Die (169mm²) als der Deneb (258mm²), da er auf den großen 6MB-L3 verzichtet. Das kostet zwar Performance, aber wer Performance will, kann zum dann wohl noch teureren Zosma oder Thuban greifen.

gruffi · 20.02.2010

Also ich muss sagen, dass ich grosse shared Caches mehr und mehr für wenig sinnvoll im Mainstream Markt halte. Propus ist schon ein feines Stück Silizium. Die 5%, die ihm vielleicht auf den Phenom bei gleicher Taktrate fehlen, sind vernachlässigbar. Und das ohne jeglichen L3. Dafür spart man aber 1/3 der Fläche. Und für diese kann man lieber den einen oder anderen Kern mehr aufs Die packen. Die bringen bei entsprechendem Software Support weit mehr. Ich bin mal gespannt, ob AMD ein Bulldozer Design ohne L3 plant. Ein Bulldozer Quad ohne L3 und für den Client Markt unnötigen Interconnects dürfte extrem klein und preiswert zu produzieren sein, wäre aber wohl trotzdem um einiges performanter als ein Phenom II. Praktisch perfekt für Mainstream und hohe Absatzzahlen. Und mit 2x 2 MiB L2 wäre trotzdem noch mehr als ausreichend Cache vorhanden.

Opteron · 21.02.2010

gruffi schrieb:
Dafür spart man aber 1/3 der Fläche. Und für diese kann man lieber den einen oder anderen Kern mehr aufs Die packen

Oder ne GPU

gruffi schrieb:
Und mit 2x 2 MiB L2 wäre trotzdem noch mehr als ausreichend Cache vorhanden.

Jo das stimmt allerdings, die 2x2 würden sicher dicke reichen.
Aber ob ein extra "Bulldozer Propus" kommt ist fraglich, eher gleich ein Bulldozer Fusion in einem Jahr.

Twodee · 21.02.2010

gruffi schrieb:
Also ich muss sagen, dass ich grosse shared Caches mehr und mehr für wenig sinnvoll im Mainstream Markt halte. Propus ist schon ein feines Stück Silizium. Die 5%, die ihm vielleicht auf den Phenom bei gleicher Taktrate fehlen, sind vernachlässigbar. Und das ohne jeglichen L3. Dafür spart man aber 1/3 der Fläche. Und für diese kann man lieber den einen oder anderen Kern mehr aufs Die packen. Die bringen bei entsprechendem Software Support weit mehr. Ich bin mal gespannt, ob AMD ein Bulldozer Design ohne L3 plant. Ein Bulldozer Quad ohne L3 und für den Client Markt unnötigen Interconnects dürfte extrem klein und preiswert zu produzieren sein, wäre aber wohl trotzdem um einiges performanter als ein Phenom II. Praktisch perfekt für Mainstream und hohe Absatzzahlen. Und mit 2x 2 MiB L2 wäre trotzdem noch mehr als ausreichend Cache vorhanden.

Bei Thg gibts einen Vergleich beider Typen. Dabei ist der Abstand meistens sogar geringer als 5%, jedoch gibt es auch ein paar Ausnahmen, welche immer Speicher+Rechenintensiv sind: WinRar 15%, PCMark-Mem: 11%, AES-Encrypt. 10% und das Game Left4Dead mit 17%

rkinet · 21.02.2010

BavarianRealist schrieb:
Damit gehe ich davon aus, dass vermutlich Deneb komplett durch Thuban/Zosma ersetzt werden dürfte. Dabei wird vermutlich Zosma aus teildefekten Thubans gewonnen und vermutlich nur in wenigen Varianten mit möglichst hohen Takten angeboten.
Später dürfte AMD dann die günstigeren Desktop-Quads nur noch aus den billigeren Propus-Dice gewinnen, deren Takte man dann vemutlich endlich nach oben ziehen wird, womöglich wird man dann sogar auch 125Watt-Versionen von Propus anbieten, die bis dahin wohl locker 3,6Ghz machen sollten (da weniger Last ohne L3).

Es würde eher Sinn ergeben wenn Propos und Champlain (mobil Quad) das gleiche DIE und nur andere Selektion bedeuten würden.

Das wäre dann eher 45-65 Watt Desktop-Quad mit Taktraten <<3 GHz.
Jedes Watt weniger im Mobilbereich ist bares Geld für AMD. Dafür dann einen 3 GHz Quasi-'Propos' aus einem Thuban zu selektieren kosten AMD kaum was.
Und je mehr Thuban-DIEs in Dreden gefertigt werden desto höher der max.Takt aus Selektionen.

Wie schon Analysten bei AMD anmerkten können Thin Clients interessant werden als Absatzmarkt. Und hier einen 45 Watt Champlain/Propos Trible-Core gegen den Clarkdale und Penryn zu positionieren wäre ideal da voll in deren Perfomancebereich gelegen.
Alles Andere könnten Weiterproduktion des Deneb und natürlich der Thuban erledigen.

Wobei aktuell lt. http://www.computerbase.de/news/har...0/februar/zwoelf_prozessoren_amd_c3-stepping/ - erst mal Stepping C3 bei Propos/Rena und Regor kommt. Da man Verfügbarkeit bis Anfang 2011 locker jetzt ansetzen.
AMD bleibt bei 45 Watt oder 95 Watt Modelreihen

LehmannSaW · 22.02.2010

och.. Leute!
Rana heißt der Stern (Stars-Plattform) und nicht Rena. 8-(

http://de.wikipedia.org/wiki/Rana_(Stern)

Gruß Lehmann

Lynxeye · 22.02.2010

rkinet schrieb:
Wie schon Analysten bei AMD anmerkten können Thin Clients interessant werden als Absatzmarkt. Und hier einen 45 Watt Champlain/Propos Trible-Core gegen den Clarkdale und Penryn zu positionieren wäre ideal da voll in deren Perfomancebereich gelegen.

Ich wüsste nicht, wofür ein ThinClient nen TripleCore benötigt. Wenn man das mit den aktuellen Thins vergleicht, dürfte ein 2x1,2GHz Prozzi gekoppelt mit nem halbwegs aktuellen Chipsatz dick reichen, um die gesamte Konkurrenz hinter sich zu lassen. ThinClients haben keine hohe Rechenlast, dort kommt es einzig und allein auf niedrigen Stromverbrauch und Zeitgemäße Ein- und Ausgänge (Netzwerk, Display, Eingabegeräte) an. 45W CPUs sind dort schon viel zu stark, da diese sich nicht mehr passiv kühlen lassen. So sieht jedenfalls die Realität bei mir auf Arbeit aus.

Was kommt (nach den ersten Deneb (K10.5+)) fuer den Desktop bis zum Launch der BD(APUs)?

Grand Admiral Special

Lord of the Stats, Special, ,

Fleet Captain Special

Lord of the Stats, Special, ,

Fleet Captain Special

Admiral Special

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Grand Admiral Special

Grand Admiral Special

Grand Admiral Special

Fleet Captain Special

Grand Admiral Special

Lord of the Stats, Special, ,

Fleet Captain Special

Grand Admiral Special

Grand Admiral Special

Admiral Special

Grand Admiral Special

Grand Admiral Special

Redaktion☆☆☆☆☆☆

Lord of the Stats, Special, ,

Grand Admiral Special

Vice Admiral Special

Admiral Special

Ähnliche Themen

Redaktion
☆☆☆☆☆☆

Redaktion
☆☆☆☆☆☆