Deneb vs. Konkurrenz - Performance und Preisgefüge

[Mondrial]

Hör auf mir Worte in den Mund zu legen! Du scheinst dir sehr sicher zu sein, das Nehalem entweder eher oder zur gleichen Zeit wie Deneb erscheint. Da wäre ich mir nicht so sicher und nur darauf wollte ich hinaus

Den AMD 45nm Daneb darf man eigentlich auch nicht mit den aktuellen 45nm Prozessoren von Intel vergleichen.

Der FSB wird abgeschafft und der Nehalem steht vor der Tür. Angesichts dieser Tatsache, sollte man den Daneb mit der kommenden Nehalem Generation vergleichen, da die ungefähr zeitgleich auf den Markt kommen werden.

 

[F-kopp]

Was meinst du damit?
Es gibt keine DualCore Anwendungen.

Entweder ist eine Application multithreaded programmiert oder nicht. Und wenn sie multithreaded ist kann sie alle verfügbaren Prozessoren ansprechen. Egal ob 2, 4, 8 oder mehr Kerne.

Die aktuellen Intel Prozessoren sind doch schon in der Singlecore und Multicore Leistung erheblich stärker als die AMD Konkurrenz. (trotz FSB)

Warum soll beim Nehalem die Leistung dann verpuffen bei Single Core Anwendungen?

schon mal was von 7zip gehört?
informiere dich mal, bevor du son unqualifizierten Unsinn von dir gibst.

 

[Chrizzyy]

schon mal was von 7zip gehört?
informiere dich mal, bevor du son unqualifizierten Unsinn von dir gibst.

Es gibt keine Dualcore Anwendungen. Es gibt Anwendungen die auf 2 Threads limitiert sind.
Aber sowas nennt man nicht Dualcore Anwendungen!

Auch wenn 7 zip maximal 2 Prozessoren zum packen/entpacken benutzt ist es keine Dualcore Anwendung. Vielmehr ist 7 Zip auf 2 Threads limitiert, da es keinen Sinn macht mehr Kerne für 7zip zu nutzen. Und warum das so ist, da musst du die 7 zip Developer fragen.

Da ich selbst Programmierer bin kann ich dir das ziemlich sicher sagen.

 

[F-kopp]

es ist egal wie man es nennt.
Wenn 7zip nur 2 Threads benutzt, benutzt es auch nur 2 Kerne.

 

[Chrizzyy]

es ist egal wie man es nennt.
Wenn 7zip nur 2 Threads benutzt, benutzt es auch nur 2 Kerne.

Stop da liegt der Fehler.

7 Zip kann zum Entpacken/Packen nur 2 Kerne benutzen. (das liegt am Source Code von 7zip)

Aber 7 Zip kann auch 2, 4, 8 oder mehr Kerne ansprechen.

Dazu probierst du am besten mal den Benchmark aus. Wie ich sehe hast du in deiner Signatur einen Quadcore.

Damit könntest du dir im Benchmark live anschauen wie 7ip alle 4 Kerne benutzt (wenn du es so einstellst).

Daher ist 7zip keine "Dualcore" Anwendung. Sondern lediglich bei einer Entpack/Verpack Aufgabe haben die Developer dies auf 2 Kerne limitiert.

Wenn du weitere Fragen zur multithreaded Programmierung hast kann ich dir auch gerne per PM ein paar Hinweise geben. (hier gehört es ja nur indirekt rein)

Und jetzt würde ich sagen:

 

[Mondrial]

Für was benutzt 7Zip die anderen Kerne, wenn nicht zum packen oder entpacken?

 

[Chrizzyy]

Für was benutzt 7Zip die anderen Kerne, wenn nicht zum packen oder entpacken?

Beim packen/entpacken (einer Aufgabe) also z.B. einem Ordner kann man an sich nur 1 Thread benutzen.

Moderne Programme wie 7 Zip oder WinRaR fangen beim packen/entpacken gleichzeitig mit einem Thread von vorne und mit dem anderen Thread von hinten an zu entpacken.

Das hat aber wirklich nichts mit mulithreaded zu tun.

Aus Programmierer Sicht sieht es leider so aus, dass das entpacken/packen nur mit einem Thread funktioniert. Dadurch das vorne und hinten angefangen wird geht es halt auch mit 2 Threads.

Aber beim klassichen multithreaded kommunizieren die Kerne miteinander und versuchen so effektiv wie möglich zu arbeiten und nutzen alle verfügbaren Recheneinheiten. (CPU Kerne)

Daher ist 7zip eher eine Art Singlecore Anwendung. Zumindest vom Code. Beim Benchmark werden einfach verschiedene Entpack Prozesse benutzt und dadurch können alle Prozessoren benutzt werden.

Ist praktisch wie wenn man gleichzeitig 2 verschiedene Sachen packen/entpacken würde.

 

[daysleeper83]

Stop da liegt der Fehler.

