Deneb vs. Konkurrenz - Performance und Preisgefüge

[Chrizzyy]

Das ging mir gerade auch durch den Kopf , beim K10 ist das doch kein Problem mehr. Bleibt die Frage ob der niedrigere Rechenaufwand durch den höheren Kommunikationsaufwand wieder relativiert wird.

Wenn eine multithreaded Application viel mit den anderen Threads (Kernen) kommunizieren muss was passiert dann? Es entsteht Rechenaufwand. Umso mehr Rechenaufwand entsteht umso langsamer wird eine multithreaded Application. Daher hält man die Kommunikation (den Rechenaufwand) der Threads (Kerne) untereinander so gering wie möglich.

Meint ihr nicht das der Kommunkationsaufwand je nach Anwendung eine mehr oder weniger feste Größe ist? Entweder sind die Berechnungen voneinander abhängig und eine gewisse Datenmenge muss übertragen werden oder nicht, dass man einfach künstlich Kommunikation "erzeugt", um damit eine Berechnung beschleunigen zu wollen kann ich mir nicht wirklich vorstellen... Wo sind die Multithread-Programmierer, sagt mal was dazu

Feste größe? Da gibts keine feste Größe. Das hängt von jedem Programmierer und dessen Applications ab wieviel da kommuniziert wird.

Ich habe in ein paar Posts weiter oben dazu alles erklärt. Egal ob man AMD oder Intel oder Sparc oder sonst was als Plattform benutzt. Zusätzlicher Rechenaufwand verringert die Performance der Application.

Daher ist es das Ziel der multithreaded Programmierung den Rechenaufwand der Threads untereinander so gering wie möglich zu halten.

Man kann auf keinem Fall durch viel Kommunikation der Kerne die Performance erhöhen. Genau das Gegenteil ist der Fall.

Im Enterprise Segment entsteht durch Kommunikation ein weiteres großes Problem. Denn durch den hohen Rechenaufwand der Threads untereinander wäre die Application ncht mehr gut skalierbar. Es ist sehr wichtig, dass sich Enterprise Applications oder HPC Applications sehr gut skalieren lassen.

Daher ist die Vorgabe immer so zu programmieren, dass man den Rechenaufwand der Kerne untereinander so gering wie möglich hält.

 

[Mondrial]

Das ist klar. Aber bei Chrizzyy wird ja angeblich nur nach dem Grundsatz minimaler Kommunikation programmiert. Das kann ich mir für eine dominierende FSB-Architekur zwar vorstellen, aber sobald diese bei Intel abgeschafft wird, ist der Grundsatz größtenteils hinfällig.

 

[Undertaker 1]

Feste größe? Da gibts keine feste Größe. Das hängt von jedem Programmierer und dessen Applications ab wieviel da kommuniziert wird.

Ich habe in ein paar Posts weiter oben dazu alles erklärt. Egal ob man AMD oder Intel oder Sparc oder sonst was als Plattform benutzt. Zusätzlicher Rechenaufwand verringert die Performance der Application.

Daher ist es das Ziel der multithreaded Programmierung den Rechenaufwand der Threads untereinander so gering wie möglich zu halten.

Man kann auf keinem Fall durch viel Kommunikation der Kerne die Performance erhöhen. Genau das Gegenteil ist der Fall.

Im Enterprise Segment entsteht durch Kommunikation ein weiteres großes Problem. Denn durch den hohen Rechenaufwand der Threads untereinander wäre die Application ncht mehr gut skalierbar. Es ist sehr wichtig, dass sich Enterprise Applications oder HPC Applications sehr gut skalieren lassne.

Daher ist die Vorgabe immer so zu programmieren, dass man den Rechenaufwand der Kerne untereinander so gering wie möglich hält.

Gemeint war damit, dass es doch entweder notwendig ist, bestimmte Daten von einem Kern auf den anderen zu übertragen um weiterarbeiten zu können oder eben nicht. Insofern wäre der Kommunikationsaufwand von der Aufgabenstellung an das Programm abhängig und nur bedingt von der Implementierung - Also z.B. bei einem Raytracer kann jeder Kern recht frei für sich rechnen, bei einer KI-Simulation müssen sich die Kerne hingegen untereinander austauschen da Abängigkeiten z.B. durch Interaktionen bestehen.

 

[daysleeper83]

Wenn eine multithreaded Application viel mit den anderen Threads (Kernen) kommunizieren muss was passiert dann? Es entsteht Rechenaufwand. Umso mehr Rechenaufwand entsteht umso langsamer wird eine multithreaded Application. Daher hält man die Kommunikation (den Rechenaufwand) der Threads (Kerne) untereinander so gering wie möglich.

