Hallo
ist es sinvoll sich jetzt einen Quadcore-Prozessor zuzulegen,oder sollte man noch warten?Ich meine für einen Gamer-Pc.
Thx
Archiv Prozessoren 8.660 Themen, 54.742 Beiträge
BigBossBigge noschäuble „Dualcore oder Quadcore“
Hi!
Hol dir einfach einen Intel Core2Dou aus der E8xxx-Serie. Die haben das beste Preisleistungsverhältnis und stechen so manchen Quadcore aus. Damit kannst du dann ordentlich zocken. Eine gute Grafikkarte brauchst du natürlich auch noch und da würde ich zur ATI 4870 raten.
Soviel von meiner Seite. MadHatter kann dir da bestimmt noch fachkundigeren Rat geben.
Xdata BigBossBigge „Hi! Hol dir einfach einen Intel Core2Dou aus der E8xxx-Serie. Die haben das...“
Eine CPU mit 2 Kernen reicht.
Etwa ein Core2 Duo E8400 2x3.0GHz.
Ein Quadcore kann nur -- schneller warten..
MadHatter noschäuble „Dualcore oder Quadcore“
Also wenn ich an Far Cry 2 oder an das kommende Alan Wake denke...
Ist aber eine Glaubensfrage. Ich will nicht mehr ohne Quad - bin aber auch kein Hardcore-Gamer ;-)
Stichwort Zukunft? Wer weiß denn schon, wann die breite Masse an Spielen tatsächlich von einem Quad profitiert. Heute kann man die noch an einer Hand abzählen. Fraglich bleibt auch, ob der heute gekaufte Quad zu diesem Zeitpunkt dann nicht schon zum alten Eisen gehört...
Von daher: ACK @ BBB!
Xdata MadHatter „Also wenn ich an Far Cry 2 oder an das kommende Alan Wake denke... Ist aber eine...“
Es müßte einen Mechanismus geben der alle Kerne ohne Unterstützung der Software nutzt.
Bei dem nicht mehr unterstützten BeOs, waren die Kerne nahzu
gleich viel belastet also die Arbeit auf beiden Kernen in gleicher Höhe verteilt.
Das waren aber noch jeweils 2 Einzel CPU`s.
Schon NT 4 konnte "mehrere CPU`s" da hat aber glaube ich ebenfalls das Bs und nicht die Anwendungen die Kontrolle bei der Verteilung der Kerne übernommen.
Kann mich noch an einen Rechner mit 2 Celeron`s erinnern die nur durch eine Brücke zu gemeinsamer Arbeit bewegt werden konnten.
Nt lief flüssiger - mehr noch als bei den heutigen Lösungen
wo anscheinend der Software die Entscheidung überlassen wird. -- Bei normalen Anwendungen.
Bei dieser Methode könnten sich 4 Kerne lohnen,
also wenn "jede" Aufgabe auf "alle" Kerne in gleichen
Anteilen zerlegt (verteilt) wird.
Auch bei nur einer Aufgabe, oder einem Programm das garkein Mutiprozessing kennt.
Borlander Xdata „Es müßte einen Mechanismus geben der alle Kerne ohne Unterstützung der...“
Es müßte einen Mechanismus geben der alle Kerne ohne Unterstützung der Software nutzt.
Die werden doch auch alle genutzt. Eine Software die nur einen Thread hat kann aber immer auch nur auf einem CPU-Kern zur Zeit laufen. Wird auf einem Quad-CPU-System damit dann maximal 25% der verfügbaren CPU-Zeit nutzen können...
Bei dem nicht mehr unterstützten BeOs, waren die Kerne nahzu
gleich viel belastet also die Arbeit auf beiden Kernen in gleicher Höhe verteilt.
Das ist bei Windows doch auch Standard. Hat aber keinen konkreten Vorteil die Aualastung gleichmäßig auf alle CPUs zu verteilen. Wenn nur eine leistungshungrige Anwendung läuft springt diese zwischen den einzelnen CPUs umher und verliert dann jedes mal den Cache-Inhalt (bei Multi-Core-CPUs mit gemeinsamen Cachestufen nicht mehr ganz so dramatisch wie früher bei Multi-CPU-Systemen).
Schon NT 4 konnte "mehrere CPU`s" da hat aber glaube ich ebenfalls das Bs und nicht die Anwendungen die Kontrolle bei der Verteilung der Kerne übernommen.
Es ist absolut üblich, daß das Betriebssystem die Prozesse auf die CPUs verteilt.
Nt lief flüssiger - mehr noch als bei den heutigen Lösungen
wo anscheinend der Software die Entscheidung überlassen wird. -- Bei normalen Anwendungen.
Die Software kann dem Scheduler nicht rein reden. Wäre auch nicht sinnvoll. Was drin liegt ist die Zuordnung einer Prozesspriorität und ggf. noch die Bindung an eine bestimmte CPU(-Gruppe).
also wenn "jede" Aufgabe auf "alle" Kerne in gleichen
Anteilen zerlegt (verteilt) wird. Auch bei nur einer Aufgabe, oder einem Programm das garkein Mutiprozessing kennt.
Und genau das ist nicht möglich. Parallelisierung ist nicht so ganz einfach, vor allem wenn mehrere parallele Threads die selben Daten manipulieren. Auf Compilerseite gibt es zwar teilweise schon die Möglichlichkeit z.B. Schleifen automatisch parallelisieren zu lassen, aber auch das ist nur möglich wenn der Programmierer entsprechende Vorraussetzungen schafft.
Gruß
Borlander
Die werden doch auch alle genutzt. Eine Software die nur einen Thread hat kann aber immer auch nur auf einem CPU-Kern zur Zeit laufen. Wird auf einem Quad-CPU-System damit dann maximal 25% der verfügbaren CPU-Zeit nutzen können...
Bei dem nicht mehr unterstützten BeOs, waren die Kerne nahzu
gleich viel belastet also die Arbeit auf beiden Kernen in gleicher Höhe verteilt.
Das ist bei Windows doch auch Standard. Hat aber keinen konkreten Vorteil die Aualastung gleichmäßig auf alle CPUs zu verteilen. Wenn nur eine leistungshungrige Anwendung läuft springt diese zwischen den einzelnen CPUs umher und verliert dann jedes mal den Cache-Inhalt (bei Multi-Core-CPUs mit gemeinsamen Cachestufen nicht mehr ganz so dramatisch wie früher bei Multi-CPU-Systemen).
Schon NT 4 konnte "mehrere CPU`s" da hat aber glaube ich ebenfalls das Bs und nicht die Anwendungen die Kontrolle bei der Verteilung der Kerne übernommen.
Es ist absolut üblich, daß das Betriebssystem die Prozesse auf die CPUs verteilt.
Nt lief flüssiger - mehr noch als bei den heutigen Lösungen
wo anscheinend der Software die Entscheidung überlassen wird. -- Bei normalen Anwendungen.
Die Software kann dem Scheduler nicht rein reden. Wäre auch nicht sinnvoll. Was drin liegt ist die Zuordnung einer Prozesspriorität und ggf. noch die Bindung an eine bestimmte CPU(-Gruppe).
also wenn "jede" Aufgabe auf "alle" Kerne in gleichen
Anteilen zerlegt (verteilt) wird. Auch bei nur einer Aufgabe, oder einem Programm das garkein Mutiprozessing kennt.
Und genau das ist nicht möglich. Parallelisierung ist nicht so ganz einfach, vor allem wenn mehrere parallele Threads die selben Daten manipulieren. Auf Compilerseite gibt es zwar teilweise schon die Möglichlichkeit z.B. Schleifen automatisch parallelisieren zu lassen, aber auch das ist nur möglich wenn der Programmierer entsprechende Vorraussetzungen schafft.
Gruß
Borlander
Xdata Borlander „ Die werden doch auch alle genutzt. Eine Software die nur einen Thread hat kann...“
Danke für die Aufklärung,
ganz so einfach scheint parallelität dann doch nicht zu sein.
Hab mal in die Bescchreibung vom damaligen BeOs noch mal reingeschaut.
Da wurde gesagt, schon auf Programmebene wurde darauf geachtet die Aufgabe so zu programmieren um vieles in Threads einzuteilen.
Multiprozessing, paralelle Threads und "parrallel computing" scheinen nicht das gleiche zu sein.
Die Materie ist viel komplizierter als ich zuerst vermutet habe.
Auf Compilerseite ist fraglich ob jetzige Programmiersprachen (c)
dafür geeignet sind.
Ada scheint es ja kaum noch zu geben.
ChrE Xdata „Danke für die Aufklärung, ganz so einfach scheint parallelität dann doch...“
Hallo!
Hardwareseitung muss man parallelisieren können und softwareseitig auch.
Die Hardware macht das so:
http://de.wikipedia.org/wiki/SIMD
Bei der Software gibt es auch verschiedene Wege:
- die Sprache unterstützt direkt Parallelisierung
- entsprechende Bibliotheken werden eingebunden
- der Compiler/Interpreter ist "intelligent" und durchsucht den Quelltext selbständig
nach parallelisierbaren Abschnitten
Viele Programmiersprachen unterstützen heute Threading.
Gruss
ChrE
Borlander ChrE „Hallo! Hardwareseitung muss man parallelisieren können und softwareseitig auch....“
SIMD ist nun wieder eine ganz andere Geschichte und vollkommen unabhängig davon ob ein Programm in mehreren Threads ausgeführt wird. Probleme wie die Synchronisierung von Threads die auf die selben Daten zugreifen wollen hat man da nicht. Und genau diese Probleme sind eine große Fehlerquelle mit Fehlern die nur selten auftreten und nicht so leicht zu entdecken sind.
der Compiler/Interpreter ist "intelligent" und durchsucht den Quelltext selbständig nach parallelisierbaren Abschnitten
Das wird i.A. aber keine befriedigenden Ergebnisse liefern. Allein schon, weil man für die effiziente parallele Bearbeitung oftmals ganz andere Algorithmen einsetzen muß...
Gruß
Borlander
Borlander Xdata „Danke für die Aufklärung, ganz so einfach scheint parallelität dann doch...“
schon auf Programmebene wurde darauf geachtet die Aufgabe so zu programmieren um vieles in Threads einzuteilen.
Das ist die Grundvoraussetzung wenn eine Anwendung von mehreren CPUs profitieren soll. Wichtig ist auch, daß die Threads möglichst unabhängig von einander ausführbar sind und sich möglichst selten gegenseitig blockieren.
Die aktuell für ersthafte Anwendungsentwicklung eingesetzten Programmiersprachen sollten eigentlich alle die Möglichkeit bieten mit Threads zu arbeiten...
Das ist die Grundvoraussetzung wenn eine Anwendung von mehreren CPUs profitieren soll. Wichtig ist auch, daß die Threads möglichst unabhängig von einander ausführbar sind und sich möglichst selten gegenseitig blockieren.
Die aktuell für ersthafte Anwendungsentwicklung eingesetzten Programmiersprachen sollten eigentlich alle die Möglichkeit bieten mit Threads zu arbeiten...
