wird AMD den leistungsunterschied von Intels neuen Cpus aufholen? [Archiv]

Gast

2006-03-12, 15:24:00

Ich wäre dafür den Thread offen zu lassen, stattdessen aber ins Spekulationsforum zu schieben. Hat schließlich nichts mit "AMD" ODER "Intel" Threads zu tun, sondern mit beiden auf einmal!

Ob AMD den Vorsprung aufholen können wird, ist im moment schwer zu sagen.
Ich gehe davon aus, das Intel mit dem Conroe längere Zeit das beste Produkt auf dem Markt haben wird, vorallendingen deshalb, da der Conroe schon in 65nm gefertigt wird und daher seine Taktreserven wohl noch nicht voll ausgeschöpft sind.

Bei AMD kommen erstmal nur 2,8 GHz (evtl. 3 GHz) + DDR2. Alles in allem, sollten etwa 10-15% Mehrleistung drin sein beim 3 GHz Produkt, verglichen mit dem vor kurzem veröffentlichten Conroe Benchmarks.

Das ist aber immer noch zu wenig, ich gehe von bis zu 30% Performancevorsprung des Conroes aus, verglichen mit 2,8 GHz/DDR400 auf AMD Seite.

Danach hängt es davon ab, wie es weiter geht. Eventuell dreht Intel noch weiter an der Taktschraube oder wird den Conroe erstmal längere Zeit auf dem Niveau lassen.
Viel Zeit dafür haben sie jedoch nicht, denn Anfang 2007 soll es dann auch von AMD 65nm geben und mit mehr L2 oder gar L3 Cache sollten nochmal bis zu 5% Mehrleistung bei gleicher Taktrate möglich sein. Zudem lassen sich die Taktraten weiter erhöhen.

Ich schätze die Lage mal so sein:
Bis Conroe-Veröffentlichtung: AMD - 2,8 GHz DC.
Conroe-Veröffentlichtung - Anfang 2007: Conroe 2,67-3,33 GHz DC
Q1 2007 - Q3 2007: AMD bis auf 10% an Intel dran (65nm bei AMD)
Q3 2007 - Q4 2007: Intel wieder vorne (45nm)

Danach ist es unklar, vielleicht wird dann mehr an der Technik geschraubt, so das größere Performancevorsprünge möglich sind.

Gast

2006-03-12, 15:31:46

Was noch angeführt werden kann, ist die Tatsache, das AMD CPUs bei mehreren Cores wahrscheinlich etwas besser skalieren werden, als bei Intel.

Das dürfte besonders bei Quad oder Octa-Core Prozessoren zum tragen kommen.

hans_wurst

2006-03-12, 15:57:33

Jo ihr habt recht, AMD geht Pleite. Intel zieht auf und davon. Oh backe :ulol5:

Biete Thread schließen, ich kann diesen Mist echt nicht mehr sehen :crazy: :crazy: :crazy:

Gast

2006-03-12, 16:00:00

Kannst du vielleicht mal vernünftig argumentieren und sachlich bleiben?

Genau solche Postings, die nichts zum Thema beitragen, führen dazu, das solche Threads geschlossen werden oder in einem Flamewar ausarten. :down:

Coda

2006-03-12, 16:03:15

Was noch angeführt werden kann, ist die Tatsache, das AMD CPUs bei mehreren Cores wahrscheinlich etwas besser skalieren werden, als bei Intel.Wieso das denn?

Gast

2006-03-12, 16:07:03

Wieso das denn?

Ich bin kein CPU Guru, jedoch wird wohl der FSB ein Faktor sein, der bei mehreren Cores zum tragen kommt.

Bei DualCore Prozessoren sehe ich das nicht als Problem, denn selbst aktuelle 800er P4s skalieren recht gut.

Allerdings ist das so eine Sache... Intel kann den FSB noch deutlich erhöhen, wie weit, das wissen wir nicht. Bei heutigen Overclocking-Rekorden wurden soweit ich weiß, schonmal über 500 MHz FSB erreicht, das sollte also die nächsten paare Jahre wohl noch nicht zum Problem werden...

BlackBirdSR

2006-03-12, 16:07:06

Wieso das denn?

Vielleicht geht er davon aus, dass Intel per Quad und Multicore-CPUs eher auf mehrere DIEs pro Träger setzt und über den FSB kommunizieren lässt.
Da hätte AMD dann wieder Vorteile.

Allerdings habe ich keine Ahnung, wie Intel das nun macht.
Selbst in diesem Fall wird man wohl die DIEs untereinander direkt verbinden.

Neomi

2006-03-12, 17:03:22

reunion

2006-03-12, 17:25:13

Avalox

2006-03-12, 17:39:41

Na ich weiss nicht. AMD feiert zwar Erfolge im Home- und Desktop Bereich. Aber AMDs Zielmarkt ist das eigentlich nicht mehr.

Wenn ich mir den fetten Retention Frame des AM2 ansehe, dann denke ich zu verstehen, wie AMD weiterhin in der Homeperformance punkten will.

BlackBirdSR

2006-03-12, 18:37:46

AMD bringt mit dem 65nm-Prozess Anfang 2007 angeblich den K8L, also einen stark überarbeiteten K8, welcher vorallem in punkto FP-Performance neue Maßstäbe setzten soll. Also nicht bloß mehr L2/L3-Cache. Könnte durchaus sein, dass sich hier das Blatt schon wieder wendet.

Dabei muss man aber bedenken, dass Conroe nicht durch seine überlegene FP-Performance vorne liegt in diesen Benchmarks von der IDF.

Wenn überhaupt, wurde die SIMD Performance maßgeblich gesteigert. Und wir wissen ja, wie unglaublich stark alle Spiele und Programme auf SSE/2 optimiert sind :wink:
Das trifft schon eher auf Encoding/Decoding und so Zeugs zu. Da lässt sich durch ein paar Anpassungen bestimmt auch noch Performance rausholen.

Der Punkt ist: Stärkere FP-Leistung würde dem K8 hier auch nicht helfen.
Der große Bonus von Conroe ist die Art und Weise, wie er dafür sorgt genug Arbeit zu haben.

svenw

2006-03-12, 18:46:37

Grmbl, ich finds nicht mehr. Heise hatte eine Meldung das AMD eine Speichertechnik gekauft hat, die bei ihrem Prozeß (SOI) die Größe einer Speicherstelle radikal verkleinert. Somit könnte sie bald mit wesentlich größeren Caches arbeiten, was allerdings auf Kosten der TDP gehen dürfte oder mit wesentlich kleineren Chips, was auch kürzere Signalwege und günstigere Preise nach sich zieht. Das ganze könnte vor allem im Server bereich wo Monster Caches die Regel sind einges bringen.

ha, doch noch gefunden AMD kauft Fertigungstechnologie (http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/68588&words=SOI)

BlackBirdSR

2006-03-12, 19:05:39

Grmbl, ich finds nicht mehr. Heise hatte eine Meldung das AMD eine Speichertechnik gekauft hat, die bei ihrem Prozeß (SOI) die Größe einer Speicherstelle radikal verkleinert. Somit könnte sie bald mit wesentlich größeren Cahes arbeiten, was allerdings auf Kosten der TDP gehen dürfte oder mit wesentlich kleineren Chips, was auch kürzere Sinalwege und günstigere Preise nach sich zieht. Das ganze könnte vor allem im Server bereich wo Monster Caches die Regel sind einges bringen.

ha, doch noch gefunden AMD kauft Fertigungstechnologie (http://www.heise.de/newsticker/result.xhtml?url=/newsticker/meldung/68588&words=SOI)

Ich hab die PDF gerade nicht zur Hand.
Aber Intel gibt für den Montecito (Itanium) an, dass die 24MB L3-Cache 5W verbrauchen (könnten auch 10W sein)
Keine Ahnung wieviel AMDs Technik dann brauchen wird. Aber man kann sich ja ein paar Anhaltspunkte holen.

Avalox

2006-03-12, 19:11:38

Ist etwas OT, aber ist denn eigentlich mal was von Fred Weber zu hören gewesen? Der AMD Chef Entwickler, welcher ja die Hammer Architektur vorangetrieben hat, hat doch irgendwann Mitte letzten Jahres AMD verlassen.

svenw

2006-03-12, 19:13:11

Ich hab die PDF gerade nicht zur Hand.
Aber Intel gibt für den Montecito (Itanium) an, dass die 24MB L3-Cache 5W verbrauchen (könnten auch 10W sein)
Wenn das wirklich so wenig wäre und AMD die Technik komplett ausnutzt könnten sie beim Wechsel auf 65nm bis zu 10MB pro Kern bei ungefähr gleicher Die-Fläche anbieten. Das wäre schon ein Kick, ich bezweifele aber, das sie die Technik so schnell integrieren können. Andererseits, wenn sie jetzt schon L3 Caches auf der Roadmap haben....

Gast

2006-03-12, 19:44:10

Wenn ich mir Benchmarks ansehe, brachte die Steigerung von 1 MB auf 2 MB Cache gerade mal 1-3% Performance.
Bei 2 auf 4 MB oder gar von 4 auf 8 MB usw. pro Core würde der Unterschied wohl noch geringer ausfallen.

Damit solche großen Caches Sinn machen, müsste wohl erstmal die Funktionsweise geändert werden, so das der größere Cache auch voll ausgenutzt werden kann.
So weit scheint man noch nicht zu sein, wenn man jetzt schon 16+ MB verbauen kann, dies jedoch aufgrund der nutzlosigkeit bei Desktopprozessoren noch nicht tut.

Gast

2006-03-13, 14:11:22

Abgesehen von Fear bewegt sich alles in der Vergleichstabelle im Rahmen der Speicherperformance. Mit dem Sockel AM2 wird sich zumindest dieser Punkt wieder ausgleichen (sogar mehr als das, wenn man bei AMD dann DDR2 800 einsetzt). Wie die anderen Benches darauf reagieren werden, weiß ich mangels Kenntnis der jeweiligen Flaschenhälse nicht.

Kurz: abwarten. Der Gegner für den Conroe wird der AM2 A64 sein, nicht der S939 A64. Intel wird wohl ein wenig besser dastehen, aber so groß wird der Abstand dann auch wieder nicht sein.

Glaubst du das wirklich ? Also eine durchschnittlicher Vorsprung von 20% ist sicher nicht auf die Speicherperformance zurückzuführen. Tomshardware hat gezeigt wie der AM2 mit 533 DDR2 läuft -> langsamer als S939 bit DDR400, DDR2 800 wird nur marginal schneller sein, sicher aber nicht im Rahmen von 20%. Man sollte schon mal jemandem Respekt zollen, wenn ihm Respekt gebührt ;)
Conroe wird mMn AMD den Rang ablaufen, und das eine ganze Weile .... sofern der Preis stimmt; und Intel lässt sich den technologischen Vorteil sicher mind. 1:1 in barer Münze bezahlen. Danach wird sich die Fraktion der Spieler wohl in AMD Fetischisten und Performance Fetischisten unterteilen..

Hansea7

2006-03-13, 20:16:05

DDRII 800? Warum nicht gleich DDRII 1066!? ;)

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1142119062

Neomi

2006-03-13, 20:21:41

Glaubst du das wirklich ? Also eine durchschnittlicher Vorsprung von 20% ist sicher nicht auf die Speicherperformance zurückzuführen. Tomshardware hat gezeigt wie der AM2 mit 533 DDR2 läuft -> langsamer als S939 bit DDR400, DDR2 800 wird nur marginal schneller sein, sicher aber nicht im Rahmen von 20%. Man sollte schon mal jemandem Respekt zollen, wenn ihm Respekt gebührt ;)

Habe ich irgendwo angedeutet, daß ich glaube, AMD würde komplett aufschließen? Das glaube ich nicht, Tim. Ich habe nur gesagt, daß der AM2 A64 der Gegner für den Conroe sein wird und daß der Unterschied nicht so groß sein wird, wie es jetzt aussieht.

Und wo du schon von Toms Hardware Guide redest, dann schau dir doch mal die Benchmarks genau an. Aber nicht nur schauen, sondern auch richtig interpretieren. Sogar im Speicherbenchmark verliert der A64 mit DDR2 gegen niedriger getakteten DDR SDRAM. Das heißt für mich eindeutig, daß es da noch ein Problem mit dem Speichercontroller gibt, was so lange vor der Markteinführung nicht sonderlich schlimm ist. Hier tritt AMDs allererste CPU mit DDR2-Unterstützung lange vor dem Markteintritt gegen eine CPU mit ausgereifter Unterstützung für DDR 400 an. Intel dagegen hat schon einige Erfahrung mit DDR2, und die wird AMD auch noch erlangen. Ich sage nicht, daß AMD den Vorsprung von Intel einholen oder sogar Intel überholen kann, aber schrumpfen wird er sicherlich, sobald AMD das DDR2-Problem in den Griff bekommt.

Conroe wird mMn AMD den Rang ablaufen, und das eine ganze Weile .... sofern der Preis stimmt; und Intel lässt sich den technologischen Vorteil sicher mind. 1:1 in barer Münze bezahlen. Danach wird sich die Fraktion der Spieler wohl in AMD Fetischisten und Performance Fetischisten unterteilen..

Es gibt wesentlich mehr als nur Fetischisten.

Spasstiger

2006-03-13, 20:41:16

DDRII 800? Warum nicht gleich DDRII 1066!? ;)

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1142119062
Wie soll denn das funktionieren, wenn die CPUs auf einen Ref.-Takt von 200 MHz abgestimmt sind?
Denn z.B. 3 GHz/533 MHz = 5,63 => Speicherteiler 6 => 3 GHz/6 = 500 MHz Speichertakt (DDRII-1000).

Gmax

2006-03-20, 14:08:28

Ein weiterer ddr2 800 Bench ist hier (http://www.hkepc.com/hwdb/am2-4800-7.htm) zu finden.

Gast

2006-03-20, 14:23:57

Undertaker

2006-03-20, 14:43:53

Wenn das stimmt, dann gute Nacht AMD!

So geringe Vorteile trotz DDR2/800 und hier sieht man sogar im Gegensatz zu THG, das AM2 teilweise etwas besser ist.

Nur: Es wurde hier lediglich mit DDR400 verglichen, aber mittlerweile gibts schon recht günstige DDR500 Module.
Für Poweruser sogar 2x1 GB DDR550 und da wäre selbst DDR2/800 weit abgeschlagen, z.B. bei Sandra Memory Bench: Über 7000 MB/s...

ist das nicht der beste beweis dafür, das der ram gar nicht auf ddr2-800 sondern nur ddr2-400 lief...? zumindest die memorybandwith bei sandra MUSS auch mit schlechten timings vom doppelten speichertakt nahezu linear profitieren... und damit sind auch alle anderen benches in den bisherigen tests witzlos...

Gast

2006-03-20, 14:50:02

Die Memory Bandwith müsste höher sein - ja, aber dennoch hat AM2 hier und da seine Vorteile, also an ein zu niedriges getaktetes Modul sollte es nicht liegen (DDR2/400 @ 5-5-5-15 würde ich klar ausschließen, dafür sind die Vorteile einfach zu "groß" bei diesen Timings). Denn DDR2/400 müsste @ CL5 müsste langsamer sein, als DDR400 @ CL2,5, ist es hier aber nicht.

Also entweder stimmen die Ergebnisse, dann ist der neue A64 sehr Latenzabhängig oder irgendwas ist noch nicht optimiert genug.
Wobei: in 2,5 Monaten soll der Launch sein, da sollte sich langsam mal was tun!

LudiKalell

2006-04-10, 16:34:27

Habe ich irgendwo angedeutet, daß ich glaube, AMD würde komplett aufschließen? Das glaube ich nicht, Tim. Ich habe nur gesagt, daß der AM2 A64 der Gegner für den Conroe sein wird und daß der Unterschied nicht so groß sein wird, wie es jetzt aussieht.

Ich heiße Hannes, aber fast richtig.. Gut, dann sagst du das. Schön. Die Zukunft wird's zeigen, aber wer so blind hoffend auf irgendeine Art von für ihn "Naturgesetz" zählt, was da lautet "Es wird immer einen relativen Gleichstand geben"(und das meine ich zwischen den Zeilen zu lesen) der ist mMn einfach nur
a) naiv
b) ein Fanboy der Fraktion die da gerade anscheinend den kürzeren zieht
c) beides

und solche Reaktionen sah man schon oft genug.

Es gibt wesentlich mehr als nur Fetischisten.

Hardcore Spieler sind Fetischisten. Und wenn man NVIDIA und ATi betrachtet offensichtlich auch keine kleine Fraktion unter den Spielern.

Wie auch immer, es gibt noch die Fraktion der Pragmtiker, mit der ist AMD groß geworden: Leute für die nur Leistung bzw Preis/Leistungsverhältnis zählt. Dazu zähle ich mich auch. Für solche Leute war in der Vergangenheit AMD die bessere Wahl. Sie zögern aber auch nicht lange die Plattform zu wechseln. Mal schaun wieviele Fans AMD wirklich hat.

Hier noch ein Artikel zum schmökern:
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2738&p=1

Sicher, nur ein Problem mit dem Speichercontroller.. Frage ist nur, ob der es reißen kann. Den Performanceunterschied zwischen beiden Plattformen nur auf die Speicherperformance zurückzuführen ist lachhaft. Seit wann führt diese denn zu solch enormen Performanceschüben ? Der Unterschied liegt mMn in der Corelogic, und da macht AMD offensichtlich keine großen Sprünge. Gut, es ist mehr ein Bauchgefühl.. (von jemandem der .. sicher wie du auch.. seit Jahren Hardwarebenchmarks verfolgt).. selbst wenn AMD den Speichercontroller besser in den Griff bekommt (anzunehmen), bleibt Conroe um ein gutes, signifikantes Stück vorne. Zmindest solange AMD nicht wirklich an den ALUs rumoperiert.

Aber wir werden ja sehen was die Zukunft bringt.

Gast

2006-04-10, 16:54:04

Welche neuen Intel CPUs?
Ist da etwa das Marketinggeblubber von Intel gemeint, dass einen Prototypen mit einem Produkt vergleicht, deren Markteinführung fast ein Jahr auseinanderliegt?

*gähn*

Tigerchen

2006-04-10, 16:59:46

Tigerchen

2006-04-10, 17:04:02

Wie soll denn das funktionieren, wenn die CPUs auf einen Ref.-Takt von 200 MHz abgestimmt sind?
Denn z.B. 3 GHz/533 MHz = 5,63 => Speicherteiler 6 => 3 GHz/6 = 500 MHz Speichertakt (DDRII-1000).

Man könnte den PC1066 Speicher als PC800 mit besonders niedrigen Latenzen laufen lassen. Wär das nix?

Pinoccio

2006-04-10, 17:17:40

Welche neuen Intel CPUs?
Ist da etwa das Marketinggeblubber von Intel gemeint, dass einen Prototypen mit einem Produkt vergleicht, deren Markteinführung fast ein Jahr auseinanderliegt?:up:

Wenn Intel neue Prozessoren bringt, sollten diese schon schneller sein als die aktuelle Generation, meist war es ja auch so. Und 20% schneller als ein Prozessor, der über deutlich über ein Jahr alt ist ... nach Moore's Law würde man mehr erwarten! ;-)

mfg Sebastian

Botcruscher

2006-04-10, 17:38:29

Gast

2006-04-10, 17:45:39

Ich kanns nicht mehr lesen... Es giebt weder unabhängige, nachvollziehbare Ergebnisse vom neuen Intel, noch vom AM2 aber jeder zerreist sich über geziehlt gestreute Gerüchte die Schnauze.

Im Xtremesystems Forum gibt es unabhängige Benchmarks von einem User! und Anandtech hat seit kurzem unabahängige Benchmarks des AM2 auf der Seite.

Was soll deine Aussage nun:confused:

Botcruscher

2006-04-10, 18:08:08

Im Xtremesystems Forum gibt es unabhängige Benchmarks von einem User! und Anandtech hat seit kurzem unabahängige Benchmarks des AM2 auf der Seite.

Was soll deine Aussage nun:confused:

Ein SuperPI-Wert ist ja auch so aussagekräftig und Werte des Vorserienboards von Antech sind genau so viel wert wie die von T*G, da keiner sagen kann ob der Ram den ordentlich läuft.

Hauptsache es kommt bewegung in den Markt. Seit 2 Jahren hat sich ja fast nichts mehr getan. Aber bis dahin lasse ich die Glaßkugel lieber im Schrank.
Einen Teil des Forums kann man ja schon als Hühnerstall voller Junkies bezeichnen, die kurz davor sind ihr Dope zu bekommen. Wahhhhaaa 20%!!!1111 muhahahahahahahaha.

Gast

2006-04-10, 18:10:01

Im Xtremesystems Forum gibt es unabhängige Benchmarks von einem User! und Anandtech hat seit kurzem unabahängige Benchmarks des AM2 auf der Seite.

Was soll deine Aussage nun:confused:Wenn Intel einen Conroe Prototypen, wovon es noch lange kein Produkt auf dem Markt geben wird, im Vergleich mit der schon seit langem (fast ein Jahr) auf dem Markt kaufbaren Athlon64 X2 Technologie demonstiert, ist die darauf basierende Diskussion ueber die Frage ob "AMD den leistungsunterschied von Intels neuen Cpus aufholen" kann total absurd!

Gast

2006-04-10, 18:32:07

