werden aktuelle CPU's unterstützt?
- Thread starter Marian
- Start date
Stefan Lemke
Registered
haben sie es schon wo erwähnt...denn so ganz sicher bin ich mir da nicht...nen quadcore zu unterhalten is nich so einfach^^
Aber bei Multicore, und rF2 klingelt da was im Gehirnskasten.
Stefan Lemke
Registered
hm dann freu mich ja drauf
Spacekid
Registered
Hagen Tröger
Registered
Warum soll das nicht wichtig sein?
Gonzo
Member
Warum sollte es wichtig sein?
Es geht doch nicht darum ob das Spiel irgendetwas unterstützt, sondern darum das es vernünftig läuft.
Es dürfte wohl keinen Softwareentwickler geben der Multicoresysteme nicht beachtet.
"Unterstützen" ist auch kein treffender Begriff.
Man wird wohl 2 Threads haben müssen, mehr ist besser, aber 8 werden definitiv nicht in den Minimum - Systemressourcen stehen.
Es geht doch nicht darum ob das Spiel irgendetwas unterstützt, sondern darum das es vernünftig läuft.
Es dürfte wohl keinen Softwareentwickler geben der Multicoresysteme nicht beachtet.
"Unterstützen" ist auch kein treffender Begriff.
Man wird wohl 2 Threads haben müssen, mehr ist besser, aber 8 werden definitiv nicht in den Minimum - Systemressourcen stehen.
Frank Geyer
Registered
*klugscheißermodus::an*
Männers, bitte verwechselt nicht Multi-Core mit Multi-Threading! Selbst ein Single-Core kann mehrere Threads verwalten/bedienen/handhaben. Sobald man aber eine Applikation in mehrere Threads unterteilt, werden auch spezielle Anforderungen an selbige gestellt. Vor allem in Bezug auf das Timing der verschiedenen Threads im Multi-Tasking. Wenn dann die einzelnen Threads noch ens auf verschiedene Cores verteilt werden, wird es noch mal ne Ecke brenzliger. Wenn da dann "schei$$e gebaut wird", kann es passieren, dass die einzelnen Kerne sich dann überwiegend dahingehend unterhalten, wer denn nun die Arbeit machen soll anstatt die eigentlich anfallenden Arbeiten zu erledigen. Im schlimmsten Fall führt das dann zu einer 100% CPU Auslastung, bei der dann aber auch rein gor nüschts mehr passiert. Klingt doch ganz so wie in einem mittlerweile standartmäßigem mittelständischen Unternehmen heutzutage
woll ... immer mehr Wasserköppe ham immer mehr zu sagen und dann passiert es, dass 3 Sichtleiter einen Maschinisten bedienen: Sichtleiter 1 gibt Anweisung A, Sichtleiter 2 gibt Anweisung B, usw. und das alles zur gleichen Zeit. Wenn wir Glück haben, bleibt der Maschinist cool und macht es so wie bisher !?!? Von entscheidender Bedeutung ist das Grunddesign einer Applikation in Bezug auf Multi-Threading, Multi-Cores. Wenn es denn dann "vernünftig" angefangen/umgesetzt wird, spielt es keine Rolle wie viele reale/virtuelle Kerne ein System besitzt ... zum Beispiel gibt es in Programmiersprachen Thread-Sichere bzw. Thread-Unsichere Objekte bzw. Konstrukte und/oder Funktionen.
*klugscheißermodus::aus*
Ich hoffe ich bin jetzt nicht zu sehr ins Detail gegangen !?!?
Gruß
Frank
PS: Korrekturen und Richtigstellungen sind ausdrücklich erwünscht!
Männers, bitte verwechselt nicht Multi-Core mit Multi-Threading! Selbst ein Single-Core kann mehrere Threads verwalten/bedienen/handhaben. Sobald man aber eine Applikation in mehrere Threads unterteilt, werden auch spezielle Anforderungen an selbige gestellt. Vor allem in Bezug auf das Timing der verschiedenen Threads im Multi-Tasking. Wenn dann die einzelnen Threads noch ens auf verschiedene Cores verteilt werden, wird es noch mal ne Ecke brenzliger. Wenn da dann "schei$$e gebaut wird", kann es passieren, dass die einzelnen Kerne sich dann überwiegend dahingehend unterhalten, wer denn nun die Arbeit machen soll anstatt die eigentlich anfallenden Arbeiten zu erledigen. Im schlimmsten Fall führt das dann zu einer 100% CPU Auslastung, bei der dann aber auch rein gor nüschts mehr passiert. Klingt doch ganz so wie in einem mittlerweile standartmäßigem mittelständischen Unternehmen heutzutage
woll ... immer mehr Wasserköppe ham immer mehr zu sagen und dann passiert es, dass 3 Sichtleiter einen Maschinisten bedienen: Sichtleiter 1 gibt Anweisung A, Sichtleiter 2 gibt Anweisung B, usw. und das alles zur gleichen Zeit. Wenn wir Glück haben, bleibt der Maschinist cool und macht es so wie bisher !?!? Von entscheidender Bedeutung ist das Grunddesign einer Applikation in Bezug auf Multi-Threading, Multi-Cores. Wenn es denn dann "vernünftig" angefangen/umgesetzt wird, spielt es keine Rolle wie viele reale/virtuelle Kerne ein System besitzt ... zum Beispiel gibt es in Programmiersprachen Thread-Sichere bzw. Thread-Unsichere Objekte bzw. Konstrukte und/oder Funktionen.*klugscheißermodus::aus*
Ich hoffe ich bin jetzt nicht zu sehr ins Detail gegangen !?!?
Gruß
Frank
PS: Korrekturen und Richtigstellungen sind ausdrücklich erwünscht!
Last edited by a moderator:
Frank Beuchel
Registered
*klugscheißermodus::an*
Männers, bitte verwechselt nicht Multi-Core mit Multi-Threading! Selbst ein Single-Core kann mehrere Threads verwalten/bedienen/handhaben. Sobald man aber eine Applikation in mehrere Threads unterteilt, werden auch spezielle Anforderungen an selbige gestellt. Vor allem in Bezug auf das Timing der verschiedenen Threads im Multi-Tasking. Wenn dann die einzelnen Threads noch ens auf verschiedene Cores verteilt werden, wird es noch mal ne Ecke brenzliger. Wenn da dann "schei$$e gebaut wird", kann es passieren, dass die einzelnen Kerne sich dann überwiegend dahingehend unterhalten, wer denn nun die Arbeit machen soll anstatt die eigentlich anfallenden Arbeiten zu erledigen. Im schlimmsten Fall führt das dann zu einer 100% CPU Auslastung, bei der dann aber auch rein gor nüschts mehr passiert. Klingt doch ganz so wie in einem mittlerweile standartmäßigem mittelständischen Unternehmen heutzutage
*klugscheißermodus::aus*
Ich hoffe ich bin jetzt nicht zu sehr ins Detail gegangen !?!?
Gruß
Frank
PS: Korrekturen und Richtigstellungen sind ausdrücklich erwünscht!
... I'like 
Hagen Tröger
Registered
Habe ich das richtig verstanden, dass bei einer perfekten multithreaded application es vollkommen wurscht ist, wieviele virtuelle und reelle Kerne der Rechner besitzt? Also würde dann eine singlecore CPU genauso schnell sein wie ein Quadcore?
Frank Geyer
Registered
Hallo Hagen,
Nee, das stimmt so nicht ganz. Du musst die Aussage, welche ich da gemacht habe in Bezug auf die vorherigen Posts beziehen ... dann wird ein Schuh draus.
Wenn eine Applikation über nur einen Thread ausgeführt wird, und diese App eine Mindestvoraussetzung von 3,0GHz an die CPU des Systems stellt, dann ist eine Single-Core-CPU mit 3,2GHz gegenüber einer Quad-Core-CPU mit "nur" 2,0GHz pro "reellem" Kern im Vorteil. Denn egal was Du versuchst, die App verwurstet seinen anfallenden Aufgaben immer nur auf einem Kern. Wenn die gleiche App dann aber so aufgesetzt wird, dass sie die anfallenden Aufgaben auf mehrere Threads verteilt und diese Threads dann auch noch dynamisch auf die Kerne einer Multi-Core-CPU verteilt werden können, dann ist natürlich die Multi-Core-CPU im Vorteil. Man muss dann dabei aber auch noch zwischen reellen und virtuellen Kernen, Turbo-Boost, Hyper-Threading und "tatsächlichen" CPUs eines SMP-System usw. unterscheiden - kurz um: Eigentlich sollte durch Standards alles miteinander kompatibel sein. Aber wie wir schon seit Urzeiten wissen gibbet keine Eierlegende-Woll-Milch-Sau !!!
Hoffe ich hab es einigermaßen verständlich rübergebracht !?!?
Gruß
Frank
Nee, das stimmt so nicht ganz. Du musst die Aussage, welche ich da gemacht habe in Bezug auf die vorherigen Posts beziehen ... dann wird ein Schuh draus.
Wenn eine Applikation über nur einen Thread ausgeführt wird, und diese App eine Mindestvoraussetzung von 3,0GHz an die CPU des Systems stellt, dann ist eine Single-Core-CPU mit 3,2GHz gegenüber einer Quad-Core-CPU mit "nur" 2,0GHz pro "reellem" Kern im Vorteil. Denn egal was Du versuchst, die App verwurstet seinen anfallenden Aufgaben immer nur auf einem Kern. Wenn die gleiche App dann aber so aufgesetzt wird, dass sie die anfallenden Aufgaben auf mehrere Threads verteilt und diese Threads dann auch noch dynamisch auf die Kerne einer Multi-Core-CPU verteilt werden können, dann ist natürlich die Multi-Core-CPU im Vorteil. Man muss dann dabei aber auch noch zwischen reellen und virtuellen Kernen, Turbo-Boost, Hyper-Threading und "tatsächlichen" CPUs eines SMP-System usw. unterscheiden - kurz um: Eigentlich sollte durch Standards alles miteinander kompatibel sein. Aber wie wir schon seit Urzeiten wissen gibbet keine Eierlegende-Woll-Milch-Sau !!!
Hoffe ich hab es einigermaßen verständlich rübergebracht !?!?
Gruß
Frank
Last edited by a moderator:
Hagen Tröger
Registered
Ja, das ist alles irgendwie sonnenklar, aber mir ist jetzt nicht klar, wie das deine obige Aussage erklären soll und mir ist auch nicht klar, warum es nicht von Bedeutung sein soll, in wieviele Threads rF2 aufgeteilt wird.
Mein Verständnis reicht soweit, dass man aus einer Multicore CPU einen Vorteil erzielen kann, wenn man die App in mehrere Threads aufteilt. Von daher kann ich mir vorstellen, dass beispielsweise für eine Quadcore CPU auch 4 Threads von Vorteil wären, jedenfalls vorteilhafter als nur 2 Threads.
Mein Verständnis reicht soweit, dass man aus einer Multicore CPU einen Vorteil erzielen kann, wenn man die App in mehrere Threads aufteilt. Von daher kann ich mir vorstellen, dass beispielsweise für eine Quadcore CPU auch 4 Threads von Vorteil wären, jedenfalls vorteilhafter als nur 2 Threads.
Last edited by a moderator:
Frank Geyer
Registered
So isset. Eine "vernünftig" programmierte Multi-Thread-App bestimmt beim Start die CPU und die Anzahl deren Kerne und kann somit die Anzahl der Threads bestimmen und sorgt dann für die gleichmäßige Verteilung der Threads auf die jeweiligen Kerne.
Es geht um das dynamische anlegen von Threads in Abhängigkeit zu den zu erledigenden Aufgaben und deren dynamische Verteilung auf die Cores einer CPU. Die Anzahl der Threads ist "idealerweise" ein vielfaches der Anzahl der Cores einer CPU oder besser gesagt die Anzahl der "Cores" in einem System um eine gleichmäßige Lastverteilung zu erreichen - ist aber nicht zwingend erforderlich – wäre aber besser – muss aber nicht *fg*.
4 Threads auf 4 Kerne, 8 Threads auf 4 Kerne, 6 Threads auf 6 Kerne usw.
Ein schönes Beispiel bei der man die Anzahl der Threads manuell bestimmen kann, ist der FTP-Server FileZilla. Es geht schlussendlich „eigentlich nur“ um eine dynamische, gleichmäßige Lastverteilung der anfallenden Arbeiten in Abhängigkeit zu vorherrschenden CPU. Und deswegen spielt es keine Rolle wie viele reale/virtuelle Kerne ein System besitzt. Der Programmierer bestimmt in „erster Linie“ wie gut oder wie schlecht eine App mit einem Mehr-Kern-System harmoniert (vorausgesetzt Du hast ein harmonisch konfiguriertes und stabil laufendes System).
Ein schönes Gegenbeispiel dafür ist rF1. rF1 war/ist standartmäßig eine Single-Thread-App. Der Parameter +fullproc, welcher nachträglich eingebaut wurde, bewirkt eigentlich nur das von vornherein die rFactor.exe zu allen Kernen zugehörig ist (standartmäßig ist es nur CPU0). Man lagert dann ein paar kleinere anfallende Aufgaben auf die anderen Kerne aus, aber die Hauptlast bleibt weiterhin auf CPU0 (sieht man auch ganz gut im Perf-Mon von Windows). Das erklärt auf der einen Seite zwar den Anstieg der In-Game FPS, geht aber meistens zu Lasten der Stabilität wenn System und App an seine Grenzen herangefahren werden.
Wenn jetzt nicht, dann weiß ich auch nicht mehr wie ich es noch erklären soll …
Gruß
Frank
Es geht um das dynamische anlegen von Threads in Abhängigkeit zu den zu erledigenden Aufgaben und deren dynamische Verteilung auf die Cores einer CPU. Die Anzahl der Threads ist "idealerweise" ein vielfaches der Anzahl der Cores einer CPU oder besser gesagt die Anzahl der "Cores" in einem System um eine gleichmäßige Lastverteilung zu erreichen - ist aber nicht zwingend erforderlich – wäre aber besser – muss aber nicht *fg*.
4 Threads auf 4 Kerne, 8 Threads auf 4 Kerne, 6 Threads auf 6 Kerne usw.
Ein schönes Beispiel bei der man die Anzahl der Threads manuell bestimmen kann, ist der FTP-Server FileZilla. Es geht schlussendlich „eigentlich nur“ um eine dynamische, gleichmäßige Lastverteilung der anfallenden Arbeiten in Abhängigkeit zu vorherrschenden CPU. Und deswegen spielt es keine Rolle wie viele reale/virtuelle Kerne ein System besitzt. Der Programmierer bestimmt in „erster Linie“ wie gut oder wie schlecht eine App mit einem Mehr-Kern-System harmoniert (vorausgesetzt Du hast ein harmonisch konfiguriertes und stabil laufendes System).
Ein schönes Gegenbeispiel dafür ist rF1. rF1 war/ist standartmäßig eine Single-Thread-App. Der Parameter +fullproc, welcher nachträglich eingebaut wurde, bewirkt eigentlich nur das von vornherein die rFactor.exe zu allen Kernen zugehörig ist (standartmäßig ist es nur CPU0). Man lagert dann ein paar kleinere anfallende Aufgaben auf die anderen Kerne aus, aber die Hauptlast bleibt weiterhin auf CPU0 (sieht man auch ganz gut im Perf-Mon von Windows). Das erklärt auf der einen Seite zwar den Anstieg der In-Game FPS, geht aber meistens zu Lasten der Stabilität wenn System und App an seine Grenzen herangefahren werden.
Wenn jetzt nicht, dann weiß ich auch nicht mehr wie ich es noch erklären soll …
Gruß
Frank
Last edited by a moderator:
Gonzo
Member
Die Aussage bzgl. rF1 ist so nicht richtig.
+fullproc wurde nicht nachträglich eingebaut, andersherum.
Es gab Probleme bei einigen bzgl Mehrkernprozessoren als diese plötzlich in Masse aufkamen, man hat dann rFactor auf 1 Thread begrenzt und bietet aber denen die keine Probleme haben oder es austetsten wollen mit "+fullproc" die Möglichkeit es normal zu benutzen wie es vorher war.
4 Threads auf 4 Kerne und 8 auf 8 ist auch Quatsch.
Da sich die Threads von der Leistung die sie benötigen unterscheiden.
In Zukunft wird es ja in Richtung 60 und mehr Kerne gehen und die Taktfrequenzen stagnieren mehr oder weniger im Bereich um 3 Ghz.
rFactor2 wird auf rFactor1 aufsetzen, eine große Weiterentwicklung mit >4 Jahren Entwicklungszeit inzwischen, natürlich wird es aktuelle Hardware besser unterstützen als rFactor 1, die Engines sind aber nicht grundlegend neu sondern aufgeräumt, verbessert, ausgebaut, erweitert und modernisiert.
Ich denke es wird noch einige Zeit dauern bis man die endgültigen Spezifikationen haben wird (da wohl noch nicht alle Features implementiert sind).
Sicher ist aber das ein Singlecore wohl zu wenig sein wird, wenn es das nicht bei rFactor 1 zu wenig gewesen ist.
Beachte man doch das ab DualCore alle Hintergrundprozesse das Spiel nicht mehr so beeinflussen weil eben ein zweiter Kern da ist.
+fullproc wurde nicht nachträglich eingebaut, andersherum.
Es gab Probleme bei einigen bzgl Mehrkernprozessoren als diese plötzlich in Masse aufkamen, man hat dann rFactor auf 1 Thread begrenzt und bietet aber denen die keine Probleme haben oder es austetsten wollen mit "+fullproc" die Möglichkeit es normal zu benutzen wie es vorher war.
4 Threads auf 4 Kerne und 8 auf 8 ist auch Quatsch.
Da sich die Threads von der Leistung die sie benötigen unterscheiden.
In Zukunft wird es ja in Richtung 60 und mehr Kerne gehen und die Taktfrequenzen stagnieren mehr oder weniger im Bereich um 3 Ghz.
rFactor2 wird auf rFactor1 aufsetzen, eine große Weiterentwicklung mit >4 Jahren Entwicklungszeit inzwischen, natürlich wird es aktuelle Hardware besser unterstützen als rFactor 1, die Engines sind aber nicht grundlegend neu sondern aufgeräumt, verbessert, ausgebaut, erweitert und modernisiert.
Ich denke es wird noch einige Zeit dauern bis man die endgültigen Spezifikationen haben wird (da wohl noch nicht alle Features implementiert sind).
Sicher ist aber das ein Singlecore wohl zu wenig sein wird, wenn es das nicht bei rFactor 1 zu wenig gewesen ist.
Beachte man doch das ab DualCore alle Hintergrundprozesse das Spiel nicht mehr so beeinflussen weil eben ein zweiter Kern da ist.