Aber 7 Zip kann auch 2, 4, 8 oder mehr Kerne ansprechen.

Funzt sogar

Aber warum der 8 Threads braucht für die volle Auslastung der Kerne soll mir mal einer erklären . Übrigens auch hier ne sehr gute Kernskalierung .

 

[F-kopp]

Stop da liegt der Fehler.

7 Zip kann zum Entpacken/Packen nur 2 Kerne benutzen. (das liegt am Source Code von 7zip)

Aber 7 Zip kann auch 2, 4, 8 oder mehr Kerne ansprechen.

Dazu probierst du am besten mal den Benchmark aus. Wie ich sehe hast du in deiner Signatur einen Quadcore.

Damit könntest du dir im Benchmark live anschauen wie 7ip alle 4 Kerne benutzt (wenn du es so einstellst).

Daher ist 7zip keine "Dualcore" Anwendung. Sondern lediglich bei einer Entpack/Verpack Aufgabe haben die Developer dies auf 2 Kerne limitiert.

Wenn du weitere Fragen zur multithreaded Programmierung hast kann ich dir auch gerne per PM ein paar Hinweise geben. (hier gehört es ja nur indirekt rein)

Und jetzt würde ich sagen:

ich hab einen qc, die dropdownbox für die threads enthält nur 2 items:
1
2

 

[Mondrial]

Ich frag mich aber grad warum man Winrar Multicoreunterstützung nachsagt und auch nachweisen kann und 7Zip nachweislich maximal 2 Kerne nutzt.

 

[Limit]

Prinzipiell sollte es kein großes Problem sein ein Packprogramm multithreaded zu gestalten. Man splitet einfach die zu komprimierenden Daten in n Teile und packt sie einzeln. Darunter leidet evtl. der Kompressionsfaktor ein wenig, aber bei hinreichend großen Datenmengen sollte sich das nicht sonderlich auswirken. Beim entpacken kommt es dann wohl drauf an, wie die Daten organisiert sind. Wenn jede Datei einzeln komprimiert wird (ist glaub ich bei den meisten Windows Packprogrammen Standard), kann zumindest jeder Kern an einer anderen Datei arbeiten solange es eben genug davon gibt.

Multithreaded heißt übrigens nur, dass ein Programm mit mehreren Threads arbeitet, ob diese untereinander kommunizieren ist dabei nicht relevant. Man wird auch immer versuchen das Programm so zu strukturieren, dass die Kerne möglichst nicht miteinander kommunzieren müssen, da das die einfachste Methode ist eine maximale Skalierung zu erreichen. Bei Problemen, bei denen das nicht möglich ist, sollte die Architektur der Opterons und des Nehalems den FSB-basierten Architekturen deutlichst überlegen sein.

 

[mr.dude]

Bitte lies Posting 21. Ich sprach davon, dass synthetische Tests irrelevant sind und die Spiele zu großen Teilen GPU-limitiert. Nix anderes, also hör bitte mit diesen Unterstellungen auf.

Du sprachst davon, dass die Ergebnisse genau hier "einige % näher dran sind als unter Vollast". Was immer das auch heissen soll. Synthetische Tests laufen nahezu immer unter Vollast. Ob du diese Tests nun für irrelevant hältst oder nicht, spielt dabei keine Rolle. Das ändert am Kontext deiner Aussage nichts.
Ich frage mich echt, warum du so stur bist. Bist du nicht mal in der Lage dazu, dir einen Fehler einzugestehen? Und selbst, wenn es nur eine falsche Formulierung war.

Wenn du gerne mit Sandra, Superpi oder Everest spielst dann tu das. Für mich sind solche Werte bedeutungslos und gehören in kein CPU-Rating.

Meine Güte, du hast echt eine lange Leitung. Das sage ich dir nun schon seit etlichen Seiten. Die Ergebnisse sind aber nun mal im Rating von CB enthalten. Und genau deshalb ist dieses auch verzerrt. Und zwar nicht nachteilig für Intel.

Ich frage dich nocheinmal: Streitest du bei solchen Werten weiter ein GPU-Limit ab?

http://www.computerbase.de/artikel/...test_amd_athlon_x2_4850e/22/#abschnitt_crysis (High)

Erstmal ist Crysis sicherlich nicht repräsentativ. Und zweitens kann man bei 800x600 wunderbar sehen, dass ein keine Limitierung durch die GPU gibt. Und auch keine 20% Skalierung zwischen QX9770 und Q9450, wie man aufgrund des Taktes vermuten könnte.

Tjo, anscheinend klappt die Skalierung nur unter 64Bit - unter 32Bit schlägt sich der Core2 augenscheinlich ebenso gut, mal besser (Povray) mal schlechter (Cinebench 32Bit in einem anderen Review), insgesammt wohl vergleichbar.

Tolle Erklärung. Jetzt bin ich genauso schlau wie vorher. Aber irgendwie geben solche Kommentare immer wieder dein technisches Verständnis wieder. Ausser Opportunismus ist da nix vorhanden.