Das ist schon klar was anders habe ich auch nicht gemeint du verstehst mich nicht richtig. Es geht mir um die Relation zwischen Rechenaufwand für die stärkere Kommunikation an sich und den möglichen Einsparungen für die Berechnungen des Programms durch die bessere Kommunikation und Verteilung. Ob das eine das andere relativiert oder das eine oder andere deutlich überwiegt.

 

[Limit]

Gemeint war damit, dass es doch entweder notwendig ist, bestimmte Daten von einem Kern auf den anderen zu übertragen um weiterarbeiten zu können oder eben nicht. Insofern wäre der Kommunikationsaufwand von der Aufgabenstellung an das Programm abhängig und nur bedingt von der Implementierung - Also z.B. bei einem Raytracer kann jeder Kern recht frei für sich rechnen, bei einer KI-Simulation müssen sich die Kerne hingegen untereinander austauschen da Abängigkeiten z.B. durch Interaktionen bestehen.

In der Theorie ist das vollkommen korrekt. Allerdings unterschätzt du die Rolle, die die Implementierung spielt. Nehmen wir als Beispiel einfach mal die genannte KI. Hat man eine einfache, regelbasierte Struktur, kann man das Problem kaum für mehrere Kerne aufteilen und selbst wenn, dann nur mit großem Overhead. Wenn man allerdings wesentlich komplexere Algorithmen benutzt, die z.B. mit Hilfe von Wahrscheinkeiten versuchen vorherzusehen, was passieren könnte, hat man sehr gute Möglichkeiten, das Problem zu zerteilen und unabhängig voneinander auf die Kerne zu verteilen, indem einfach jeder Kern eine andere Variante berechnet.

Die KI der meisten Spiele lässt sich daher nur schlecht parallelisieren. Bei einem Schachprogramm dagegen ist das absolut kein Problem.

Das ist schon klar was anders habe ich auch nicht gemeint du verstehst mich nicht richtig. Es geht mir um die Relation zwischen Rechenaufwand für die stärkere Kommunikation an sich und den möglichen Einsparungen für die Berechnungen des Programms durch die bessere Kommunikation und Verteilung. Ob das eine das andere relativiert oder das eine oder andere deutlich überwiegt.

Wieso sollte man weniger Rechenaufwand haben, wenn man die Kommunikation erhöht? Es ist ja nicht so, dass die Kerne große Mengen an Daten und Zwischenergebnissen auf Vorrat hätten.

 

[daysleeper83]

Bin kein Programmierer. Für mich stellt sich halt die Frage inwieweit es möglich ist durch bessere interne Kommunikation bestimmte Aufgaben schneller abzuarbeiten und wie weit sowas Sinn machen würde ?

 

[mr.dude]

Das ist keine Spekulation, dazu musst du nur die Augen öffnen und den CB-Test ansehen Z.B. im Fall von WiC erkennst du es ganz klar: http://www.computerbase.de/artikel/...hlon_x2_4850e/21/#abschnitt_world_in_conflict

Und was soll ich da sehen? Dass Phenom näher an seiner Leistungsgrenze liegt? Das scheinst ja besonders gute Augen zu haben.

Na endlich hat er's Nun machen wir aus den 1-2 noch realistische 5-6 Fälle, die erhebliche GPU-Limits für die schnelleren CPUs besaßen, und alles ist geklärt

Also langsam wird es nur noch lächerlich. Da wurden gerade mal 6 Spiele getestet. Jedes ist also GPU limitiert und ohne würde Intel viel schneller sein, AMD jedoch nicht? Äusserst einleuchtend und überzeugend. Besonders mit deinen wie immer sachlichen und faktenbasierten Begründungen.

Ach, die Kompetenz der Ersteller reicht schon aus?

Sagen wir mal so, Maxxon halte ich für WEEEEEIIIIITAUS kompetenter als dich.

@Chrizzyy
Ich habe fast das Gefühl, du redest ein wenig am Thema vorbei. Natürlich sollte Thread Kommunikation so gering wie möglich gehalten werden. Du sagtest es ja schon, je mehr Thread Kommunikation, umso mehr unproduktive Rechenlast. Dagegen hat auch niemand etwas gesagt. Genauso wenig, dass man Anwendungen so designed, dass extra Thread Kommunikation stattfindet. Das Problem ist aber, dass du an irgendeinem Punkt nicht mehr drumrum kommst. Spätestens dann, wenn du Threads bzw Objekte synchronisieren musst. Und genau dann kommen auch Vorteile bei AMD zum tragen. Wie viel das ist und ob das ausschlaggebend sein kann, steht wiederum auf einem ganz anderen Blatt geschrieben und hängt vom jeweiligen Szenario ab.

 

[Undertaker 1]

