News Intel Core i7-6950X: Support-Seiten bestätigen neue CPU-Spitze

[Lars_SHG]

wie z.B. Crysis 3) hatten der Hexa- und der Octacore Probleme, den 6700K zu erreichen

C3 nutzt bei mir 10 Threads. Die sind natürlich nicht alle ausgelastet, werden aber belastet.
Habe ich eine CPU mit "nur" 8 Threads, läuft das eben auch über die vorhandenen Threads und kann Leistung kosten.

Das Problem ist ja, ein Benchmark gibt nur den Augenblick wieder, nicht aber das gesamte Verhalten während des games.

Davon ab ist Crysis ja auch immer sehr stark GPU-limitiert. Hier fällt ein CPU-Limit nicht so schnell auf.

Und was die "neue" Architektur betrifft, ja, das kann im Einzelfall ne Menge bringen, aber wie sieht es in der Realität aus? Natürlich kann auch der größere Cache der 2011(-3) Serie mal die entscheidende Rolle spielen - wird ja gern vergessen das es da noch mehr gibt, was die 6 oder Mehr-Kerner bieten!

 

[Kasmopaya]

Aber bei verschiedenen Architekturen ist dann wieder so eine Sache. In Dingen wie Encoding, Videoschnitt etc. hat der ältere Hexacore zwar die Nase vorne

Laut Gerüchten ist der Broadwell-E dann noch mal "Architektonisch" besser aufgestellt. Dann bleibt von poplingen Skylake mit 0815 WLP nix mehr übrig.

Zur Info, die Pro-Mhz-Leistung bei Skylake ist schlechter als bei Broadwell, der Nachfolger ist also langsamer als der Vorgänger.
Jetzt fragt man sich sicher „wie kann dies sein, Skylake ist ja neuer also muss er auch schneller sein, Skylake hat eine höhere/größere Versionszahl“, die bessere frage ist eher "warum wissen dies so wenige“.
Zur Veranschaulichung :
in F1 2013 ist Broadwell 13% schneller als Skylake,
in Anno 2070 ist Broadwell 8% schneller als Skylake,
in Crysis3 ist Broadwell 3% schneller als Skylake,
in StarCraft2 ist Broadwell 9% schneller als Skylake,
in TES 5 Skyrim ist Broadwell 10% schneller als Skylake,
bei Professionellen Anwendungen sieht es übrigens nicht viel anders aus.
Dies alles kann ich natürlich auch beweisen - PCGH Heftausgabe 09/2015 auf Seite 13, rechts oben.

Warten wir mal ab. Bis jetzt war es noch nie(Sandy Ausnahme) eine gute Idee den kleinen 4 Kerner mit sinnlos IGP zu nehmen. (Darum auch alle auf den Xeon ohne GPU)

 

[ottoman]

Der "normale" Broadwell nutzt den Speicher der iGPU als zusätzlichen CPU Cache und war deshalb in den Benchmarks so gut. Bei Broadwell-E ist das nur leider nicht mehr der Fall. Diese Tatsache wird aber in so ziemlich jedem damaligen Broadwell Review noch mal extra erwähnt, die PCGH sollte da keine Ausnahme machen. Also bitte auch den Text lesen und nicht nur die Balken anschauen

 

[GaNgAr]

Auf diese Cpu hab ich gewartet aber 1500 euro wären mir zu viel . 1000 würde ich ausgeben

Also berhalte ich meinen 3960x wohl vorerst

 

[Shoryuken94]

C3 nutzt bei mir 10 Threads. Die sind natürlich nicht alle ausgelastet, werden aber belastet.
Habe ich eine CPU mit "nur" 8 Threads, läuft das eben auch über die vorhandenen Threads und kann Leistung kosten.

Das Problem ist ja, ein Benchmark gibt nur den Augenblick wieder, nicht aber das gesamte Verhalten während des games.

Davon ab ist Crysis ja auch immer sehr stark GPU-limitiert. Hier fällt ein CPU-Limit nicht so schnell auf.

Und was die "neue" Architektur betrifft, ja, das kann im Einzelfall ne Menge bringen, aber wie sieht es in der Realität aus? Natürlich kann auch der größere Cache der 2011(-3) Serie mal die entscheidende Rolle spielen - wird ja gern vergessen das es da noch mehr gibt, was die 6 oder Mehr-Kerner bieten!

Crysis war nur ein Prominentes Beispiel, da es bekanntermaßen gut mit mehr Threads skaliert. Digital Foundry hat verschiedene Tests gemacht, auch mit 980ti´s im SLI (bei 1080p) um das GPU Limit etwas zu umgehen. In fast allen Spielen waren die 6 und 8 Kerner gleich auf mit dem 6700K. Es wurde je Spiel auch nicht nur eine benchmarkszene genutzt, sondern verschiedene Stellen aus den spielen.

Die großen Haswell Chips waren nur selten im Vorteil und das war dann auch recht knapp. Es waren ja realitätsnahe Tests, hier halt rein bezogen auf Spiele. Das Ergebnis war unterm Strich halt, dass mehr Kerne im vergleich zu einer neueren Architektur nicht soviel bringen. In anderen tests, wo man einen i7 4790k gegenüber gestellt hat, konnten sich die Hexa und Octa Cores noch absetzen, je nach Spiel deutlich. Zumindest waren sie immer gleich auf mit dem doch deutlich höher getakteten 4790k und taktbereinigt hat sich das Ergebnis noch deutlicher richtung Hexa und Octacore geschoben. So sieht es zumindest in Spielen aus. Bei Anwendungstests ziehen auch die älteren Haswwl Chips mit mehr Kernen deutlich davon

 

[oldmanhunting]

Wenn ich nur am PC zocke, würde ich mir einen i5 oder i7 mit 4 Kernen kaufen und mich über die hohe IPC freuen. Es gibt aber Leute die am PC mehr machen als nur zocken und wo mehr Kerne enorm helfen. Mit einem 6 bis 10 Kerner kann man natürlich nebenbei auch zocken. Keine Frage!

 

[jbauer]

Dann erkläre mal! Welchen Unterschied gibt es am Ende für den Nutzer? Ob Prozess mit mehreren Threads oder mehrere Prozesse.

Das hat ganz entscheidende Unterschiede. Ein Prozess läuft in seiner eigenen abgeschotteten Umgebung, threads eines Prozesses laufen in zusammen in dessen Umgebung. Wenn ein Prozess eine Aufgabe parallel bearbeiten soll, geschieht das (üblicherweise) über threads (Man kann das ggf. auch über Prozesse machen, das ist aber ungleich aufwendiger).
Wenn Chrome also jedem Tab einen eigenen Prozess spendiert, beschleunigt das nicht die Darstellung in einem einzelnen Tab. Mehrere Tabs sind aber unterschiedliche Aufgaben, dazu brauchst du diese nicht in chrome öffnen, du kannst auch andere Browser nehmen.