Wenn man sich auch die Workstation und Server Benchmarks anschaut fällt auf das die Intel Prozessoren genauso gut mit 4-8 Kernen skalieren wie die AMD Prozessoren. Allerdings ist die Core 2 Mikroarchitektur leistungsfähiger als die K10 Architektur und daher sind Intel Prozessoren zurzeit leistungsfähiger.

Nope. Da werden dir aber viele Serverbetreiber widersprechen. Erstmal kann man nicht pauschalisieren. Das sollte hier im Forum mittlerweile zum guten Ton gehören. Da du noch relativ neu bist, sei dir das an dieser Stelle gesagt. Und weiterhin ist bekannt, dass gerade AMD aufgrund ihrer Direct Connection Architecture, also der direkten CPU Kommunikation, bei Mehrsockel-Systemen Performance Vorteile hat. Da ist nicht nur die Kern-Architektur ausschlaggebend, sondern die gesamte Infrastruktur. Und darüber hinaus ist der Opteron bei FP besonders stark.

Den AMD 45nm Daneb darf man eigentlich auch nicht mit den aktuellen 45nm Prozessoren von Intel vergleichen.

Der FSB wird abgeschafft und der Nehalem steht vor der Tür. Angesichts dieser Tatsache, sollte man den Daneb mit der kommenden Nehalem Generation vergleichen, da die ungefähr zeitgleich auf den Markt kommen werden.

Davon darf man sich aber nicht täuschen lassen. Erstmal werden Deneb und Nehalem nicht für das gleiche Marktsegment gleichzeitig gelauncht. Nehalem bedient ja erstmal Enthusiasten, während Deneb praktisch Agena ablöst. Und zweitens hängt AMD mit ihrer Entwicklung zurück, nicht zuletzt durch die Probleme beim K10. Rein entwicklungstechnisch ist Shanghai das Gegenstück zu Penryn. Das Gegenstück zu Nehalem ist eigentlich Bulldozer. Ob der es aber noch rechtzeitig schafft, wenigstens zum Nehalem Shrink Westmere, oder Sandy Bridge dann schon in den Startlöchern steht, ist fraglich. Hinzu kommt, dass beide Unternehmen nicht dem gleichen Entwicklungszyklus unterliegen.

Entweder ist eine Application multithreaded programmiert oder nicht. Und wenn sie multithreaded ist kann sie alle verfügbaren Prozessoren ansprechen. Egal ob 2, 4, 8 oder mehr Kerne.

Nein. Hier musst du zwischen Anwendungen unterscheiden, die partitionieren. Dazu gehören so Sachen wie Renderer (Cinebench). Und Anwendungen, die eher "delegieren", also Teilaufgaben auslagern. Und hier werden auch nur so viele Kerne genutzt, wie es Teilaufgaben gibt. Bestes Beispiel für sowas sind Spiele. Der Unterschied liegt übrigens nicht nur bei den verwendeten Kernen, sondern auch bei deren Auslastung.

Da ihr gerade bei Cinebench seit:

http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3326&p=7

Cinebench R10 1 Thread N-Threads Speedup
Nehalem (2.66GHz) 3015 12596 4.18x
Core 2 Quad Q9450 - Penryn - (2.66GHz) 2931 10445 3.56x

Da sieht man deutlich was bei Intel die Abschaffung des FSB´s bringt.

Wenn Intel mit 4,18x skaliert, skaliert Intel besser als AMD mit mehreren Kernen.

Dir ist aber schon bewusst, dass es sich hier um 8 Threads bzw 4 reale und 4 virtuelle Kerne handelt? Wenn man mal von den bis zu 30% mehr Leistung durch SMT ausgeht, was ja auch schon in einigen Tests zu sehen war, müsste die maximale Skalierung bei 5,2 liegen (4*1,3). 4,18 sind aber nur 80% davon, während eine Skalierung von 3,56 beim Penryn fast 90% der maximalen Leistung (4) ist. Eine Skalierung hier von "nur" 4,18 wäre also sogar ein relativ schlechtes Ergebnis für Nehalem.
Es heisst übrigens Deneb, nicht Daneb.

Durch SMT sind hier Werte >4 im übrigen auch möglich, bei einem Phenom stellt dies einen Messfehler dar.

Messtoleranz, nicht Messfehler.

 

[redfirediablo]

Wie ihr euch mal wieder hier an die Gurgel geht

Freut euch doch: mit dem Deneb kommt ein Prozessor, der die Nachteile des 65nm Phenoms gekonnt ausmerzt:

Stromaufnahme praktisch halbiert und damit auf dem Niveau eines 45nm Intelquads mit eventuellen Vorteilen im Idle.

Leistungsniveau in etwa auf dem eines Yorkfield, etwaige Differenzen, egal ob plus oder minus, werden am Markt durch die Preise ausgeglichen. Alles sieht jedoch danach aus das das Leistungsniveau annähernd gleich sein wird und somit man nicht zu Intel wechseln MUß wenn man viel Leistung haben möchte, mangels alternative bei AMD wie es bisher war.