Sorry, man muss aber schon verpeilt sein, wenn man glaubt, das DDR2 mehr als 0-5% bringt.
Denn genau das sagt dieser Test bei anandtech aus. Anwendungen die von Bandbreite profitieren, legen um ein paar Prozente zu, Anwendungen die von der Latenz abhängen, nicht - was logisch nachvollziehbar ist.

Dazu kann ich eure Argumente nicht ganz nachvollziehen.
Der Conroe ist in nicht allzu weiter Ferne, denn ihr müsst das Launchdatum zwischen AM2 und Conroe betrachten, nicht zwischen heute und Conroe!

AM2 -> 6. Juni
Conroe -> Ab Q3. Kann also schon am 1. Tag des Monats darauf sein, spätestens jedoch 15 Wochen danach und ihr wollt mir doch nicht ernsthaft erzählen, das 3-15 Wochen viel später sind:confused:

Dazu kommt:
Leistungsmäßig liegt der AM2 schon vor dem S939 Pendant, die Optimierungen greifen also bereits. Während beim Conroe bereits jetzt gute Ergebnisse zu verzeichnen sind - er kann nur noch schneller werden, nicht langsamer.

Und davon mal abgesehen, ist er auch in anderen Anwendungen als SuperPI verdammt gut:
http://www.xtremesystems.org/forums/showthread.php?t=95021

InsaneDruid

2006-04-10, 18:48:29

Wie soll denn das funktionieren, wenn die CPUs auf einen Ref.-Takt von 200 MHz abgestimmt sind?
Denn z.B. 3 GHz/533 MHz = 5,63 => Speicherteiler 6 => 3 GHz/6 = 500 MHz Speichertakt (DDRII-1000).

zB 3200MHz, Speicherteiler 6, Reftakt 200, Multiplikator 16.

Oder man hebt den Reftakt an, ist doch absolut kein Problem.

Botcruscher

2006-04-10, 18:52:28

Ehrlich mir ist es sowas von egal wieviel AM2 und Conroe am Ende schneller sein könnten. Keine der Platformen ist JETZT im Massenmarkt verfügbar.

Verpeilt sind hier höchstens die Leute welche sich wie ein Hühnchen auf Speed über das bischen Werbung her machen.
Das Conroe nicht schlecht wird dürfte klar sein aber deswegen kann man doch bitte auf dem Teppich bleiben und das Hirn anschalten. Aber nein es geschieht das selbe wie beim Start einer neuen Graka- oder Konsolegeneration. Gigantische Leistung und das baldige Amagedon das PC, ruft es aus jeder Ecke... Alles nur noch eine Frage der Zeit, alle Jahre wieder. :rolleyes:

Gast

2006-04-10, 18:59:39

Ich weiß nicht, aber der einzige der hier "Werbung" betreibt und zwar im negativen Sinne, bist Du.

Es gibt von beiden Plattformen unanabhängige Benches und diese spiegeln bereits wieder, das beide Plattformen an Performance zugelegt haben. Du schriebst oben, das eine Diskussion sinnlos ist, so lange keine Benches da sind, aber die sind doch bereits da! Sie sind bloß noch nicht so umfangreich, wie bisher... aber das spielt doch keine Rolle, wenn jetzt schon abzusehen ist, das es klare Verbesserungen gegeben hat.

Was ist daran so schwer zu glauben? Ich bin mir sogar hunderprozentig sicher, das der Conroe so leistungsfähig sein wird, wie Intel ihn anpreist, das sehe ich allein daran, das bereits aktuelle Architekturen so leistungsfähig sein können, wenn man sie ein wenig außerhalb der Spezifikationen betreibt.
Der Yonah ist das beste Beispiel dafür, er wird unter Wert verkauft... nur mit 2,16 GHz, nur 2 MB Cache, nur FSB667.

Im übertakteten Zustand mit 3+ GHz haut er jede aktuelle CPU weg und das sollte der Conroe mit leichtigkeit ausbauen können.

Bokill

2006-04-10, 19:08:24

Die Frage zum Thread impleziert, dass Sockel AM2 AMD CPUs schlechter als die Konkurrenz sein soll.

Ich hingegen kenne noch keine regulären Benches von Serien CPUs von Intel und AMD.

Das was wir sehen, sind Undergroundmarketing, nicht mehr und nicht weniger.

Im Mai kommen die ersten neuen Turions in Dual Core, im Juni kommen die Sockel AM2 CPUs für den Desktop.

Wann überhaupt die ersten Conroes auf den Ladentheken stehen ist noch nicht klar. Auch Preislisten sind keine Hinweise auf Leistung. Bei Preislisten müssen dann auch die Hochtaktmodelle verfügbar sein. Der Yonah derzeit ist nicht so verfügbar, wie es Preislisten vermitteln wollen ... soll das schlagartig mit dem Conroe anders sein?

Abgesehen davon, wird der Conroe im Jahr 2006 NICHT die Massen CPU sein. Im Jahr 2007 hingegen wird der Massenconroe sicherlich NICHT gegen den K8 in der Revision E vor sich haben, sondern aktuellere Revisionen ... auch deren Leistungsstärke ist noch nicht klar.

In Sachen Verfügbarkeit, Nachfrage und abverkauften CPUs kann AMD sicherlich nicht klagen. Sogar im Sauren Gurken Quartal 2 wird AMD vermutlich der Nachfrage gar nicht Herr. Die aktuelle Konsequenz sieht man. Sogar geringfügige Preiserhöhungen hat AMD für den Desktop mit den Athlon 64, Athlon 64 X2 angekündigt ...

Schwäche und Angst sehen anders aus ...

MFG Bobo(2006)

Gast

2006-04-10, 19:20:30

Die Frage zum Thread impleziert, dass Sockel AM2 AMD CPUs schlechter als die Konkurrenz sein soll.

Nach dem bisherigen Kenntnissstand wird er das auch sein, sofern es keine weiteren grundlegenen technischen Verbesserung gibt.
Davon war von Anfang an bei den ersten AM2-CPUs nie die Rede. Vielleicht ändert sich das 2007, aber das ist schon wieder zu weit vorgegriffen, denn Intel will auch den Conroe bis dahin weiter beschleunigen.

Ich weiß gar nicht, was daran so schwer zu verstehen ist. AMD hatte jahrelang die Nase vorn und das teilweise mit über 10, 20% bei games.
Nun kommt der Conroe und das gleiche Prozedere wird fortgeführt, nur das es sich jetzt um einen anderen Hersteller handelt.
Was ist daran unglaubwürdig? War die letzten Jahre immer so...

Bei Preislisten müssen dann auch die Hochtaktmodelle verfügbar sein.

http://tweakers.net/nieuws/41855/Introductie-Intel-Conroe-in-twee-fases.html

Der Yonah derzeit ist nicht so verfügbar, wie es Preislisten vermitteln wollen ...

Wie meinst du das? Verfügbar ist er, eine Preissenkung soll bald erfolgen.
Falls du meinst, das er im moment teurer ist, als in den Preislisten: Könnte sein, aber das mag daran liegen, das der Yonah kaum "einzelnd" gekauft wird, sondern in Notebooks etc. geliefert wird. Unübliche Lösungen sind halt meist teurer... nur wird der Conroe die Massen ansprechen, daher ist er aus prinzip schon nicht mit den Yonah-Preisen zu vergleichen.

Botcruscher

2006-04-10, 19:32:11

Ich weiß nicht, aber der einzige der hier "Werbung" betreibt und zwar im negativen Sinne, bist Du.

Dann müste ich ja behaupten das er ganz doll schlecht ist. Damit es mal ganz unglaublich wird werfe ich einfach mal 20% in den Raum.

die sind doch bereits da! Sie sind bloß noch nicht so umfangreich, wie bisher... aber das spielt doch keine Rolle, wenn jetzt schon abzusehen ist, das es klare Verbesserungen gegeben hat.

Die paar lächerlichen Werte sagen fast nix aus. Börsenspeckulanten könnten genau so gut das Wetter vorraus sagen. Jeder glaubt etwas zu wissen...

Was ist daran so schwer zu glauben? Ich bin mir sogar hunderprozentig sicher, das der Conroe so leistungsfähig sein wird, wie Intel ihn anpreist, das sehe ich allein daran, das bereits aktuelle Architekturen so leistungsfähig sein können, wenn man sie ein wenig außerhalb der Spezifikationen betreibt.

Hätte, würde, könnte in verbindung mit "hunderprozentig sicher" und dem Wörtchen "glauben". :| Damit hat die Kirche 1000 Jahre lang die Menschen verdummt und die Politiker heute machen es nicht anders.

Glaubt doch an:

- 100% mehr Leistung
- 35 Stundenwoche
- sichere Renten
- "Blühende Landschaften"
- Wirschaftswunder, Vollbeschäftigung, den Osterhasen...

ICH glaube was ICH nachprüfen kann!

Gast

2006-04-10, 19:44:44

Botcrusher, wenn du zu dem Thema nichts zu sagen hast, wieso bleibst du diesem dann nicht fern?

Du kannst glauben was du willst, nur musst du damit rechnen, das wenn du dies öffentlich tust, auch tausend andere Meinungen bekommen wirst.

Ich weiß auch gar nicht, was an meinen Postings so schwer zu verstehen ist. Vielleicht sollte ich sie unformulieren: Ich weiß das der Conroe so leistungsfähig sein wird, wie Intel ihn angepriesen hat.
Ob du das nun glaubst, ist dein Ding, nur solltest du auch mal darüber diskutieren mit Argumenten und nicht mit nichtssagenden Phrasen.

Bokill

2006-04-10, 19:45:41

... Wie meinst du das? Verfügbar ist er, eine Preissenkung soll bald erfolgen.
Falls du meinst, das er im moment teurer ist, als in den Preislisten: Was nutzen Preislisten, wenn die Kunden wochenlang darauf warten müssen.

Preissenkungen fressen dann am durchschnittlichen Verkaufspreis. Denn was Wochen früher zu einem höheren Preis verkauft worden wäre, wurde wegen Nichtexistenz auf den Ladentheken nicht verkauft.

Was bleibt ist der Wochen spätere niedrigere Preis ...

Achtet doch mal auf die Gewinnmargen von Intel die nächsten Quartale. Zugegeben, AMD musste bislang bei jedem Quartalsgewinn eine Kerze in das Fenster stellen. Ich denke, die Wahrheit liegt auf den Ladentisch ... da wird der Marktkampf entschieden. Nicht mit Monate zuvor gebrachten Benches von Vaporware.

Könnte sein, aber das mag daran liegen, das der Yonah kaum "einzelnd" gekauft wird, sondern in Notebooks etc. geliefert wird. Natürlich wird der Yonah so verkauft. Die Frage lautet, wie viel wird von dem Yonah verkauft?

Ich bin mir jedenfalls noch nicht sicher, wie stark die AMD Konkurrenz ausfallen wird. Es ist doch merkwürdig, wenn aus den anfangs so schlechten Speicherbenchmarkwerten zunehmend bessere werden? Die T*G Benchmarks waren derartig absurd niedrig (Speicherbandbreite bei PC 3200 quasi gleich hoch wie PC-2 6400 Benches) mit Sockel AM2 CPUs, dass damit kein Staat zu machen ist. Nein. hier wird mit verdeckten Karten gespielt.

Einen Leistungs-Hinweis bekommt man erst mit den kommenden Turion-Notebooks im neuen Mobilsockel S ... nicht vorher. Und da tritt AMD vermutlich mit einem Single-Channel Speicherinterface an ...

MFG Bobo(2006)

Gast

2006-04-10, 19:57:40

Was nutzen Preislisten, wenn die Kunden wochenlang darauf warten müssen.

:confused:

Wie kommst du jetzt überhaupt darauf?
Die letzten Preissenkungen waren schon Tage vor der offiziellen Bekanntmachung umgesetzt bei einigen Händlern.

Da du vom Yonah geredet hast, kannst du direkt mal hier nachschauen:
http://www.computerbase.de/news/hardware/prozessoren/intel/2006/maerz/cebit06_neue_cpus_preise_april/
(alte/aktuelle Preise).

Preise:
http://www.geizhals.at/eu/?cat=cpumobi&sort=p
http://www.geizhals.at/eu/?cat=cpup7&sort=p

Ich finde die Preise passen sogar sehr gut zusammen. Fast 1:1 umgerechnt, wie es bei Intel gewöhnlich der Fall ist.

Ich bin mir jedenfalls noch nicht sicher, wie stark die AMD Konkurrenz ausfallen wird. Es ist doch merkwürdig, wenn aus den anfangs so schlechten Speicherbenchmarkwerten zunehmend bessere werden? Die T*G Benchmarks waren derartig absurd niedrig (Speicherbandbreite bei PC 3200 quasi gleich hoch wie PC-2 6400 Benches) mit Sockel AM2 CPUs, dass damit kein Staat zu machen ist. Nein. hier wird mit verdeckten Karten gespielt.

Was war daran merkwürdig? THG hat einfach nur mist gebaut. Die hätten die Benches nicht veröffentlichen sollen, weil sie scheinbar nicht gemerkt haben, das es noch einige Probleme gab (ich gehe vom Board/BIOS aus).

Nun bei anandtech sieht es komplett anders aus und ich bin mir sicher, das sich daran nicht mehr viel ändern wird, s.u.

Einen Leistungs-Hinweis bekommt man erst mit den kommenden Turion-Notebooks im neuen Mobilsockel S ... nicht vorher. Und da tritt AMD vermutlich mit einem Single-Channel Speicherinterface an ...

Die Leistung lässt sich auch jetzt schon abschätzen, wenn man einfach normalen DDR400 RAM gegen DDR500 und besser bencht. Die Unterschiede sind nicht allzu groß, folglich kann DDR2 auch nicht allzu viel bringen. Natürlich mehr als DDR500, aber eben keine >10%.

Botcruscher

2006-04-10, 19:58:56

BLUB

Haha welch ein Argument. ;D Keine wasserdichten Zahlen, keine Möglichkeit selber nach zu prüfen und ein Produkt was irgenwan in ferner Zukunft erscheinen wird. Und jetzt verlangst du noch das ich dieses "Nichts" mit festen Argumenten wiederlege. ;D
Kein Wunder das du glaubst das die paar Anhaltspünktchen einer Diskussion wert wären. :tongue:

PS: Da du es ja "weist" kann du auch sicher ein paar Realworldanwenungen mit den Ergebnissen posten. Nein? Gut cu lieber Gast. :cool:

Gast

2006-04-10, 20:03:00

Ich verlange eine sachliche Diskussion, wie es die Forenregeln vorgeben.

Nur von dir kamen bisher lediglich solche Phrasen:

Glaubt doch an:

- 100% mehr Leistung
- 35 Stundenwoche
- sichere Renten
- "Blühende Landschaften"
- Wirschaftswunder, Vollbeschäftigung

Aber nein es geschieht das selbe wie beim Start einer neuen Graka- oder Konsolegeneration. Gigantische Leistung und das baldige Amagedon das PC, ruft es aus jeder Ecke... Alles nur noch eine Frage der Zeit, alle Jahre wieder.

Ich sehe keinerlei zusammenhang mit diesem Thema.
Wenn du nichts zu sagen hast, dann lass es einfach, sonst werde ich noch in die Versuchung kommen und mich anmelden müssen, allein um zu erfahren, was die Modschaft dazu sagt.

Botcruscher

2006-04-10, 20:12:51

was die Modschaft dazu sagt.
Nichts, da sie auch nichts wissen.

Bitte noch mal langsam für dich:

- keine wasserdichten Ergebnisse des Conroe
- spekulatives Marketing von Intel
- es sind keine zukünftigen Preise bekannt
- es ist nicht bekannt wie schnell AM2 wirklich ist
- es ist nicht bekannt welche CPUs AMD bis dahin bringt

Das absolute Minimum um einen Vergleich an zu stellen wären also reproduzierbare Benches verschiedenster Anwendungen. Dann lieber Gast stehe ich dir auch in einer sachlichen Diskussion zur verfügung.

Aber bis dahin bleibt Conroe vapoware.

aylano

2006-04-10, 21:32:55

AM2 -> 6. Juni
Conroe -> Ab Q3. Kann also schon am 1. Tag des Monats darauf sein, spätestens jedoch 15 Wochen danach und ihr wollt mir doch nicht ernsthaft erzählen, das 3-15 Wochen viel später sind
Ich finde es sehr komisch, dass Intel nicht den genauen Tag-X angibt, an dem tolle Conore präsentiert wird.
Ich verstehe nicht, wo das Problem ist, diesen Tag anzugeben.

Marketingmäßig wäre es doch IMO sinnvoller, wenn man den Tag-X Auslieferungstag schon Monate füher bekannt gibt, oder nicht?

Einen Teil des Forums kann man ja schon als Hühnerstall voller Junkies bezeichnen, die kurz davor sind ihr Dope zu bekommen. Wahhhhaaa 20%!!!1111 muhahahahahahahaha.
Ich weiß nicht. Der Conore hat AFAIK doppelt soviel Transitoren wie der Athlon und wenn der jetzt 20 % schneller ist, ist das dann nicht ein bischen wenig???

Komisch finde ich auch, dass Intel die Conore Preise relativ niedrig angesetzt hat.
Warum will Intel nicht mehr Geld verdienen, wenn die CPUs so toll sind?

Ich kann mich ja auch irren, da ich nicht so lange dabei bin, aber ich finde es komisch, wenn eine Aktiongesellschaft sehr gute Produkte billig verkauft.

svenw

2006-04-10, 21:43:38

Das Problem ist doch, das AMd es sich kaum leisten kann hinten zu liegen. Intel hat das in den letzten 2 Jahren weh getan, ja, aber bedrohlich war es für die Firma nicht. Sie haben noch immer eine gigantische Marktmacht und dadurch wesentlich höhere Gewinnmargen als AMD. Das beste für alle wäre eine Situation ala Graka Markt: 2 gleichgroße Player die sich nichts schenken. Momentan hat AMD schlichtweg nicht die Power um gegen Intel anzustinken. Wir reden immer darüber wie toll AMD CPUs als Spiel Proz sind, nur wird der Großteil der Rechner von Firmen gekauft. Intel hat dort einen topsoliden Ruf und macht gute Gewinne. Solange AMD dort nciht endlich mit einem vernünftigen Bundel von Chipsätzen und Prozessoren reinkommt, wird es immer benachteiligt bleiben. Viel Gewinn bedeutet auch viel Geld für Forschung und Aquisition und das scheint Intel sehr gut in Zukäufen angelegt zu haben. Sie haben sich die israelischen Firmen gekauft die die jetzigen tollen Chips entwickeln.