Jedes davon kann auf jeweils unterschiedlichen Kernen laufen und somit beliebig skalieren. Vorausgesetzt die Anwendung ist nich nur auf x Threads/Prozesse beschränkt.

Um eine Aufgabe zu parallelisieren musst du die Aufgabe in gleichaufwendige von einander unabhängige Teilaufgaben aufteilen. Dies geht aber nicht beliebig, manchmal halt sogar gar nicht.

Ich wiederhole meine Frage gerne nun zum fünften mal. Dann nenne mir eine x-beliebige halbwegs aktuelle Software die

Wie gesagt, aktuelle Software für spezielle Aufgaben tut das. Videoschnitt, 3D-Renderer usw. Programme für den üblichen Alltag tun das eben nicht, oder zumindest sehr beschränkt. Dazu zählen Browser, und wie oben gezeigt, ausdrücklich auch Chrome, Office, ausdrücklich auch Excel, wie in deinem link gezeigt, usw.

Ich will nicht sagen, dass 2C- oder 4C-CPUs unnötig sind, das wäre falsch, aber deine Behauptung ("vier Kerne Barriere"), alles wird schneller, wenn es nur mehr Kerne gibt, ist halt falsch.
Und auch bei Spielen kommt auf jeden Titel, der heute vier Kerne sinnvoll nutzen kann, zig Titel, die das eben nicht können.

Ich weiss nicht woraus du deine Weisheiten ziehst, aus Mangel von Quellenangaben vermutlich aus dem Finger. Sämtliche

Lies halt hier mal.

 

[Buttermilch]

https://www.pugetsystems.com/all_articles.php dort gibt es Skalierungsvergleiche bis 20cores mit diversen CPU Generationen von xeon haswell, multi cpu, Desktop i7 usw mit aktueller software die jetzt nicht gaming ist:
Bildverarbeitung, solidworks Produkte, Blender, Maja,
Premiere Pro CC 2015.1, after effects, usw. Besonders Matt Bachs Erfahrungen mit Adobe war verblüffend,
Mein plan war ja 2x xeon E5 2670 sandy mit board für den preis eines haswell-e zu kaufen,... naja lest es besser selbst.

 

[Philarmonic]

Bei "vertretbaren Spannungen" liegt genau das derzeitige Problem bei 14nm. Das Gateoxid ist so dünn (~3nm), dass wie bereits beschrieben, durch zu hohe Feldstärken im Kanalbereich heiße Elektronen generiert werden können, die das Gateoxid schädigen (betrifft nur n-Kanal Typen, da beim p-Kanal aufgrund der geringeren Beweglichkeit die erforderlichen Feldstärken für heiße Ladungsträger nich erreicht werden). Wenn ihr also die Spannung anhebt, die Temperaturen in Ordnung sind und euer System stabil läuft, bedeutet das bei 14nm CPUs eben nicht, dass sie auch noch nach zwei Jahren fehlerfrei laufen. Der Prozessor altert durch zu hohe Spannung schlichtweg. Seid also vorsichtig, was die Kernspannung angeht.

Interessant, hast du dazu eine quelle zum vertiefen? In OC Ratgebern wird Skylake bis 1.4 v als akzeptabel angesehen, bei Haswell eher 1.3 v . Effizienz mal ausgeblendet...
Daher dachte ich bisher der neuere Prozess verträgt etwas mehr und der Broadwell 4C sei nur auf Sparsamkeit getrimmt. Denkt ihr Broadwell E hätte dann geringeres OC Potential?

 

[ascer]

@Multicore-Debatte:

Natürlich benötigt *noch* der Ottonormalverbraucher nicht mehr als 4 Kerne. Der Otto* wird sicherlich nicht mal einen Unterschied merken, wenn man ihm einfach eine Dual-Core-CPU verbaut. Das ändert aber trotzdem nichts daran, dass bei größerer Verfügbarkeit von Mehrkernprozessoren auch expliziter auf Parallelisierung in Software eingegangen werden würde.


Hier Amdahl's Law zu nennen ist grober Unfug. Erstens ist das ganze eine Theorie und grobe Approximation. Jedem sollte schnell klar sein, dass das keine wirkliche Gesetzmäßigkeit darstellt. Zweitens ist Amdahl's Law eine der pessimistischsten Herangehensweisen an Multi-Core-Software überhaupt.

Ist euch eigentlich klar, dass jedweder Befehl, welcher mit dem Cache einer CPU auskommt, in wenigen Takten, das meiste sogar in 1-2 Takten, berechnet werden kann?
Ist euch weiterhin klar, dass die Auslagerung in den RAM, wenn es eben nicht in den Cache passt, meistens über 100 Takte benötigt? Wir sprechen hier also von einem Geschwindigkeitsverlust, der häufig grob mit dem Faktor 100 approximiert werden kann.

Dazu muss man dann nur noch wissen, dass mit mehr Kernen bisher immer ein linearer Anstieg des Caches einherging. Dadurch kann Software mit mehr Kernen nicht nur linear, sondern sogar supralinear beschleunigt werden.
Und bevor jetzt ein Kasper exorbitante Cacheerhöhungen auf Single-Cores vorschlägt: bei Single-Core-CPUs limitert die Frequenz, die bekanntlich ab 4GHz nur noch schwer zu erhöhen ist. Ein riesiger Cache für einen Core würde also nichts bringen...viel Cache für viele Cores hingegen schon.


Bezüglich der Browserdebatte: Erstmal ergeben mehrere Prozesse natürlich einen Speedup für den User. Was ist das für ein Quark? Wenn eine Anwendung in einem Tab läuft und sehr viel Ressourcen frisst, dann gibt es natürlich keinen Speedup. Nichtsdestoweniger ist das ja aber wohl selten der Fall, dass ein einziger Tab eine ganze CPU auslasten würde. Der Otto* weiß im schlimmsten Fall selbstredend gar nichts mit Tabs anzufangen. Den interessiert die Performance ja aber sowieso nicht. Das ändert damit also auch nichts daran, dass beispielsweise ich genau deshalb mal von Firefox weg bin (als der noch alles in einem Prozess laufen ließ): ein Chrome schmiert dir eben auch mit 100 Tabs nicht ab und reagiert immer noch super fix, eben weil nicht alles linearisiert abläuft. Wer, der heutzutage weiß was ein Quad-Core ist und auf Performance achtet, nutzt denn bitte nicht mehrere Threads?