Somit hat man gegen ende des Jahres wunderbar die Wahl welchen Prozessor man nimmt, das wird vor allem die momentan überteuerten Preise der 45nm Intelquads deutlich nach unten reduzieren.

Meine Meinung zu Nehalem bleibt erstmal: 2008 wird er im Desktop, für das was er bietet, inkl Plattformkosten zu teuer sein.

Bezüglich SB750 angeblich ein MUß für Deneb OC:

Wiedermal ungelegte Eier, bisher macht die SB 750 100-200 mhz aus. Das ist ganz gut jedoch macht das den Kohl auch nicht fett. Wie die Wirkung auf den Deneb sein wird kann man jetzt noch nicht sagen.

Für mich steht ein Boardwechsel an weil MSI für mein AM2 kein neues Bios rausbringt. Hätte ich ein AM2+ würde ich wegen denn paar mhz sicher nicht das Board extra wechseln. Für Leute ohne OC ambitionen ohnehin irrelevant.

Noch zu dem Thema was man vergleichen darf:

Also ICH vergleiche was gleich viel kostet, eventuell auf Gesamtkosten für die Plattform bezogen.

Ist doch genau der selbe Quark wie das man single gpu Karten "angeblich" nich mit dual gpu Karten vergleichen dürfe. Solange sie gleich viel Kosten ist das absolut egal, beim Vergleich muß man dann natürlich abwegen zwischen Vorteilen bei den fps und Nachteilen durch Stromverbrauch oder etwaige Mikroruckler.

 

[Chrizzyy]

@mr.dude

Ich muss dir leider in fast allen Punkten widersprechen. Was du schreibst ist zum Teil "laienhaftes" Wissen.

Ich arbeite als Programmierer bei einer großen amerikanischen IT Firma und wir programmieren so, dass die einzelnen CPU Threads bei multithreaded Applications möglichst wenig miteinander kommunizieren.

Diese Kommunikation der Kerne untereinander (egal ob bei AMD oder Intel) führt zu Performance Verlusten.

Aus diesem Grunde schreiben wir unsere multithreaded Software so, dass die Threads möglichst unabhängig voneinander sind und die Kommunikation so niedrig wie möglich ist.

Daher ist es falsch, dass AMD bei multithreaded Software besser skaliert.

Bezüglich der Leistung:

Wir haben hier verschiedene Intel Quadcore Workstations mit 2 Sockeln und auch noch ein paar AMD Workstation und Server und momentan sind bei unseren Tests die Intel Workstations eindeutig schneller.

Ich weiss nicht was für Serverbetreiber du da meinst, aber es ist defintiv falsch.

Ich hoffe, dass ich dir es verständlich erklärt habe.

 

[daysleeper83]

Das Gegenstück zu Nehalem ist eigentlich Bulldozer. Ob der es aber noch rechtzeitig schafft, wenigstens zum Nehalem Shrink Westmere, oder Sandy Bridge dann schon in den Startlöchern steht, ist fraglich. Hinzu kommt, dass beide Unternehmen nicht dem gleichen Entwicklungszyklus unterliegen.

Sorry 4 OT

Vielleicht geht die ganze Sache auch in eine ganz andere Richtung:

Speku:

AMD will ja mit der neuen Grafikkarten Generation auf den offenen Standard OpenCL und Direct X11 setzen. Rein theoretisch könnte man dann mit der passenden Software alle Rechenintensiven komplett auf die GPU auslagern welche die CPU an Leistung um weiten übertreffen sollte. Eine CPU hätte dann nur noch Verwaltungsfunktion und exorbitante Leistung ist gar nicht mehr von Nöten. Gerade opencl könnte ziemlich schnell viel Anhänger bekommen wegen fehlenden Restriktionen und relativer Einfachheit.

Dann stellt sich nämlich nicht mehr die Frage nach der CPU sondern nach der Plattform: AMD (OpenCl; Direct X11), Intel (cGPU) oder Nvidia (Cuda)?

 

[Undertaker 1]

Du sprachst davon, dass die Ergebnisse genau hier "einige % näher dran sind als unter Vollast". Was immer das auch heissen soll. Synthetische Tests laufen nahezu immer unter Vollast. Ob du diese Tests nun für irrelevant hältst oder nicht, spielt dabei keine Rolle. Das ändert am Kontext deiner Aussage nichts.
Ich frage mich echt, warum du so stur bist. Bist du nicht mal in der Lage dazu, dir einen Fehler einzugestehen? Und selbst, wenn es nur eine falsche Formulierung war.

Du verstehst wohl nicht, dass wir hier zwei verschiedene Fälle betrachten.