Zum Thema: ich glaube nicht das AMD momentan was zum kontern hat, sonst hätten sie es längst getan. Man kann nur hoffen das AMD es schafft die Entwicklung der neuen Microarchitektur zu beschleunigen um wieder konkurrenzfähig zu werden. 20% wird der Intel Vorsprung wohl kaum sein, aber 10% dürften locker drin sein. und wenn man sieht wie die Spieler und Computerkäufer auf sub 1% Vorsprünge abfahren (Übertaktetes RAM, Null Komma irgendwas Frames Vorsprung für...).... ;(

svenw

2006-04-10, 21:50:24

Komisch finde ich auch, dass Intel die Conore Preise relativ niedrig angesetzt hat.
Warum will Intel nicht mehr Geld verdienen, wenn die CPUs so toll sind?
Gegenfrage: wie kann man besser Geld verdienen: als Monopolist oder mit einem gleichwertigen Gegner. Intel hat AMD mit Preissenkungen immer knapp an der Rentabilitätsgrenze gehalten. Billige CPUs mit mehr Leistung, ich weiß nicht wie lange AMD das durchsteht? :frown: Momentan verliert Intel so vieleicht etwas Geld, mit etwas Pech holen sie es aber in ein paar Jahren doppelt und dreifach wieder rein.

Und Intels PR Abteilung sollte man gratulieren, sie haben es fast geschafft sämtliche Käufer mit dem Kauf bis zum Erscheinen des Conroe warten.

Gast

2006-04-10, 21:55:33

- keine wasserdichten Ergebnisse des Conroe

Mir reicht es zu wissen, das die gaming performance hoch sein wird.

- spekulatives Marketing von Intel

Hat mich nie interessiert.

- es sind keine zukünftigen Preise bekannt

Die des Conroes schon und wie heißt es so schön: Es kann nur besser werden.

- es ist nicht bekannt wie schnell AM2 wirklich ist

Die werden im besten Fall 10% schneller sein, als ihre S939 Pendants, durchschnittlich eher weniger.
Kann jeder selbst nachprüfen, der schonmal ein paar Benches gefahren hat. Man nehme sich paar Speicherriegel mit unterschiedlichen Taktraten, vergleiche die Bandbreite und den daraus resultierenden Leistungsgewinn.

- es ist nicht bekannt welche CPUs AMD bis dahin bringt

2,8 GHz sicher, 3 GHz eventuell zum Launch des Conroe oder kurz danach. Mehr ist nicht zu erwarten bis dahin.
Größere Veränderungen wird es kurzfristig nicht geben, denn die wären längst durchgesickert - wie jedes mal.

Komisch finde ich auch, dass Intel die Conore Preise relativ niedrig angesetzt hat.
Warum will Intel nicht mehr Geld verdienen, wenn die CPUs so toll sind?

Man will den Konkurrenten durch aggressive Preispolitik Marktanteile wegnehmen bzw. zurückgewinnen.

Bokill

2006-04-10, 23:45:42

... Wie kommst du jetzt überhaupt darauf?
Die letzten Preissenkungen waren schon Tage vor der offiziellen Bekanntmachung umgesetzt bei einigen Händlern.

Da du vom Yonah geredet hast, kannst du direkt mal hier nachschauen:
http://www.computerbase.de/news/hardware/prozessoren/intel/2006/maerz/cebit06_neue_cpus_preise_april/
(alte/aktuelle Preise).

Preise:
http://www.geizhals.at/ ...
http://www.geizhals.at ...

Ich finde die Preise passen sogar sehr gut zusammen. Fast 1:1 umgerechnt, wie es bei Intel gewöhnlich der Fall ist. Noch einmal.

Was nutzen niedrige Preise, wenn die Ware nicht da ist?

Bei einer anstehenden Preiserunde verfallen die Preise dann weiter ... davon werden dann aber keine weiteren CPUs in die Welt gesetzt.

Was passiert, wenn die Preise gesenkt werden, aber die Produkte nicht geliefert werden? Genau die lieferbaren Exemplare kosten noch weniger und die Margen werden aufgefressen ... darum geht es.

Was war daran merkwürdig? THG hat einfach nur mist gebaut. Ohh da berichtest du mir ja was neues ;D

Die Leistung lässt sich auch jetzt schon abschätzen, wenn man einfach normalen DDR400 RAM gegen DDR500 und besser bencht. Die Unterschiede sind nicht allzu groß, folglich kann DDR2 auch nicht allzu viel bringen. Natürlich mehr als DDR500, aber eben keine >10%. Was macht dich so sicher, dass man diesen Schluss so ziehen kann? AMD war sehr schmallippig, was so alles in den kommenden Kern reinkommt. Sicher ist Presidio und Pacifica ... das alleine sind schon einschneidende Erweiterungen/Verbesserungen. Schon deswegen ist es nicht nur ein Interfaceupdate ... Was noch weiter daran gedreht wurde ist derzeit alles andere als klar.

Dass der Conroe ein rechenstarkes Konkurrenzprodukt ist, stelle ich gar nicht in Abrede.

Ich wunderte mich dagegen sehr, wenn AMD diesesmal ausgerechnet jetzt keine weitere Leistungssteigerungen eingeplant haben sollte, wo sie doch sonst von K8 Kern zu K8 Kern immer dezente Leistunges-Verbesserungen eingebaut hatten.

Der Clawhammer der K8 Anfangstage ist nicht so leistungsstark, wie seine späteren Revisionen (bei identischer L2 Cachegrösse).

MFG Bobo(2006)

pnume

2006-04-11, 00:25:30

AM2 ist doch nur eine Änderung eines "alten" Designs.

So wie wenn man von einem KT266a auf einen nforce2 umsteigt.

Der A64 wurde 2003 vorgestellt und erst 3 Jahre später schafft es Intel einen besseren Chip zu bauen!

Denniss

2006-04-11, 00:38:12

][immy

2006-04-11, 07:33:18

Ein netter Marketing-Gag von Intel mit den Benches vom zweifellos schnellen Prototypen. Ob der nun im Endeffekt wirklich so schnell bleiben wird oder ob es sich um einen leicht hochgezüchteten Vertreter handelte werden wir erst bei der Markteinführung mit unabhängigen Vergleichstests erfahren können.

sehe ich auch so, die ersten prototypen von intel waren meist extrem schnell. wenn ich da so an die ersten prototypen des P4 denke, die waren mit 1,4 GHz schneller in den tests als die P3s. und dann kamen sie in den markt und was stellte sich heraus, eher das gegenteil, wonach ein P3 mit 1Ghz einen P4 mit 1,4GHz ohne probleme abgehängt hat. Vorserienmodelle eben.

entweder es wird vorrausgesetzt das nur ausgewählte benches zum einsatz kommen, oder das endprodukt wird noch um einiges beschnitten, damit es wirtschaftlich herzustellen ist und an den mann gebracht werden kann.

eben aus solchen gründen würde ich nicht sehr viel auf die tests geben. zwar gehe ich ebenfalls davon aus, das intel mit dem conroe in führung gehen dürfte, aber 20% mehrleistung bei gleichem takt halte ich immoment für das endprodukt nicht für realistisch. solche extremen vorsprünge können auch durch ein spezial Bios ausgebaut werden. machen die mainboardhersteller ja nicht anders. bei der einführung sind zwar noch ein paar bugs drin, aber dafür sind die mainboards schnell. später wenn es neue Bios-updates gibt werden die boards meist ein wenig langsamer, dafür aber stabiler, allerdings sind die großen tests dann schon vorbei in denen es um die reine performance ging. Teilweise alles nicht als marketing

BlackBirdSR

2006-04-11, 08:18:48

[immy']sehe ich auch so, die ersten prototypen von intel waren meist extrem schnell. wenn ich da so an die ersten prototypen des P4 denke, die waren mit 1,4 GHz schneller in den tests als die P3s. und dann kamen sie in den markt und was stellte sich heraus, eher das gegenteil, wonach ein P3 mit 1Ghz einen P4 mit 1,4GHz ohne probleme abgehängt hat. Vorserienmodelle eben.

Das ist nicht wahr.
Die Benchmarks waren einfach speziell selektiert, und die Benchmarkumgebung entsprechend angepasst. Oft gab es auch nur Ausschnitte aus Benchmarks.
Die Prototypen waren nicht schneller, als was du dann kaufen konntest.

entweder es wird vorrausgesetzt das nur ausgewählte benches zum einsatz kommen, oder das endprodukt wird noch um einiges beschnitten, damit es wirtschaftlich herzustellen ist und an den mann gebracht werden kann.

Das Endprodukt - hier der Pentium4 - wurde dann nicht beschnitten vergleichen mit den Modellen die Intel vorher gefertigt hatte.
Was es ursprünglich an Ideen für den Pentium4 gab, ist nie als zugängliche CPU verfügbar gewesen, und davon gab es auch niemals Benchmarks.

Gast

2006-04-11, 16:13:31

[immy']wenn ich da so an die ersten prototypen des P4 denke, die waren mit 1,4 GHz schneller in den tests als die P3s.

Sie sie auch heute noch. Bei Audio/Video/Grafikbearbeitungen ist der P4 einfach schnell, auch bei dieser Taktrate.

und dann kamen sie in den markt und was stellte sich heraus, eher das gegenteil, wonach ein P3 mit 1Ghz einen P4 mit 1,4GHz ohne probleme abgehängt hat. Vorserienmodelle eben.

Das ist falsch, er wurde nicht problemlos abgehängt.

Hier (http://www2.tomshardware.de/cpu/20001121/p4-14.html) gewinnt er alle 4 Games-Benchmarks deutlich gegen den P3.

Hier (http://www2.tomshardware.de/cpu/20001121/p4-16.html) hängt er den P3 um 51% ab!

Botcruscher

2006-04-11, 16:20:21

Hier (http://www2.tomshardware.de/cpu/20001121/p4-14.html) gewinnt er alle 4 Games-Benchmarks deutlich gegen den P3.
Hier (http://www2.tomshardware.de/cpu/20001121/p4-16.html) hängt er den P3 um 51% ab!

Ein tolles Beispiel dafür was einzelne Leistungsangaben wert sind.

HOT

2006-04-11, 16:30:12

Gast

2006-04-11, 16:33:21

Ein tolles Beispiel dafür was einzelne Leistungsangaben wert sind.

Eigentlich waren das sehr Praxisnahe Benchmarks zu dieser Zeit. Quake 3, UT, FlaskMPEG wurden zu dem Zeitpunkt immer beliebter und ich habe nur versucht, die Aussage vom Vorposter zu widerlegen.

Intel hatte Benchmarks veröffentlicht, aber dabei handelte es sich nicht um Games-Benchmarks. Somit war die Aussage Intels nicht falsch, als sie sagten, der "P4 wäre so viel schneller", sie sagten nur nicht wodrin.

Hier sieht man es ganz deutlich:
http://www.heise.de/newsticker/meldung/11478

Intel hat nie versprochen, das der P4 in allen Bereichen schnell sein würde, das haben die User einfach so angenommen - und das war und ist auch noch ziemlich dumm.

Gast

2006-04-11, 16:38:11

Man verkleinere den L2 Cache und verringere die Latenz und füge einen langsameren L3 hinzu, schon bringt auch der Cache mehr Performance. Siehe Gallatin, der hat vorgeführt wie es funktioniert ;)

Beim Gallatin wurde der L2-Cache nicht verkleinert, sondern einfach ein L3 Cache hinzugefügt.

Das (http://www.computerbase.de/artikel/hardware/prozessoren/2003/vorschau_intel_pentium_4_extreme_edition_2_mb_cache/31/#abschnitt_leistungsrating_fortsetzung) kommt dann dabei heraus.
Aber wie du hier (http://www.computerbase.de/artikel/hardware/prozessoren/2006/test_intel_pentium_extreme_edition_965/19/#abschnitt_performance_rating) siehst, profitiert der Athlon weit weniger, von einem größeren Cache, als der P4.
Wenn sie die Latenzen so einfach senken könnten, hätten sie es wohl schon längst getan...

Botcruscher

2006-04-11, 16:38:47

Intel hat nie versprochen, das der P4 in allen Bereichen schnell sein würde, das haben die User einfach so angenommen - und das war und ist auch noch ziemlich dumm.

Ack ich gebe dir vollkommen recht so wie du es jetzt sagst. Das Problem liegt an Ottonormalversager bei dem nur noch die X Prozent ankommen und sich der Verstand abschaltet.

Schnurrbart

2006-04-13, 17:27:53

Oh man wie ist die Frage lächerlich...
Fakt ist dass AMD (besonders Desktop-) CPUs derzeit leistungsfähiger sind als deren Intel Pendants, obwohl Intel bereits auf 65nm umgestiegen ist.

Ein Prototyp vom Conroe wurde von Intel mit seit Ewigkeiten kaufbarer AMD-Technik verglichen, und sofort gibt es Helden die daraus schließen dass Intel AMD "eingeholt" hat.

Nein, die K8F mit DDR2 controller sind nicht das Gegenstück zum Conroe.
Einfach clever sein und ein paar Wochen nach Einführung vom Conroe warten und sehen wie sich folgendes von AMD bewähren wird:

http://img136.imageshack.us/img136/3452/39273111vq.jpg (http://imageshack.us)

Coda

2006-04-13, 17:31:23

Das unterhalb des normalen Caches dürfte Z-RAM L3 sein. Für Server bestimmt sehr interessant...

RLZ

2006-04-13, 17:45:44

Das unterhalb des normalen Caches dürfte Z-RAM L3 sein. Für Server bestimmt sehr interessant...
Hans de Vries sieht das etwas anders:
http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=4254&Thread=6&entryID=65537&roomID=11
http://www.realworldtech.com/forums/index.cfm?action=detail&PostNum=4254&Thread=9&entryID=65549&roomID=11
Wäre auch zu schön gewesen. :frown:

Gast

2006-04-13, 17:51:11

Der K8L scheint schon erhebliche Design-Änderung zu haben.
Wie bereits bekannt deutet der scheinbar zusätzliche Befehlsdecoder auf einer Verdopplung der FP-Einheiten hin.
Das würde einen erheblichen Leistungsgewinn gerade in den typischen Desktopanwendungen mit hohem Leistungsbedarf bedeuten.

Auf jeden Fall hat sich im Layout einiges getan.

aylano

2006-04-13, 18:34:51

Das unterhalb des normalen Caches dürfte Z-RAM L3 sein. Für Server bestimmt sehr interessant...
Warum wird der L2 Cach nicht mit Z-Rams gemacht???

Für was sind die Lila-Flächen links und rechts oben???

Coda

2006-04-13, 18:50:16

Warum wird der L2 Cach nicht mit Z-Rams gemacht???
Zu lahm. Das ist DRAM. Aber ich glaube RLZ hat recht und es ist eh keiner.

Bokill

2006-04-13, 22:06:17

Warum wird der L2 Cach nicht mit Z-Rams gemacht???

Für was sind die Lila-Flächen links und rechts oben??? Das wird allenfalls für Embedded-Designs angedacht.

Z-RAM hat Vorteile bei Kosten, Kompaktheit, Integration. Wer SOI-Technologie beherrscht soll recht einfach Z-RAM nutzen können.

Im Embedded-Bereich soll Z-RAM Flash RAM und SDRAM ersetzen. Das soll die Designs übersichtlicher und kompakter machen. Geschwindigkeitsgewinn ist dabei nicht vorrangig. Allerdings dürfte Z-RAM schneller als Flashspeicher sein. Z-RAM verliert aber seine Daten, wenn der Strom abgeschaltet ist, das ist nun mal die Domäne von Flashspeicher.

MFG Bobo(2006)

reunion

2006-04-16, 17:43:48

Gast

2006-04-17, 00:10:58

AMD hat doch noch einiges im Ärmel.

1.) Erst kürzlich gingen doch Nachrichten herum, dass AMD mit einer Firma (Name vergessen) verhandelt, welches eine Technick entwickelt hat, mit der man mehr Speicher in kleinerem Raum unterbringen kann -> Mehr Cache, wie z.T. bereits erwähnt.

2.) AMD kooperiere mit einer anderen Firma um einen so genannten Co-Prozessor für die Multicoreprozessoren, so die Gerüchte. Wieder Performanceschub möglich.

3.) AMD ist immernoch bei 90nm. Bei 65nm sollte sich doch einiges an Potenzial aufweisen.

Und vielleicht gibt es noch zahlreiche "neue Techniken", von der die Presse noch nicht Wind bekommen hat. Glaub nicht, dass AMD einfach zugucken wird wie Intel davonzieht. Gilt natürlich auch umgekehrt.

Also abwarten und Tee trinken...

Gast

2006-04-17, 01:31:36

aylano

2006-04-17, 11:20:32

3.) AMD ist immernoch bei 90nm. Bei 65nm sollte sich doch einiges an Potenzial aufweisen.
AMD hat angegeben, dass AMDs 65er inkl. SOI3 eine Peformenzsteigerung (Leistung und Wattverbrauch) von 40% hat.
Intel hat bei ihren Benches gezeigt, dass der Conore auch 40% vor den aktuellen AMDs liegt.
Es könnte durchaus sein, dass beide gleich auf liegen. Diese Firma die bis Anfang 2007 noch wo anderst Performenz herausholt, liegt dann ein wenig vorne.

BlackBirdSR

2006-04-17, 11:50:46

AMD hat angegeben, dass AMDs 65er inkl. SOI3 eine Peformencsteigerung (Leistung und Wattverbrauch) von 40% hat.

Es ist immer ein Leistung oder Verbrauch

aylano

2006-04-17, 12:08:40

Aufteilen könnte man das nicht???
z.B. 20% für Leistung und 20% für Verbrauch?!?

Power

2006-04-17, 12:34:07

Ich möchte nur sagen, dass nichts so heiss gegessen wird wie es gekocht wird. Das soll heissen, in den gesponserten Tests von Intel ist ein Performancevorteil von 20% das mindeste.
Man muss erstmal abwarten wieviel Realworldperformance in den Serienprodukten davon übrigbleibt. Bei der Vorstellung des Northwood wollte Intel auch 4GHz in 12 Monaten erreichen, wie wir wissen hat es 24 Monate gedauert.
Es wäre im übrigen auch nicht das erste mal das Intel zu solch einem Marketingtrick greift, für mich ist das nicht mehr Wert als ein Paperlaunch oder ein technologypreview kann man halt auslegen wie man grad lustig ist.
Das ist auch der Grund warum ich diese Hysterie nicht ganz verstehen kann, zumal ich den FX60 im Laden jetzt kaufen kann aber diesen "ominösen" Conroe halt nicht.

Und wiso sollte der conroe nicht 20% und mehr vorne liegen nur weils AMD sagt ?, und viele AMD Fanboys es einfach nicht für wahr haben wollen daß Intel wiedermal die Prformancekrone an sich reißen wird ?

Man wie dumm muß man sein zu glauben das eine Firma mit mehr als 100fachen Geldreserven von AMD nicht wieder an die Spitze zurückkommt ?

Ich freu mich schon auf den Launch und auf die langen Gesichter von AMD - die so überheblich sind und denn gleichen Fehler wie Intel machen und sich aus einem Schrink nur Vorteile erhoffen - bei Intel kam auch die ernüchterung nachdem der Prozeß Serienreife hatte.

Auch SOI ist kein Allwundermittel und hat Grenzen.

Botcruscher

2006-04-17, 12:34:11

Aufteilen könnte man das nicht???
z.B. 20% für Leistung und 20% für Verbrauch?!?

Das ist sogar weit näher an der Realität.

BlackBirdSR

2006-04-17, 12:40:21

Aufteilen könnte man das nicht???
z.B. 20% für Leistung und 20% für Verbrauch?!?

ein 20% mehr Takt oder 20% weniger Verlustleistung trifft es wohl eher.

(del)

2006-04-17, 13:13:26

AMD hat angegeben, dass AMDs 65er inkl. SOI3 eine Peformenzsteigerung (Leistung und Wattverbrauch) von 40% hat.
Intel hat bei ihren Benches gezeigt, dass der Conore auch 40% vor den aktuellen AMDs liegt.
Es könnte durchaus sein, dass beide gleich auf liegen. Diese Firma die bis Anfang 2007 noch wo anderst Performenz herausholt, liegt dann ein wenig vorne.
Max. 20%. Die 40% die Intel gezeigt hat, sind Propaganda. Wo hat AMD das denn angegeben? 40% mehr Verbrauch geht garnicht. 150W CPUs sind out ;)

(del)

2006-04-17, 13:17:52

Und wiso sollte der conroe nicht 20% und mehr vorne liegen nur weils AMD sagt ?, und viele AMD Fanboys es einfach nicht für wahr haben wollen daß Intel wiedermal die Prformancekrone an sich reißen wird ?

Man wie dumm muß man sein zu glauben das eine Firma mit mehr als 100fachen Geldreserven von AMD nicht wieder an die Spitze zurückkommt ?

Ich freu mich schon auf den Launch und auf die langen Gesichter von AMD - die so überheblich sind und denn gleichen Fehler wie Intel machen und sich aus einem Schrink nur Vorteile erhoffen - bei Intel kam auch die ernüchterung nachdem der Prozeß Serienreife hatte.

Auch SOI ist kein Allwundermittel und hat Grenzen.
Sorry für OT, aber diese Art zu posten hat sich im 3DC irgendwie überlebt. Ich dachte 2006 hat das auch der letzte ewig gestrige mitbekommen :| Ergo: Rausch bitte nicht rum.

Coda

2006-04-17, 14:03:42

1.) Erst kürzlich gingen doch Nachrichten herum, dass AMD mit einer Firma (Name vergessen) verhandelt, welches eine Technick entwickelt hat, mit der man mehr Speicher in kleinerem Raum unterbringen kann -> Mehr Cache, wie z.T. bereits erwähnt.
Das ist bloß DRAM, das taugt bestenfalls als L3-Cache. Eher für Server interessant.

2.) AMD kooperiere mit einer anderen Firma um einen so genannten Co-Prozessor für die Multicoreprozessoren, so die Gerüchte. Wieder Performanceschub möglich.
Bringt auch nichts bei nicht angepassten Programmen. Das ist auch eher für Server gedacht.

3.) AMD ist immernoch bei 90nm. Bei 65nm sollte sich doch einiges an Potenzial aufweisen.
Das schon eher.

Auch SOI ist kein Allwundermittel und hat Grenzen.
Eigentlich wird SOI in Zukunft schon immer wichtiger. Das angesprochene Z-RAM funktioniert auch ausschließlich damit.

Max. 20%. Die 40% die Intel gezeigt hat, sind Propaganda. Wo hat AMD das denn angegeben? 40% mehr Verbrauch geht garnicht. 150W CPUs sind out ;)
AMD stellt mit 65nm auch auf embedded SiGe um. Das sollte die Transistorperformance auf jedenfall über die gängige Steigerung eines normalen Die-Shrinks hieven.

SavageX

2006-04-17, 14:20:31

Ach, ich für meinen Teil fürchte nicht um AMD, da deren Roadmap für die nahe Zukunft so einige interessante Produkte mit sich bringt - z.B. diese 35 Watt Desktop Linie (Semprons, A64s und kleine X2s). Wäre glatt was für mich.

Ich gehe schon davon aus, dass Intel die Performancekrone mal wieder bei sich haben wird - das wurde aber auch Zeit ;)

Interessanter als die Frage "Was ist das schnellste, was einem Privatkunden angedreht werden kann" ist eher die Frage "Was kann man Unternehmen anbieten?". Bei Intel steht da bei den Servern erstmal kein Conroe an, sondern noch eine Generation Netburst-Überlebender. Wenn dann endlich die Conroe Architekur bis zum Xeon durchgesickert ist könnte AMD den K8L schon bereit haben (*wildeste* Spekulation - also Obacht). Soooo heiss ist bei den Servern die Suppe für AMD also nicht.

"Opteron auf dem Server, Sempron/A64 mit 35 W auf dem Client" - klingt doch gar nicht schlecht, zumal ja endlich taugliche Chipsätze mit integrierter Grafik auf dem Markt und im Stable Corporate Platform Programm von AMD sind.