Und was soll ich da sehen? Dass Phenom näher an seiner Leistungsgrenze liegt? Das scheinst ja besonders gute Augen zu haben.

Ich erklär es dir gerne Bei WiC DX10 liegt erst der Penom mit 2,2 - 2,3GHz im GPU Limit. Das erkennst du daran, dass es darüber nur noch geringe Steigerungen gibt. Auf Intelseite reicht hingegen bereits ein E6420. So, nun gibt es auf AMD-Seite maximal noch 300-400MHz mehr zu kaufen (9950BE), auf Intelseite jedoch maximal eine CPU mit bis zu 6-fachem L2 Cache, doppelten Kernen und über 1GHz Mehrtakt. Folgerung? Der schnellste Phenom hat deutlich weniger Luft nach oben als der schnellste Yorkfield, auch wenn es prozentual nur 8% Unterschied auf Grund der GPU-Limitierung sind.

Also langsam wird es nur noch lächerlich. Da wurden gerade mal 6 Spiele getestet. Jedes ist also GPU limitiert und ohne würde Intel viel schneller sein, AMD jedoch nicht?

Leg mir nichts in den Mund, was ich nicht gesagt habe. Ich erwähnte, dass ein GPU-Limit mögliche Unterschiede zwischen verschiedenen CPUs kaschiert. Siehe das Beispiel mit dem E6420, der im Rating nur 2% hinter dem 9950 liegt. Das entspricht genausowenig der Realität, wie das der QX9770 nur 24% schneller ist.

Sagen wir mal so, Maxxon halte ich für WEEEEEIIIIITAUS kompetenter als dich.

Danke, da verkneif ich mir doch mal lieber die Einschätzung wo du liegen wirst

 

[aelo]

http://hardware-infos.com/news.php?news=2284
das dürfte unserem Undertaker 1 gut gefallen

Für mich stellt sich halt die Frage inwieweit es möglich ist durch bessere interne Kommunikation bestimmte Aufgaben schneller abzuarbeiten und wie weit sowas Sinn machen würde ?

jeder Strom der durch XOR/NOR/AND usw.. Schaltungen "geschickt" werden muss, benötigt eine bestimmte Anzahl von Takten um komplett verarbeitet zu werden (pro Takt wird der Strom durch eine Schaltung "geschickt" (und dabei eben die Spannung geändert (symbolisch für 0/1))).

je kürzere/bessere interne Kommunikation -> weniger Schaltungen -> weniger Transistoren -> weniger Takte -> schneller -> kühler -> billiger
dies aber maximal auszunutzen ist eine Kunst und genau das wird beim verbessern auch gemacht, neue Befehlssätze, Verbessern der logischen Schaltungen und ist dann schluss endlich verantwortlich für ein besseres/schlechtere PRO-Takt-Leistungsverhältnis

warum jede Schaltung einen Takt benötigt lässt sich so erklären:
ein Strom wird mithilfe eins Flip-Flops vor und nach jeder Schaltung zwischengespeichert,
das muss damit gemacht werden, damit der Schaltung genügend Zeit bleibt um den Strom zu verarbeiten (Spannung zu erhöhen zu vermindern)
dies wird auch zu einem Verhängnis beim übertakten, sobald man die Clockrate hochjagt (FSB) werden die Flip-Flops schneller geschalten, den Schaltungen bleibt zu wenig Zeit um den Strom zu "verarbeiten" und das gibt dann die Fehler z.b. bei PRIME, weil das Ergebnis das im "Ausgangs"-Flipflop gespeichert ist nicht korrekt ist. Deshalb muss beim erhöhen des Takts eben auch die vCore erhöht werden (leider )

mfg
aelo

 

[mr.dude]

Ich erklär es dir gerne Bei WiC DX10 liegt erst der Penom mit 2,2 - 2,3GHz im GPU Limit. Das erkennst du daran, dass es darüber nur noch geringe Steigerungen gibt. Auf Intelseite reicht hingegen bereits ein E6420. So, nun gibt es auf AMD-Seite maximal noch 300-400MHz mehr zu kaufen (9950BE), auf Intelseite jedoch maximal eine CPU mit bis zu 6-fachem L2 Cache, doppelten Kernen und über 1GHz Mehrtakt. Folgerung? Der schnellste Phenom hat deutlich weniger Luft nach oben als der schnellste Yorkfield, auch wenn es prozentual nur 8% Unterschied auf Grund der GPU-Limitierung sind.