Abgesehen davon: für JavaScript gibt es seit geraumer Zeit WebWorker. Damit kann man, selbst wenn der Browser selbst Javascript nur einen Thread spendiert, zusätzliche Threads innerhalb von JS spawnen. Wenn der Programmierer dieses Feature nicht nutzt, hat das doch gar nichts damit zu tun, dass es nicht schneller gehen würde. Ich hab z.B. schon neuronale Netze mit JS libraries im Browser (einfach mal zum Testen) laufen lassen und kann euch sagen: das skaliert wunderbar.
Ich wüsste im Übrigen auch nicht, was dagegen sprechen sollte, beispielsweise im Extremfall jedes Bild, jeden Button usw. parallelisiert zu laden - mal stark übertrieben dargestellt. Bei normalen Webseiten, sowas wie Wikipedia beispielsweise oder CB, ist der Speedup nur schlicht nicht nötig: es ist schon schnell genug. Das hat aber - nochmal - gar nichts damit zu tun, dass es nicht schneller gehen würde, wenn es parallelisiert werden würde.


Zu "einige Sachen lassen sich nicht parallelisieren": Das ist doch ebenfalls Quark. Natürlich gibt es Algorithmen, die sich nicht oder nur schlecht parallelisieren lassen, aber welchen Otto* interessiert das denn bitte? Hier wird mit einigen Exoten aus der Wissenschaft argumentiert, dass Parallelisierung ungemein schwierig wäre. So ein Quark.
Um nur mal ein super banales Beispiel zu nennen: Ich habe als Training im dritten Semester ein Pacman programmiert in C++11, wo jeder der vier Geister in einem eigenen Thread lief, sowie Pacman selber und die Spielwelt. Mit ein, zwei Hintergrundgeschichten und Syncen war es am Ende ein 8-Core Pacman.
Synchronisiert habe ich das ganze mit vektoriellen Zeitstempeln. Ohne extra sync über die Systemzeit und Drossel lief das mit ~80% Auslastung auf allen Cores und einer gefühlten Quadrillion FPS.
Dabei hatte ich im dritten Semester noch keine Ahnung von vernünftiger, hochparalleler Software und weder viel Zeit noch viel Mühe in die Parallelisierung gesteckt.

Natürlich wird darauf direkt ein Argument wie "ein Crysis zu parallelisieren ist aber schwieriger, als einfach Geister in Pacman parallel laufen zu lassen, wegen mehr Abhängigkeiten" kommen.
Ja, natürlich ist das so. Aber: arbeitet an Crysis auch nur ein Student im dritten Semester? Oder vielleicht ein paar Zehn oder Hundert Entwickler, im besten Fall fertige Absolventen, die sich gefälligst mit Parallelisierung auseinandergesetzt haben?

Wenn ich da immer so einen Quark höre, man könne Games nicht beliebig parallelisieren, deshalb werden nicht mehr als 4 Kerne unterstützt. Oder Speedup wäre zu gering. Der Speedup ist vielleicht bei 400 oder 4000 Kernen nicht mehr gegeben, wenn irgendwann alles im Cache liegt und man bei auch nur einem einzigen Thread mehr in der Sync-Hölle landet. Bis dahin ist es einfach nur mehr Entwicklungsaufwand, eine vernünftige Parallelisierung zu schreiben.

Ein Freund von mir, der sehr stark in Richtung Gamedesign agiert, hat beispielsweise (nur zu Demozwecken, keine vollwertige Kopie) einen C++11 Klon von Minecraft geschrieben, indem jeweils die einzelnen Chunks parallelisiert geladen und behandelt werden. Damit hat der eine 32 Thread Xeon-Workstation in der Uni auf 70% Auslastung gebracht, wo man gefühlt im Game Kilometer weit blicken konnte. Ebenso ermöglichte das dann Berge, die nicht wie im Original vielleicht mal 200, sondern da eben beispielsweise 2000 Blöcke hoch waren.

Ganz klar: das war angepasste Software, hatte einen limitierten (nur "rumfliegen" oder Blöcke "hin- bzw. wegklicken") Anwendungsbereich usw. Ebenso nur Singleplayer, sobald man Multiplayerzeugs hat wird die Parallelisierung natürlich noch aufwendiger. Aber auch hier: das hat ein einziger Student entwickelt. Minecraft hat Microsoft Milliarden gekostet. Wenn überhaupt, dann hat man einfach keinen Bock darauf entsprechendes Entwicklungsbudget zur Verfügung zu stellen.
Kein Kasper kann mir erzählen, Spiele wären nicht vernünftig parallelisierbar. Auf 400 Threads, wie gesagt, mag das sicherlich anders aussehen. Auf 8, 10, 12 oder 24 Threads sicherlich nicht.

Btw: beispielsweise bei Physikberechnungen in Spielen hat man, wegen der enormen Menge an floating point operations, ja bekanntlich auf die GPU ausgelagert (wo das möglich war). Ist euch klar, dass eine GPU nichts anderes als ein hochparallelisierter Chip ist? Was meint ihr denn, warum sowas auf GPUs so viel schneller läuft (abgesehen von der Menge an Befehlen, die ein x86 Kern können muss)? Wenn das nicht auf Hunderte oder häufig (Zehn-)Tausende Einzelberechnungen parallelisierbar wäre, dann wäre eine GPU in der Berechnung unendlich viel langsamer als eine CPU.

 

[Cool Master]

Zu "einige Sachen lassen sich nicht parallelisieren": Das ist doch ebenfalls Quark.....

Ich glaube damit ist/war eher gemeint es ergibt bei manchen Programmen einfach kein Sinn. Ein Powerpoint oder Word auf Quad Cores zu parallelisieren wäre Verschwendung und würde das Programm nur teurer machen und damit lässt es sich effektiv nicht parallelisieren. Wie in jeder komerzielen Anwendung muss das einfach mit einbezogen werden, ob es sich lohnt so viel Aufwand zu betreiben dass es sich auch lohnt. Klar es lässt sich alles umsetzen die Frage ist halt bringt es was wenn die Software danach statt 150,- € 1500,- € kostet?

Gerade bei Spielen ist das noch kritischer als bei "Software". Wenn man ein Kundenstamm hat der sagt ey wir wollen Quad oder Octa Support wird es das auch geben. Aber es heulen ja heute schon alle wenn ein Spiel mal 70 € kostet. Da kann man nicht rechtfertigen es voll auf Quads zu programmieren.

Also ja in der Theorie lässt sich alles super paralleliseren in der Praxis ist es aber einfach nicht möglich und damit kann man die Aussage schon so stehen lassen mit "einige Sachen lassen sich nicht parallelisieren".

 

[jbauer]

https://www.pugetsystems.com/all_articles.php dort gibt es Skalierungsvergleiche bis 20cores mit diversen CPU Generationen von xeon haswell, multi cpu, Desktop i7 usw mit aktueller software die jetzt nicht

Auf jeden Fall ein interessanter link, danke sehr.

Ich glaube damit ist/war eher gemeint es ergibt bei manchen Programmen einfach kein Sinn.