Ist doch alles herrlich Konsistent mit http://www.atmarkit.co.jp/fsys/kaisetsu/032analyst2003/focus-l.jpg ;)

reunion

2006-04-17, 14:26:25

AMD stellt mit 65nm auch auf embedded SiGe um. Das sollte die Transistorperformance auf jedenfall über die gängige Steigerung eines normalen Die-Shrinks hieven.

Genau, und alleine dadurch verspricht sich AMD eine 40% höhere Transistorenperformance. Der kleinere Fertigungsprozess ist dabei noch nicht berücksichtigt:

http://www.amd.com/de-de/Corporate/VirtualPressRoom/0,,51_104_543~103127,00.html

BH abgemeldet

2006-04-17, 14:42:47

Genau, und alleine dadurch verspricht sich AMD eine 40% höhere Transistorenperformance. Der kleinere Fertigungsprozess ist dabei noch nicht berücksichtigt:

http://www.amd.com/de-de/Corporate/VirtualPressRoom/0,,51_104_543~103127,00.html
Was aber heißt, daß sie über den Takt zu Intel aufschliessen wollen (?) Was egal wäre (!), wenn die Verlustleistung stimmt. Ich kann den P4 nicht deswegen nicht leiden :| weil es recht wenig Leistung pro Takt bringt, sonden weil es dabei auch noch eine übermässige Verlustleistung vorweist. Und nach entsprechenden Netzteilen und Kühler... brüllt.

Coda

2006-04-17, 15:17:05

Ach, ich für meinen Teil fürchte nicht um AMD, da deren Roadmap für die nahe Zukunft so einige interessante Produkte mit sich bringt - z.B. diese 35 Watt Desktop Linie (Semprons, A64s und kleine X2s). Wäre glatt was für mich.
Ich glaube nicht, dass Intel da Probleme hat mit Conroe mitzuhalten. Im Stromsparen ist die Architektur wohl hervorragend.

Was aber heißt, daß sie über den Takt zu Intel aufschliessen wollen (?)
AMD hat da ja wohl schon geplant bevor Conroe überhaupt in Sicht war, von daher ist es evtl. zwar eine Möglichkeit mit ihm mitzuhalten, aber wohl keine geplante.

RLZ

2006-04-17, 15:45:05

DerGroße

2006-04-17, 15:49:40

also, viele glauben IMMER NOCH an Intel, aber Dummerweise war es bei AMD immer so, dass die etwas im Petto haben und es erst später, wenn die ganze Technik ausgereift ist...und ziehen sich dann wieder vor Intel, in ein paar Jahren kommt Intel dann wieder mit soner HAMMER CPU und AMD macht wieder das gleiche, wie oft wurde AMD schon für tot gehalten nach sonem Pressebericht, also mach ich mir da keine sorgen, das AMD bald tot wäre :cool:

SavageX

2006-04-17, 16:00:08

Ich glaube nicht, dass Intel da Probleme hat mit Conroe mitzuhalten. Im Stromsparen ist die Architektur wohl hervorragend.

Klar. Das macht die Angebote des Konkurrenten aber nicht uninteressant.

Die Brot-und-Butter Prozessoren dürften auch weiterhin verkaufbar sein, selbst wenn man im High-End für einige Monate Prügel einstecken muss. Das demonstriert Intel seit Jahren sehr erfolgreich und AMD kennt sich mit dieser Situation auch noch gut aus ;)

GloomY

2006-04-17, 23:23:53

Der kleinere Fertigungsprozess ist dabei noch nicht berücksichtigt:

http://www.amd.com/de-de/Corporate/VirtualPressRoom/0,,51_104_543~103127,00.htmlEin kleinerer Fertigungsprozess führt heutzutage nicht mehr automatisch zu schnellerer Schaltgeschwindigkeit und weniger Verlustleistung. Siehe dazu auch den Bericht zur oben zitierten IEDM-Konferenz: Klick (http://www.realworldtech.com/page.cfm?ArticleID=RWT123005001504).

Interessant ist z.B. auch die Tabelle zu den verschiedenen Herstellungsprozessen. Darin ist Intels 90nm-Prozess von 2003 sogar schneller (höherer Drive Current) als der 65nm-Prozess von 2005. Dass der neue Prozess trotzdem besser als der alte ist, sieht man an den Leckströhmen. Diese sind ungefähr um einen Faktor fünf kleiner :)

Daher glaube ich nicht, dass AMD eine überdurchschnittliche Steigerung der Performance beim Wechsel auf 65 nm hinbekommen wird.

AnarchX

2006-04-18, 12:23:43

Ich werf mal noch ein paar Links in den Raum.
http://www.theinquirer.net/?article=31022
http://realworldtech.com/forums/index.cfm?action=detail&PostNum=4268&Thread=1&entryID=65714&roomID=11
http://aceshardware.com/forums/read_post.jsp?id=115160986&forumid=1

http://winfuture.de/news,24975.html

Ob das funktionieren kann?
Man kann doch nicht aus zwei getrennten CPUs eine machen?

Nightspider

2006-04-18, 12:48:26

Nichts ist unmöglich...Toyota... ;D

Also ich denke schon, dass es möglich ist, die werden schon wissen wie sie es machen.
Aber habe ich es richtig verstanden, dass AMD diese Technik erst bei dem K9 anwenden wird ?
Wann wird dieser wohl kommen ?
Bei QuadCore dürften wir wohl noch nicht mit diesem Feature rechnen oder ? ;(

Coda

2006-04-18, 12:58:26

http://winfuture.de/news,24975.html

Ob das funktionieren kann?
Man kann doch nicht aus zwei getrennten CPUs eine machen?
Ich habs in nem anderen Thread schon erwähnt: Nichtmal Compiler schaffen es vernünftig ein Programm in zwei Threads zu zerlegen, wie soll es eine CPU zur Runtime schaffen mit einem Instruction-Windows von evtl. 128?

Das ist mit Sicherheit eine Falschmeldung oder irgendjemand hat was falsch verstanden.

AnarchX

2006-04-18, 13:04:22

Ich habs in nem anderen Thread schon erwähnt: Nichtmal Compiler schaffen es vernünftig ein Programm in zwei Threads zu zerlegen, wie soll es eine CPU zur Runtime schaffen mit einem Instruction-Windows von evtl. 128?

Das ist mit Sicherheit eine Falschmeldung oder irgendjemand hat was falsch verstanden.

Könnte es sein, dass es sich nicht mehr um einen Dualcore handelt, wie er aktuell erhältlich ist, sondern 2 Cores die soweit miteinander verbunden sind, dass sie wie eine CPU arbeiten können?

Gast

2006-04-18, 13:16:26

Gonzo:

Hm, irgendwie vergleicht man hier Äpfel mit Birnen und einige glauben echt das was all die Seiten so berichten, welche dieser Seiten ist denn unabhängig, wenn ich die Werbebanner auf den ganzen Seiten sehe wird mir schlecht, die meisten sind doch gesponsort.
Selbst wenn der Conroe 40% vorne liegt, wieso sollte das für AMD eine Niederlage sein?! Amd liegt seit 2-3 Jahren mit dem Athlon 64 vorne.

Pentium 3 - Athlon XP
Pentium 4 - Athlon 64 + Athlon 64 AM2
Conroe - K8L, K9 ?!?!

Amd agiert momentan nicht, sie reagieren, der AM2 ist nichts weiter als der einstige vom K8 in DDR2, die Hammer (K8) Technologie ist alt und bewährt, läuft Intel gegen den Pentium 4 in fast allen Benchmarks den Rang ab, bei Spielen sehr deutlich, bei Officeanwendungen ein bisschen enger.
Ist der Conroe einmal da, so wird AMD nachlegen, und das nicht mit dem Athlon 64 für den AM2. Da wurde ein Prototyp getestet, die Speicherbenchmarks zeigen es doch, das hier nur bis zu 5% rausgeholt werden würden war doch schon vorher klar.

Amd hat mit dem Athlon XP den Pentium 3 geschlagen, auch wenn man mit sensiblen Cores ohne Heatspreader und hohen Temperaturen, zumindestens anfangs nicht ganz glänzte.
Der Athlon 64 ist und bleibt dem Pentium 4 voraus, welcher nur mit irrsinns Taktraten bei irrsinns Abwärme mithalten kann, die Standardlüfter haben wir oft genug verkauft, ich sag euch, fönen ist angenehmer.
Jetzt kommt der Conroe von Intel, entdlich mit durchdachterem Design und geringerer Abwärme und ist ein paar Schritte voraus, durchaus normal bei einer Technologie die mehr als 3 Jahre neuer ist.
Glaubt ihr AMD schläft? Die testen doch sicher intern schon ganz neue Dinge.
AMD wartet ab, reagiert auf den Markt und maximiert den Gewinn, liegt Intel dann wirklich vorne wird was neues nachgelegt.

Konkurrenz der beiden hilft uns Konsumenten, nicht auszudenken was wäre würde einer der beiden eine Monopolstellung einnehmen.

Freuen wir uns auf neue Leistungssteigerungen, es ist nicht alles Gold was glänzt, die Herren bei Intel atmen denselbe Sauerstoffanteil wie jeder andere ;).

Coda

2006-04-18, 13:22:48

Könnte es sein, dass es sich nicht mehr um einen Dualcore handelt, wie er aktuell erhältlich ist, sondern 2 Cores die soweit miteinander verbunden sind, dass sie wie eine CPU arbeiten können?
Bringt nichts. Du kannst soviele Einheiten nicht auslasten, selbst mit radikalster Out-of-Order-Execution. Es gibt schon einen Grund warum wir seit Jahren nichts tut.

Selbst der extrem breit ausgelegte Conroe hat nur 4 Ports.

up¦²

2006-04-18, 13:37:46

AMD wird am 6.6.06 :devil: seinen plan vorstellen und das ist mehr al rechtzeitig.
Die intel-machine beeindruckt momentan nur mit zukunftsplänen, die für sich genommen sensationelle produkte versprechen, aber verdammt gut von der gegenwärtigen produktion ablenken :wink:
warum sollte AMD sich schon jetzt den spaß nehmen lassen, erstmal endlich abzusahnen? Gutes geld für gute ware :rolleyes:
"It's driven by the fact that they can't talk about their current products, because everybody knows their current products aren't very good," said Henri Richard, AMD's chief sales and marketing officer, in an interview with CNET News.com

CharlieB

2006-04-18, 14:06:50

...Man ist sich bei AMD darüber im Klaren, dass die aktuelle K8-Architektur nicht mit den neuen Technologien aus dem Hause Intel mithalten kann. Die Hoffnung liegt nun im Anti Hyper Threading, wie es inzwischen inoffiziell genannt wird....

http://www.winfuture.de/news,24975.html

Anti-Hyper-Threading ... Innovation oder eher Rückschritt?

CB

up¦²

2006-04-18, 14:18:23

The magic word is 'quad-core' :wink:

Schon länger bekannt, ok, aber da geht's lang ...
Alter link dazu.
AMD will introduce support for DDR2 (double data rate 2) memory along with a new socket technology called AM2 in the second half of the year. That will allow system builders to drop quad-core processors into the same chipsets for upcoming dual-core chips, he said.

The integrated memory controller is still AMD's greatest advantage, Richard said. Integrating the memory controller allows that key link between the processor and memory to run at the speed of the chip, moving data into the processor more quickly than the front-side bus used by Intel's chips. Analysts and reviewers have consistently given an edge to AMD because of this feature, which Intel is not expected to duplicate anytime soon.
http://news.zdnet.com/2100-9584_22-6043587.html

Coda

2006-04-18, 14:23:34

http://www.winfuture.de/news,24975.html

Anti-Hyper-Threading ... Innovation oder eher Rückschritt?
Schwachsinn.

CharlieB

2006-04-18, 14:28:53

Schwachsinn.

nun für "Schwachsinn" wird schon zuviel davon geredet ...

Neomi

2006-04-18, 15:26:15

nun für "Schwachsinn" wird schon zuviel davon geredet ...

Schwachsinn bleibt Schwachsinn, selbst wenn von nichts anderem mehr geredet würde.

BlackBirdSR

2006-04-18, 16:12:42

nun für "Schwachsinn" wird schon zuviel davon geredet ...

glaubst du das?

Ich kann dir sagen wie die Sache gelaufen ist.
Die Seite x86-Secrets hat auf frz. einen Text verfasst. Darin spricht man an der Bar! eines Lokals mit einem angeblichen AMD Mitarbeiter über neue AMD Features.
Dabei soll es auch um etwas gehen, das x86-secret mal eben schnell als Anti-Hyperthreading bezeichnet.

Die ganze Sache landet in ein oder zwei Foren, wo sich nach 2-3 Tagen jemand bereit erklärt den Text zu übersetzen.
Ab dann geht es los. Irgendwelche Leute durchstreifen dies und jenes Forum und stoßen auf den kläglich übersetzten Text.
Das wird dann in Foren gepostet, bzw die Leute waren Newsschreiber bestimmter Seiten. Manche nutzen eben jede Möglichkeit um an irgendwelche News zu kommen.

Schlussendlich wird dann diese News wieder hier im Forum gepostet.
Da man es im Forum schon gesehen hat, es schon auf 3 Newsseiten steht und jetzt wieder im Forum, ist es natürlich eine große Sache und schon viel zu viel diskutiert, als dass es nicht so sein müsste.

Dabei basiert das GESAMTE immernoch auf der Aussage (in frz), man hätte einen AMD Mitarbeiter an der bar getroffen und mit ihm ein wenig geplaudert....

denkt euch den Rest

onkel2003

2006-04-18, 18:20:23

Schwachsinn hin und her, die Idee ist gut, und wenn schon die Software Industrie nicht willig ist oder in der lage ihre Software auf mehrere core´s zu verteilen, dann muss halt die Hardware dies machen.

schaut man sich aber mal die Situation an, wie lange gibt es dualcore, und was macht die Software daraus, irgendwie nichts.
Woran liegt es den nun, das es kaum Software gibt die eine dualcore wirklich voll ausnutzt.
Ist ja nicht so das es diese erst ein paar tage gibt.
In sachen games kannste dualcore ganz vergessen, hier und da gibt es ne Software die sehr deutlich von dualcore profitiert, aber in ganzen, hat dualcore fast kein nutzen.
Also entweder ist die Software Industrie nicht in der lage, ihre Anwendungen auf dualcore zu optimieren, oder sie haben gar keine anreize dafür dies zu machen.

Also bleibt nur die Hardware Lösung über.
Und warum sollte es nicht gehen, dualcore, nach außen als eine cpu zu zeigen.
Technisch möglich bestimmt, nur fraglich ob es was bringt.

Ob ein besoffener AMD Mitarbeiter geplaudert hat oder nicht spielt keine rolle, gehe ich aber mal er nicht von aus, den nicht jeder hanswurst AMD Mitarbeiter wird info´s haben, und die oberen die an der quelle sitzen werden kaum für ein Bier die schnauze aufmachen, und nachher Stammkunde beim AA sein.

Coda

2006-04-18, 18:29:05

Schwachsinn hin und her, die Idee ist gut
Sie funktioniert aber nicht. Das kann nichtmal ein Compiler. Zur Run-Time mit dem kleinen Instruction-Window eines Prozessor hast du da komplett verloren.

onkel2003

2006-04-18, 18:39:28

Sie funktioniert aber nicht. Das kann nichtmal ein Compiler. Zur Run-Time mit dem kleinen Instruction-Window eines Prozessor hast du da komplett verloren.
Schade
Von der Software seite ist auch nichts zu erwarten, frage bleibt da nur, was und die ganzen core in zukunft bringen werden, wenn man sie kaum einsetzen kann.

Neomi

2006-04-18, 19:10:05

Schwachsinn hin und her, die Idee ist gut, und wenn schon die Software Industrie nicht willig ist oder in der lage ihre Software auf mehrere core´s zu verteilen, dann muss halt die Hardware dies machen.

Es ist keine gute Idee, Zeit und Geld in Dinge zu investieren, die schonmal prinzipiell nicht funktionieren können.

Also bleibt nur die Hardware Lösung über.
Und warum sollte es nicht gehen, dualcore, nach außen als eine cpu zu zeigen.
Technisch möglich bestimmt, nur fraglich ob es was bringt.

Es geht einfach nicht. Beispiel: "a = ((b * c + d) * e + f) * g + h". Das sind 3 Additionen und 3 Multiplikationen, also 6 arithmetische Operationen. Was davon soll ein zweiter Core übernehmen können?

Schade
Von der Software seite ist auch nichts zu erwarten, frage bleibt da nur, was und die ganzen core in zukunft bringen werden, wenn man sie kaum einsetzen kann.

Sie werden eine Menge bringen, weil man sie sehr wohl einsetzen kann. Das passiert aber nicht automatisch, deshalb ist ein wenig Geduld nicht verkehrt.

onkel2003

2006-04-18, 19:21:32

Es ist keine gute Idee, Zeit und Geld in Dinge zu investieren, die schonmal prinzipiell nicht funktionieren können.

Es geht einfach nicht. Beispiel: "a = ((b * c + d) * e + f) * g + h". Das sind 3 Additionen und 3 Multiplikationen, also 6 arithmetische Operationen. Was davon soll ein zweiter Core übernehmen können?

Sie werden eine Menge bringen, weil man sie sehr wohl einsetzen kann. Das passiert aber nicht automatisch, deshalb ist ein wenig Geduld nicht verkehrt.

ob es funktionieren würde oder nicht, stell ich erst mal nicht in frage, da werden sich die passenden personen schon den kopf zerbrechen.

das die gedult zur software angeht, nun ja ich für mein teil finde das es schon zu lange dualcore gibt, und sich die hersteller der software nicht wirklich drum kümmern.

und da gibt es 2 punkte
1. software hersteller juckt es nicht, ( was ich mir kaum vorstellen kann )
2. software hersteller können es nicht bzw die software ist nicht so leicht auf mehre core´s zu proggen.

Coda

2006-04-18, 19:23:29

ob es funktionieren würde oder nicht, stell ich erst mal nicht in frage, da werden sich die passenden personen schon den kopf zerbrechen.
*seufz*

Glaub mir, da haben sich schon verdammt viele Personen den Kopf zerbrochen darüber. Das ist eines der größten Probleme der Informatik und bisher gibt es nirgends auch nur einen guten vollautomatischen Ansatz dazu. Nicht einmal auf Compilerebene.

onkel2003

2006-04-18, 19:33:16

*seufz*

Glaub mir, da haben sich schon verdammt viele Personen den Kopf zerbrochen darüber. Das ist eines der größten Probleme der Informatik und bisher gibt es nirgends auch nur einen guten vollautomatischen Ansatz dazu. Nicht einmal auf Compilerebene.

gut also bleibt erst mal nur die software lösung über.
nur wie wird es da weiter gehn, man sieht ein sehr sehr kleiner teil kann was mit dualcore anfangen, bald kommen cpu´s mit noch mehr core´s
letztentlich wenn ich viele anwendungen gleichzeitig benutze bringt mir mehrere core´s was, nur ist es natürlich wünschenswert wenn eine anwendung alle core´s nach möglichkeit fast ganz ausnutzt.

sind also software hersteller garnicht in der lage solche software zu proggen, oder wo ist da das prob ?.

RLZ

2006-04-18, 19:35:35

Es geht einfach nicht. Beispiel: "a = ((b * c + d) * e + f) * g + h". Das sind 3 Additionen und 3 Multiplikationen, also 6 arithmetische Operationen. Was davon soll ein zweiter Core übernehmen können?
1. Schritt
w=e*g
x=b*c
y=f*g
2. Schritt
z=w*x
k=d*w
l=y+h
3. Schritt
m=z+k
4. Schritt
a=m+l
Läuft so schon schneller auf SingleCore, da er immer mehrere Berechnungen in die Pipeline schieben kann.
Gerade beim Horner-Schema wird mit zunehmendem Grad des Polynoms ausmultiplizieren und bisschen optimieren wesentlich schneller als stupides Formelanwenden. Von Sony Research gabs mal ein interessantes Paper zu solchen Dingen.

up¦²

2006-04-18, 19:39:58

Schade
Von der Software seite ist auch nichts zu erwarten, frage bleibt da nur, was und die ganzen core in zukunft bringen werden, wenn man sie kaum einsetzen kann.

Gute frage!
Multi core wird also wenig bis garnix bei linearen operationen bringen, dafür aber 'simultan' funzen, also multithreading: q4 spielen und gleichzeitig avi codieren oder dvd brennen :wink:
http://harkal.sylphis3d.com/2006/02/16/multithreading-game-engines-for-multicore-machines/

http://devforums.amd.com/index.php?showtopic=450

http://www.intel.com/cd/ids/developer/asmo-na/eng/strategy/multicore/index.htm

http://www.intel.com/intelpress/sum_mcp.htm

onkel2003

2006-04-18, 20:17:13

Gute frage!
Multi core wird also wenig bis garnix bei linearen operationen bringen, dafür aber 'simultan' funzen, also multithreading: q4 spielen und gleichzeitig avi codieren oder dvd brennen :wink:
http://harkal.sylphis3d.com/2006/02/16/multithreading-game-engines-for-multicore-machines/

http://devforums.amd.com/index.php?showtopic=450

http://www.intel.com/cd/ids/developer/asmo-na/eng/strategy/multicore/index.htm