Du scheinst wie immer einiges zu übersehen. Erstmal haben wir von IPC gesprochen, nicht von Modellen mit unterschiedlichen Taktraten. Zweitens ist selbst Intels schnellster Quad im Tests vorhanden. Drittens fallen nur K8 und K10 B2 (TLB?) ab. Wie du hier Rückschlüsse zum K10 B3 ziehen kannst, ist mir schleierhaft. Und viertens und letztens, wie du sehen kannst, ist ein leichter Anstieg nach oben hin zu sehen. Von daher kann es keine reine GPU Limitierung sein. Das Leistungspotenzial jeder CPU muss also zumindest teilweise ausgeschöpft werden.

Leg mir nichts in den Mund, was ich nicht gesagt habe. Ich erwähnte, dass ein GPU-Limit mögliche Unterschiede zwischen verschiedenen CPUs kaschiert.

Aber nicht in dem Ausmasz, wie du glaubst. Wie gesagt, so wie dort getestet wurde, kommt das Intel eher noch zugute.

 

[Undertaker 1]

http://hardware-infos.com/news.php?news=2284
das dürfte unserem Undertaker 1 gut gefallen

Stand da nicht gerade noch ein anderer Name Aber mal im Ernst, was soll ich da auszusetzen haben? Der Deneb bringt nach diesem Test ein durchaus realistisches Leistungsplus und einen sehr guten Verbrauch. Wird, wie ich schon zu Anfang geschrieben habe, ein sehr vergleichbarer Konkurrent des Yorkfield werden. Wie es mit dem Nehalem ausschaut hängt von dessen Leistungssprung und den Taktraten des Deneb ab - meines Wissens zu Beginn maximal 2,8GHz?

Du scheinst wie immer einiges zu übersehen. Erstmal haben wir von IPC gesprochen, nicht von Modellen mit unterschiedlichen Taktraten. Zweitens ist selbst Intels schnellster Quad im Tests vorhanden. Drittens fallen nur K8 und K10 B2 (TLB?) ab. Wie du hier Rückschlüsse zum K10 B3 ziehen kannst, ist mir schleierhaft. Und viertens und letztens, wie du sehen kannst, ist ein leichter Anstieg nach oben hin zu sehen. Von daher kann es keine reine GPU Limitierung sein. Das Leistungspotenzial jeder CPU muss also zumindest teilweise ausgeschöpft werden.

Nein, wir sprachen davon das es ein GPU-Limit gibt, dass schnellere CPUs im Rating benachteiligt. Desweiteren hast du wohl den 9150e (B3) übersehen . Und zum letzten, zweifellos richtig. Gerade die Explosionen ziehen für kurze Zeit die FPS rein CPU-limitiert stark nach unten, was auch noch für sehr viel schnellere CPUs als getestet eine gewisse Skalierung ermöglicht. Wie stark diese war kannst du z.B. am Vergleich Q6600 zu QX9770 erkennen, aus 39/42% (Anwendungen/Multimedia) werden schmale 8%, was ein GPU-Limit des WiC Tests bei CPUs dieser Leistung von grob abgeschätzt 80% ergibt, aber auf einen solchen Wert müssen wir uns jetzt gar nicht festnageln.

Aber nicht in dem Ausmasz, wie du glaubst. Wie gesagt, so wie dort getestet wurde, kommt das Intel eher noch zugute.

Beispiel CoH: Ein QX9770 fällt von Low auf High von 78% Vorsprung zum E6420 auf 10%. Willst du behaupten, dass sich Faktoren wie Kernskalierungen auch nur annähernd in dieser Größenordnung bewegen bzw. wie du sagst sie sogar übertreffen, damit AMD benachteiligt wäre?

 

[mr.dude]

Nein, wir sprachen davon das es ein GPU-Limit gibt, dass schnellere CPUs im Rating benachteiligt.

Diese Benachteiligung liegt aber weniger zwischen Quadcore A und Quadcore B, sondern eher zwischen Dualcore und Quadcore.

Desweiteren hast du wohl den 9150e (B3) übersehen .

Dort steht ein "sim.". Soll ich der verraten, was das bedeutet? Oder kommst du da selbst drauf? Weitere Diskussionen sind an dieser Stelle also Spekulation.

Wie stark diese war kannst du z.B. am Vergleich Q6600 zu QX9770 erkennen, aus 39/42% (Anwendungen/Multimedia) werden schmale 8%, was ein GPU-Limit des WiC Tests bei CPUs dieser Leistung von grob abgeschätzt 80% ergibt, aber auf einen solchen Wert müssen wir uns jetzt gar nicht festnageln.

Erstmal solltest du aufhören, dir ständig irgendwelche Rosinen rauszupicken. Was für einen Sinn macht es denn, einzelne Anwendungen mit ganzen Bereichen zu vergleichen? Da könnte ich genauso gut argumentieren, zwischen Q6600 und QX9770 liegen 27% bei 7-zip, bei Spielen 21%. Passt also. Und bitte höre endlich mit diesem Anwendungsbereich Geschwätz auf. So wie ich das sehe, fliessen hier die zwei Packer (7-zip, Winrar) und die für AMD-Intel Vergleiche wenig aussagekräftigen Cinebench und Lighwave (ICC) Tests ein. Auch seltsam, im anderen Thread streitest du die Gültigkeit für Winrar als CPU Test ab. Hier plötzlich soll das aber nicht mehr gelten?