1. Das Problem der synthtischen Benches. Egal wie diese Ausfallen, für den Nutzwert der CPU sind diese irrelevant
2. Das Problem von Spielen unter GPU-Limit. Hier erreichen z.T. Phenom und C2 die gleichen FPS, der Phenom muss dafür aber weitaus näher an seiner Leistungsgrenze arbeiten.

Ich habe nichts anderes behauptet oder geschrieben, also lass deine Phantasie mal nicht ins blaue kreisen

Meine Güte, du hast echt eine lange Leitung. Das sage ich dir nun schon seit etlichen Seiten. Die Ergebnisse sind aber nun mal im Rating von CB enthalten. Und genau deshalb ist dieses auch verzerrt. Und zwar nicht nachteilig für Intel.

Da hast du dich verschaut, wärend im Anwendungs/Multimediabereich gemittelt etwa 15% IPC zugunsten des Yorkfield zu finden sind, ist es synthetisch weit weniger. Das ist klar eine Bevorteilung des Phenom

Erstmal ist Crysis sicherlich nicht repräsentativ. Und zweitens kann man bei 800x600 wunderbar sehen, dass ein keine Limitierung durch die GPU gibt. Und auch keine 20% Skalierung zwischen QX9770 und Q9450, wie man aufgrund des Taktes vermuten könnte.

Du hast dich wieder verguckt, ich habe von Crysis - High gesprochen. Und von Anno. Und von WiC. Alles ganz saubere GPU-Limits.
Das gleiche Problem ergibt sich übrigens von der anderen Seite. Wie wäre es wenn ich jetzt mal sage, das ein Phenom 9950 in Spielen nur 2% schneller ist als ein E6420? Das zeigt das CB-Spiele-Rating ja

Tolle Erklärung. Jetzt bin ich genauso schlau wie vorher. Aber irgendwie geben solche Kommentare immer wieder dein technisches Verständnis wieder. Ausser Opportunismus ist da nix vorhanden.

Du hast Recht, ich muss zugestehen das deine technische Erklärung hier an dieser Stelle jegliche tiefgreifend Fragen beantwortet hat.

Messtoleranz, nicht Messfehler.

Diese Unterscheidung ist nicht feststellbar

 

[Chrizzyy]

Sorry 4 OT

Vielleicht geht die ganze Sache auch in eine ganz andere Richtung:

Speku:

AMD will ja mit der neuen Grafikkarten Generation auf den offenen Standard OpenCL und Direct X11 setzen. Rein theoretisch könnte man dann mit der passenden Software alle Rechenintensiven komplett auf die GPU auslagern welche die CPU an Leistung um weiten übertreffen sollte. Eine CPU hätte dann nur noch Verwaltungsfunktion und exorbitante Leistung ist gar nicht mehr von Nöten. Gerade opencl könnte ziemlich schnell viel Anhänger bekommen wegen fehlenden Restriktionen und relativer Einfachheit.

Dann stellt sich nämlich nicht mehr die Frage nach der CPU sondern nach der Plattform: AMD (OpenCl; Direct X11), Intel (cGPU) oder Nvidia (Cuda)?

Sicherlich haben GPU´s in einigen Bereichen sehr große Vorteile.

Aber das was du beschreibst wird so wohl nicht passieren, da sich GPU´s nur für bestimme Arten von Berechnungen eignen wie z.B. Matrizenberechnung, Vektorberechnung usw.

Damit geht nur ziemlich wenig. (Spiele jetzt mal aussen vor gelassen)

Für general purposes sind klassiche x86 Prozessoren weitaus besser und das wird wohl auch noch ein paar Jahre so bleiben.

Für bestimmte Sachen z.B. in der Wissenschaft können aber auch GPU´s weitaus leistungsfähiger sein.

Dafür gibt es z.B. die NVIDIA Tesla Systeme. http://www.nvidia.de/page/tesla_computing_solutions.html

Das sind praktisch Server mit merheren Grafikkarten wo die GPU´s zum rechnen genommen werden.

 

[daysleeper83]

Was ist denn z.B. ein general Purpose ?

Was sind denn die primären rechenintensiven Sachen im Desktop Bereich ? Video Codieren, Bild Bearbeitung, Spiele, vielleicht noch 3D Rendering und Musik.

Video Codieren gibt es bald schon mit Cuda, bei Bildbearbeitung (Photoshop)wird doch glaube ich heute schon die Graka mitverwendet. Bei Spielen rennen wir momentan von ein GPU Limit ins Nächste und die CPU Berechnungen (Physik) kann auch schon die Graka übernehmen. Wie es beim Rendern ausschaut weiß ich nicht bei Musik auch nicht.

Der große Rest der Anwendungen ist jetzt schon hoffnunsglos mit der ganzen CPU Power überfordert.

 

[Chrizzyy]

Was ist denn z.B. ein general Purpose

For example db2 oder oracle database software.
Dafür ist eine GPU nicht geeignet und dazu zählen noch viele andere Kategorien.

Kein operating system würde mit einer GPU Starten weil man dafür eine Plattform braucht worauf die Applications laufen.