Zum einen das, aber bei anderem Programmen ist es schlicht nicht möglich, oder zumindest nur bei unbedeutenden Teilfunktionen (s. u. bei "Pacman"). Aber der wirtschaftliche Aspekt ist, wie du schon sagst, natürlich auch nicht zu vernachlässigen. Für ein Spiel, dass sich beispielsweise bei steam zehntausend mal für zehn Euro verkaufen lässt, lohnt sich so ein Aufwand nicht, selbst wenn es möglich wäre.

: grober Unfug. .. ein Kasper .. Was ist das für ein Quark? .. Das ist doch ebenfalls Quark. .. So ein Quark. .. Wenn ich da immer so einen Quark höre .. Kein Kasper kann mir erzählen ..

Bevor ich auf dein längeren Beitrag antworte, bitte ich dich, doch zu einem sachlichen Tonfall zu finden und Kraftworte sowie Referenzen zu Handpuppen oder Milchprodukten zu unterlassen.

Hier Amdahl's Law zu nennen ist grober Unfug. Erstens ist das ganze eine Theorie und grobe Approximation. Jedem sollte schnell klar sein, dass das keine wirkliche Gesetzmäßigkeit darstellt.

Wieso ist das Unfug? Es ist eine Abschätzung für den maximalen Geschwindigkeitsgewinn, der sich durch zusätzliche CPUs für ein Programm ergeben kann. Wo ist diese falsch oder Unfug?

Zweitens ist Amdahl's Law eine der pessimistischsten Herangehensweisen an Multi-Core-Software überhaupt

Ganz im Gegenteil, sie ist viel zu optimistisch, es werden nämlich weder die zusätzlichen Kosten für die Threaderzeugung berücksichtigt, noch die zusätzlichen Kosten für den Kommunikations- und Synchronisationsaufwand. Der Geschwindigkeitsgewinn wird in der Praxis also immer (deutlich) geringer ausfallen.

Ist euch eigentlich klar, dass jedweder Befehl, welcher mit dem Cache einer CPU auskommt, in wenigen Takten, das meiste sogar in 1-2 Takten, berechnet werden kann?
Ist euch weiterhin klar, dass die Auslagerung in den RAM, wenn es eben nicht in den Cache passt, meistens über 100 Takte benötigt? Wir sprechen hier also von einem Geschwindigkeitsverlust, der häufig grob mit dem Faktor 100 approximiert werden kann.

Dazu muss man dann nur noch wissen, dass mit mehr Kernen bisher immer ein linearer Anstieg des Caches einherging. Dadurch kann Software mit mehr Kernen nicht nur linear, sondern sogar supralinear beschleunigt werden.

Erstens ist der Zuwachs der Cachegröße eine Designentscheidung der CPU-Bauer und nicht zwangsweise gekoppelt an die Anzahl der Kerne. Zweitens produzieren mehr CPU-Kerne natürlich auch mehr Cache-misses, wenn der Cache nicht um den gleichen Faktor wie die Anzahl der CPU-Kerne wächst. Drittens müssen sich die ganzen Kerne leider immer noch den Speicherbus teilen, an der Stelle gibt es also einen zusätzlichen Engpass, da mehr Kerne nun mal auch häufiger auf den Speicher zugreifen wollen.

Und bevor jetzt ein Kasper exorbitante Cacheerhöhungen auf Single-Cores vorschlägt: bei Single-Core-CPUs limitert die Frequenz, die bekanntlich ab 4GHz nur noch schwer zu erhöhen ist. Ein riesiger Cache für einen Core würde also nichts bringen...viel Cache für viele Cores hingegen schon.

Was in aller Welt hat den jetzt die Taktfrequenz mit der Cachegröße zu tun? Natürlich bringt ein größerer Cache bei Singlecores etwas, nur steigt halt der Aufwand (Cachegröße) sehr viel stärker als der Gewinn, aber eben völlig unabhängig von der Taktfrequenz der CPU.
(Übrigens hat der DEC Alpha von 1995 bis zu 64MB L3 Cache bei 266MHz Takt)

Erstmal ergeben mehrere Prozesse natürlich einen Speedup für den User. Was ist das für ein Quark? Wenn eine Anwendung in einem Tab läuft und sehr viel Ressourcen frisst, dann gibt es natürlich keinen Speedup.

Dir fällt schon auf, dass du dir hier selbst widersprichst?

Nichtsdestoweniger ist das ja aber wohl selten der Fall, dass ein einziger Tab eine ganze CPU auslasten würde.

Genau genommen lastet er die CPU so ziemlich gar nicht aus, wenn er die Seite gerendert hat. Es sei denn irgendein Script läuft Amok.

Der Otto* weiß im schlimmsten Fall selbstredend gar nichts mit Tabs anzufangen. Den interessiert die Performance ja aber sowieso nicht.

Also ich gehe bei Otto* von dem Durchschnittsnutzer bei seinen alltäglichen Aufgaben aus, nicht von jemanden, der damit überfordert ist, zu entscheiden, auf welche Seite vom Bildschirm er schauen soll.

Das ändert damit also auch nichts daran, dass beispielsweise ich genau deshalb mal von Firefox weg bin (als der noch alles in einem Prozess laufen ließ): ein Chrome schmiert dir eben auch mit 100 Tabs nicht ab

Ja, und warum macht er das? Weil er seine Tabs in Prozesse auslagert, somit jeder der Prozesse eine eigene Umgebung hat und untereinander geschützt ist. Firefox stopft dagegen alles in einen Prozessraum rein, weswegen ihm da oft auch schlicht einfach der Speicher ausgeht, und da er, abgesehen von dem Speicherlecks, auch recht buggy ist, stürzt er halt mit allen Tabs ab. Wenn bei Chrome hingegen ein Tab stirbt, stirbt nur dieses. Das hat aber nichts mit der Anzahl der CPU-Kerne zu tun. Hab ich jetzt aber auch schon mehr als einmal geschrieben.

Abgesehen davon: für JavaScript gibt es seit geraumer Zeit WebWorker. Damit kann man, selbst wenn der Browser selbst Javascript nur einen Thread spendiert, zusätzliche Threads innerhalb von JS spawnen. Wenn der Programmierer dieses Feature nicht nutzt, hat das doch gar nichts damit zu tun, dass es nicht schneller gehen würde.

Was ist denn "es" was jetzt schneller gehen würde?

Ich hab z.B. schon neuronale Netze mit JS libraries im Browser (einfach mal zum Testen) laufen lassen und kann euch sagen: das skaliert wunderbar.

Ich glaube, neuronale Netze in Javascript im Browser laufen zu lassen, ist ganz genau das, was Otto* jeden Tag macht.

Zu "einige Sachen lassen sich nicht parallelisieren": Das ist doch ebenfalls Quark. Natürlich gibt es Algorithmen, die sich nicht oder nur schlecht parallelisieren lassen