Beispiel CoH: Ein QX9770 fällt von Low auf High von 78% Vorsprung zum E6420 auf 10%. Willst du behaupten, dass sich Faktoren wie Kernskalierungen auch nur annähernd in dieser Größenordnung bewegen bzw. wie du sagst sie sogar übertreffen, damit AMD benachteiligt wäre?

Meine Güte, kannst du es nicht endlich mal bleiben lassen? Dass Intels CPU Potenzial sich bei diesen Einstellungen nicht 1 zu 1 in Frames bemerkbar macht, kann ja nun jeder sehen. Dort ist 1 (!) B3 Phenom. Woran kannst du bitteschön erkennen, dass es dort anderes ist?

 

[Undertaker 1]

Diese Benachteiligung liegt aber weniger zwischen Quadcore A und Quadcore B, sondern eher zwischen Dualcore und Quadcore.

Hä? Keines der getesteten Spiele profitiert nennenswert von einem Quad. Mehrtakt kannst du bei Abwesenheit anderer Limitierungen hingegen durchgängig in Mehrleistung umwandeln.

Dort steht ein "sim.". Soll ich der verraten, was das bedeutet? Oder kommst du da selbst drauf? Weitere Diskussionen sind an dieser Stelle also Spekulation.

Hier ziehst du dich aber ganz billig aus der Affäre...

Erstmal solltest du aufhören, dir ständig irgendwelche Rosinen rauszupicken. Was für einen Sinn macht es denn, einzelne Anwendungen mit ganzen Bereichen zu vergleichen?

Bei einer bis auf die Cachemenge praktisch identischen Architektur sehr viel. Wenn dich dieser Makel noch stört, nimm den Q9450 und den QX9650 (11% zu 1%). Der Vergleich ist rein technisch makellos und zeigt das gleiche.

Da könnte ich genauso gut argumentieren, zwischen Q6600 und QX9770 liegen 27% bei 7-zip, bei Spielen 21%.

Nein das kannst du nicht, du hast wohl aus dem anderen Thread vergessen das Packer viel zu sehr am Ram hängen

Und bitte höre endlich mit diesem Anwendungsbereich Geschwätz auf. So wie ich das sehe, fliessen hier die zwei Packer (7-zip, Winrar) und die für AMD-Intel Vergleiche wenig aussagekräftigen Cinebench und Lighwave (ICC) Tests ein. Auch seltsam, im anderen Thread streitest du die Gültigkeit für Winrar als CPU Test ab. Hier plötzlich soll das aber nicht mehr gelten?

Der Meinung bin ich nach wie vor, also nimm die beiden Packer gerne heraus wenn du möchtest. Der reale Komprimierungsvorgang ist aber zumindest im Fall von Winrar deutlich CPU-abhängiger als der Benchmark, was an der besseren Takt-Skalierung erkennbar ist.

Meine Güte, kannst du es nicht endlich mal bleiben lassen? Dass Intels CPU Potenzial sich bei diesen Einstellungen nicht 1 zu 1 in Frames bemerkbar macht, kann ja nun jeder sehen. Dort ist 1 (!) B3 Phenom. Woran kannst du bitteschön erkennen, dass es dort anderes ist?

Ich fange jetzt nicht an zu zählen wie oft ich schon erwähnt habe, dass dies die schnelleren Phenoms in exakt gleicher Weise betrifft, siehe den Vergleich zum E6420 im Spielerating - weit unter der realen Differenz. Je schneller eine CPU ist, desto größer ist der Nachteil durch anteilig immer weiter steigende GPU-Limits. Siehe den 4050e, der wohl fast vollständig am Limit arbeiten kann und so fast perfekt skalierte 9% hinter dem 4450e liegt. Die schnellste CPU, der QX9770, wird somit am stärksten benachteiligt.

 

[mr.dude]

Ich fange jetzt nicht an zu zählen wie oft ich schon erwähnt habe, dass dies die schnelleren Phenoms in exakt gleicher Weise betrifft

Toll, du redest also seitenlang vollkommen am Thema vorbei. Wenn ich dich vielleicht nochmal erinnern darf, es ging um IPC zwischen K10 und Core2. Seitenlanges offtopic deinerseits, nur weil du nicht weisst, um welches Thema es geht. Danke fürs Gespräch.

 

[Undertaker 1]