Da könnte ich jetzt noch tausend andere Sachen aufzählen aber langsam wirds auch spät

 

[daysleeper83]

Klar im Server Bereich kann das komplett gerade bei Datenbanken etc pp anders aussehen mir ging es jetzt auch primär um den Deskop Bereich. Das man eine CPU braucht sollte auch klar sein ich sprach ja auch von reinen "Verwaltungsaufgaben". Ich sehs zumindest für den Desktop als realistisch das man diesen Weg einschlägt, wie lange das dauert ist wieder ein andere Frage. Vielleicht wird ATI doch noch AMDs "Rettungsanker". In diesem Sinne Gudde N8

 

[mr.dude]

Ich muss dir leider in fast allen Punkten widersprechen. Was du schreibst ist zum Teil "laienhaftes" Wissen.

Ich arbeite als Programmierer bei einer großen amerikanischen IT Firma und wir programmieren so, dass die einzelnen CPU Threads bei multithreaded Applications möglichst wenig miteinander kommunizieren.

Diese Kommunikation der Kerne untereinander (egal ob bei AMD oder Intel) führt zu Performance Verlusten.

Aus diesem Grunde schreiben wir unsere multithreaded Software so, dass die Threads möglichst unabhängig voneinander sind und die Kommunikation so niedrig wie möglich ist.

Daher ist es falsch, dass AMD bei multithreaded Software besser skaliert.

Und was soll eure Arbeitsweise mit den Architekturunterschieden zwischen AMD und Intel zu tun haben? Mal abgesehen davon, dass deine Aussagen überhaupt nichts gegenteiliges zu meinem Beitrag sagen.
(nur zur Info, ich programmiere seit über 15 Jahren, beruflich und privat, also bitte unterlasse dieses überhebliche Getue von wegen "laienhaft", sonst könnte ich das noch beleidigend empfinden )
Nebenbei, darf ich mal fragen, wie viel du von Low Level Programmierung verstehst?

Wir haben hier verschiedene Intel Quadcore Workstations mit 2 Sockeln und auch noch ein paar AMD Workstation und Server und momentan sind bei unseren Tests die Intel Workstations eindeutig schneller.

Bitte halte dich mit solchen Aussagen zurück, sonst nimmt dich schnell niemand mehr ernst. Erstmal solltest du schon sagen, welche Systeme ihr konkret verwendet. Und zweitens, welche Anwendungen ihr verwendet. Und auch dann reden wir immer noch nicht von Allgemeingültigkeit. Das ist dir doch hoffentlich bewusst?

Du verstehst wohl nicht, dass wir hier zwei verschiedene Fälle betrachten.

1. Das Problem der synthtischen Benches. Egal wie diese Ausfallen, für den Nutzwert der CPU sind diese irrelevant
2. Das Problem von Spielen unter GPU-Limit. Hier erreichen z.T. Phenom und C2 die gleichen FPS, der Phenom muss dafür aber weitaus näher an seiner Leistungsgrenze arbeiten.

Erstens ist das Spekulation. Und zweitens, jetzt höre doch mal bitte auf, dich da rauszureden. Es geht ganz konkret um deine Formulierung und um nichts anderes. Glaubst du wirklich, ich bin so naiv, nicht zu verstehen, was du mit deinem Beitragswirrwarr sagen willst?

Da hast du dich verschaut, wärend im Anwendungs/Multimediabereich gemittelt etwa 15% IPC zugunsten des Yorkfield zu finden sind, ist es synthetisch weit weniger. Das ist klar eine Bevorteilung des Phenom

Du gehst hier von einem falschen Vorsatz aus. Dass das Anwendungs-Rating aus dem Rahmen fällt, habe ich dir zuvor schon gesagt. Und nicht jeder Rating Bereich muss auch den exakt gleichen Unterschied zeigen.

Du hast dich wieder verguckt, ich habe von Crysis - High gesprochen. Und von Anno. Und von WiC. Alles ganz saubere GPU-Limits.

Mann, du bist echt nur noch zum Kopf schütteln. Was in Gottes Namen soll ohne GPU Limitierung in Crysis High eine bessere CPU Skalierung als in Crysis Low ermöglichen? Nochmal, auch in Crysis Low gibt es keine perfekte Skalierung. Und wenn hier 1-2 Ratings ins Ergebnis mit einfliessen, die den Unterschied der Leistung der Prozessoren nicht korrekt wiederspiegeln, dann nimm sie von mir aus raus. Intel hat hier dafür wiederum andere Vorteile (Crysis, low Settings, wenig Multicore Ausnutzung, kein Racer). So wie da getestet wurde, kommt das Intel eher noch zugute. Das macht aber keinen grossen Unterschied. Die wirklichen Unterschiede findest du an ganz anderer Stelle.

Diese Unterscheidung ist nicht feststellbar