Hier widersprichst du dir schon wieder selbst. Liegt es am Milchprodukt?

Hier wird mit einigen Exoten aus der Wissenschaft argumentiert, dass Parallelisierung ungemein schwierig wäre. So ein Quark.

Tja, Parallelisierung ist aber nun mal nicht einfach, das ist ganz und gar nicht exotisch.

Um nur mal ein super banales Beispiel zu nennen: Ich habe als Training im dritten Semester ein Pacman programmiert in C++11, wo jeder der vier Geister in einem eigenen Thread lief, sowie Pacman selber und die Spielwelt. Mit ein, zwei Hintergrundgeschichten und Syncen war es am Ende ein 8-Core Pacman.

Ist ja jetzt ganz wunderbar, nun sag mir doch mal wie hoch der Geschwindigkeitsgewinn zur Singlecoreversion ist (Nur zur Erinnerung, Pacman lief schon auf 8Bit CPUs perfect).
Ich weiß, dass das nur ein Beispiel ist, aber nehmen wir doch mal an, dass das was du getan hast sinnvoll wäre und du hast jetzt tatsächlich mit den vier Geistern vier Cores , plus weitere vier für irgendwelche "Hintergrundgeschichten", also acht Kerne voll ausgelastet. Und jetzt lässt du das ganze mal auf einer 16C CPU laufen. Was passiert? Dein Programm wird kein deut schneller, es skaliert null mit weiteren Kernen. Soviel zum Thema Exotik. Dein Beispiel ist viel mehr ein Beispiel dafür, dass Parallelisierung eben nicht beliebig möglich ist.

Natürlich wird darauf direkt ein Argument wie "ein Crysis zu parallelisieren ist aber schwieriger, als einfach Geister in Pacman parallel laufen zu lassen, wegen mehr Abhängigkeiten" kommen.
Ja, natürlich ist das so.

Ja natürlich kommt das Argument. Und wenn es die Abhängigkeiten im kritischen Pfad nicht zulassen, können das auch hunderte von Mitarbeitern nicht ändern.

Aber: arbeitet an Crysis auch nur ein Student im dritten Semester? Oder vielleicht ein paar Zehn oder Hundert Entwickler, im besten Fall fertige Absolventen, die sich gefälligst mit Parallelisierung auseinandergesetzt haben?

Wenn ich da immer so einen Quark höre, man könne Games nicht beliebig parallelisieren, deshalb werden nicht mehr als 4 Kerne unterstützt. Oder Speedup wäre zu gering. Der Speedup ist vielleicht bei 400 oder 4000 Kernen nicht mehr gegeben, wenn irgendwann alles im Cache liegt und man bei auch nur einem einzigen Thread mehr in der Sync-Hölle landet. Bis dahin ist es einfach nur mehr Entwicklungsaufwand, eine vernünftige Parallelisierung zu schreiben.

Dann mal die Gegenfrage, wenn Parallelisierung der Game-Engine so einfach oder überhaupt möglich wäre, glaubst du wirklich, man hätte das nicht längst getan? Bei einem AAA-Titel mit zig Mitarbeitern und Multimillionen $ Budget sollte das doch dann ein leichtes sein, oder glaubst du, dass dort nur inkompetente Deppen sitzen oder zu faul sind?

Ganz klar: das war angepasste Software, hatte einen limitierten (nur "rumfliegen" oder Blöcke "hin- bzw. wegklicken") Anwendungsbereich usw. Ebenso nur Singleplayer, sobald man Multiplayerzeugs hat wird die Parallelisierung natürlich noch aufwendiger.

Ich kenne das Programm deines Freundes nicht, auch will ich ganz sicher nicht seine Leistung schmälern. Aber wie du selbst sagst, ist das ganze sehr rudimentär, keine Gegner, keine Interaktionen, letztendlich nur eine Art 3D-Paint, wo du den Cursor bewegen kannst und einzelne Blöcke setzen und löschen kannst.

Kein Kasper kann mir erzählen, Spiele wären nicht vernünftig parallelisierbar.

Wie gesagt, die Kunst besteht darin, die Abhängigkeiten im kritischen Pfad so aufzulösen und auf unabhängige Teilaufgaben zu verteilen, dass mehrere Kerne ausgelastet werden können. Einfach nur ein paar Partikeleffekte rauszunehmen, oder die Physikberechnungen auf die GPU zu verlagern hilft da halt nicht weiter, weil das eben nicht reicht um auf eine beliebige Anzahl von Kernen zu skalieren. Offenbar ist das also nicht so trivial, wie du das hier versuchst darzustellen, wenn es denn tatsächlich möglich wäre, dann ist es doch erheblicher Aufwand, der letztendlich bezahlt werden muss, und deswegen nur bei einer geringen Zahl von Titeln mit entsprechendem Budget möglich ist.

 

[xexex]

Ich glaube damit ist/war eher gemeint es ergibt bei manchen Programmen einfach kein Sinn. Ein Powerpoint oder Word auf Quad Cores zu parallelisieren wäre Verschwendung und würde das Programm nur teurer machen und damit lässt es sich effektiv nicht parallelisieren.

Aber genau diese Aussage ist Quatsch und Word unterstützt schon lange mehrere Threads. Passende Links dazu habe ich bereits in diesem Thread verlinkt.

Wofür das Ganze?

Den größten Unterschied wird man bei der Autokorrektur und Grammatikpprüfung merken, allerdings nutzt Word selbst beim Öffnen von Dokumenten mehrere Kerne.
http://www.pcmag.com/article2/0,2817,2363800,00.asp
Bei PowerPoint hingegen vergisst du vielleicht die möglichen Effekte bei der Präsentation. Die brauchen einiges an Rechenzeit und nutzen selbstverständlich auch mehrere Kerne eines Prozessors.

 

[Cool Master]

Aber genau diese Aussage ist Quatsch und Word unterstützt schon lange mehrere Threads. Passende Links dazu habe ich bereits in diesem Thread verlinkt.

Threads sagen halt mal genau 0 aus. Mein Firefox hat aktuell 65 Threads am laufen trotzdem ist dieser nicht auf Multicore Systeme optimiert oder programmiert. Ich habe eben mal diesen Test ausgeführt und der bestätigt, dass ich nur 100% Auslastung der CPU bekomme und nein das bedeutet nicht alle Kerne aktiv sondern nur einer meiner 8. Handbrake nutzt z.B. 800% der CPU. Dazu kommt das sind keine eigenstädigen Threads sondern nur Child Threads die abhänig von dem Parent Thread sind da dieser die main() ausführt.

Den größten Unterschied wird man bei der Autokorrektur und Grammatikpprüfung merken