Hast du nicht immer wieder nachgehakt? Aber bitte, dann jetzt

 

[neowkewl]

hehehe wasn scheiss thread -gg- total sinfrei -gg-


dachte hier steht was objektives bzw ein paar news -g- aber wundert mich umsomehr warum nicht speku thread vorm thread steht -.-

und weil hier alles offtopic ist -gg- mein phenom B2 aus der signatur läuft auf meinem asrock board für 20 euro von ebay mit 2,8 ghz -gg-

 

[DonGeilo]

Was nen Thead, das der im EXTREM OFFTOPIC ausartet war klar schon der erste POST ist PROVOZIEREND.

 

[Mondrial]

Könnt ihr mal aufhören Kritik zu üben?!? Dieser Thread wird von der Moderation unterstützt. Kritik wird einfach wortlos gelöscht...

 

[Limit]

jeder Strom der durch XOR/NOR/AND usw.. Schaltungen "geschickt" werden muss, benötigt eine bestimmte Anzahl von Takten um komplett verarbeitet zu werden (pro Takt wird der Strom durch eine Schaltung "geschickt" (und dabei eben die Spannung geändert (symbolisch für 0/1))).

je kürzere/bessere interne Kommunikation -> weniger Schaltungen -> weniger Transistoren -> weniger Takte -> schneller -> kühler -> billiger
dies aber maximal auszunutzen ist eine Kunst und genau das wird beim verbessern auch gemacht, neue Befehlssätze, Verbessern der logischen Schaltungen und ist dann schluss endlich verantwortlich für ein besseres/schlechtere PRO-Takt-Leistungsverhältnis

warum jede Schaltung einen Takt benötigt lässt sich so erklären:
ein Strom wird mithilfe eins Flip-Flops vor und nach jeder Schaltung zwischengespeichert,
das muss damit gemacht werden, damit der Schaltung genügend Zeit bleibt um den Strom zu verarbeiten (Spannung zu erhöhen zu vermindern)
dies wird auch zu einem Verhängnis beim übertakten, sobald man die Clockrate hochjagt (FSB) werden die Flip-Flops schneller geschalten, den Schaltungen bleibt zu wenig Zeit um den Strom zu "verarbeiten" und das gibt dann die Fehler z.b. bei PRIME, weil das Ergebnis das im "Ausgangs"-Flipflop gespeichert ist nicht korrekt ist. Deshalb muss beim erhöhen des Takts eben auch die vCore erhöht werden (leider )

mfg
aelo

Deine Ausführung ist ein wenig stark vereinfacht, aber im Prinzip richtig. Allerdings war das eigentlich nicht die Antwort auf die Frage, da es nicht um die Kommunikation in einem Kern, sondern um die Kommunikation zwischen den Kernen geht. Also Crossbar vs. FSB.

 

[aelo]

Deine Ausführung ist ein wenig stark vereinfacht, aber im Prinzip richtig. Allerdings war das eigentlich nicht die Antwort auf die Frage, da es nicht um die Kommunikation in einem Kern, sondern um die Kommunikation zwischen den Kernen geht. Also Crossbar vs. FSB.

sorry, naja, die Kommunikation zwischen den Kernen wird ja auch ähnlich sein
sind ja im Prinzip auch nur Transistoren und da gelten die selben physikalischen Gesetze (muss aber zugeben hab die Postings davor nicht wirklich durchgelesen)

und natürlich stark vereinfacht, detailiert wäre zu viel gewesen, dass müsste ich selbst auch in den Unterrichtsnotizen nachlesen ^^
außerdem hab ich das alles nur anhand des 8086 gelernt und der ist auch stark vereinfacht, wobei die Prinzipien die selben sind

mfg
aelo

 

[Limit]

sorry, naja, die Kommunikation zwischen den Kernen wird ja auch ähnlich sein
sind ja im Prinzip auch nur Transistoren und da gelten die selben physikalischen Gesetze (muss aber zugeben hab die Postings davor nicht wirklich durchgelesen)

Nun, da hast du eine entscheidende Sache übersehen. Im Gegensatz zu den AMD Quads haben Intel Quads keinen gemeinsamen Cache und auch keinen sonstigen direkten Kommunikationskanal zwischen den beiden Dualcore-Hälften. Damit läuft die Kommunikation zwischen den beiden Dualcores innerhalb des Quadcores über den FSB ab, an dem auch Graka, I/O und vor allem der RAM hängt. Da kann man sich vorstellen, dass da zusätzliche Interprozessor-Kommunikation nicht ohne zusätzliche Verzögerungen erfolgen kann.