Ich gehe davon aus, Maxxon weiss, wie sie die Skalierung messen. So viel Kompetenz traue ich ihnen schon zu. Du nicht? Schon mal was von Echtzeit- und ereignisgesteuerten Systemen gehört? Windows gehört übrigens zum letzteren. Das KANN übrigens ein Grund für Messtoleranzen sein.

 

[w0mbat]

@mr.dude

Ich muss dir leider in fast allen Punkten widersprechen. Was du schreibst ist zum Teil "laienhaftes" Wissen.

Ich arbeite als Programmierer bei einer großen amerikanischen IT Firma und wir programmieren so, dass die einzelnen CPU Threads bei multithreaded Applications möglichst wenig miteinander kommunizieren.

Diese Kommunikation der Kerne untereinander (egal ob bei AMD oder Intel) führt zu Performance Verlusten.

Aus diesem Grunde schreiben wir unsere multithreaded Software so, dass die Threads möglichst unabhängig voneinander sind und die Kommunikation so niedrig wie möglich ist.

Daher ist es falsch, dass AMD bei multithreaded Software besser skaliert.

Bezüglich der Leistung:

Wir haben hier verschiedene Intel Quadcore Workstations mit 2 Sockeln und auch noch ein paar AMD Workstation und Server und momentan sind bei unseren Tests die Intel Workstations eindeutig schneller.

Ich weiss nicht was für Serverbetreiber du da meinst, aber es ist defintiv falsch.

Ich hoffe, dass ich dir es verständlich erklärt habe.

Bei welcher Firma arbeitest du denn?

zB verliert man durch CPU interne Kommunikation nur an Performance wenn die Apps nicht multi-threaded programmiert sind. Mit einer gute Programmierung kann man durch CPU interne Kommunikation viel an Leistung gewinnen, da man so div. Rechenschritte einsparen kann. Jede grosse Firma setzt auf viel Interkommunikation und slice-sharing.

Aktuell sind AMD-Systeme bei HPC-Anwendungen den Intel Pendants ziemlich ueberlegen. Ich muss mr.dude in fast allen Belangen zustimmen, du solltest dich einfach etwas mehr informieren.

Und bevor du jetzt mit deiner grossen US Firma kommst fuer die du arbeitest, hier in Chicago sind wir bestimmt nicht dem Trend hinterher.

 

[Mondrial]

@mr.dude

Ich muss dir leider in fast allen Punkten widersprechen. Was du schreibst ist zum Teil "laienhaftes" Wissen.

Ich arbeite als Programmierer bei einer großen amerikanischen IT Firma und wir programmieren so, dass die einzelnen CPU Threads bei multithreaded Applications möglichst wenig miteinander kommunizieren.

Diese Kommunikation der Kerne untereinander (egal ob bei AMD oder Intel) führt zu Performance Verlusten.

Aus diesem Grunde schreiben wir unsere multithreaded Software so, dass die Threads möglichst unabhängig voneinander sind und die Kommunikation so niedrig wie möglich ist.

Daher ist es falsch, dass AMD bei multithreaded Software besser skaliert.

Klar verlieren beide etwas an Performance durch die interne Kommunikation, aber bei guter Programmierung kann dadurch auch wieder was gewonnen werden. Diesen Effekt wirst du schnell kennenlernen sobald Nehalem draußen ist. Dann werden nämlich alle schnell den von dir genannten Grundsatz verwerfen und versuchen mehr interne Kommunikation einzubauen, weils dann auf Intelplattformen damit keinen Nachteil mehr gibt.

Aktuell hat AMD da einfach Architekturvorteile und die kannst du auch nicht widerlegen, wenn du nur diese eine Programmiertechnik anwendest.

 

[Undertaker 1]

Erstens ist das Spekulation. Und zweitens, jetzt höre doch mal bitte auf, dich da rauszureden. Es geht ganz konkret um deine Formulierung und um nichts anderes. Glaubst du wirklich, ich bin so naiv, nicht zu verstehen, was du mit deinem Beitragswirrwarr sagen willst?

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
Meine Aussage und Formulierung war absolut korrekt, wie du jetzt wohl auch erkennen kannst

Du gehst hier von einem falschen Vorsatz aus. Dass das Anwendungs-Rating aus dem Rahmen fällt, habe ich dir zuvor schon gesagt. Und nicht jeder Rating Bereich muss auch den exakt gleichen Unterschied zeigen.

Deswegen mitteln wir auch, zum zehnten Mal jetzt. Und da kommen die ~15% heraus.

Mann, du bist echt nur noch zum Kopf schütteln. Was in Gottes Namen soll ohne GPU Limitierung in Crysis High eine bessere CPU Skalierung als in Crysis Low ermöglichen? Nochmal, auch in Crysis Low gibt es keine perfekte Skalierung. Und wenn hier 1-2 Ratings ins Ergebnis mit einfliessen, die den Unterschied der Leistung der Prozessoren nicht korrekt wiederspiegeln, dann nimm sie von mir aus raus.

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