Da das Dokument im RAM liegt spürt man da nicht wirklich ein Unterschied. Den Unterschied welchen man spürt ist einfach die jährliche gesteigerte Single Core Leistung und eine mögliche SSD im System. Ich hatte bis letze Woche noch Office 2011 im Einsatz und bin nun auf Office 2016 ich spüre 0 Unterschied. Es sieht halt schöner aus das ist aber auch der einzige Unterschied.

allerdings nutzt Word selbst beim Öffnen von Dokumenten mehrere Kerne.

Kann ich nicht bestätigen. Bein öffnen eines Vertrages über 6 Seiten mir Arial Narrow in Größe 12 war der Peak bei 56,7% und somit nur auf einem Kern.

http://www.pcmag.com/article2/0,2817,2363800,00.asp

Alles Mitarbeiter von Microsoft mit welchen da gesprochen wurde. Der Bericht ist also nichts wert.

Bei PowerPoint hingegen vergisst du vielleicht die möglichen Effekte bei der Präsentation. Die brauchen einiges an Rechenzeit und nutzen selbstverständlich auch mehrere Kerne eines Prozessors.

Sorry aber Effekte in Powerpoint? Das bekommt selbst mein alter Mac in der Signatur, der nun 10 Jahre alt ist, ohne Probleme hin. Selbst mein alter Pentium 4 konnte PP mit diversen Effekten, Videos und Audio ohne Probleme laden und wiedergeben. Aber ich habe es auch hier wieder getestet und auch hier nope keine Multicore Support.

 

[xexex]

Da das Dokument im RAM liegt spürt man da nicht wirklich ein Unterschied. Den Unterschied welchen man spürt ist einfach die jährliche gesteigerte Single Core Leistung und eine mögliche SSD im System. Ich hatte bis letze Woche noch Office 2011 im Einsatz und bin nun auf Office 2016 ich spüre 0 Unterschied. Es sieht halt schöner aus das ist aber auch der einzige Unterschied.

Office ist laut Microsoft bereits seit der Version 2007 auf die Nutzung von Mehrkernprozessoren ausgelegt. Welchen Unterschied wolltest du also merken?

Abgesehen davon gibt es Office 2011 nur für Mac, das lässt sich eh schlecht mit einer PC Version vergleichen.

Du behauptest also die bei Microsoft wären alle Lügner und behaupten nur, ihre Software würde mehrere Kerne nutzen weil DU keinen Unterschied merkst..... Nun gut....Soso....

Ihr vergesst außerdem bei den ganzen selbst erstellten Vergleichen, dass Office genauso auf einem €80 Tablet wie auch einem Terminal Server läuft. Da macht eine Optimierung auf jeden Fall sinn. Ob man davon was auf einer 4Ghz Gamerkiste mitbekommt, ist eine andere Sache, war aber auch nicht bestand der Diskussion.

Letztlich ging es darum die Behauptung zu widerlegen nur ganz spezielle Software würde nur unter wenigen Umständen mehrere Kerne nutzen. Das ist aber letztlich heutzutage schon lägst nicht mehr der Fall.

 

[Cool Master]

Abgesehen davon gibt es Office 2011 nur für Mac, das lässt sich eh schlecht mit einer PC Version vergleichen.

Ich vergleiche 2011 und 2016 aufm Mac.... Wie gesagt kein Unterschied spürbar und trotzdem nutze es nur ein kern wie ich weiter oben ja schon schrieb.

Du behauptest also die bei Microsoft wären alle Lügner und behaupten nur, ihre Software würde mehrere Kerne nutzen weil DU keinen Unterschied merkst..... Nun gut....Soso....

Wo sagte ich was von Lügner? Ich glaube nur nicht einem Bericht wo es keinerlei Benchmarks gibt und alle Infos von dem Hersteller der Software kommt und weil meine Aktivitätsanzeige nur bis max. ~60% hoch geht und auch nur auf Core 0.

Ihr vergesst außerdem bei den ganzen selbst erstellten Vergleichen, dass Office genauso auf einem €80 Tablet wie auch einem Terminal Server läuft. Da macht eine Optimierung auf jeden Fall sinn. Ob man davon was auf einer 4Ghz Gamerkiste mitbekommt, ist eine andere Sache, war aber auch nicht bestand der Diskussion.

Das sprach ich ja an. Du spürst einfach ein unterschied wegen der Single Core Leistung der letzen Generationen an Intel Core i Prozessoren und nicht weil die Software so super optimiert ist.

 

[jbauer]

Aber genau diese Aussage ist Quatsch und Word unterstützt schon lange mehrere Threads. Passende Links dazu habe ich bereits in diesem Thread verlinkt.

Jeden deiner links habe ich widerlegt. Das Problem ist, dass du anscheinend nicht den Unterschied zwischen Prozessen, Threads und CPU-Kernen verstehst.

Ein Programm nutzt nur dann N Kerne (sinnvoll), wenn wenigsten zeitweise auch mindestens N Threads _gleichzeitig_ laufen. Also nicht einfach nur existieren, sondern wirklich gleichzeitig laufen (oder im Status ready to run, r2r, sind). (*Und ja, da gibt es Ausnahmen, aber die sind jetzt im Bsp. nicht relevant)
Während das für N=1, also ST, einfach ist, ist das für N=2, also MT, schon sehr viel schwieriger. Und je größer N ist ist, um so schwerer ist das zu realisieren, oder je nach Problem schlicht unmöglich. Und für den Massenmarkt hat sich halt zZt ein N=4 am sinnvollsten erwiesen.

Zeige mir doch mal nur eine Situation, wo Word in einem einzigen Prozess 100% CPU-Auslastung (oder wenigstens (N-1)/N)) auf einem Mehrkernsystem, idealerweise natürlich mindestens acht Kerne, für einen relevanten Zeitraum hinbekommt.

Letztlich ging es darum die Behauptung zu widerlegen nur ganz spezielle Software würde nur unter wenigen Umständen mehrere Kerne nutzen. Das ist aber letztlich heutzutage schon lägst nicht mehr der Fall.

Und du kannst es noch zig mal wiederholen, durch ständige Wiederholung wird es weder wahrer noch irgendwann tatsächlich wahr.

 

[Buttermilch]

Fühlt sich durch die Diskriminierung von Milchprodukten herabgewürdigt.
Ich finde in den von mir verlinkten Beiträgen recht gut erklärt, wo die Grenzen der parallelisierbarkeit und damit Amdahls Gesetze greifen, gut gezeigt. Der Zusatznutzen pro Kern nimmt immer weiter ab, bis es Nachteile gibt es also langsamer geht.