Ich denke Spiele wären eine Kategorie, bei der man prinzipiell den Unterschied zwischen echtem und "nicht echtem" Quadcore merken sollte. Das Problem dabei ist im Moment allerdings, dass es kein Spiel gibt, dass 4 Cores wirklich auslasten kann. 2 Kerne werden mittlerweile ganz ordentlich ausgelastet, aber die übrigen 2 Cores machen meist nur irgendwelche Hilfsjobs. Daher fällt der theoretische Nachteil der Core-Quads auch kaum auf. Ich denke es wird noch einige Zeit dauern, bis es Spiele gibt, die auch mit 4 Kernen noch gut skalieren werden. Da Intel bis dahin wohl schon Nehalem rausgebracht haben wird, wird die kleine Schwäche der aktuellen Core-Architektur in der Hinsicht wohl niemals Relevanz erfahren.

 

[F-kopp]

Nun, da hast du eine entscheidende Sache übersehen. Im Gegensatz zu den AMD Quads haben Intel Quads keinen gemeinsamen Cache und auch keinen sonstigen direkten Kommunikationskanal zwischen den beiden Dualcore-Hälften. Damit läuft die Kommunikation zwischen den beiden Dualcores innerhalb des Quadcores über den FSB ab, an dem auch Graka, I/O und vor allem der RAM hängt. Da kann man sich vorstellen, dass da zusätzliche Interprozessor-Kommunikation nicht ohne zusätzliche Verzögerungen erfolgen kann.

Ich denke Spiele wären eine Kategorie, bei der man prinzipiell den Unterschied zwischen echtem und "nicht echtem" Quadcore merken sollte. Das Problem dabei ist im Moment allerdings, dass es kein Spiel gibt, dass 4 Cores wirklich auslasten kann. 2 Kerne werden mittlerweile ganz ordentlich ausgelastet, aber die übrigen 2 Cores machen meist nur irgendwelche Hilfsjobs. Daher fällt der theoretische Nachteil der Core-Quads auch kaum auf. Ich denke es wird noch einige Zeit dauern, bis es Spiele gibt, die auch mit 4 Kernen noch gut skalieren werden. Da Intel bis dahin wohl schon Nehalem rausgebracht haben wird, wird die kleine Schwäche der aktuellen Core-Architektur in der Hinsicht wohl niemals Relevanz erfahren.

WORD!
Mein reden.

Es gibt ein paar konsolenportierte Spiele, die auch 3 Kerne ganz gut auslasten sollten.
Immerhin hat man dort ja einen Tricore + SMT.

ich bin schon richtig gespannt auf GTA 4.
mal schauen, ob man für die Portierung ein halbes Jahr gebraucht hat oder ob da ein nativer Quad endlich richtig zur geltung kommen kann.

 

[aelo]

Da kann man sich vorstellen, dass da zusätzliche Interprozessor-Kommunikation nicht ohne zusätzliche Verzögerungen erfolgen kann.

das ist natürlich eine Tatsache, aber die Architektur wurde ja schließlich auch darauf optimiert (auf FSB)
maybe ist auch dass einer der Gründe warum Multithreaded-Anwendungen von der AMD-Architektur profitieren
aber auch daran arbeitet Intel, man darf also auf Nehalem gespannt sein

Und wie kommst du darauf das Spiele von nativen QuadCores + HT/QPI profitieren? Könnte hier mir höchstens die Physik-Effekte vorstellen.

Ich denke Spiele wären eine Kategorie, bei der man prinzipiell den Unterschied zwischen echtem und "nicht echtem" Quadcore merken sollte. Das Problem dabei ist im Moment allerdings, dass es kein Spiel gibt, dass 4 Cores wirklich auslasten kann. 2 Kerne werden mittlerweile ganz ordentlich ausgelastet, aber die übrigen 2 Cores machen meist nur irgendwelche Hilfsjobs. Daher fällt der theoretische Nachteil der Core-Quads auch kaum auf. Ich denke es wird noch einige Zeit dauern, bis es Spiele gibt, die auch mit 4 Kernen noch gut skalieren werden.

es gibt auch noch Anwedungen außerhalb der Spielewelt

Da Intel bis dahin wohl schon Nehalem rausgebracht haben wird, wird die kleine Schwäche der aktuellen Core-Architektur in der Hinsicht wohl niemals Relevanz erfahren.

dito

mfg
aelo

 

[Undertaker 1]

Ich denke Spiele wären eine Kategorie, bei der man prinzipiell den Unterschied zwischen echtem und "nicht echtem" Quadcore merken sollte. Das Problem dabei ist im Moment allerdings, dass es kein Spiel gibt, dass 4 Cores wirklich auslasten kann.