http://www.intel.com/intelpress/sum_mcp.htm

gut klar sobald es um multithreading geht, ist natürlich dualcore vorne.
aber wie sieht es nun mit einer anwendung aus, kann man davon ausgehn, das diese irgend wann was mit dualcore anfangen kann, oder bleibt man hier auf der strecke.
schaue ich mir jetzt beispiel Windows Media Encoder 9.0 an.
dieser macht in gleichen takt der cpu dualcore vs singlecore fast 80 % schneller.
so also hier sieht man dualcore optimierung für single anwendung möglich.

nur leider sind die anwendungen die es können recht rar, obwohl es schon ne ganze weile dualcore gibt.
bei games sieht es ja noch schlimmer aus.

Neomi

2006-04-18, 20:27:02

Läuft so schon schneller auf SingleCore, da er immer mehrere Berechnungen in die Pipeline schieben kann.
Gerade beim Horner-Schema wird mit zunehmendem Grad des Polynoms ausmultiplizieren und bisschen optimieren wesentlich schneller als stupides Formelanwenden. Von Sony Research gabs mal ein interessantes Paper zu solchen Dingen.

Hoppla, daran hatte ich jetzt gar nicht gedacht, dabei habe ich das letztens noch selbst gemacht (für einen Spline auf Basis eines Polynoms 5. Grades). Sollte aber auch nur ein schnelles Beispiel sein, es gibt genug Fälle ohne mathematisches Äquivalent. Als simpelstes Fällt mir spontan "a = b + c + d" ein, die zwei Additionen lassen sich unter keinen Umständen beschleunigen.

up¦²

2006-04-18, 20:32:27

Was mich wundert, ist wie wenig aufmeksamkeit ein patch von quake bekommen hat, das mächtig viel ausmacht bei DC :|
Find so schnell nicht die info/benchmarks ...

Gast

2006-04-18, 20:35:33

aber wie sieht es nun mit einer anwendung aus, kann man davon ausgehn, das diese irgend wann was mit dualcore anfangen kann, oder bleibt man hier auf der strecke.

die frage ist vor allem ob es sich auszahlt aufwändige multicore-optimierungen vorzunehmen, oder ob die software nicht auch mit einem core schnell genug läuft.

gerade bei vielen spielen ist die geschwindigkeit mit einem P43GHz+ single-core absolut ausreichend, wieso also aufwändig in multi-core investieren?

bei anwendungen wo es sich auszahlt, wie video-en/decoder wird ja auch eifrig auf multicore optimiert.

onkel2003

2006-04-18, 20:54:03

die frage ist vor allem ob es sich auszahlt aufwändige multicore-optimierungen vorzunehmen, oder ob die software nicht auch mit einem core schnell genug läuft.

gerade bei vielen spielen ist die geschwindigkeit mit einem P43GHz+ single-core absolut ausreichend, wieso also aufwändig in multi-core investieren?

bei anwendungen wo es sich auszahlt, wie video-en/decoder wird ja auch eifrig auf multicore optimiert.

bin nicht so der starke gamer, aber reicht die heutige cpu wirklich aus um die zureit immer stärkeren grakas wirklich mit daten zu futtern.

also ich denke mal um die cpu leistung wirklich zu vernachlässigen, muss man doch bestimmt bei 4 grakas die man jetzt schon benutzen kann, die auflösung auf extrem hochstellen von den max quali erst garnicht zu reden.

wie sieht es aus bei tft´s mit 1280*1024, selbst wenn ich da an quali alles rein haue, ist die stärkste cpu, noch in der lage 4 grakas auszulasten ?.

dilated

2006-04-18, 22:26:52

kauf 2 grakas weniger dann gehts auf jedenfall :rolleyes:

Gast

2006-04-18, 23:00:49

bin nicht so der starke gamer, aber reicht die heutige cpu wirklich aus um die zureit immer stärkeren grakas wirklich mit daten zu futtern.

bei oblivion nicht, tomb raider legend scheint auch so ein kandidat zu sein, ebenso wie X3.

für den großteil der games sind allerdings aktuelle single-cores mehr als ausreichend.

also ich denke mal um die cpu leistung wirklich zu vernachlässigen, muss man doch bestimmt bei 4 grakas die man jetzt schon benutzen kann, die auflösung auf extrem hochstellen von den max quali erst garnicht zu reden.

wer sich 4 grakas kauft und nicht ultrahohe auflösungen und/oder FSAA/AF-stufen verwendet sollte sich fragen für was er 4 grakas braucht.
der sinn von SLI ist nicht in "gewöhnlichen" auflösungen doppelt so schnell zu sein, sondern hohe auflösungen und/oder FSAA-stufen zu ermöglichen ohne dass die framerate einbricht.

ist eine cpu schnell genug für ein bestimmtes spiel (dh. die framerate ist ausreichend hoch) ist sie das immer, egal mit welcher graka.
eine stärkere graka erlaubt es "nur" höhere auflösungen, mehr details bzw. FSAA/AF-settings einzustellen als bei einer schwachen graka. die anforderungen an die cpu bleiben gleich.

wie sieht es aus bei tft´s mit 1280*1024, selbst wenn ich da an quali alles rein haue, ist die stärkste cpu, noch in der lage 4 grakas auszulasten ?.

siehe oben, wer sich quad-sli holt sollte sich natürlich auch einen entsprechenden monitor dazu besorgen um es auszunutzen, sonst ist es natürlich sinnlos.

up¦²

2006-04-19, 01:39:05

Hier ein exzellenter artikel zu thema:
http://www.gotw.ca/publications/concurrency-ddj.htm

#44

2006-04-19, 07:28:44

und von wegen: software ist noch nicht optimiert obwohl es schon so lange dc gibt...

bei games: da ist einfach die entwicklungsdauer so lange das die games zwangsweise erst einiges später erscheinen... bei games die bis jetzt erschienen sind ist man bei der entwicklung schon davon ausgegangen das >85% der user noch gar kein dc hat, wenn nicht sogar noch mehr. und games die dann daraufhin programmiert werden sind einfach noch nicht erschienen (2-5 jahre entwicklungszeit eines games (gilt nicht für fortsetzungen;))...)
bei anwendungen: was willst du da zb? ein dc optimiertes word/excel/outlook? bringt doch nichts... bei programmen die einen nutze daraus ziehen (media encoder) gibts die optimierungen schon... und natürlich ist hier die entwicklungszeit auch maßgeblich

ein prog lässt sich im allgemeinen nicht durch einen einfachen patch dc kompatibel machen so wie sich hier das einige vorstellen. wenn der code nicht schon gewisse grundvorraussetzungen erfüllt würde ich es gar als unmöglich bezeichnen (ganz zu schweigen das eine dc optimierung für die meisten älteren programme unnötig ist, da schon zum erscheinungsdatum ausreichend schnelle sc´s verfügbar waren)

ZilD

2006-04-19, 07:51:10

wird ja zeit das intel mal was macht ... eine neue schnelle intel cpu generation in 10 jahren heisst aber noch lange nicht das amd hinten ist.
nur weil intel die letzten jahre hinten war und auf einmal eine leistungsstarke cpu rausbringt soll amd zusperren? :)
never ever

die neue intel cpu könnte nur dann amd angst machen wenn sie billiger wäre und zugleich auch noch schneller als jene von amd.
denke aber nicht das der conroe billig sein wird, somit hat sich das thema auch schon wieder erledigt.

AnarchX

2006-04-19, 08:52:26

die neue intel cpu könnte nur dann amd angst machen wenn sie billiger wäre und zugleich auch noch schneller als jene von amd.
denke aber nicht das der conroe billig sein wird, somit hat sich das thema auch schon wieder erledigt.

Genau danach sieht es ja auch aus.
Der 1000$ FX-62 wurde vom 500$ 2,66Ghz Conroe meist um die 20% übertroffen.
Zudem wird die Produktion von Intel in 65nm billiger als die von AMD in 90nm sein.

Avalox@Gast

2006-04-19, 09:58:17

Genau danach sieht es ja auch aus.
Der 1000$ FX-62 wurde vom 500$ 2,66Ghz Conroe meist um die 20% übertroffen.
Zudem wird die Produktion von Intel in 65nm billiger als die von AMD in 90nm sein.

Ein FX-62 gibt es nicht und wird es auch in der von Intel gezeigten Form nie geben. Die Gemeinsamkeit zum Conroe ist, dass es den Conroe auch nicht auf dem Markt gibt. Wenn der Conroe erscheint, wird auch AMD in der 65nm Produktion sein. Es ist eine müssige Diskussion. Abwarten, Tee trinken und beobachten

CharlieB

2006-04-19, 11:03:43

wird ja zeit das intel mal was macht ... eine neue schnelle intel cpu generation in 10 jahren ....

anscheinend kannst du die letzten 10Jahre Prozessorgeschichte nicht richtig nachvollziehen,
sonst kämst du nicht zu solch einer falschen Aussage

CB

Coda

2006-04-19, 11:43:26

Wenn der Conroe erscheint, wird auch AMD in der 65nm Produktion sein.
Da wär ich mir nicht so sicher.

aylano

2006-04-19, 14:35:06

die neue intel cpu könnte nur dann amd angst machen wenn sie billiger wäre und zugleich auch noch schneller als jene von amd.
Dazu müsste sie aber auch lieferbar sein.

Gut, Intel hat praktisch bis Ende 2006 schon 3 Fabriken in 65er umgestellt, aber die produzieren doch neben den Pentium Ds noch eine ganze Menge wie chips, Nor-speicher und sonstige Chips.

Die 965er Extrem Edition ist doch vor 3 Wochen vorgestellt worden!?!
Bis jetzt ist sie noch nicht einmal bei geizhals gelistet, oder wird sie daweil nur beim OEM-Markt verkauft.

AnarchX

2006-04-19, 16:32:43

Die 965er Extrem Edition ist doch vor 3 Wochen vorgestellt worden!?!
Bis jetzt ist sie noch nicht einmal bei geizhals gelistet, oder wird sie daweil nur beim OEM-Markt verkauft.

Eine Prestige-CPU mit dem Conroe zu vergleichen, welcher Intels neues Lineup in fast allen Preisklassen darstellt, ist doch etwas ungünstig. ;)

AMD ist aktuell in der Notwendigkeit schnell auf 65nm umzustellen, da man mit 90nm nicht mehr sonderlich viel erreichen kann, vor allem nicht die Leistung des Conroes.
Da kann man nur für AMD hoffen, dass der Umstieg auf 65nm nicht wie jener von Intel auf 90nm verläuft. ;)

Bokill

2006-04-19, 16:55:32

Eine Prestige-CPU mit dem Conroe zu vergleichen, welcher Intels neues Lineup in fast allen Preisklassen darstellt, ist doch etwas ungünstig. ;)

AMD ist aktuell in der Notwendigkeit schnell auf 65nm umzustellen, da man mit 90nm nicht mehr sonderlich viel erreichen kann, vor allem nicht die Leistung des Conroes.
Da kann man nur für AMD hoffen, dass der Umstieg auf 65nm nicht wie jener von Intel auf 90nm verläuft. ;) Kannst du mir mal erklären was Fertigungstechnik direkt mit einem CPU Design zu tun hat?

90 nm mit hohem Yield erreicht vor allem eines ... Gewinne & Nachfrage befriedigen.

Was nutzt ein teurer Fertigungsschritt, wenn der Yield und die Stückzahl nicht stimmt? Die letzten Shrinkings waren auch immer mit dem hohen Risiko behaftet, zwar kleiner zu sein (was durch Cache wieder aufgefressen wurde), aber Stromersparnis war damit eben nicht mehr automatisch zu bekommen. Auch der Yield muss stimmen, sonst nützt ein Sprung auf den nächst kleineren Fertigungsknoten gar nichts.

Bist du dir bewusst, dass der "altmodische" Fertigungschritt von AMD in 90 nm in etwa mithält zu den 65 nm Fertigungsschritt von Intel (Strombedarf) und mit der Fab 36 und den grösseren 300 mm Wafern hat AMD einen höheren Durchsatz gegenüber ihrer Fab 30 mit 200 mm Wafern?

MFG Bobo(2006)

Gast

2006-04-19, 16:57:59

aylano

2006-04-19, 17:46:38

Eine Prestige-CPU mit dem Conroe zu vergleichen, welcher Intels neues Lineup in fast allen Preisklassen darstellt, ist doch etwas ungünstig.
Und warum nicht.
Besser gesagt, warum sollte der Conroe-Prestige so leicht herstellbar sein, und er der 965 EE nicht?
Da sollte man sich die Frage stellen, ob am Anfang, wann immer der ist, nicht der Conroe 2,66 Ghz der "Prestige" ist oder doch der eigentliche Prestige CPU Conroe 3 Ghz.
Denn ein 3 Ghz CPU wurde beim IDF nicht gezeigt.
Vielleicht hat das zu bedeuten, dass die noch keinen gescheiten zusammengebracht haben?

AMD ist aktuell in der Notwendigkeit schnell auf 65nm umzustellen, da man mit 90nm nicht mehr sonderlich viel erreichen kann, vor allem nicht die Leistung des Conroes.
Soweit ich weiß, produzieren die schon die Test 65er-Strukturen. Mir kommt es eher vor, dass sie sich eher Zeit lassen und zum richtigen Zeitpunkt es einführen.
Bis dahin wird natürlich weiterhin die Fertigung und die CPUs optimiert.

Faster

2006-04-19, 17:47:20

es ist doch egal wer am ende schneller wird beide firmen arbeiten an ihrer performance aber ich sag amd läst sich mehr zeit für ihre technologien und feil mehr drann aber ich sag amd wir auch noch viel verkaufen weil bei denen der pres einfach stimmt aber pentium wird auf alle fälle noch marktführer bleiben aber leider sind halt die pentiums am einstig meist viel teuerer als die amds also pentium wird was für perfomance bewusste leute und der amd wir halt immer wat für preisbewusste sein
dass is meine meinung wat sagt ihr dazu ???

mfg Andy
ich sag:
schonmal was von satzzeichen gehört? beim lesen deines textes bekommt man ja augenkrebs! :devil:

generell stimme ich dir zu, sollte der conroe wirklich soviel deutlich schneller sein als ein gleich teurer AM2, dann wird AMD mit den preisen runter gehen (müssen).

Gast

2006-04-19, 18:30:12

Kannst du mir mal erklären was Fertigungstechnik direkt mit einem CPU Design zu tun hat?

90 nm mit hohem Yield erreicht vor allem eines ... Gewinne & Nachfrage befriedigen.Nein, die Gewinne und die Ausbeute ist bis auf kleine Schwankungen konstant.
Sonst wuerde das Gewinn- zu Umsatzverhaeltnis von AMD und Intel konstant steigen.

Neue Fertigungstechniken ermoeglichen vor allem erhoehte CPU-Komplexitaet und/oder andere Leistungssteigerungen.

up¦²

2006-04-19, 18:42:18

AM2 launch vorverlegt!

June 6, 2006 didn't fit AMD's schedule

We just got official confirmation from motherboard and chipset manufacturers in Taiwan -- AMD has moved the official launch date of Athlon 64 DDR2 up two weeks to May 23, 2006. AMD roadmaps have previously put the AM2 launch at June 6, 2006 (during Computex 2006), but since motherboards and CPUs are already completed, the launch will be pushed up. AMD insiders tell us Conroe's launch date was also a factor in pushing the AM2 launch date up, though even we do not know the exact date Intel's Conroe will launch.

AMD's latest advisories claimed the following:

May 16, 2006: Global announcement of Energy Efficient Processor roadmap and pricing
May 23, 2006: Global announcement of Socket AM2 and new desktop product availability and pricing
May 31, 2006: Global announcement of AMD LIVE! desktop system availability
http://www.dailytech.com/Article.aspx?newsid=1854

mix mit 666 :biggrin:

Migrator

2006-04-19, 18:46:23

Coda

2006-04-19, 19:12:22

Mit 65nm mit eSiGe dürften locker 4Ghz drin sein, aber das gibts erst nächstes Jahr.

Szenario21

2006-04-19, 19:38:27

auf planet3dnow war heute das zu lesen http://planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1145445277, der schon bekannte vorzeitige release und angebliche Anti Hyperthreading CPU#s die spaeter kommen sollen.

Jetzt ist die Frage, lohnt sich dann ein DC system ueberhaupt noch, denn wenn dieses Anti HT wirklich kommt braucht kein Entwickler mehr fuer mehere Kerne optimieren.

Andererseits ist die Frage wann diese Anti HT CPU#s ueberhaupt kommen, wie teuer sie sein werden und vor allem ob sie das ganze auch gut in die Praxis umsetzen koennen.

dilated

2006-04-19, 20:14:18

ich dachte das ist unmöglich "anti ht"?? :)

wenns möglich ist macht es aber sicher nicht doppelt soviel leistung aus imho

aber für den kunden evtl schon ob nun 1 conroe core oder 1.5 k8 core

da sind die 20% weg (bei nur 50%) sind das in den fällen dann wieder 20% mehr als conroe*gg*(den takt mal wegdenk:P)

wenn das denn kommt, und wenns so gut funktioniert!

was ich mir nicht so ganz vorstellen kann (laut aussagen hier:))

BlackBirdSR

2006-04-19, 20:15:51

Andererseits ist die Frage wann diese Anti HT CPU#s ueberhaupt kommen, wie teuer sie sein werden und vor allem ob sie das ganze auch gut in die Praxis umsetzen koennen.

>Meine Güte..
das stammt von jemand der auf einem Barhocker saß.
Mal ganz langsam mit dieser neuen Supertechnologie.

Neomi

2006-04-19, 21:27:44

Jetzt ist die Frage, lohnt sich dann ein DC system ueberhaupt noch, denn wenn dieses Anti HT wirklich kommt braucht kein Entwickler mehr fuer mehere Kerne optimieren.

Und wenn der gleiche Mist noch weitere 12000x abgeschrieben wird, es bleibt Mist. Man kann nicht mehrere Cores zu einem schnelleren einzelnen Core zusammenfassen, Punkt.

Bokill

2006-04-19, 21:31:54

Nein, die Gewinne und die Ausbeute ist bis auf kleine Schwankungen konstant.
Sonst wuerde das Gewinn- zu Umsatzverhaeltnis von AMD und Intel konstant steigen. Is das dein Ernst? Yield bleibt konstant?! BITTE?! Wo hast du denn diesen Schmonzes her?

AMD hatte zu Zeiten des Thoroughbred A ganz erhebliche Probleme ... da war nix mit konstant ... und Intel hat sich ganz fett in die Nesseln gesetzt mit den ersten Prescotts ... wenn da anfänglich da Konstanz war, dann der anfängliche 90 nm niedrige Prescottyield.

Neue Fertigungstechniken ermoeglichen vor allem erhoehte CPU-Komplexitaet und/oder andere Leistungssteigerungen. Ja das ist immer wieder ein neuere Balanceakt von Feastureset, Transistorbedarf, maximal möglicher Takt, Strombedarf und was weiss ich noch für welche Parameter ...

MFG Bobo(2006)

Avalox

2006-04-19, 23:42:08

>Meine Güte..
das stammt von jemand der auf einem Barhocker saß.
Mal ganz langsam mit dieser neuen Supertechnologie.

Na mal sehen, vielleicht ist dass der erste Hinweise auf eine AMD CPU mit spezialisierten Kernen, welche hinter einem Abstraktionslayer tatsächlich wie ein Kern erscheinen. So was 10x durch die Gerüchtemühle und es kommt eine AntiSMT Technik bei raus.

Bruno[Gast]

2006-04-20, 00:54:56

Das diese Technik vorher nicht parallelisierbaren Code plötzlich paralleliseren kann halte ich auch für sehr unwahrscheinlich.
Dennoch wirkt der Ansatz durchaus nachvollziehbar, denn der Prozessor könnte dank Virtualisierung nun selbst entscheiden wie er mit den ihm präsentierten Aufgaben umgeht. Wäre doch schon von Vorteil wenn zB. das Betriebssystem nicht mehr aus irgendwelchen abstrusen Gründen ständig ein Programm zwischem dem einen Kern und dem anderen hin und herspielt wie einen Ping-Pong Ball, sowas kostet schließlich auch Leistung.
Eine Hardware Lösung bringt da wohl schon Vorteile, wenn man davon ausgeht das der Prozessor selbst am besten weiß wie die Aufgaben verteilt werden sollten.

Coda

2006-04-20, 01:05:38

Es gibt nichtmal eine Software-Lösung, wie soll man das dann in Echtzeit in Hardware lösen?

haifisch1896

2006-04-20, 01:32:09

In Hardware kann ich mir das gut vorstellen, nur wie sollte man es in Software lösen? Ich denke, so einen Treiber vor dem Laden des Betriebssystems zu laden, wäre für die verschiedenen Systeme, die es gibt (Windows, Linux, Unix,...) doch ein zu komplexes und für den Anwender nicht durchführbares Unterfangen.
Denn dieser Treiber müsste ja eigentlich noch vor dem Bootloader geladen werden. Bzw sofort danach.

Ich kenne die Fachbehriffe dafür nicht, aber es muss doch möglich sein, zwei CPU´s wie eine aussehen zu lassen. Schau Dir doch mal den Cell an. Der gibt sich doch auch als nur eine CPU aus und hat dabei einen PowerPC-Kern und acht weitere Unterkerne.

