Mehr Kerne = die "beste" Verbesserung?

Mehr Cores ist und bleibt die Notlösung.

Äh ja.... darum ist es auch schon seit zig Jahren üblich in Superrechner mehr und mehr CPU´s zu verbauen.

Man muss schon sehr Engstirnig sein um mehrere Jahrzehnte in denen im High End Bereich immer auf Multi Prozessor Systeme gesetzt wurde als Notlösung abzutun ;)

Im Gegenteil, man hat erkannt das der GHZ Wahn völliger Humbug ist. Es gab da mal einen netten Bericht über Intel, ist schon zig Jahre her, da lief in einem Labor eine CPU mit annährend 10 GHZ! Aber der Ingenieur sagte schon damals das die Zukunft den Multiprozessor Systemen gehört, da sie Energieeffizienter seien. Selbst der Moderator der Sendung ( der Computerclub), hatte schon damals Wunschvorstellungen von Multicore CPU´s geäussert.
Der Grund waren Regelmäßige Veranstaltungen von eben dieser Sendung in der Cluster aus so vielen Rechnern wie Möglich gebaut wurden, um mehr Leistung zu erzielen.

Heute hat man die Möglichkeit mit relativ einfachen Mitteln eine Rechenleistung zu generieren die vor ein paar Jahren (Trotz 10 GHZ CPU´s im Labor) noch undenkbar war. Da man die Hitze nicht mehr abführen konnte.
Es gab gar Überlegungen Rechner mit Kompressorkühlungen Salonfähig zu machen. Siehe Waibels Wahnsseeblitz, ein 1 Ghz Athlon zu Zeiten als grad mal 600 bis 700 Mhz CPU´s das Nonplusultra waren. Aber die Firmen wie Asetek mit ihren Kommerziellen Kompressorkühlungen sind praktisch mit erscheinen der Multicore CPU´s im Abseits verschwunden, bzw. haben sich auf andere Geschäftsfelder spezialisiert, weil es im Professionellen Bereich keinen Bedarf an Zig Ghz CPU`s gab die ausser heisser Luft nicht viel zur Produktivität beitrugen. Selbst die ersten Pentium 4 mit den ersten Hyperthreading Versuchen waren in passenden Umgebungen einem Single CPU System Überlegen.
Also in bestimmten Bereichen ist der Schritt zu Multicore eher eine Folge von Richtigen Überlegungen oder besser, es wurde für den Heimbereich etwas zugänglich gemacht das im absoluten High End Bereich (Dual CPU Xenon, Itanium und co.) schon seit Zig Jahren gängige Praxis war.

Wenn ich bedenke was mich damal ein System mit 2 Prozessoren gekostet hat und heute jedes Smartphone (Aja auch dank Dualcore und co.) schneller ist... :rolleyes:

Aber hey, jeder hat seine eigenen Meinung, gell ;)
 
Sagt mal, warum geht ihr immer davon aus, dass nur eine Anwendung läuft? Wenn ich bei mir in den Taskmanager schaue, sind das 68. Und dabei ist das nicht mal viel.

Jeder Switch zwischen den Prozessen benötigt einen Kontextwechsel*. Je mehr Kerne und je weniger die Prozesse zwischen den Kernen umherspringen, desto weniger Kontextwechsel sind nötig.


*Für jene, die nicht so bewandert sind: Kontextwechsel bezeichnet das Entladen der alten Prozessumgebung und das Laden der neuen Prozessumgebung in einen CPU-Kern.
 
GrinderFX schrieb:
Dafür ist aber das Betriebssystem da um dies zu verhindern bzw. je nach notwendigkeit zu verteilen.
Es ist einfach ein Fakt, dass ein schneller Singlecore definitiv überlegen ist. Alleine schon mathematisch, da man nie perfekt eine Anwendung auf 2 oder mehr Prozessoren verteilen kann. Also wäre ein Xcore nur im Idealfall genauso schnell wie ein doppelt so schneller singlecore. (Bsp: 2 * 1 ghz VS. 1 * 2 ghz).
Wer sich mal mit Echtzeitsystemen und sowas beschäftigt hat wird es verstehen wieso es so ist.

Theorethisch :p, in der Praxis hängt es vom Anwendungsfall ab. Wenn viel zwischen verschiedenen Tasks/Threads gewechselt werden muß kann ein Multicore von Vorteil sein. Bei jedem Wechsel muß schließlich der Kontext der CPU(Stack, Cache usw.) geändert werden. Viele Taskwechsel kosten den Singlecore Zeit die er nicht fürs Rechnen verwenden kann.

@e-Laurin
:daumen:
 
Zuletzt bearbeitet: (@e-Laurin)
Fischkopp schrieb:
Äh ja.... darum ist es auch schon seit zig Jahren üblich in Superrechner mehr und mehr CPU´s zu verbauen.
Auch hier hat man nicht viele CPUs verbaut weil viele CPUs toll sind sondern weil die Leistung einer CPU nicht ausreichte, es gab also keine andere Lösung.


e-Laurin schrieb:
Sagt mal, warum geht ihr immer davon aus, dass nur eine Anwendung läuft? Wenn ich bei mir in den Taskmanager schaue, sind das 68. Und dabei ist das nicht mal viel.
Und bei wie vielen davon siehst du ne CPU-Load über 1% ?
In der Theorie ist es ja toll wenn viele Programme/Prozesse laufen und sich die Arbeit auf die CPUs aufteilen kann, aber wenn du in der Praxis dann 67 Tasks hast die zusammen 5% CPU brauchen (oder 0-1% bei Windows XP ;)) und einen einzigen der wirklich Last macht nützt das im Endeffekt nichts.


@IceDragon87:
Laut meinem "Zuverlässigkeitsmanager" liegt das letzte "Stopped responding and was closed" nen Monat zurück.
Was natürlich nicht heißt, dass das ein Programm war was 100% load gemacht hat. Sowas konnte ich nicht finden, ich entsinne mich auch an keine Situation seitdem ich Windows 7 drauf hab.
Und ich freue mich, dass du ich dein Held sein kann. ;)
 
Blutschlumpf schrieb:
...
Und bei wie vielen davon siehst du ne CPU-Load über 1% ?
In der Theorie ist es ja toll wenn viele Programme/Prozesse laufen und sich die Arbeit auf die CPUs aufteilen kann, aber wenn du in der Praxis dann 67 Tasks hast die zusammen 5% CPU ...

Ich mach mal ne Milchmädchenrechnung, also bitte nicht schreiben das es Blödsinn ist, das weiß ich.

67 Programme * 1% CPU Last = 67% also bleibt für das eigentliche Programm <33% CPUleistung übrig.

Bei zwei Kernen,
66 Programme mit 1% pro Programm auf einem Kern, da ist noch Luft
das Hauptprogramm zu 100% auf dem zweiten.

In der Praxis ist es nicht so gravierend, aber das Prinzip sollte klar sein.
 
was 100% load gemacht

Keine spricht hier von 100% Load
Ein Prozess kann sehr wohl hängen bleiben ohne das er 100% verlangt habe.
Nur dadurch das ein andere prozess bevorzugt wird der aber auch nicht zu 100% läuft.

Die sicht und verständis wird sich aber bei dir nicht ändern, vielleicht mal später.
Ich möchte auch nicht weiter diskutieren es ist wochenende.
Mein Vater könnte dich bestimmt aufklären, der ist echt ein Crack in PC. War mal 25 Jahre bei IBM.
Wo es noch IBM war :p
Bildet sich aber immer noch weiter. Und könnte dir bestimmt eine Seite lang alles erklären :D

Ich fande die Diskussuion ganz gut am anfang da es einfach interessant ist und man was lernen kann.
Aber nun macht es mich nur müde ;)..........
 
e-Laurin schrieb:
Notlösung klingt nach "irgendwie passt's scho'". Das ist aber mitnichten der Fall!
Hast Recht .. das war vielleicht etwas überdramatisch ausgedrückt.
Es ist natürlich eine Lösung, die auch funktioniert. Vor allem ist es eine Lösung, die machbar ist. Andere (noch bessere) Lösungen sind nicht so ohne weiteres machbar, weshalb MultiCores nunmal der Weg ist, den wir im Moment einschlagen.

Um auf die Thread-Frage zurück zu kommen:
Die "beste" Verbesserung ist es nicht. Und wenn du die Wahl zwischen einem DualCore und einem theoretisch gleich schnellen SixCore hast, dann nimm den DualCore, denn in der Realität kann der seine Leistung besser ausnutzen.

@Fischkopp
Es kommt auch immer auf die Einsatzzwecke an.
Für Echtzeit-Anwendungen ist es oft sehr schwer, eine gute Parallelisierung zu erreichen.
Rechencluster, die vor allem ungeheure Berge an Daten auswerten, haben ganz andere Anforderungen, als ein PC, der vor allem schnell mit seinen Berechnungen fertig sein muss.

Hansdampf12345 schrieb:
Vielleicht sollte man sich ne Quelle erstmal selbst genau durchlesen, bevor man sich damit ins Knie schießt :D
Vielleicht sollte man das gelesene auch erstmal verstehen, bevor man so einen Kommentar abgibt.
 
Zuletzt bearbeitet:
@Blutschlumpf:
Somit ist jede logische Überlegung, die darauf beruht, dass andere Wege nicht mehr beschritten werden KÖNNEN eine Notlösung....
So ein Unfug. Eine Notlösung ist eine Lösung, die entgegen logischer Wege getroffen wird, weil die Möglichkeiten die Lösung anderes zu finden aufgrund äußerer Bedingungen (z.B. fehlende Schrauben, Aufhängungen, was auch immer) mit anderen, weniger geeigneten ausgeführt wird.

Die Multi-Cores waren keine Notlösung, sondern eine logische Entwicklung der Frage: Was bringt mir mehr (kam sogar vor den wahnsinnig schnellen prozessoren auf), Viele Kerne (Menschen), die verteilt ihre Arbeit verrichten, oder ein Kern (Mensch), der ganz schnell seine Arbeit verrichtet.
Logische Antwort lautet immer viele Menschen, die verteilt arbeiten. Denn die sind einfach Produktiver.
 
vander schrieb:
Ich mach mal ne Milchmädchenrechnung, also bitte nicht schreiben das es Blödsinn ist, das weiß ich.
Warum postest du es dann wenn es dir selber schon offensichtlich ist, dass es Unsinn ist ?

Mach mal den Taskmanager auf.
XP auf nem C2D hat bei mir ca. 1% im idle gebraucht, mein Windows7 mit Winamp und nem Download im Hintergrund braucht ca. 5%.
Die ganzen Hitnergrundprogramme spielen schlichtweg keine Rolle bzw. bewegen sich im Bereich Messtoleranz.

@MichiSauer:
Um mehr als einen Core zu nutzen muss(te) man große Teile der Softwarebasis neu machen, darum ist für mich Notlösung hier passend.

btw, wenn du ein Arbeitspensum hast was eine Person abarbeiten kann ist es meiner Erfahrung nach deutlich effektiver wenn es eine Person Vollzeit macht statt 2 Personen mit halber Zeit.
Letzteres bedeutet nur Mehraufwand durch die nötigen Absprachen zwischen den beiden.
2 Arbeiter mit halbem Aufwand machen bei Menschen nur den Vorteil aus, dass einer evtl. mal Urlaub machen oder krank sein kann, das lässt sich aber eher nicht auf CPUs übertragen. ;)
 
das wird ja immer lächerlicher hier...
Wenn eine CPU mit doppelter Taktfrequenz den vierfachen Strom zieht, warum brauchte es dann Jahre bis Stromsparlösungen für PCs/Endanwender überhaupt in Frage kamen? Bsp. hatte ich 96 einen 233Mhz PII, im normalen Arbeiten (Works, Word, Internet) hätten 50 locker gereicht. Der hätte dann nur 1/8 verbraucht??
oder mein 1,5GHz P.M im X31,bei den 600Mhz, auf denen er die meiste Zeit rennt, zieht dann 1/4 der P_W?
:evillol:

Adamahl wurde ja schon gennannt. Und auch, dass die Anwendungen drauf optimiert sein müssen. Die meisten Kiddies hier haben aber schlicht zu wenig Ahnung, um zu wissen, dass auch beim 4-Kern sich Anwendungen abwechseln, und das Zeit braucht (das ist Betriebssystemabhängig, und nur genau deswegen sind emulierte CPU manchmal schneller).

Auch die Anforderungen an Supercomputer, irgendwann mal mit den massigen Rechnungen fertig zu werden, im Gegensatz zu Echtzeitanforderungen, wurden ja genannt.

Spannen zu hören, dass die hier so schreiben, gar keinen Wert auf Lags und Co legen... :king:
 
Andy386 schrieb:
Wenn eine CPU mit doppelter Taktfrequenz den vierfachen Strom zieht
Der "Verbrauch" steigt in der Regel linear zum Takt und quadratisch zur Spannung (natürlich bei gleicher CPU, Aufbau, Strukturgröße).
 
e-Laurin schrieb:
Es ist eindeutig erkennbar, dass sich die CPUs von der Architektur her in dieselbe Richtung entwickeln wie die GPUs.
Eine GPU hat bei der Grafik einfache, vorhersagbare Jobs nach bekannten Algorithmen zu erledigen, die sich prima parallelisieren lassen. Sowas kann man durch Einsatz vieler paralleler Recheneinheiten wunderbar beschleunigen. Ein Grafikchip macht immer wieder das gleiche. Da steckt man einmal viel Hirn in den Treiber, kann wunderbar optimieren und die vielen Rechenwerke auslasten.

Die Jobs, mit denen CPUs in PCs kämpfen, sind völlig anders. Sie sind möglichlichweise weniger gut parallelisierbar aber vor allem _weit_ vielfältiger und komplexer. CPUs werden mit tausenden verschiedenen Problemen gefüttert - ganz anders als eine GPU. Von den tausenden Problemen könnte man zwar theoretisch auch viele parallelisieren, aber man muß das für jedes neue Problem erneut tun. Das ist teuer und passiert deshalb in der Praxis nur selten. Deshalb sind viele CPUs eigentlich nur in Servern sinnvoll, wo man die Probleme gar nicht erst parallelisieren muß, um den Server gut auszulasten. Man füttert den Server einfach gleichzeitig mit vielen Problemen, oft mit vielen Instanzen des gleichen Problems. Damit wird zwar der einzene Job durch vielen CPUs des Servers nicht schneller fertig, aber wenigstens steigt der Durchsatz (Gesamtzahl Jobs pro Zeit).

Abseits von Servern, die man leicht mit vielen Jobs gleichzeitig auslasten kann, sind Multi-CPU-Rechner tatsächlich nur eine Notlösung. Ein Single-Core mit 4-facher Leistung pro Kern wäre selbstverständlich viel toller als ein Quad-Core, der theoretisch in der Summe seiner 4 Kerne das gleiche leisten kann. Dummerweise bekommen die Ingenieure sowas nicht hin. Also baut man paar mehr Kerne in den 0815-Rechner (die paar mm^2 Chipfläche sind billig) und hofft darauf, dass alle Welt ihre simplen, bewährten Algorithmen in komplizierte, parallelisierte Algorithmen transformiert.

MichiSauer schrieb:
@Blutschlumpf:
Somit ist jede logische Überlegung, die darauf beruht, dass andere Wege nicht mehr beschritten werden KÖNNEN eine Notlösung....
So ein Unfug. Eine Notlösung ist eine Lösung, die entgegen logischer Wege getroffen wird, weil die Möglichkeiten die Lösung anderes zu finden aufgrund äußerer Bedingungen (z.B. fehlende Schrauben, Aufhängungen, was auch immer) mit anderen, weniger geeigneten ausgeführt wird.
Blutschlumpf hat das schon richtig beschrieben. Notlösung triffts wunderbar. Eine Notlösung ist keinesfalls ein "unlogischer Weg". Das Problem, Rechner nicht mehr so schön regelmäßig schneller machen zu können wie vorher, lösten Multi-CPUs für PCs anfangs gar nicht. Es gab schlichtweg keine Probleme auf PCs, bei denen mehrere CPUs die Lösung waren, weil es keine Software gab, die von zusätzlichen CPUs profitierte.

Wenn du etwas schneller von A nach B transportieren willst, wünschst du dir ein schnelleres Auto. Sagen wir mal 200km/h. Wenn aber alle Autos dieser Welt nur wie dein eigenes Auto 100km/h schaffen, ist es keine äquivalente Lösung, dir statt des gewünschten 200km/h-Autos ein 2. 100km/h-Auto vor die Tür zu stellen. Schneller wirst du durch das 2. Auto nicht.

Trotzdem _kann_ das 2. Auto eventuell als Notlösung helfen. Vielleicht wolltest du nur schneller von A nach B, weil du dann die Tour öfter fahren könntest und so pro Monat mehr Volumen liefern könntest. Wenn das der Fall ist, würde das 2. Auto tatsächlich helfen (wenn du noch einen 2. Fahrer einstellst). Es könnte aber auch sein, dass du schneller von A nach B wolltest, weil die gelieferte Milch bei B immer schon sauer war. Dann hilft die "Notlösung" 2. Auto nicht weiter.

Genauso sieht es bei Multi-CPU in PCs als Notlösung für schnellere single-CPUs aus. Manches Problem löst die Multi-CPU, wenn man den Zusatzaufwand auf sich nimmt, die Software auf Parallelverarbeitung umzuschreiben. Geht das Umschreiben nicht, bringt die Multi-CPU gar nichts. Es ist eben nur eine Notlösung für den schnelleren Rechner.
 
Zuletzt bearbeitet:
Blutschlumpf schrieb:
Warum postest du es dann wenn es dir selber schon offensichtlich ist, dass es Unsinn ist ?
...

Wie erklärt man ein komplexes Problem das auf einer Fülle von möglichen Kombinationsmöglichkeiten besteht? Man sucht sich eine Möglichkeit heraus und stellt sie dar. Damit hat man zwar bei weitem nicht alles abgedeckt, aber die Komplexität wird auf ein verständliches Maß reduziert. Ist dir der Zweck meines Beispiels jetzt klar?
Schon komisch das du es nicht verstehst(verstehen wills?), schließlich nutzt du die gleiche Technik in deinem Posting, du weist nur nicht darauf hin.

btw, wenn du ein Arbeitspensum hast was eine Person abarbeiten kann ist es meiner Erfahrung nach deutlich effektiver wenn es eine Person Vollzeit macht statt 2 Personen mit halber Zeit.
Letzteres bedeutet nur Mehraufwand durch die nötigen Absprachen zwischen den beiden.
2 Arbeiter mit halbem Aufwand machen bei Menschen nur den Vorteil aus, dass einer evtl. mal Urlaub machen oder krank sein kann, das lässt sich aber eher nicht auf CPUs übertragen.
 
@Andy386
Ziemlich arrogant geschrieben. Das wirft kein gutes Licht auf dich und wertet dadurch deinen Post ab.
warum brauchte es dann Jahre bis Stromsparlösungen für PCs/Endanwender überhaupt in Frage kamen?
Weil ein heutiger Highend-PC so viel Saft verbrauchen kann, dass man kaum noch andere etwas mehr Strom ziehende Geräte an denselben Steckdosenring anschließen kann, ohne dass die Sicherung fliegt.

@mensch186
Ich meinte es mehr in der Hinsicht, dass eine CPU in der Zukunft (hoffentlich) die starren Kerne abschafft.
Im Moment ist es ja so, dass ein Kerne eine komplette in sich starre Einheit mit 3 bis 4 Integereinheiten, einer FPU, Registern usw. ist, die von einem Befehlsdecoder gesteuert wird. Ich hoffe, dass sich das mal so weit entwickelt, dass es viele Befehlsdecoder gibt, die alle(!) Recheneinheiten ansteuern können, ohne an einen Kern gebunden zu sein. Gerade bei MIMD sollte das ne Menge bringen.
 
Zuletzt bearbeitet:
Ich denke, dass mehr Kerne durchaus die bessere Verbesserung waren. Ich habe einen AMD Phenom II 970 mit 4x 3,5GHz und nichts was ich bisher am PC gemacht habe hat meine CPU komplett ausgelastet. Programme die höhere CPU Leistung benötigen werden des Weiteren sowieso für Multi-Cores optimiert und lagern in andere Threads aus.
 
e-Laurin schrieb:
Im Moment ist es ja so, dass ein Kerne eine komplette in sich starre Einheit mit 3 bis 4 Integereinheiten, einer FPU, Registern usw. ist, die von einem Befehlsdecoder gesteuert wird. Ich hoffe, dass sich das mal so weit entwickelt, dass es viele Befehlsdecoder gibt, die alle(!) Recheneinheiten ansteuern können, ohne an einen Kern gebunden zu sein.
Das wird nichts werden. Du findest im Code nicht genug voneinander unabhängige Instruktionen, um so viele Recheneinheiten einer Art halbwegs auszulasten. Dieses "automatische parallelisieren" geht im Kleinen mit wenigen Einheiten, wie du mit den mehreren Int-Einheiten richtig beschreibst. Selbst da wird schon mit spekulativen Berechnungen "getrickst" um sich wenigstens von Sprüngen nicht aus dem Takt bringen zu lassen. Spätestens wenn es Datenabhängigkeiten zwischen den Instruktionen gibt, geht gar nichts mehr. Die Methode skaliert also extrem mies.
e-Laurin schrieb:
Gerade bei MIMD sollte das ne Menge bringen.
Geht auch nur bei unabhängigen Daten. Ist ja das gleiche wie oben, nur mit noch mehr Daten. Für parallelisierbare Standardalgorithmen kann man sowas in handoptimierten Bibliotheken nutzen. Für die Beschleunigung von "normalem" Code, den ein Compiler erzeugt hat, taugt die Technik nicht. Das ist aber die Stelle, an der es mit der Performance der CPUs nicht mehr so recht vorran geht, seitdem die MHz-Schraube klemmt.
 
Sehe ich gerad selber wieder beim Encodieren,6x 2,6 GHz (13GHz Rechenleistung) mit 2 Lüftern 600-650 U/min und 150Watt am Strommesser(Prime rund 165 Watt).
Für die Rechenleistung braucht man schon nen x4 mit 3,8GHz und diesen bekomm ich nicht so Leise und mit so wenig Verbrauch am laufen.
Was soll man da mit nem 1 Kern mit 13 GHz und Stickstoffkühlung........

Und ja mehr Kerne bringen immer was und sind die richtige Richtung.
 
Zuletzt bearbeitet:
Casi030 schrieb:
...
Und ja mehr Kerne bringen immer was und sind die richtige Richtung.

Das Multicore mit niedrigem Takt besser skalieren als vergleichbare CPUs mit weniger Kernen und höherem Takt dürfte an der begrenzten Geschwindigkeit der Peripherie(Cache, Ram, Platte) liegen. Sobald man ein Programm nutzt das nicht auff Multicore skaliert ist es eh vorbei.
Deine Behauptung stimmt nur in Bezug auf deine Anwendung(Encoding), ist also schlichtweg falsch.

Edit
Guck mal hier Man beachte den 4core am Ende der Liste und den Text von CB.
 
Zuletzt bearbeitet: (Edit)
Das will ich sehen wie du mit nem Einkern Lame,BFBC2,Downloads.....gleichzeitig am laufen bekommst.
Ergänzung ()

Ich frag mich eh,wiso imme 1 Programm mit 1000 Kerne laufen muss,bekommen es die Leute die so einen Schwachsinn immer schreiben nicht gebacken mehr als 1 Programm anzuklicken?Ein Virenprogramm kann man auch ruhig Automatisch mit windows starten........
 
Zuletzt bearbeitet:
Hier haben beide Parteien Recht, mehr Cores sind im Desktop-Bereich eine Notlösung für die nur noch marginal steigenden Taktzahlen, im Server- und vor allem Servercluster-Bereich sieht die Sache wiederum anders aus, da man dort wunderbar parallelisierbare Probleme lösen muss, bei denen X komplett voneinander unabhängig Probleme oder Problemteile aufgesplittet werden können, im Desktop-Bereich gibt es dies aber fast nicht.
Es lassen sich zwar Probleme auf mehrere Kerne aufteilen, das Problem dabei ist aber, dass die Probleme im Desktop-Bereich immernoch eine starke Kommunikation benötigen, womit die Parallelisierung nicht voll ausgenutzt werden kann. Ab Dualcores hätte man also wieder theoretisch (wenn es möglich wäre) die Taktfrequenz steigern können.

Im Desktop-Bereich stoßen wir da eben auf Ahmdals Gesetz, dass Software nicht weit genug parallelisierbar ist (meist deutlich unter 20%) und somit mehrere Prozessoren nicht voll ausgenutzt werden können, höhere GHz aber durch den Speedup von nicht parallelisierbaren Problemen (linearer Code) effektiv eine lineare Leistungssteigerung ermöglichen.
Im Server-, Servercluster- und Supercomputer-Bereich stoßen wir aber auf Probleme die sich nach dem Teile und Herrsche-Ansatz perfekt aufsplitten lassen, so dass mehrere Kerne unabhängig ein Problem bearbeiten und nachher nur noch die fertigen Lösungen zusammengefasst werden müssen.
Ebenso wird in diesem Bereich nicht nur ein Problem gleichzeitig gelöst, was wiederum durch Amdals Gesetz an bestimmte Leistungsgrenzen gebunden wäre, sondern hier gilt ebenso Gustafons Gesetz, was besagt, dass solche Multicore-Rechner nicht nur ein Problem gleichzeitig lösen, sondern viele gleichzeitig und somit nicht jedes Problem optimal parallelisierbar sein muss, sondern einfach mehrere Probleme gleichzeitig berechnet werden können, um den Prozessor voll auzulasten.
Im Desktop-Bereich ist die Anzahl an Problemen die gleichzeitig gelöst werden können, aber so gering, dass über einem Dualcore mehr Kerne theoretisch keinen Sinn machen. Denn dann könnte 1 Kern das gewünschte "Main-Programm" ausführen und 1 Kern ist für das Betriebssystem und Hintergrundprogramme.

Also ich möchte keineswegs sagen, dass mehr Kerne im Desktop-Bereich unnütz sind - bitte nicht falsch verstehen - es passt nur eben nicht zu den Problemen, die dort gelöst werden müssen. Ein Dualcore mit "maximalen GHz" wäre für 98% der Probleme im Desktop-Bereich die optimalste Lösung. Es gibt natürlich auch Desktop-Probleme (Videokodierung, mathem. Probleme) die sich optimal berechnen lassen, aber der Großteil der Desktop-Probleme beruht doch auf einem sehr schnellen Request-Response-Verhalten durch eine grafische Oberfläche mit "wenigen" wirklich rechenintensiven Aufgaben.

Beispiele:
Desktop: Nehmen wir für den Desktop-Bereich ein Spiel als Beispiel, wir haben hier das Problem, dass sowohl KI, Physik und Grafik stark verzahnt sind, versimpelt gesprochen (entspricht nicht ganz der Reakität) muss für jedes Frame was durch die Grafik dargestellt wird, die KI und Physik berechnet werden, ich habe also nicht viele parallelisierbare Probleme, und selbst wenn sie parallelisierbar sind, muss trotzdem die Grafik auf die Beendigung der KI und Physik warten.
Server: Der CB-Webserver im Gegensatz greift aber wieder auf Gustafons Gesetz zu, er braucht das Berechnen der Webseite (Logik + DB-Abfragen) überhaupt nicht zu parallelisieren, und der Server kann trotzdem voll ausgenutzt werden. Warum? Es existiert nicht nur eine Person die gleichzeitig eine Anfrage an den Webserver stellt, sondern viele gleichzeitig, so reichen versimpelt für 4 Cores 4 Webseitenaufrufe um zu einem Zeitpunkt den Server voll auszulasten.
 
Zuletzt bearbeitet:
Zurück
Oben