Keine Ahnung ob sich das mit weiteren Cache Stufen L3 L4 L5, verbesserte Sprungvorhersagen, anderes Pipelinedesign, mehr spezielle ALU und Fpga units statt algemeiner Rechenwerke im der CPU, Vergrößern von Bandbreite zum Cache, Reduktion von Wartezyklen bei SRAM Zellen, andere Organisationsform dieser, mehr Speicherkanäle für die aktivere Nutzung einer RAM disk und co weiter vermeiden lässt oder ob eine neue CPU-Architektur die Flaschenhälse reduziert einen neuen Ansatz darstellt. Evtl auch Wege wie es im ARM Bereich ist, mit big Little Strategien, oder wenn viele Kerne sich wie ein paar Größere verhalten. Apples A9 2 oder 3 Kerne ist z.B. auch das Gegenteil von Samsung ARM CPU Ansatz oder was ja bei skylake vermutet wird / wurde das es ein umgekehrtes SMT geben könnte. Ich bin leider kein CPU Experte, da fehlt mir das Wissen in theoretischer Informatik zu.
Ich denke aber, das hier mehr knowhow zu finden ist aber sowohl Hardwareseitig Ls auch Softwareentwickler bzw Betriebssysteme und Entwicklern von Interpretern, Compilern und Entwicklern neuer Hochsprachen da zusammensetzen müssen.

 

[ascer]

Bevor ich auf dein längeren Beitrag antworte, bitte ich dich, doch zu einem sachlichen Tonfall zu finden und Kraftworte sowie Referenzen zu Handpuppen oder Milchprodukten zu unterlassen.

Nun, tatsächliche Fäkalsprache liegt mir nicht, weshalb ich Emotionen gern mit Handpuppen oder Milchprodukten manifestiere. Bei einem konstruktiven Diskurs kann ich jenes natürlich gern unterlassen, aber die Masse der Beiträge hier las sich eben wie "mehr als 4 Kerne geht nicht!!!11einself" oder "keine Software kann mehr als 4 Kerne nutzen!!!11einself" - wobei Software bei der Masse hier ja auch noch direkt Synonym zu Spielen ist. Gleichzeitig bezweifle ich stark, dass die Masse hier je in der Softwareentwicklung tätig war, besonders was Parallelisierung angeht.
Deshalb, so finde ich, waren die Milchprodukte und der Kasperl ganz nett

Wieso ist das [Schlussfolgerung aus dem Ahmdalschen Gesetz] Unfug? Es ist eine Abschätzung für den maximalen Geschwindigkeitsgewinn, der sich durch zusätzliche CPUs für ein Programm ergeben kann. Wo ist diese falsch oder Unfug?

Abgesehen von der Cache-Problematik (die Amdahl komplett ignoriert; siehe weiter oben, wo ich die Supralinearität durch Cachezuwachs kurz angeschnitten habe), geht Amdahl z.B. auch von konstanter Problemgröße aus. D.h. Ahmdal's Law beschreibt im Prinzip den Speedup eines konstanten Problems, das so schnell wie möglich ablaufen soll.
Für die theoretische Informatik ist das in der Tat interessant (gibt wohl auch keine Uni, die das nicht durchnimmt)...für die Praxis ist das aber Quatsch.

Ein praktisches Beispiel, um es der Masse verständlicher zu machen:
Setzt man einen Polizisten ein, um ein Waldstück w der Größe 10m^2 nach einer Leiche abzusuchen, dann schafft der eine Polizist das in einer bestimmten Zeit t. Logischerweise macht es in der Praxis gar keinen Sinn, w mit 1.000 Polizisten abzusuchen - die passen nicht mal ansatzweise überhaupt zeitgleich auf w. Man möchte mit 1.000 Polizisten also nie einfach nur t noch weiter verringern. Man möchte mehr als nur w parallel machen.
Genau diese Annahme macht Amdahl's Law aber: konstante Problemgröße, mit größerer Aufteilung. Also so viel Polizisten wie möglich auf w werfen, damit t so klein wie möglich wird. Klar, dass das sehr schnell sehr ineffizient wird.

In der Realität macht es aber ja genau andersrum: hat man mehr Ressourcen (=Kerne) zur Verfügung, dann bearbeitet man größere Probleme. Anstatt also ein einziges Waldstück w abzusuchen mit 1.000 Polizisten, erhöht man das Suchgebiet auf 500 Waldstücke mit z.B. 20m^2.

Denn: durch die gleichzeitige Erhöhung der Gesamt- sowie der Teilkomplexität erhält man einen vernünftigen Speedup.
Durch mehr Ressourcen, also mehr Kerne, kann ich damit ein größeres Problem als vorher abarbeiten. Erhöhe ich gleichzeitig noch die Teilproblemgröße, wird der Aufwand für Initialisierung und Synchronisierung der Threads immer indifferenter.

Natürlich, da gebe ich dir auch vollkommen Recht, funktionieren derartige Praktiken immer nur bis zu einem endlichen N. Dadrüber werden die Teilprobleme zu groß (-> Threads müssen zu lange auf Ressourcen anderer Threads warten), dadrunter werden sie zu klein (-> Initialisierungaufwand und/oder RAM-Verbrauchung ist größer als Performancegewinn durch weitere Aufteilung. Oder das Problem ist sogar nicht mehr weiter sinnvoll aufteilbar).

Nichtsdestoweniger kann mir aber niemand erzählen, dass N=4 (seit Jahren) einfach für jedwedes Spiel und N=[1, 4] für beliebige "Normalsoftware" die perfekte Lösung darstellt.

Das liegt imho einzig an einer Teilmenge von:
- zu wenig Budget
- zu unversierten Programmierern
- der Tatsache, dass im Consumermarkt seit Jahren nur 1-4 Kernprozessoren verkauft werden

Erstens ist der Zuwachs der Cachegröße eine Designentscheidung der CPU-Bauer und nicht zwangsweise gekoppelt an die Anzahl der Kerne.

Deshalb schrieb ich "bisher war die Cachegröße immer linear mit der Anzahl der CPU-Kerne". Bitte richtig lesen.

Zweitens produzieren mehr CPU-Kerne natürlich auch mehr Cache-misses, wenn der Cache nicht um den gleichen Faktor wie die Anzahl der CPU-Kerne wächst.

Das ist richtig, aber irrelevant wenn man möglichst an den Idealzustand rankommt, dass so viele Kerne wie möglich was zu tun haben und die Masse der Befehle, die die Kerne verarbeiten, möglichst in deren Cache passt.

Drittens müssen sich die ganzen Kerne leider immer noch den Speicherbus teilen, an der Stelle gibt es also einen zusätzlichen Engpass, da mehr Kerne nun mal auch häufiger auf den Speicher zugreifen wollen.

Korrekt, aber Busbreite und andere Faktoren wurden mit der Zeit ja nun auch immer nach oben skaliert und stagnierten nie.

Was in aller Welt hat den jetzt die Taktfrequenz mit der Cachegröße zu tun?