Das einzige, was das Betriebssystem in so einem Fall merken würde, wäre ein Anstieg der CPU-Zeit, um etwas auszuführen, um im besten Fall 100%. So brauch das System die Daten nicht hin- und herverteilen.

Ich stelle mir aber auch die Programmierung des Schedulers ziemlich schwierig vor, denn wenn ein Prozeß alle Kraft für sich verlangt (z.B. Film-Encoding), stocken die anderen ja wieder und wir sind beim Problem der vor-SMT-Zeit. Da fällt dann Spielen und gleichzeitig Filme umwandeln flach.

Sollte da ein Denkfehler sein, bitte berichtigen.

crusader4

2006-04-20, 02:24:10

Ich bin ja auch kein Experte, aber dieses Aussehen lassen wie eine CPU funktioniert nur dann, wenn du einer bestimmten CPU einen bestimmten Befehl zuordnen kannst. Z.B. so, das man sagt: Befehl "add" wird immer von CPU1 ausgeführt, Befehl "mul" geht immer an CPU2. Das hat aber nix mit SMP zu tun, denn du mußt auf die Ergebnisse warten, bis du weitermachst. Sinnvoll ist das wahrscheinlich, wenn du eine spezielle Recheneinheit für bestimmte Befehle einbaust und dann einfach die Befehle entsprechend an die Recheneinheiten verteilst.

Versuchst du aber, eine Befehlsfolge auf mehrere gleichartige Kerne zu verteilen, weil du Dir einen Performancevorteil erhoffst, dann mußt du eigentlich schon vorher wissen, welche Befehle folgen und ob diese voneinander abhängig sind. Das ist schon für Compiler schwierig (und der kann das komplette Programm analysieren), aber für eine Hardware, die nur einen kleinen Ausschnitt aus der Befehlsfolge sieht, unmöglich. So hab ich das bisher zumindest verstanden. Außerdem brauchst du dafür erstmal Algorithmen, die überhaupt parallelisierbar sind. Mit nichtparallelisierbarem Code mußt du nämlich alle Befehle nacheinander ausführen, und da ist es Latte auf welcher CPU das geschieht. Im Zweifel ist dabei eine CPU mit nur einem Kern schneller, weil die Entscheidung, auf welcher CPU nun gerechnet wird, ja auch Zeit kostet.

Ich hoffe ich habe nun nicht völligen Mist geschrieben.

Grüße, Crusader

Neomi

2006-04-20, 02:30:53

Ich kenne die Fachbehriffe dafür nicht, aber es muss doch möglich sein, zwei CPU´s wie eine aussehen zu lassen.

Nein! Es ist nicht möglich. Zwei Cores können sich nur durch eine Art als Singlecore ausgeben, und zwar indem der zweite einfach versteckt wird. Inklusive seiner Rechenleistung allerdings.

Schau Dir doch mal den Cell an. Der gibt sich doch auch als nur eine CPU aus und hat dabei einen PowerPC-Kern und acht weitere Unterkerne.

Nein! Der Cell tut das nicht. Kann er auch nicht, weil ein Prinzipproblem nicht durch eine andere Architektur umgehbar ist.

onkel2003

2006-04-20, 03:14:36

Nein! Es ist nicht möglich. Zwei Cores können sich nur durch eine Art als Singlecore ausgeben, und zwar indem der zweite einfach versteckt wird. Inklusive seiner Rechenleistung allerdings.

Nein! Der Cell tut das nicht. Kann er auch nicht, weil ein Prinzipproblem nicht durch eine andere Architektur umgehbar ist.

dann halt 3 Cores .
eine wird von sys erkannt, und gibt die daten, bzw verteilt diese an die zwei Cores .

oder wie auch immer.
die aussage, Nein! Es ist nicht möglich find ich ein wenig falsch. ausser du sagst mir jetzt du arbeitest vorort, sprich deine mittagspausen machste in der kantine von AMD.
wenn dem nicht so ist, würd ich mit aussagen wie Es ist nicht möglich vorsichtig sein, zumal wir hier in Spekulationen sind, und da ist nun mal alles möglich/unmöglich

BlackBirdSR

2006-04-20, 11:36:19

Ich halte es für wahrscheinliche, dass es bei diesem Barhocker-Gespräch um Überlegungen geht, dass verschiedene Kerne einen gemeinsamen Pool an Ausfürhungseinheiten teilen.
Dazu gibt es bereits verschiedenste Dokumente und anscheinend auch Aussagen von AMD.

Anti-SMT ist das aber keines.

Neomi

2006-04-20, 11:47:46

dann halt 3 Cores .
eine wird von sys erkannt, und gibt die daten, bzw verteilt diese an die zwei Cores .

die aussage, Nein! Es ist nicht möglich find ich ein wenig falsch.

Das geht auch mit 1024 Cores nicht. Code, der nicht parallelisierbar ist, wird mit egal wievielen Cores niemals schneller laufen als mit nur einem einzigen Core gleicher Art. Ich habe schon mehrfach gesagt, daß das nicht einfach nur ein Problem ist, sondern ein Prinzipproblem. Eine Verschmelzung von mehreren Cores zu einem schnelleren Singlecore geht nicht, denn ein schnellerer Singlecore muß auch unparallelisierbaren Code schneller ausführen.

Was ich für durchaus möglich halte (zwar schwierig, aber mit viel Aufwand machbar) ist eine automatische Parallelisierung von parallelisierbarem Code per Hardware, zumindest im kleinen Rahmen. Das wäre dann quasi eine erweiterte Out of Order Execution und kann je nach Code mehr oder weniger Zusatzleistung bringen. Wenn die Gerüchte auf Falschinterpretationen basieren und nicht auf frei erfundenen Informationen, dann wird es sowas sein. Mit einer Verschmelzung mehrerer Cores zu einem hat das aber nichts zu tun.

Bei manchen Dingen reicht einfach ein wenig Logik, um zu wissen, daß sie unmöglich sind. Beispiel: nenne mir eine positive reelle Zahl, die kleiner als 0 ist.

mboeller

2006-04-20, 12:30:22

ich poste das ganze hier mal doppelt:
____________

scheint so zu sein, das auch die dunkle Seite der Macht an diesem Thema arbeitet. Allerdings incl. Compiler + Software support. Das ganze heist dort spekulative Threading.

link (as found on Beyond3D): http://www.intel.com/technology/mag...eading-1205.htm

Pinoccio

2006-04-20, 12:39:13

http://www.intel.com/technology/mag...eading-1205.htmDein Link funktioniert nicht, die (irgendwo) autoamtisch ind er Mite eingefügten Pünktchen passen nicht.

Funktionierender Link (http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm).

mfg Sebastian

dilated

2006-04-21, 01:04:28

Aquaschaf

2006-04-21, 01:47:42

glaub amd hat da leute die sich besser auskennen

Von denen dir jeder bestätigen können wird, dass so etwas grundsätzlich nicht möglich ist.

Neomi

2006-04-21, 02:44:55

glaub amd hat da leute die sich besser auskennen,

wobei das mit dem barhocker schon recht lustig klingt, in jeder lüge ist ein bischen wahrheit(intel arbeitet ja auch dran)

Nochmal zum mitschreiben: nein, es ist nicht möglich. Das wissen auch alle Leute bei AMD und Intel, die sich damit auskennen, und genau deshalb arbeiten sie nicht daran. Sie arbeiten zwar bestimmt daran, Code per Hardware automatisch parallelisieren zu lassen (in kleinem Rahmen), aber so eine "Kernschmelze" ist Schwachsinn. Nicht parallelisierbarer Code läßt sich nunmal nicht parallelisieren.

Das alles läßt sich auf ein kleines Kernproblem reduzieren. Mal angenommen, Instruktion B benötigt zwingend das Ergebnis von Instruktion A. Wie zur Hölle soll man jetzt Instruktion B ausführen (parallel zu A), wenn das Ergebnis von Instruktion A noch nicht vorliegt? Ist es etwa für irgendjemanden nicht offensichtlich, daß das nicht geht?

up¦²

2006-04-21, 02:58:41

AMD Interview
http://www.amdzone.com/modules.php?op=modload&name=Sections&file=index&req=printpage&artid=251

CharlieB

2006-04-21, 11:29:51

...
Bei manchen Dingen reicht einfach ein wenig Logik, um zu wissen, daß sie unmöglich sind. Beispiel: nenne mir eine positive reelle Zahl, die kleiner als 0 ist.

na du hast die Logik ja echt mit der Muttermilch geschlürft ...
Respekt was du alles weißt ;D

CB

Neomi

2006-04-21, 14:04:58

na du hast die Logik ja echt mit der Muttermilch geschlürft ...
Respekt was du alles weißt ;D

Ja, ich kann logisch denken. Was ist daran jetzt so lustig? Wenn du nicht sachlich dagegenhalten kannst, dann laß es einfach bleiben.

Es bleibt weiterhin dabei, daß es nicht einen einzigen vernünftigen Grund gibt, warum eine virtuelle Kernschmelze funktionieren sollte. Dagegen gibt es gute Gründe, warum es nicht funktionieren kann.

Coda

2006-04-21, 14:12:57

Das was sich alle Leute hier vorstellen gibt es doch eh schon. Der Code wird auf mehrere Funktionseinheiten aufgeteilt. Ist halt nur begrenzt möglich und schon mit einem Core weitgehendst ausgereizt.

Gast

2006-04-21, 14:12:59

Ihr mögt ja durchaus Ahnung haben, doch wie viele Dinge galten in der Vergangenheit als unmöglich?!
Da arbeiten Genies mit dementsprechent hohen Gehältern, es gab oft Dinge die für unmöglich gehalten wurden und möglich wurden.

Wer weis was AMD da doktort ;).
Vielleicht müssen die Cores einfach nur mehr möglichkeiten bekommen untereinander u kommunizieren.
Warten wir es ab.

Neomi

2006-04-21, 14:43:25

Ihr mögt ja durchaus Ahnung haben, doch wie viele Dinge galten in der Vergangenheit als unmöglich?!
Da arbeiten Genies mit dementsprechent hohen Gehältern, es gab oft Dinge die für unmöglich gehalten wurden und möglich wurden.

Och nö, nicht schon wieder. Es ist ein Unterschied, ob man etwas für unmöglich hält, weil man bisher keine Lösung gefunden hat, oder ob man weiß, daß etwas unmöglich ist, weil man die Unmöglichkeit sogar beweisen kann. Es ist auch ein Unterschied, ob etwas nur momentan unmöglich ist, weil die Fertigungstechnologie es nicht zuläßt, oder ob etwas schon auf logischer Ebene unmöglich ist. Egal wie genial jemand ist, die Realität umdefinieren kann er nicht.

Das Kernproblem habe ich ein paar Postings weiter oben schon beschrieben:

Das alles läßt sich auf ein kleines Kernproblem reduzieren. Mal angenommen, Instruktion B benötigt zwingend das Ergebnis von Instruktion A. Wie zur Hölle soll man jetzt Instruktion B ausführen (parallel zu A), wenn das Ergebnis von Instruktion A noch nicht vorliegt? Ist es etwa für irgendjemanden nicht offensichtlich, daß das nicht geht?

Das ist doch wirklich offensichtlich, daß es dafür keine Lösung gibt. Genau das würden euch auch die Genies sagen, von denen ihr einfach mal erwartet, daß sie das unmögliche schon irgendwie möglich machen. Ein schon durch simple Logik als unlösbar erkennbares Problem läßt sich auch mit komplexer Logik nicht lösen. Genausowenig, wie ein Mathematik-Nobelpreisträger 2+2=5 richtig sein lassen kann, wobei schon ein Grundschüler das sofort als falsch erkennen muß.

Gast

2006-04-21, 16:35:59

Strom, Autos, Menschen die fliegen.
Es gibt so einiges was mal für unmöglich erklärt wurde.

Coda

2006-04-21, 16:43:46

Man sollte moderne Wissenschaften und Aberglauben evtl. auseinanderhalten.

Eine CPU hat jetzt schon eine Vielzahl von Recheneinheiten. Wenn sich die Rechenleistung damit skalieren ließe dann würde man längst viel mehr davon einbauen anstatt sich mit unglaublich aufwändigen Out-Of-Order-Processing auseinanderzusetzen.

Tut man aber nicht. Seit dem Pentium Pro stagniert das im wesentlichen bei den Integer-ALUs.

Der ganze Sinn hinter Dual Core ist ja, dass sich die Parallelität mittels Hardware nicht mehr ausbauen lässt, deshalb wälzt man das ganze auf die Programmierer ab.

dilated

2006-04-21, 16:53:18

Och nö, nicht schon wieder. Es ist ein Unterschied, ob man etwas für unmöglich hält, weil man bisher keine Lösung gefunden hat, oder ob man weiß, daß etwas unmöglich ist, weil man die Unmöglichkeit sogar beweisen kann. Es ist auch ein Unterschied, ob etwas nur momentan unmöglich ist, weil die Fertigungstechnologie es nicht zuläßt, oder ob etwas schon auf logischer Ebene unmöglich ist. Egal wie genial jemand ist, die Realität umdefinieren kann er nicht.

Das Kernproblem habe ich ein paar Postings weiter oben schon beschrieben:

Das ist doch wirklich offensichtlich, daß es dafür keine Lösung gibt. Genau das würden euch auch die Genies sagen, von denen ihr einfach mal erwartet, daß sie das unmögliche schon irgendwie möglich machen. Ein schon durch simple Logik als unlösbar erkennbares Problem läßt sich auch mit komplexer Logik nicht lösen. Genausowenig, wie ein Mathematik-Nobelpreisträger 2+2=5 richtig sein lassen kann, wobei schon ein Grundschüler das sofort als falsch erkennen muß.

deine meinung kennen wir nun... von kernschmelze und doppelter leistung redet ja wohl auch keiner.....
das das was du willst nicht geht kapiert auch jeder, oder?^^

das heist aber nicht das die leistung bei singlecore anwendungen nicht doch etwas beschleunigt werden kann (was du ja auch selbst sagst:))

man wird sehen, oder auch nicht

stav0815

2006-04-21, 16:54:18

Och nö, nicht schon wieder. Es ist ein Unterschied, ob man etwas für unmöglich hält, weil man bisher keine Lösung gefunden hat, oder ob man weiß, daß etwas unmöglich ist, weil man die Unmöglichkeit sogar beweisen kann. Es ist auch ein Unterschied, ob etwas nur momentan unmöglich ist, weil die Fertigungstechnologie es nicht zuläßt, oder ob etwas schon auf logischer Ebene unmöglich ist. Egal wie genial jemand ist, die Realität umdefinieren kann er nicht.

Das Kernproblem habe ich ein paar Postings weiter oben schon beschrieben:

Das ist doch wirklich offensichtlich, daß es dafür keine Lösung gibt. Genau das würden euch auch die Genies sagen, von denen ihr einfach mal erwartet, daß sie das unmögliche schon irgendwie möglich machen. Ein schon durch simple Logik als unlösbar erkennbares Problem läßt sich auch mit komplexer Logik nicht lösen. Genausowenig, wie ein Mathematik-Nobelpreisträger 2+2=5 richtig sein lassen kann, wobei schon ein Grundschüler das sofort als falsch erkennen muß.
Naja, ich denke der AMD Ansatz wird hierüber gehen, zur Laufzeit paralellisierbaren Code, der noch nicht in Threads gefasst wurde oder schlampig programmiertes zu beschleunigen. Quasi Optimierung in Echtzeit. Wie das geht, hab ich allerdings keine Ahnung...

Neomi

2006-04-21, 17:04:08

Strom, Autos, Menschen die fliegen.
Es gibt so einiges was mal für unmöglich erklärt wurde.

Langsam wird das wirklich nervig. Deine Beispiele fallen in den Bereich Physik. In der Physik kann man neue Details entdecken und bestehende Theorien verfeinern oder umwerfen. Hier geht es aber um Logik, und das ist quasi (und nicht nur quasi) Mathematik. Da gibt es keine Nebeneffekte, die unter bestimmten Bedingungen zu einem speziellen Verhalten führen können. 2+2 wird immer exakt 4 sein, bei jeder Temperatur und bei jeder Luftfeuchtigkeit, an jedem Ort und auch bei Schwerelosigkeit.

Die (definitiv unmögliche) virtuelle Kernschmelze basiert darauf, Instruktionen zu parallelisieren, die nicht parallelisiert werden können. Niemand kann nicht parallelisierbare Instruktionen parallelisieren. Das geht deshalb nicht, weil sie nicht parallelisierbar sind. Sie sind nicht parallelisierbar, weil man sie nicht parallelisieren kann. Klingt komisch, ist aber so.

Neomi

2006-04-21, 17:18:57

deine meinung kennen wir nun... von kernschmelze und doppelter leistung redet ja wohl auch keiner.....
das das was du willst nicht geht kapiert auch jeder, oder?^^

Um "Meinungen" geht es hierbei ja nicht, sondern um richtig oder falsch. Ich bin zwar der einzige hier, der "Kernschmelze" dazu gesagt hat, aber auch nur, weil ich nicht jedes mal "Verschmelzung mehrerer Cores zu einem virtuellen Singlecore" ausschreiben will. Und genau davon reden leider viel zu viele Leute. Diese Kernschmelze ist auch nicht das, was ich will, sondern das, was die Leute erwarten, die das trotzdem noch für möglich halten.

das heist aber nicht das die leistung bei singlecore anwendungen nicht doch etwas beschleunigt werden kann (was du ja auch selbst sagst:))

Ja, das ist möglich und wird Out of Order Execution genannt. Der mögliche Gewinn einer zusätzlichen Verbreiterung ist allerdings klein und manche Algorithmen werden überhaupt nicht davon profitieren können. Und mit dem besagten Anti-Hyper-Threading hat der Ansatz gar nichts zu tun.

Coda

2006-04-21, 17:33:01

das heist aber nicht das die leistung bei singlecore anwendungen nicht doch etwas beschleunigt werden kann
Doch genau das heißt es. Leute das kann nicht mal ein Offline-Compiler - und der hat könnte dafür soviel Rechenleistung verbraten wie er möchte.

GloomY

2006-04-22, 02:24:35

[...] Anti Hyperthreading CPU [...]Bla. Allein der Name ist schon sowas von schlecht.

Den Bemerkungen in diesem Thread zu diesem Thema ("unmöglich" etc.) möchte ich nicht direkt widersprechen, aber ich kenne zumindest eine theoretische Möglichkeit:
Das Einzige, was mir hierbei in den Sinn kommt, wie man mehrere CPU Cores für nur einen Thread nutzen könnte, ist das vor einigen Jahren mal betrachtete Konzept von "Helper-Threads". Nicht nur, dass das imho nie verwirklicht wurde, ich habe davon auch seit mehreren Jahren nichts mehr gehört.

Das Konzept der "Helper-Threads" ist eigentlich recht einfach. Das sind keine echten Programme (im Sinne von Prozessen in einem Betriebssystem) sondern Threads, die das Laufzeitverhalten von anderen Threads probieren zu optimieren, in dem sie einige Instruktionen im Voraus laufen. Wenn es möglich sein sollte, durch diesen zeitlichen Versatz z.B. die Bedingung, an die die Richtung eines Sprungs im Programm geknüpft ist, schon im Vorraus zu berechnen, dann kann man diesen Sprung mit absoluter Sicherheit richtig vorhersagen. Genauso könnte man z.B. das Laden von Daten in den Cache im Voraus machen, wenn der im Voraus laufende Thread den Zugriff darauf als sicher voraussagt.

Nicht nur dass es bei Abhängigkeiten, die echte Ketten bilden, unmöglich ist, etwas im Vorraus zu berechnen, stellt die Komplexität dieser Lösung wohl das größte Problem bei der Realisierung dar. Die Idee ist sicher interessant, aber ich bezeifele dann doch, dass sich das realisieren lässt bzw. dass das Verhältnis von Aufwand zu Nutzen zu schlecht ist.

Neomi

2006-04-22, 16:06:04

Das Konzept der "Helper-Threads" ist eigentlich recht einfach. Das sind keine echten Programme (im Sinne von Prozessen in einem Betriebssystem) sondern Threads, die das Laufzeitverhalten von anderen Threads probieren zu optimieren, in dem sie einige Instruktionen im Voraus laufen. Wenn es möglich sein sollte, durch diesen zeitlichen Versatz z.B. die Bedingung, an die die Richtung eines Sprungs im Programm geknüpft ist, schon im Vorraus zu berechnen, dann kann man diesen Sprung mit absoluter Sicherheit richtig vorhersagen. Genauso könnte man z.B. das Laden von Daten in den Cache im Voraus machen, wenn der im Voraus laufende Thread den Zugriff darauf als sicher voraussagt.

Das ist ein interessantes Konzept, aber es gabt dabei natürlich auch einige Probleme...

Wenn der im Voraus laufende Hilfsthread sich bei einem Sprung verschätzt, dann profitiert der Hauptthread zwar davon, aber der Hilfsthread stallt dadurch. Der Hauptthread holt also auf, der Hilfsthread läuft nicht mehr im Voraus und kann daher nicht mehr mit exakten Sprungvorhersagen dienen. Genau das gleiche passiert mit Cachemisses, die den Hilfsthread bremsen und den Hauptthread aufholen lassen.