Die gibt es schon, nur leider keinen einzigen Test, der Phenom mit 1/2/4 Kernen gegen Yorkfield (oder auch Kentsfield) mit 1/2/4 Kernen testet - dann könnte man erkennen, in wie weit dieser theoretische Nachteil auch wirklich praxisrelevant ist, und nur das ist von Bedeutung... Bei den Tests, wo zumindest der C2Q allein dabei ist, kann ich zumindest keine wirklichen Skalierungsprobleme erkennen, man beachte die Minimum-FPS:

http://enthusiast.hardocp.com/article.html?art=MTMwNiw1LCxoZW50aHVzaWFzdA==

 

[KarottenRambo]

Supreme Commander profitiert kaum von Quad-Cores, Assassins Creed & UT3 haben einen deutlich besseren Multicore-Support.
Außerdem steht da nicht wie diese Werte ermittelt wurden, wenn der Perftest genutzt wurde kann man es eigentlich schon direkt in die Tonne kloppen, da der sich nicht immer identisch abspielt. Wenn dann ein paar Explosionen gleichzeitig erscheinen, kann sich die Min-FPS selbst mit gleichem System vom vorherigen Durchlauf unterscheiden.

 

[Undertaker 1]

Wie du siehst profitiert es sogar perfekt von Quadcores, 100% und mehr (durch diverse FPS-unabhängige Hintergrundberechnngen) bei den min-fps. Getestet wurde folgendermaßen:

"The following article represents countless hours of real gameplay scenarios played out over and over to validate results"

 

[KarottenRambo]

Der Test lässt sich allerdings mit dem Test nicht vereinbaren und wenn man sich die Prozessorauslastung anschaut, sieht man auch das sich die FPS nicht so radikal verbessern können, wie bei deinem Link.

 

[Limit]

Die gibt es schon, nur leider keinen einzigen Test, der Phenom mit 1/2/4 Kernen gegen Yorkfield (oder auch Kentsfield) mit 1/2/4 Kernen testet - dann könnte man erkennen, in wie weit dieser theoretische Nachteil auch wirklich praxisrelevant ist, und nur das ist von Bedeutung... Bei den Tests, wo zumindest der C2Q allein dabei ist, kann ich zumindest keine wirklichen Skalierungsprobleme erkennen, man beachte die Minimum-FPS:

http://enthusiast.hardocp.com/article.html?art=MTMwNiw1LCxoZW50aHVzaWFzdA==

Jein. Die FPS lassen auf eine gute Skalierung schließen, allerdings wird in dem gleichen Test festgestellt, dass nur eine CPU voll ausgelastet wird und die andern Cores max. 50% oder noch weniger genutzt werden. Daher find ich es schon seltsam, dass praktisch 1 Core + 3 * 1/2 Core trotzdem bei Min-FPS etwa die 4-fache Leistung bringen. Desweiteren ist es seltsam, dass der Wechsel von 1 auf 2 Cores mehr als 100% Geschwindigkeitsgewinn bringt und zwar bei Min und Avg FPS.Das legt für mich den Verdacht nah, dass dort ein ganz anderer Faktor mit im Spiel ist. Welcher das ist, kann ich im Augenblick allerdings nicht sagen. Selbst wenn bei diesem einen Spiel die Skalierung so gut wäre, müsste man noch wesentlich mehr Spiele testen, bevor man daraus etwas schließen könnte.

 

[Undertaker 1]

Der Test lässt sich allerdings mit dem Test nicht vereinbaren und wenn man sich die Prozessorauslastung anschaut, sieht man auch das sich die FPS nicht so radikal verbessern können, wie bei deinem Link.

Bei deinem Link liegen praktisch alle CPUs gleichauf -> GPU Limit.

Übrigens, die Steigerungen von z.T. >100% kommen durch FPS-unabhängige Hintergrundberechnungen, dass lässt sich auch in anderen Spielen beobachten.

 

[Limit]

Bei deinem Link liegen praktisch alle CPUs gleichauf -> GPU Limit.

Übrigens, die Steigerungen von z.T. >100% kommen durch FPS-unabhängige Hintergrundberechnungen, dass lässt sich auch in anderen Spielen beobachten.

Wenn die FPS sich dabei verändern, sind diese Berechnungen keinenfalls FPS-unabhängig.
Außerdem würde das nur einen Sinn ergeben, wenn man das Spiel extrem CPU-limitiert wäre. Wenn hier das der Fall wäre, wäre der Multicore-Support doch sehr bescheiden, denn das Spiel wäre dann CPU-limitiert und würde trotzdem nur einen Core komplett ausnutzen. Der Grund für den die großen Performanceunterschiede wäre dann allerdings nicht die gute Skalierbarkeit des Prozessors, sondern schlechte Qualität des Codes, der es irgendwie schafft CPUs mit wenigen Cores stark auszubremsen.

Es braucht also mehr Tests mit mehr Programmen, sonst ist das alles nur Raterei.