Intel hat hier dafür wiederum andere Vorteile (Crysis, low Settings, wenig Multicore Ausnutzung, kein Racer). So wie da getestet wurde, kommt das Intel eher noch zugute. Das macht aber keinen grossen Unterschied. Die wirklichen Unterschiede findest du an ganz anderer Stelle.

Es gibt keinerlei annähernd glaubhafte Belege, dass sich ein Phenom in diesen Fällen überdurchschnittlich gut schlagen würde.

Ich gehe davon aus, Maxxon weiss, wie sie die Skalierung messen. So viel Kompetenz traue ich ihnen schon zu. Du nicht?

Ach, die Kompetenz der Ersteller reicht schon aus? Dann sollte es solchen Unfug beim benchen z.B. wie bei OC-Club ja gar nicht geben können

 

[Chrizzyy]

zB verliert man durch CPU interne Kommunikation nur an Performance wenn die Apps nicht multi-threaded programmiert sind. Mit einer gute Programmierung kann man durch CPU interne Kommunikation viel an Leistung gewinnen, da man so div. Rechenschritte einsparen kann. Jede grosse Firma setzt auf viel Interkommunikation und slice-sharing.

Aktuell sind AMD-Systeme bei HPC-Anwendungen den Intel Pendants ziemlich ueberlegen. Ich muss mr.dude in fast allen Belangen zustimmen, du solltest dich einfach etwas mehr informieren.

Was soll ich dazu noch sagen? Das stimmt überhaupt nicht. Ich bin Developer bei Sun aber das tut hier überhaupt nichts zur Sache.

Bei Server, High-End, Workstation oder gerade bei HPC Cluster Applications geht es darum, dass die so effektiv wie möglich arbeiten und ganz wichtig skalierbar sind.

Gutes multithreaded programmieren heisst so wenig interne CPU Kommunikation wie möglich. Umso weniger Kommunikation umso mehr Performance. Das hat übrigens rein gar nichts mit AMD oder Intel zu tun. Gerade bei AMD HPC Cluster Applications geht es darum, dass diese so skalierbar wie nur möglich sind. Das erreicht man nur durch guten multithreaded Code. Und guter Code heisst, dass die Threads mit so wenig Kommunikation wie möglich und unabhängig voneinander laufen. Umso skalierbarer sind die Applications.

Jeder Developer, der sauberen Code schreibt weiss, wie schwer es ist sauberen bzw. guten multithreaded Code zu schreiben. Es gibt ja auch einige Sachen die man nie multithreaded schreiben könnnen wird, weil es bei manchen Sachen wie z.B. Pi Berechnungen nicht umsetzbar ist.

Umso mehr Kommunikation der CPU´s bzw. Threads miteinander umso mehr Performance geht verloren. Wenn man wirklich so programmieren würde, dass die Threads mit absicht richtig viel miteinander kommunizieren müssten. wäre das Fazit das die Applications deutlich langsamer sind und obendrauf noch nicht mehr skalierbar sind.

Von daher ist dein HPC Argument vollkommen falsch.

Klar verlieren beide etwas an Performance durch die interne Kommunikation, aber bei guter Programmierung kann dadurch auch wieder was gewonnen werden. Diesen Effekt wirst du schnell kennenlernen sobald Nehalem draußen ist. Dann werden nämlich alle schnell den von dir genannten Grundsatz verwerfen und versuchen mehr interne Kommunikation einzubauen, weils dann auf Intelplattformen damit keinen Nachteil mehr gibt.

Siehe oben. Du Widersprichst dir selbst. Einerseits schreibst du, dass beide etwas an Performance verlieren!

Und jetzt kann bei guter Programmierung etwas gewonnen werden? Falsch.
Weil es dann schlecht programmiert ist.

Es wird natürlich IMMER Kommunikation der Kerne untereinander bei nahezu allen Applications geben. Dennoch gilt umso weniger umso besser und umso performanter sowie skalierbarer die Application.

 

[Mondrial]

Ich sehe da keinen Widerspruch. Ich bin zwar kein Programmierer, aber es kann doch Vorteile geben, wenn ein Kern weiß was der andere macht, vorallem wenn die Ergebnisse voneinander abhängen oder sich gegenseitig beeinflussen.

 

[CyLord]

Chrizzyy schrieb ja, dass das nicht aus bleibt, aber es geht darum diese Kommunikation so gering wie möglich zu halten.

 

[Mondrial]

Aber die Kommunikation unter den Kernen ist bei AMD wesentlich schneller. Warum sollte ich die dann so klein wie möglich halten, wenn ich damit Rechenaufwand sparen oder besser verteilen kann?

 

[daysleeper83]

Aber die Kommunikation unter den Kernen ist bei AMD wesentlich schneller. Warum sollte ich die dann so klein wie möglich halten, wenn ich damit Rechenaufwand sparen oder besser verteilen kann?

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.

 

[Undertaker 1]

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