Das einzig und allein darauf bezogen, dass mehr Cache nur solange etwas bringt, bis alle Befehle in den Cache passen. Da die Geschwindigkeit des Caches jetzt nie exorbitant gestiegen ist, skaliert es danach nur noch mit dem Takt. Wenn ein Algorithmus von seiner Natur aus eben 1.000 Takte benötigt, dann wird der, nachdem er vollständig in den Cache passt, nur noch doch eine deutlich höhere Taktfrequenz (oder Parallelisierung, falls möglich) schneller.

Ich glaube, neuronale Netze in Javascript im Browser laufen zu lassen, ist ganz genau das, was Otto* jeden Tag macht.

Wir wollen jetzt hoffentlich nicht in absichtlem Fehlverstehen von Aussagen kommunizieren: natürlich hat das nichts mit dem Otto* zu tun. Sollte aber eines Aufzeigen: selbst Javascript lässt sich mit vertretbarem Aufwand parallelisieren.

Und wieder: kriegt das ein Student hin, bei vergleichsweise komplexen Kram wie KIs, dann sollte es für ein ganzes Entwicklerteam und größere Software wohl nicht das Problem sein, ebenfalls mal ein wenig parallelen Code zu produzieren.



Grundlegend fand ich deine Ausführungen in Teilen durchaus korrekt, meine Milchprodukt-Résistance rebellierte also vornehmlich gegen das dogmatische wiederholen der breiten Masse, dass mehr als 4 Kerne Schwachsinn seien.

Und noch mal abschließend als Denkanstoß: auf welchem PC läuft bitte stets nur eine einzige Anwendung? Wenn also wirklich mit N=4 schon das Ende erreicht wäre, würden sicherlich trotzdem mindestens 6 Kerne für CPUs sinnvoll sein, einfach um eine Anwendung mit N=4 voll auszustatten, während der Rest im Hintergrund auf 2 Kernen läuft.

 

[xexex]

Ich vergleiche 2011 und 2016 aufm Mac.... Wie gesagt kein Unterschied spürbar und trotzdem nutze es nur ein kern wie ich weiter oben ja schon schrieb.

Die Aussage bezog sich jedoch auf Windows Software. Ich glaube kaum, dass Microsoft ihre Produkte gleichermaßen auf beiden Systemen optimiert. Auch wenn es bei den Kernen noch "eigentlich" möglich sein sollte ist schon die GPU Unterstützung auf beiden Systemen unterschiedlich. Um also die Aussage eines Microsoft Mitarbeiters die sich auf Office 2007 und 2010 bezieht zu widerlegen solltest du auch mit den Versionen testen.

OK. Meine Ausführung hätte ich mir sparen können.
https://excel.uservoice.com/forums/...-excel-for-mac-2016-utilize-multiple-cores-on
Auf dem Mac nutzt Microsoft nicht einmal für Excel mehrere Kerne.

Jeden deiner links habe ich widerlegt. Das Problem ist, dass du anscheinend nicht den Unterschied zwischen Prozessen, Threads und CPU-Kernen verstehst.

Du hast bisher gar nichts widerlegt sondern bestenfalls nur irgendwelche eigenen Behauptungen aufgestellt.

Wo bleiben deine Links? Wo bleiben deine nachvollziehbaren Tests. Sorry aber mich hier hinstellen und irgendwelche trockenen Behauptungen aufzustellen die bereits von "ascer" widerlegt wurden hat nichts mit dem Bezug zu Realität zu tun. Es geht um bereits auf dem Markt befindliche Software und deren Tauglichkeit mit der steigenden Anzahl der Kerne zu skalieren und die ist bei dem Großteil der auf dem Markt befindlicher Software bereits gegeben.

Ob man davon bei Word profitiert mag vielleicht bei der Geschwindigkeit der derzeitigen Prozessoren recht selten zutreffen. Spätestens bei dem Browser kann man bereits sehr schnell an die Grenzen der Hardware stoßen. Du solltest halt nicht von einem übertakteten i7 ausgehen, sondern von einem Atom der in vielen der heutzutage ausgelieferten Tablets verbaut ist oder gar von einer ARM CPU.

Am Ende steht die Frage würden wir von Prozessoren mit 16 oder 32 Kernen profitieren und in welchen Maße würde diese Entwicklung endlich einen gewissen Sprung bei Computern für den Endbenutzer bedeuten im Gegensatz zu den Schrittchen mit denen die Entwicklung derzeit voranschreitet? Dazu hat "ascer" denke ich gute Argumente hervorgebracht und auch Intel bestätigt bei der aktuellen Entwicklung, dass mit MEHR Kernen auch problemlos MEHR Kerne genutzt werden können. Dazu müssen diese Ressourcen aber erst einmal vorhanden sein und hier gibt ein Henne/Ei Problem.

Und nochmal für dich

Surfen - Beliebig viele Kerne werden unterstützt wenn er mehrere Tabs gleichzeitig nutzt.
Virenschutz - Profitiert von zusätzlichen Kernen.
Bildchen bearbeiten - Selbst paint.net ist ausdrücklich für mehrere Kerne optimiert.
Videos/Bilder schauen - so ziemlich jede Software die IRGENDWAS mit Multimedia zu tun hat unterstützt mehrere Kerne oder die GPU.
Office - Wie verlinkt werden AUSDRÜCKLICH mehrere Kerne unterstützt.
Komprimieren - keine Frage
Spiele - Ehrlich? soll ich noch weiter aufzählen?

Das ist durchaus ein Softwarepaket was jeder Otto Normalverbraucher in der Benutzung hat und da brauche ich keine theoretischen Ausführungen über die Unterschiede zwischen Threads, Prozessen und der Frage nach dem Sinn des Lebens. Kann ich als Endanwender bei Chrome nun von mehreren Kernen profitieren? JA! Für den Endanwender ist es die einzige Frage. Ob das derzeit nur möglich ist wenn mehrere Tabs genutzt werden oder ob Chrome bereits jeden einzelnen Download aufteilt ist mir nicht bekannt und ehrlich gesagt auch egal. Dafür läuft Chrome/IE/Edge bei allen Geräten die sich in meinem Besitz befinden einfach zu schnell. Trotzdem widerspricht es der Behauptung nur ganz spezielle Software würde von mehreren Kernen profitieren weil in meiner Auflistung sich so ziemlich jegliche Software befindet die der Otto Normaluser in seinem Alltag benötigt.

Welchen Profit er davon trägt hängt also letztlich einzig von seinem Nutzungsprofil ab und der Geschwindigkeit der einzelnen Kerne. Da sich die Geschwindigkeit derzeit aber nicht beliebig steigern lässt, die Kernzahl aber problemlos auf Serverniveau erweitert werden könnte wo 16+ Kerne immer stärker verbreitet sind, liegt hier die Zukunft in der Entwicklung die derzeit durch Intel künstlich begrenzt wird.