Es müßte also eine Möglichkeit für den Hilfsthread geben, Berechnungen zu überspringen (um den Vorsprung wieder auszubauen), indem Instruktionen ausgelassen werden. Das kann nur dann funktionieren, wenn die Ergebnisse mancher Instruktionen vorerst nicht benötigt werden. Der Hilfsthread könnte dann also auf die Ergebnisse des Hauptthreads zugreifen, die in der Zwischenzeit dort berechnet wurden, wenn sie irgendwann später doch benötigt werden sollten. Das wäre dann die Out of Order Execution, die schon als machbar angemerkt wurde. Quasi kein Anti HTT, sondern Parallelisierung on the Fly.

Was nicht in anderer Reihenfolge ausführbar ist (also OOO), kann auch nicht vom Hilfsthread übersprungen werden, er kann quasi bei solchem Code nicht schneller laufen als der Hauptthread selbst. Bei solchem Code ist der maximal mögliche Gewinn (für den Hauptthread) durch Cachehits und richtige Sprungvorhersagen die Zeit, die der Hauptthread verzögert gestartet wird. Hätte der Hauptthread also direkt gestartet, statt erstmal zu warten, wäre er mindestens genauso schnell fertig, einen echten Gewinn gibt es nicht. Nicht für Dinge, die nicht eh schon durch erweitertes OOO abgefangen werden.

Dann gibt es da noch das Problem, daß Systemfunktionen von zwei Threads aufgerufen werden, statt von einem. Sind sie nicht reentrant, wird es Chaos geben (das Problem gibt es auch rein programmintern, wenn der Hilfsthread z.B. globale Variablen verändert). Sind sie reentrant und blockieren z.B. durch eine Critical Section den Zugriff auf eine globale Ressource, kann der Hauptthread sogar durch den Hilfsthread gebremst werden. In der Regel ist es nicht wünschenswert, daß bestimmte Dinge doppelt ausgeführt werden. Wenn ich nur an Dateioperationen denke...

AnPapaSeiBua

2006-04-22, 16:51:15

dann halt 3 Cores .
eine wird von sys erkannt, und gibt die daten, bzw verteilt diese an die zwei Cores .

oder wie auch immer.
die aussage, Nein! Es ist nicht möglich find ich ein wenig falsch. ausser du sagst mir jetzt du arbeitest vorort, sprich deine mittagspausen machste in der kantine von AMD.
wenn dem nicht so ist, würd ich mit aussagen wie Es ist nicht möglich vorsichtig sein, zumal wir hier in Spekulationen sind, und da ist nun mal alles möglich/unmöglich

Wenn du's so siehst, hast Du schon lange Multi-Core-Prozessoren. Ein Prozessor hat ja mehrere Ausführungseinheiten, die Du nach außen hin nicht siehst. Ein Dual-Core-Prozessor, der nach außen hin wie ein Single-Core aussehen sollte, müßte einfach nur doppelt so viele Ausführungseinheiten (und natürlich Decoder usw.) besitzen. Das bringt nur leider nicht viel. Die Ausführungseinheiten werden nicht mal annähernd voll ausgelastet. Sieht man ja am HT des P4, was ja dafür da ist, die Einheiten wieder stärker auszulasten...

BlackBirdSR

2006-04-22, 17:00:44

Sieht man ja am HT des P4, was ja dafür da ist, die Einheiten wieder stärker auszulasten...

Und ich propagiere, dass es in den meisten Fällen einfach nur Leerlauf überbrückt hat und Windowsproblemchen gemildert hat.

AnPapaSeiBua

2006-04-22, 17:12:10

Und ich propagiere, dass es in den meisten Fällen einfach nur Leerlauf überbrückt hat und Windowsproblemchen gemildert hat.

Wozu jetzt genau HT eingeführt wurde, darüber lässt sich natürlch streiten...
Aber die Mehrleistung, die MT-Software teils aus HT ziehen kann, kommt doch vom Nutzen der sonst brachliegenden Recheneinheiten.

Bokill

2006-04-22, 19:25:05

SMT ist keine singuläre Erfindung von Intel.

Das scheinen viele hier zu vergessen. Schon DEC beschäftigte sich sehr früh damit. Leider ist das Projekt EV-8 nur noch vorgestellt worden, aber nie offiziell in Slizium engebrannt worden.

Auch IBM und Sun, Fujitsu haben schon sehr lange SMT in einigen Prozessoren drin ... die haben das Feature aber nicht mit "HyperThreading" bezeichnet.

SMT ist sinnvoll, weil es eine Grundauslastung der CPU sichert. Muss die CPU-Pipeline doch einen Thread nullen, so läuft dann immer noch ein weiterer Thread parallel weiter in der CPU-Pipeline durch ... von der Idee her ist das ein netter Leistungssteigerungsansatz. Im Vergleich zu Dual-Core soll es auch deutlich weniger Transistoren fressen, von daher macht das auch unter dem Blickpunkt Transistorcount/Ökonomie einen Sinn.

Bleibt die Frage der praktischen Umsetzung in der Hardware gemacht, bzw. wie die Software darauf hin (multithreaded) geschrieben wird.

MFG Bobo(2006)

Gast

2006-04-22, 19:36:58

Dein Link funktioniert nicht, die (irgendwo) autoamtisch ind er Mite eingefügten Pünktchen passen nicht.

Funktionierender Link (http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm).

mfg Sebastian

Danke!

Ich hätte den Link wohl nicht einfach per copy und Paste einfügen sollen.

http://www.intel.com/technology/magazine/pix/speculative-threading_g3.gif

Text:

Figure 3. In this graph, the blue bars show the performance improvement going from an in-order to an out-of-order
core with about twice the amount of resources. The red bars indicate the performance of a processor with perfect
memory, illustrating the potential performance improvement for any technique that targets simply reducing memory latency. The yellow bars show the performance gains that result when using Mitosis with a four-core processor.

Intel behauptet auf dieser Seite das ein Quad-Core System bei single-Threaded Apps bis zu 3x schneller sein kann wie ein optimaler Single-Core wenn der Quad-core das speculative Threading benutzt. Der benutzte Benchmark ( Olden benchmark suite ) ist angeblich vor allem single-threaded und lässt sich mit konventionellen Methoden mit Multi-core systemen nahezu nicht beschleunigen. ( siehe link oben ).

grüsse

Manfred

Gast

2006-04-23, 02:21:24

1. Schritt
w=e*g
x=b*c
y=f*y
2. Schritt
z=w*x
k=d*w
l=y+h
3. Schritt
m=z+k
4. Schritt
a=m+l
Läuft so schon schneller auf SingleCore, da er immer mehrere Berechnungen in die Pipeline schieben kann.
Gerade beim Horner-Schema wird mit zunehmendem Grad des Polynoms ausmultiplizieren und bisschen optimieren wesentlich schneller als stupides Formelanwenden. Von Sony Research gabs mal ein interessantes Paper zu solchen Dingen.
Was solld as werden?

Neomi

2006-04-23, 02:47:46

Was solld as werden?

Parallelisierbarer Code. Zuerst war da eine mathematische Formel, bei der jede Operation das Zwischenergebnis der vorherigen Operation benötigte. Durch Ausmultiplizieren wurde eine andere, aber mathematisch äquivalente Formel daraus gemacht. Das sieht zwar umständlicher aus und es sind tatsächlich insgesamt mehr Operationen, die ausgeführt werden müssen, aber mit einem entscheidenden Vorteil. Jetzt können mehrere Operationen parallel zueinander ausgeführt werden (sogar schon mit Singlecore dank mehrerer Funktionseinheiten und Out of Order Execution), so daß die Berechnung insgesamt schneller wird.

Edit: hoppla. Hab gerade erst gesehen, daß du eine spezielle Stelle meinst und den Sinn des Ganzen offenbar kennst. Tja, das wird dann wohl ein Tippfehler sein, da sollte "y=f*g" stehen.

RLZ

2006-04-23, 10:23:27

Edit: hoppla. Hab gerade erst gesehen, daß du eine spezielle Stelle meinst und den Sinn des Ganzen offenbar kennst. Tja, das wird dann wohl ein Tippfehler sein, da sollte "y=f*g" stehen.
So siehts aus ;)

up¦²

2006-04-24, 03:36:29

http://badhardware.blogspot.com/2006/04/amd-65nm-core-g.html

Gast

2006-04-24, 11:07:10

Langsam wird das wirklich nervig. Deine Beispiele fallen in den Bereich Physik. In der Physik kann man neue Details entdecken und bestehende Theorien verfeinern oder umwerfen. Hier geht es aber um Logik, und das ist quasi (und nicht nur quasi) Mathematik. Da gibt es keine Nebeneffekte, die unter bestimmten Bedingungen zu einem speziellen Verhalten führen können. 2+2 wird immer exakt 4 sein, bei jeder Temperatur und bei jeder Luftfeuchtigkeit, an jedem Ort und auch bei Schwerelosigkeit.

Die (definitiv unmögliche) virtuelle Kernschmelze basiert darauf, Instruktionen zu parallelisieren, die nicht parallelisiert werden können. Niemand kann nicht parallelisierbare Instruktionen parallelisieren. Das geht deshalb nicht, weil sie nicht parallelisierbar sind. Sie sind nicht parallelisierbar, weil man sie nicht parallelisieren kann. Klingt komisch, ist aber so.

Es ist wohl "Jedem" klar das man eine Rechnung von x+y=z nicht parallelisieren kann.
Man kann aber theoretisch zwei Rechnungen parallelisieren,

a+b=c
x+y=z

anstatt in Reihe zu rechnen ^^

a+b=c, x+y=z

BlackBirdSR

2006-04-24, 11:24:20

Es ist wohl "Jedem" klar das man eine Rechnung von x+y=z nicht parallelisieren kann.
Man kann aber theoretisch zwei Rechnungen parallelisieren,

a+b=c
x+y=z

anstatt in Reihe zu rechnen ^^

a+b=c, x+y=z

jedoch nicht

a+b = x
x+y = z

Und da liegt der Hund begraben.
Und wenn man es anders machen will, dann nicht mit x86.
Können ja auch IA64 umsteigen und die Drecksarbeit komplett vom Programmierteam und dem Kompiler erledigen lassen.

Gast

2006-04-24, 15:55:30

jedoch nicht

a+b = x
x+y = z

Und da liegt der Hund begraben.Das laesst sich bitorientiert parallelisieren.

Coda

2006-04-24, 15:56:55

Abgesehen davon dass das keine CPU machen wird, von mir aus

a+b = x
x*y = z

Ist doch scheiß egal. Es ist nunmal so dass es tausend Konstrukte gibt die einfach seriell ausgeführt werden müssen.

Gast

2006-04-24, 16:05:35

Abgesehen davon dass das keine CPU machen wird, von mir aus

a+b = x
x*y = z

Ist doch scheiß egal. Es ist nunmal so dass es tausend Konstrukte gibt die einfach seriell ausgeführt werden müssen.Auch hier koennen die einzelnen (Sub-)Operationen parallelisiert werden.
Die Frage was auch praktisch parallelisiert werden sollte ist sehr komplex und kann so einfach nicht beantwortet werden.

Neomi

2006-04-24, 16:27:52

Auch hier koennen die einzelnen (Sub-)Operationen parallelisiert werden.

Na da bin ich aber mal gespannt, wie du eine Addition oder Multiplikation parallelisieren willst. Abgesehen davon, daß eine 32 Bit Addition nicht wirklich langsamer ist als eine 16 Bit Addition, macht eine 32 Bit Addition mehr als nur zwei 16 Bit Additionen.

IVN

2006-04-24, 16:32:51

Na da bin ich aber mal gespannt, wie du eine Addition oder Multiplikation parallelisieren willst. Abgesehen davon, daß eine 32 Bit Addition nicht wirklich langsamer ist als eine 16 Bit Addition, macht eine 32 Bit Addition mehr als nur zwei 16 Bit Additionen.
Nicht alles muss parallelisiert werden. Neue Ressourcen oeffnen neue Moeglichkeiten, so einfach ist das.

Neomi

2006-04-24, 16:51:50

Nicht alles muss parallelisiert werden. Neue Ressourcen oeffnen neue Moeglichkeiten, so einfach ist das.

Ich weiß, daß das nicht parallelisiert werden muß. Aber da der Gast behauptet, daß man es parallelisieren kann (noch stärker als jetzt schon), würde ich doch sehr gerne wissen, wie er sich das vorstellt. Dieses "neue Möglichkeiten durch neue Ressourcen" klingt mir zu sehr nach "keinen Plan, wird aber schon irgendwie gehen". Die jetzigen Volladdierer sind doch schon so weit parallelisiert, wie es nur geht.

IVN

2006-04-24, 16:59:31

Ich weiß, daß das nicht parallelisiert werden muß. Aber da der Gast behauptet, daß man es parallelisieren kann, würde ich doch sehr gerne wissen, wie er sich das vorstellt. Dieses "neue Möglichkeiten durch neue Ressourcen" klingt mir zu sehr nach "keinen Plan, wird aber schon irgendwie gehen". Die jetzigen Volladdierer sind doch schon so weit parallelisiert, wie es nur geht.
Nein, nein, nein, im meinte etwas ganz anderes. Man muss die zusaetzliche "Power" des z.B. 2. oder 4. Kerns nicht in die Vordergrundaufgabe stecken. Man kann etwas anderes damit anstellen z.B. eine 3 TB grosse Datenbank nach irgendetwas durchsuchen waehrend man ein Film (bei einem kalten Bierchen :tongue: ) geniest.

Bokill

2006-04-24, 17:23:29

Heute ist HyperTransport 3.0 (http://www.hypertransport.org/tech/tech_htthree.cfm) [hypertransport.org] raus ... darin ist ein hochinteressanter Modus drin, der virtuell eine 16 Bit breite (bzw- 16 Lanes breite) HyperTransportlinkverbindung in 2 virtuelle 8 Bit breite HyperTransportlinks aufteilt. Darin ist auch der Grund enthalten:

Auto-configuration of Bi-Mode 2x8 or 1x16 Links
Link Splitting or Un-ganging (Optional)

* Auto-Configuration of Bi-Mode 2x8 or 1x16 Link Width
o More HyperTransport Ports Useful in Topologies Such As Symmetric Multi-Processing (SMP)
o Required by Vendors Interested in Dual-Mode Interfaces Mehr Eingänge sinnvoll, wenn der Aufbau dies erfordert. SMP Umgebungen sind ein sinnvolles Einsatzgebiet. Was ist denn ein Dual-Core denn ... es ist doch lediglich ein ganz spezieller Fall einer SMP Umgebung.

So luftleer wie manche glauben, scheint der K8 noch nicht zu sein ...

MFG Bobo(2006)

Avalox@Gast

2006-04-24, 17:38:11

Jetzt bin ich aber verblüfft. Ich dachte dieses konnte HT schon immer.

Neomi

2006-04-24, 17:42:03

Nein, nein, nein, im meinte etwas ganz anderes. Man muss die zusaetzliche "Power" des z.B. 2. oder 4. Kerns nicht in die Vordergrundaufgabe stecken.

OK, falsch verstanden, da muß ich dir natürlich zustimmen. Daß man noch etwas anderes zusätzlich machen kann, ist zwar richtig, aber auch nicht wirklich das Thema. Hier geht es ja alleine um das angebliche Vorhaben, singlethreaded Applikationen durch Multicores zu beschleunigen.

IVN

2006-04-24, 17:45:36

OK, falsch verstanden, da muß ich dir natürlich zustimmen. Daß man noch etwas anderes zusätzlich machen kann, ist zwar richtig, aber auch nicht wirklich das Thema. Hier geht es ja alleine um das angebliche Vorhaben, singlethreaded Applikationen durch Multicores zu beschleunigen.
Naja, da moechte ich nur viel Glueck sagen. :)

Bokill

2006-04-24, 18:08:08

Jetzt bin ich aber verblüfft. Ich dachte dieses konnte HT schon immer. Es geht um eine "Virtuelle" Lösung ...

Dass die Lanes aufgesplittet werden können, das ist in der Tat nichts neues. Es kann sogar asymetrisch die Bandbreite aufgeteilt werden.

z.B. sind 16 Lanes hin zur "Northbridge" möglich, aber die Anbindung zurück kann auch deutlich schmalbandiger sein. Da darf man auch 8, 4, 2, oder gar nur eine Lane zurück legen (ist in der Extremform 16:1 aber sicherlich sinnlos).

Der Punkt ist, dass AMD offensichtlich so etwas wie eine CPU-Kern Aufteilung macht, schon im Datenlink selber, und sich somit Leistungsvorteile gegenüber früheren HTr 2.x verspricht.

MFG Bobo(2006)

Gast

2006-04-24, 18:23:19

Eines von unendlich vielen Beispielen, wo hervorragend innerhalb eines threads parallelisiert werden kann:

for(int i=0; i < model->obj_cnt; i++)
{NormalizeMesh(mesh[i]);
}

Coda

2006-04-24, 18:38:19

Eines von unendlich vielen Beispielen, wo hervorragend innerhalb eines threads parallelisiert werden kann:
Das kann die CPU aber auch nicht selber parallelisieren, dafür ist das Instruction-Window viel zu klein und der Code enthält keinerlei Metainfos zu dem Thema.

Gast

2006-04-24, 18:46:14

Das kann die CPU aber auch nicht selber parallelisieren, dafür ist das Instruction-Window viel zu klein und der Code enthält keinerlei Metainfos zu dem Thema.Der Compiler kann da mithelfen (man kann es aber auch auf der CPU implementieren).
Mit nur einem thread koennen dann mehrere Kerne z.B. an einzelnen Iterationen arbeiten.

Neomi

2006-04-24, 18:51:50

Eines von unendlich vielen Beispielen, wo hervorragend innerhalb eines threads parallelisiert werden kann:

Und was willst du uns jetzt damit sagen? Daß es Code gibt, den man parallelisieren kann? Das ist nichts neues und wurde auch von niemandem bestritten.

Der Compiler kann da mithelfen (man kann es aber auch auf der CPU implementieren).
Mit nur einem thread koennen dann mehrere Kerne z.B. an einzelnen Iterationen arbeiten.

Natürlich kann der Compiler da mithelfen (wenn auch nur in geringem Umfang), dafür gibt es ja OpenMP (in der CPU direkt ist das illusorisch). Aber es geht dabei um die Aufteilung von Code in mehrere Threads. Mehrere Cores gleichzeitig an einem Thread arbeiten zu lassen, kannst du vergessen.

Coda

2006-04-24, 18:52:14

Der Compiler kann da mithelfen (man kann es aber auch auf der CPU implementieren).
Es gibt nichtmal eine vernünftige Lösung mit der ein Compiler automatisch ein Program selbstständig threaden könnte.

Das kannst du völlig knicken in Hardware

Gast

2006-04-24, 18:54:17

Und was willst du uns jetzt damit sagen? Daß es Code gibt, den man parallelisieren kann? Das ist nichts neues und wurde auch von niemandem bestritten.
Natürlich kann der Compiler da mithelfen, dafür gibt es ja OpenMP. Aber es geht dabei um die Aufteilung von Code in mehrere Threads. Mehrere Cores gleichzeitig an einem Thread arbeiten zu lassen, kannst du vergessen.Warum soll die Schleife in threads aufgeteilt werden? Ist doch Kaese!

Gast

2006-04-24, 18:58:39

Es gibt nichtmal eine vernünftige Lösung mit der ein Compiler automatisch ein Program selbstständig threaden könnte.

Das kannst du völlig knicken in HardwareJa eben! Weil threads synchronisiert werden muessen, etc..
Arbeitsschritte wie die Iteration einer Schleife zwischen den Kernen innerhalb eines threads zu verteilen ist dagegen viel einfacher.

Neomi

2006-04-24, 18:59:40

Warum soll die Schleife in threads aufgeteilt werden? Ist doch Kaese!

Damit sie parallel abgearbeitet werden kann. Ich habe langsam das Gefühl, du willst uns hier nur verarschen oder ein wenig spammen. Deine Ansichten zu dem Thema sind sehr laienhaft, und für einen Laien bist du dir viel zu "sicher" in deiner Ausdrucksweise.

Gast

2006-04-24, 19:02:17

Damit sie parallel abgearbeitet werden kann.Warum sollen voneinander unabhaengige Instruktionen in seperate threads aufgeteilt werden?

Coda

2006-04-24, 19:11:56

Arbeitsschritte wie die Iteration einer Schleife zwischen den Kernen innerhalb eines threads zu verteilen ist dagegen viel einfacher.
Soweit "sieht" eine CPU einfach nicht. Und einzelne Instructions verteilt sie schon auf ihre eigenen Ausführungseinheiten. Die Laufzeit bei so feinkörniger Parallelisierung wären wenn man auch noch Berechnungen vom anderen Kern ausführen lässt viel zu lang zudem haben die Kerne allein i.A. eigentlich schon ausreichen Ausführungsresourcen zum auslasten.

Gast

2006-04-24, 19:22:29

Soweit "sieht" eine CPU einfach nicht. Und einzelne Instructions verteilt sie schon auf ihre eigenen Ausführungseinheiten. Die Laufzeit bei so feinkörniger Parallelisierung wären wenn man auch noch Berechnungen vom anderen Kern ausführen lässt viel zu lang zudem haben die Kerne allein i.A. eigentlich schon ausreichen Ausführungsresourcen zum auslasten.Wir reden hier nicht von derzeitigen x86 CPUs!
Ein neuer dispatcher, usw. ist dann natuerlich noetig.

Die Vektorisierung von Arbeitsschritten wie z.B. von einander unabhaengigen Schleifeniteration ueber mehrere Kernen ist doch schon lange in Diskussion und durchaus realisierbar und sinnvoll.

Gast

2006-04-24, 19:24:58

"Die Vektorisierung von Arbeitsschritten"
Nicht nur Vektorisierung, sondern Parallelisierung allgemein.

Coda

2006-04-24, 19:25:55

Die Vektorisierung von Arbeitsschritten wie z.B. von einander unabhaengigen Schleifeniteration ueber mehrere Kernen ist doch schon lange in Diskussion und durchaus realisierbar und sinnvoll.
Ach echt? Und warum kann das dann nichtmal ein Compiler gescheit der dafür beliebig lange Zeit hätte?

Und wie gesagt hat eine CPU dafür viel zu wenig Zeit um sich über sowas "Gedanken zu machen".

Gast

2006-04-24, 19:51:07

Ach echt? Und warum kann das dann nichtmal ein Compiler gescheit der dafür beliebig lange Zeit hätte?Wie "kann nicht"?
Er kann schon, nur parallelisiert er oft nicht, weil es sich wegen des thread-Verwaltung einfach nicht lohnt.

Und wie gesagt hat eine CPU dafür viel zu wenig Zeit um sich über sowas "Gedanken zu machen".Was ist denn das Problem? Es muss nur eine neue CPU-Instruktion eingefuehrt werden.

Beispiel:

Code:

for(int i=0; i < blah; i++)
{vieleInstruktionen(mitdem[i]);
}

Compiler:

diese Schleife ist eine Vektoroperation, also benutze keinen normalen Instruktionssprung, sondern einen "dispatch_core_call"

CPU:

Oh! Ein dispatch_core_call -> core_dispatcher

(speicherzeugs)
core#1: call blah
(speicherzeugs)
core#2: call blah
(speicherzeugs)
core#3: call blah
(speicherzeugs)
core#4: call blah

Coda

2006-04-24, 21:21:11

Dann kannst ja gleich ganz normales Threading machen.

Gast

2006-04-24, 21:34:27

Dann kannst ja gleich ganz normales Threading machen.Nee, threading ist doch viel zu aufwaendig schon alleine wegen der OS-Speicherverwaltung.

Coda

2006-04-24, 23:46:06

Nee, threading ist doch viel zu aufwaendig schon alleine wegen der OS-Speicherverwaltung.
Thread Pools? Was glaubst du was OpenMP macht.

Neomi

2006-04-25, 00:46:36

Nee, threading ist doch viel zu aufwaendig schon alleine wegen der OS-Speicherverwaltung.

Wie du das nun nennst und wieviel Aufwand du reinsteckst, ob nun mit direktem Hardwaresupport oder ohne, das ändert doch nichts am Prinzip. Die Aufteilung von Programmcode auf mehrere Cores ist Multithreading. Und wenn man Threads vorhält und bei Bedarf aktiviert (Workerthreads, die einen Job nach dem anderen abarbeiten und sich bei leerer Jobqueue schlafen legen), dann ist auch der Overhead nicht weiter der Rede wert.

Deine Ausführungen klingen sehr seltsam. Oder wie würdest du es bezeichnen, wenn jemand lieber Autos fährt als Kraftfahrzeuge zu führen, weil letzteres nach mehr Aufwand klingt?

Gast

2006-04-25, 01:07:13

Das softwareseitige Verwaltung von seperaten stacks, synchronisation usw., nicht bedeutungsvoll aufwaendig ist, ist vielleich deine Meinung.
Glaubst du auch dass z.B. Superskalarlogik zum Spass hardwareseitig implementiert ist und vom OS uebernommen werden sollte, oder was?

Wenn Instruktionbloecke ohne Speicherkonflikte parallelisiert werden koennen (was wie im Beispiel oft der Fall ist), dann lohnt es sich sehr wohl dies ohne threading auf mehrere Cores ueber einen hardwareseitigen dispatcher zu verteilen.
Fuer einen Threadwechsel alleine sind mehrere tausend Instruktionen noetig!

Neomi

2006-04-25, 01:38:58

Ein Stack ist grundsätzlich nötig, wenn du eine Funktion aufrufen willst oder auch nur etwas mehr Speicher in der Schleife benötigst, als in die Register paßt. Die komplette Verwaltung mit Stack anlegen und freigeben kannst du dir zur Laufzeit sparen, wenn du Workerthreads für die komplette Laufzeit des Programms vorhälst. Auch ein Threadwechsel ist nicht nötig, wenn auf jedem Core nur ein Workerthread läuft. Die laufen einfach durch und bearbeiten einen Job nach dem anderen. Und schon schmilzt der ganze angebliche Overhead dahin.

Die Threadsynchronisation ist kein Selbstzweck. Threads, die man beim Namen nennt, benötigen nicht mehr Synchronisation als die Dinge, die du beschreibst und die ebenfalls Threads sind (auch wenn du das nicht glauben willst). Wenn zwei Cores vorhanden sind, kann man bei 1000 Schleifendurchläufen jedem Core 500 geben oder auch 10er-Päckchen (falls die Durchläufe eine variable Laufzeit haben) in eine Queue stopfen, das kann man machen wie man will. Eine Synchronisation während der Abarbeitung ist nicht nötig, wenn die Durchläufe eh unabhängig sind.

Und ob das nun von Software oder Hardware kontrolliert wird, macht vielleicht einen Unterschied in der Performance, aber beides ist Multithreading. Wobei eine festverdrahtete Lösung doch arge Nachteile haben kann, wenn es um Flexibilität geht. Softwarelösungen sind quasi beliebig skalierbar, über die Cores einer CPU, mehrere CPUs und sogar mehrere vernetzte Rechner mit jeweils mehreren Multicore-CPUs.

Gast

2006-04-25, 17:01:44

Ein Stack ist grundsätzlich nötig, wenn du eine Funktion aufrufen willst oder auch nur etwas mehr Speicher in der Schleife benötigst, als in die Register paßt.Ah nee! Und ein Computer rechnet mit 1 und 0!

Die komplette Verwaltung mit Stack anlegen und freigeben kannst du dir zur Laufzeit sparen, wenn du Workerthreads für die komplette Laufzeit des Programms vorhälst.Und was soll das bringen? Ist nichts weiter als ein zusaetzlicher thread.

Auch ein Threadwechsel ist nicht nötig, wenn auf jedem Core nur ein Workerthread läuft. Die laufen einfach durch und bearbeiten einen Job nach dem anderen. Und schon schmilzt der ganze angebliche Overhead dahin.Sorry, aber das ist einfach nur Kaese was du da schreibst!
Schon alleine die scope-Groessenordnung von threads liegt in ganz anderen Dimensionen von dem worum es hier geht!
Der overhead schon alleine vom OS scheduler und Stackverwaltung ist gewaltig in Relation zu den parallelisierbaren scopes.

Die Threadsynchronisation ist kein Selbstzweck. Threads, die man beim Namen nennt, benötigen nicht mehr Synchronisation als die Dinge, die du beschreibst und die ebenfalls Threads sind (auch wenn du das nicht glauben willst).Du solltest dich mit den Grundlagen von Threadsynchronisation befassen.
Man braucht keine Threadsynchronisation fuer Vektoroperationen wie die im Beispiel. Alles was man braucht ist eine simple Superskalarlogik.
Ganz zu Schweigen von grossen instruktion scopes die out-of-order, und damit nebenlaeufig verarbeitet werden koennen.

Parallele Verarbeitung ueber mehrere Kerne ohne Softwaresteuerung ist eines der groessten aktuellen Forschungsthemen in der Industrie.
Uebrigens hat Intel mit Hyperthreading diesen Technologieansatz fuer die superskalaren Einheiten des Pentium4 bereits realisiert.
Informier dich einfach mal per Google.

Sk_Antilles

2006-04-25, 17:23:57

Leute, ist ja ganz interessant was ihr hier seit einigen Seiten diskutiert, aber was hat das mit dem Threadtitel zu tun? Eventuell sollte man den Thread aufsplitten. :wink:

Neomi

2006-04-25, 17:26:57

Man braucht keine Threadsynchronisation fuer Vektoroperationen wie die im Beispiel. Alles was man braucht ist eine simple Superskalarlogik.

Doch nicht etwa dein Beispiel mit dem NormalizeMesh. Solange nicht alle diese Meshes eine identische Topologie haben, ist das keine vektorisierbare Operation. Es geht hier nicht um SIMD, sondern um MIMD, jeder Core arbeitet seine eigenen Befehle ab. Und an der Stelle steige ich aus, deinen pseudotechnischen Spam tu ich mir nicht weiter an.

Gast

2006-04-25, 17:43:31

Doch nicht etwa dein Beispiel mit dem NormalizeMesh. Solange nicht alle diese Meshes eine identische Topologie haben, ist das keine vektorisierbare Operation.Wie stellst du dir ein Array ohne "identische Topologie" vor? :)

Es geht hier nicht um SIMD, sondern um MIMD,Es geht um beides.
Vektorisierbare und out-of-order instruction scopes.
Beides lässt sich oft nebenläufig mit meheren Kernen ohne software-threading besser verteilen als mit.

Nerothos

2006-04-25, 21:33:48

Kleiner Zwischeneinwurf von mir: Kann es sein, dass ihr ein wenig vom Weg (Topic) abgekommen seid?
Vielleicht schreibt einer von euch einen Mod an, damit er eure (btw. interessante) Diskussion raussplittet und man hier weiter über den vermuteten Rückstand AMD's auf Intel's neue Architektur diskutieren kann.

Das wäre schön =)

LordDeath

2006-04-28, 23:21:42

gäbe es solch einen compiler, der automatisch alles auf mehrere cores verteilen kann, wäre dieser code dann nicht automatisch langsamer auf einem single core rechner?

up¦²

2006-05-04, 00:33:34

Hier mal eine brauchbare übersicht vom editor vom japan. PcWatch, Hiroshige Goto:
http://tweakers.net/ext/i.dsp/1146653340.gif
http://pc.watch.impress.co.jp/docs/2006/0503/kaigai267.htm

Wie gesagt, erst ende 2007 kommt seiner meinung nach ein neuer (quad)core mit DDR3 und Hyper transport 3

Leonidas

2006-06-26, 07:22:52

Damit hat er ja auch Recht. Das was AMD zum Anfang nächsten Jahres an QuadCores bringen wird, ist für den Workstation-Markt. Die QuadCores für den Desktop kommen wirklich erst später. Erstens weil es derzeit noch zuviel kostet (doppeltes Silizium, nur geringfügig besserer Preis) und zweitens weil die übliche Desktop-Software aus QuadCores nun gar keinen Nutzen mehr zieht, wenn der Nutzen bei DualCore schon überschaubar ist.

Aber dies dürfte bei Intel nicht anders sein. Klar macht es sich hübsch zu sagen, wie bringen QuadCore schon im ersten Halbjahr 2007. Aber auch Intel wird sich ausrechnen können, daß der zu diesem Zeitpunkt auf dem Endkunden-Markt noch wenig zu suchen hat - während der Workstation- und Server-Markt danach lechzt. Wieso QuadCore also nicht zuerst für den Workstation- und Server-Markt?!

Bokill

2006-06-26, 09:40:26

up¦²[/POST]']Hier mal eine brauchbare übersicht vom editor vom japan. PcWatch, Hiroshige Goto:
http://tweakers.net/ext/i.dsp/1146653340.gif
http://pc.watch.impress.co.jp/docs/2006/0503/kaigai267.htm

Wie gesagt, erst ende 2007 kommt seiner meinung nach ein neuer (quad)core mit DDR3 und Hyper transport 3 Nun ja, mit DDR3 (und möglicherweise FB-DIMM) mag er für das Ende vom Jahr 2007 gut liegen.

Was HyperTransport 3.0 (http://www.athlon.de/showflat.php?Cat=&Number=995088&page=1&view=collapsed&sb=5&o=&fpart=1) angeht, da vermute ich schon ab Frühjahr 2007 mit echten Silizium, zumindest ist jetzt schon bekannt, dass der K8L dem HyperTransport 3.0 Standard entspricht. Eine Quelle spricht auch davon, dass der K8L (als Opteron) mit 2 GHz (da DDR Übertragungsverfahren -> 4 GHz Datenratentakt) im Frühjahr 2007 antreten wird.

Allerdings muss auch der Chipsatz HyperTransport 3.0 entsprechen, sonst liegen die Features von HyperTransport 3.0 schlicht brach und der K8L tickt dann wie ein Host mit HyperTransport (http://www.orthy.de/index.php?option=com_glossary&Itemid=55&func=view&id=269) 2.0.

MFG Bobo(2006)

Mad-Marty

2006-06-26, 23:53:36

Ich nehm mir einfach mal eines der Neomi postings.

So absolut unmöglich wie er das darstellt ist das imo nicht.

Klar das "c = a + b; x = b+c" sich nicht parallelisieren lässt - da hat er recht.

Aber selbst die cpu interpretiert den x86 befehlssatz in µops.

Und nicht jede Operation braucht nur einen Takt.

Ich würde mal behaupten 30 % kann man schaffen.
Klar ist ne scheiss erfolgsquote, aber besser als nix stellenweise.

CPUs machen ja jetzt schon OOE (Out of Order Execution),
da lässt sich schon noch was machen denke ich.

Und notfalls rechnet man eben bei sprüngen beide wege vor ;)

Neomi[/POST]']Och nö, nicht schon wieder. Es ist ein Unterschied, ob man etwas für unmöglich hält, weil man bisher keine Lösung gefunden hat, oder ob man weiß, daß etwas unmöglich ist, weil man die Unmöglichkeit sogar beweisen kann. Es ist auch ein Unterschied, ob etwas nur momentan unmöglich ist, weil die Fertigungstechnologie es nicht zuläßt, oder ob etwas schon auf logischer Ebene unmöglich ist. Egal wie genial jemand ist, die Realität umdefinieren kann er nicht.

Das Kernproblem habe ich ein paar Postings weiter oben schon beschrieben:

Das ist doch wirklich offensichtlich, daß es dafür keine Lösung gibt. Genau das würden euch auch die Genies sagen, von denen ihr einfach mal erwartet, daß sie das unmögliche schon irgendwie möglich machen. Ein schon durch simple Logik als unlösbar erkennbares Problem läßt sich auch mit komplexer Logik nicht lösen. Genausowenig, wie ein Mathematik-Nobelpreisträger 2+2=5 richtig sein lassen kann, wobei schon ein Grundschüler das sofort als falsch erkennen muß.

Neomi

2006-06-27, 00:48:26

Mad-Marty[/POST]']Ich nehm mir einfach mal eines der Neomi postings.

So absolut unmöglich wie er das darstellt ist das imo nicht.

Klar das "c = a + b; x = b+c" sich nicht parallelisieren lässt - da hat er recht.

Es ging mir nicht darum, daß es mit DualCore nicht möglich wäre, nicht in Threads unterteilte Programme schneller auszuführen. Daß das mit entsprechend hohem Aufwand prinzipiell geht, ist mir klar. Mir gingen nur die Erwartungen der Leute gegen den Strich, die von den klugen Köpfen bei Intel und AMD Wunder erwarten, ohne sich um das Wie überhaupt Gedanken zu machen.

Mad-Marty[/POST]']Aber selbst die cpu interpretiert den x86 befehlssatz in µops.

Und nicht jede Operation braucht nur einen Takt.

Operationen, die mehr als einen Takt benötigen, lassen sich deshalb noch lange nicht parallelisieren. Man kann, sofern es sinnvoll ist, nahezu beliebig viele Transistoren parallel schalten lassen. Wenn die Schaltungen aber seriell sein müssen (wie das bei Abhängigkeiten nunmal ist), dann hat man eine lange Kette. Und wird die so lang, daß der mögliche Takt darunter leidet (der langsamste Teil bestimmt die Gesamtgeschwindigkeit), dann wird eben gesplittet. Die Abhängigkeit der einzelnen Schaltungspakete ist aber nach wie vor da.

Mad-Marty[/POST]']Ich würde mal behaupten 30 % kann man schaffen.
Klar ist ne scheiss erfolgsquote, aber besser als nix stellenweise.

CPUs machen ja jetzt schon OOE (Out of Order Execution),
da lässt sich schon noch was machen denke ich.

Je nach Software sind vielleicht 30 % machbar, 0 % oder was dazwischen. Wobei mich Ergebnisse über 10 % schon überraschen würden. Mit OoO kann man zwar viel erreichen, je nach Code bringt es aber auch manchmal gar nichts. Die theoretischen Maximalwerte (solange die nicht erreicht werden, kann eine weitere Verbreiterung auch nichts bringen) sind jedenfalls nur Peakwerte, kein Dauerzustand.

Mad-Marty[/POST]']Und notfalls rechnet man eben bei sprüngen beide wege vor ;)

Da gibt es zwar einige Situationen, in denen man das tunlichst vermeiden sollte, aber ja, bei manchen bedingten Sprüngen könnte das was bringen.

Mad-Marty

2006-06-27, 01:18:26

Neomi[/POST]']
Operationen, die mehr als einen Takt benötigen, lassen sich deshalb noch lange nicht parallelisieren. Man kann, sofern es sinnvoll ist, nahezu beliebig viele Transistoren parallel schalten lassen. Wenn die Schaltungen aber seriell sein müssen (wie das bei Abhängigkeiten nunmal ist), dann hat man eine lange Kette. Und wird die so lang, daß der mögliche Takt darunter leidet (der langsamste Teil bestimmt die Gesamtgeschwindigkeit), dann wird eben gesplittet. Die Abhängigkeit der einzelnen Schaltungspakete ist aber nach wie vor da.

Ja das alleine bringt nichts, aber zusammen mit OOE denke ich schon das das was bringen könnte.

Zum Rest: ACK

Wer jetzt 90 - 100 % Mehrleistung erwartet bei spielen glaubt auch an wunder.
Selbst Physik auslagern in threads bei 3d shootern ist schon enorm kompliziert das effizient zu machen, da solange die position der neuen objekte nicht fest steht der renderloop nicht weiter kann.

Dynamische Cachezuweisung wäre z.b. auch noch was, was der conroe macht.

²Thom

2006-06-27, 13:13:51

Wer jetzt 90 - 100 % Mehrleistung erwartet bei spielen glaubt auch an wunder.
Selbst Physik auslagern in threads bei 3d shootern ist schon enorm kompliziert das effizient zu machen, da solange die position der neuen objekte nicht fest steht der renderloop nicht weiter kann.

Dynamische Cachezuweisung wäre z.b. auch noch was, was der conroe macht.

Jau Mad-Marty das mit der dynamischen Zuweisung könnte man noch weiter spinnen.
Dynamische Zuweisung der Pipes, so dass mann diese auf die verschiedenen Cores verteilen kann sozusagen Virtual-Pipes. Je Kern müsste zumindest noch eine Pipe übrig bleiben.

Ich meine das der dickste Threat (das Ballerspiel?!?) 5 Pipes im Kern zugewiesen bekommt und der zweite Kern mit einer Pipe Hintergrundprozesse abarbeiten kann.

D.h. simultanes MP mit 3:3 pipes oder 4:3 oder 5:1 auf 6:0 müsste man denke ich mal verzichten, da es dann kein MP mehr ist. Die anzahl der Pipes wird nach Last verteilt. So lange ein Kern 100% Last hat, bekommt er Pipes zugewiesen, so lange, bis der andere Kern auch 100% hat oder nur noch eine Pipe für ihn übrig ist. Den Grundzustand bildet 3:3.

Käme aber ungefähr auf das gleiche raus wie ein athlon64 Kern mit doppelter Piplineanzahl und dynamischem HT.

Was das an Performance bringt? Im Fall 5:1 und Ballerspiel könnte ich mir Vorstellen, dass man 50-70% gut macht, vorrausgesetzt, die GraKa limitiert nicht.

sputnik1969

2006-06-27, 17:30:47

up¦²[/POST]']Hier mal eine brauchbare übersicht vom editor vom japan. PcWatch, Hiroshige Goto:
http://tweakers.net/ext/i.dsp/1146653340.gif
http://pc.watch.impress.co.jp/docs/2006/0503/kaigai267.htm

Naja, wie brauchbar die Übersicht wirklich ist, kann man sich überlegen, das nicht mal der Manchester-Core drin steht ;)

OBrian

2006-06-29, 14:43:06

Ich halte die Roadmap eher für ziemlich alt, ich glaube, sie sogar vor längerer Zeit schonmal irgendwo gesehen zu haben. So sind z.B. Dual-Core Turions aufgeführt, die es zu dem Zeitpunkt (Ende 2004) gar nicht gab. Dann ist z.B. für Sockel AM2 nur der Windsor aufgeführt, der aber neuerdings nur dem FX vorbehalten wird, der Mainstream Desktop wird mit einem 2x512kB-DualCore bestritten, der natürlich schon längere Zeit geplant ist (er ist ja schon wochenlang im Handel), aber auf dieser Roadmap auch nicht draufsteht. Und die K8L-Cores sind ja wohl eher für 2007 geplant als 2008.

Aber vielleicht sagt der japanische Text daneben auch irgendwas in der Richtung "hier nochmal die Roadmap, die wir 2003 für richtig hielten" oder so ;) Wenn jemand des Japanischen mächtig ist, könnte er ja mal nachlesen.