Warum würde ein Programm eine bestimmte Mindestanzahl von CPU-Kernen erfordern?

Ist es möglich, Code zu schreiben (oder eine vollständige Software anstelle eines Codeteils), der auf einer CPU mit weniger als N Kernen nicht ordnungsgemäß funktioniert? Ohne es explizit zu überprüfen und absichtlich zu versagen:

WENN (noOfCores <4) DANN absichtlich nicht richtig ausgeführt wird

Ich schaue mir die Mindestsystemanforderungen eines Spiels ( Dragon Age: Inquisition ) an, und es gibt ein Minimum von einer Vier-Kern-CPU an. Viele Spieler sagen, es läuft NICHT auf Zwei-Kern-CPUs und sogar auf Intel Core i3s mit zwei physischen und zwei logischen Kernen. Und es ist kein Problem der Rechenleistung.

Nach meinem Verständnis sind Threads vom Betriebssystem vollständig von der CPU isoliert, da dies nicht möglich ist.

Nur um das zu klären:

Ich frage NICHT "Kann ich die Anzahl der CPU-Kerne aus dem Code herausfinden und absichtlich versagen?" ... Ein solcher Code wäre nicht beabsichtigt (zwingt Sie dazu, eine teurere CPU zu kaufen, um ein Programm auszuführen - ohne Rechenleistung). Ich frage, dass Ihr Code beispielsweise vier Threads hat und fehlschlägt, wenn zwei Threads auf demselben physischen Kern ausgeführt werden (ohne explizite Überprüfung der Systeminformationen und absichtlich fehlgeschlagen) .

Kurz gesagt, kann es Software geben, die mehrere Kerne benötigt, ohne dass zusätzliche Rechenleistung von mehreren Kernen benötigt wird? Es wären lediglich N separate physische Kerne erforderlich.

Es kann möglich sein, dies "aus Versehen" mit unachtsamer Verwendung der Kernaffinität zu tun. Betrachten Sie den folgenden Pseudocode:

• Einen Thread starten
• Finden Sie in diesem Thread heraus, auf welchem ​​Core er ausgeführt wird
• Setzen Sie die CPU-Affinität auf diesen Kern
• starte etwas rechenintensives / loop für immer

Wenn Sie vier davon auf einer Zwei-Kern-CPU starten, liegt entweder ein Fehler bei der Einstellung der Kernaffinität vor, oder Sie haben zwei Threads, die die verfügbaren Kerne blockieren, und zwei Threads, die niemals geplant werden. Zu keinem Zeitpunkt wurde explizit gefragt, wie viele Kerne es insgesamt gibt.

(Wenn Sie Threads mit langer Laufzeit verwenden, verbessert das Festlegen der CPU-Affinität im Allgemeinen den Durchsatz.)

Die Idee, dass Spielefirmen die Leute dazu "zwingen", teurere Hardware ohne guten Grund zu kaufen, ist nicht sehr plausibel. Es kann nur Kunden verlieren.

Bearbeiten: Dieser Beitrag hat jetzt 33 Upvotes, was ziemlich viel ist, da er auf fundiertem Rätselraten basiert!

Es scheint, dass die Leute DA haben: Ich muss schlecht auf Dual-Core-Systemen laufen: http://www.dsogaming.com/pc-performance-analyses/dragon-age-inquisition-pc-performance-analysis/ Diese Analyse erwähnt, dass sich die Situation erheblich verbessert, wenn das Hyperthreading aktiviert ist. Da HT keine Anweisungseinheiten oder keinen Cache mehr hinzufügt, lässt es lediglich zu, dass ein Thread ausgeführt wird, während sich ein anderer in einem Cache-Stall befindet, was stark darauf hindeutet, dass er nur mit der Anzahl der Threads verknüpft ist.

Ein anderes Poster behauptet, dass das Ändern der Grafiktreiber funktioniert: http://answers.ea.com/t5/Dragon-Age-Inquisition/Working-solution-for-Intel-dual-core-CPUs/td-p/3994141 ; Angesichts der Tatsache, dass Grafiktreiber in der Regel ein erbärmlicher Schwarm sind, überrascht dies nicht. Eine berüchtigte Gruppe von Treibern hatte einen "richtigen & langsamen" gegenüber "schnellen & falschen" Modus, der ausgewählt wurde, wenn er von QUAKE.EXE aufgerufen wurde. Es ist durchaus möglich, dass sich die Treiber für eine unterschiedliche Anzahl von scheinbaren CPUs unterschiedlich verhalten. Vielleicht wird (zurück zur Spekulation) ein anderer Synchronisationsmechanismus verwendet. Missbrauch von Spinlocks ?

"Missbrauch von Sperr- und Synchronisationsprimitiven" ist eine sehr, sehr häufige Fehlerquelle. (Der Fehler, den ich beim Schreiben bei der Arbeit beobachten soll, ist "Absturz, wenn die Druckereinstellungen gleichzeitig mit dem Abschluss des Druckauftrags geändert werden").

Edit 2: Kommentare erwähnen das Betriebssystem, das versucht, das Verhungern von Threads zu vermeiden. Beachten Sie, dass das Spiel möglicherweise einen eigenen internen Quasi-Scheduler zum Zuweisen von Arbeit zu Threads hat und es einen ähnlichen Mechanismus in der Grafikkarte selbst gibt (was praktisch ein eigenes Multitasking-System ist). Die Wahrscheinlichkeit eines Fehlers in einem dieser Ordner oder der Interaktion zwischen ihnen ist sehr hoch.

Bei www.ecsl.cs.sunysb.edu/tr/ashok.pdf (2008) handelt es sich um eine Abschlussarbeit zur besseren Planung von Grafikkarten, in der ausdrücklich darauf hingewiesen wird, dass sie normalerweise die First-Come-First-Served-Planung verwenden, die einfach zu implementieren ist nicht vorbeugende Systeme. Hat sich die Situation verbessert? Wahrscheinlich nicht.

Möglicherweise sind 4 Kerne erforderlich, da die Anwendung vier Tasks in parallelen Threads ausführt und erwartet, dass diese fast gleichzeitig beendet werden.

Wenn jeder Thread von einem separaten Kern ausgeführt wird und alle Threads genau die gleiche Rechenlast haben, werden sie mit ziemlicher Wahrscheinlichkeit (aber bei weitem nicht garantiert) ungefähr zur gleichen Zeit beendet. Wenn jedoch zwei Threads auf einem Kern ausgeführt werden, ist das Timing viel weniger vorhersehbar, da der Kern die ganze Zeit über den Kontext zwischen den beiden Threads wechselt.

Fehler, die aufgrund eines unerwarteten Thread-Timings auftreten, werden als " Race Conditions " bezeichnet.

Im Kontext der Spieleentwicklung könnte eine plausible Architektur mit dieser Art von Problem darin bestehen, dass verschiedene Features des Spiels in Echtzeit von verschiedenen CPU-Threads simuliert werden. Wenn jede Funktion auf einem eigenen Kern ausgeführt wird, werden sie alle mit ungefähr derselben Geschwindigkeit simuliert. Wenn jedoch zwei Features auf einem Kern ausgeführt werden, werden beide nur halb so schnell simuliert wie der Rest der Spielwelt, was zu allen möglichen seltsamen Verhaltensweisen führen kann.

Beachten Sie, dass eine Softwarearchitektur, die von unabhängigen Threads abhängt, die mit bestimmten Timings ausgeführt werden, äußerst zerbrechlich ist und ein Zeichen für ein sehr schlechtes Verständnis der gleichzeitigen Programmierung ist. In praktisch allen Multithreading-APIs stehen Funktionen zur Verfügung, mit denen Threads explizit synchronisiert werden können, um solche Probleme zu vermeiden.

Es ist unwahrscheinlich, dass diese "Mindestanforderungen" etwas darstellen, unter dem das Spiel nicht ausgeführt werden kann. Viel wahrscheinlicher ist, dass sie etwas darstellen, unter dem das Spiel nicht mit akzeptabler Leistung läuft. Keine Spielefirma möchte mit vielen Kunden fertig werden, die sich über schlechte Leistung beschweren, wenn sie diese auf einer Single-Core-1-GHz-Box betreiben, selbst wenn die Software technisch laufen könnte. Aus diesem Grund werden sie wahrscheinlich absichtlich so konzipiert, dass sie bei Boxen mit weniger Kernen nicht so gut funktionieren, als dies bei einer akzeptablen Leistung der Fall wäre.

Eine wichtige Messgröße für die Spieleleistung ist die Framerate. Normalerweise werden sie mit 30 oder 60 Bildern pro Sekunde ausgeführt. Dies bedeutet, dass die Game Engine die aktuelle Ansicht aus dem Spielstatus in einer festgelegten Zeit rendern muss. Um 60 fps zu erreichen, sind dafür nur etwas mehr als 16 ms erforderlich. Spiele mit High-End-Grafik sind extrem CPU-gebunden, und daher gibt es ein großes Auf und Ab zwischen dem Versuch, eine höhere Qualität zu erzielen (was mehr Zeit in Anspruch nimmt) und der Notwendigkeit, in diesem Zeitbudget zu bleiben. Somit ist das Zeitbudget für jeden Rahmen extrem eng.

Da das Zeitbudget knapp ist, möchte der Entwickler im Idealfall exklusiven Zugriff auf einen oder mehrere Kerne. Sie möchten wahrscheinlich auch in der Lage sein, ihre Rendering-Aufgaben ausschließlich in einem Kern zu erledigen, da dies mit dem Zeitbudget geschehen muss, während andere Aufgaben wie die Berechnung des Weltzustands in einem separaten Prozess ablaufen, in dem dies nicht der Fall ist eindringen.

Theoretisch könnte man das alles auf einen Kern packen, aber dann wird alles viel schwieriger. Plötzlich musst du sicherstellen, dass alles, was mit dem Spielstatus zu tun hat, schnell genug vonstatten geht und dass dein Rendering funktioniert. Sie können sie nicht einfach zu zwei Software-Threads machen, da es keine Möglichkeit gibt, dem Betriebssystem klar zu machen, dass "Thread A X-Arbeit in 16 ms erledigen muss, unabhängig davon, was Thread B tut".

Spieleentwickler haben kein Interesse daran, dass Sie neue Hardware kaufen. Der Grund für die Systemanforderungen ist, dass sich die Kosten für die Unterstützung von Maschinen der unteren Preisklasse nicht lohnen.

Drei Echtzeit-Threads, die niemals schlafen, und ein weiterer Thread. Wenn weniger als vier Kerne vorhanden sind, wird der vierte Thread nie ausgeführt. Wenn der vierte Thread mit einem der Echtzeit-Threads kommunizieren muss, damit der Echtzeit-Thread beendet wird, wird der Code nicht mit weniger als vier Kernen beendet.

Wenn Echtzeit-Threads auf etwas warten, das sie nicht schlafen lässt (z. B. ein Spinlock), hat der Programmdesigner offensichtlich Fehler gemacht.

Zunächst einmal haben Softwarethreads nichts mit Hardwarethreads zu tun und werden häufig vertauscht. Software-Threads sind Codeteile, die im Prozesskontext einzeln abgesetzt und ausgeführt werden können. Hardware-Threads werden zumeist vom Betriebssystem verwaltet und bei normalen Programmen an den Prozessorkern gesendet. Diese Hardwarethreads werden basierend auf der Last gesendet. Der Hardware-Thread-Dispatcher verhält sich mehr oder weniger wie ein Load Balancer.

Wenn es jedoch um Spiele geht, insbesondere High-End-Spiele, werden die Hardware-Threads manchmal vom Spiel selbst verwaltet oder das Spiel weist den Hardware-Thread-Dispatcher an, was zu tun ist. Das liegt daran, dass nicht jede Aufgabe oder Aufgabengruppe die gleiche Priorität hat wie in einem normalen Programm. Da Dragon Age aus einem High-End-Game-Studio stammt, das High-End-Game-Engines verwendet, kann ich mir vorstellen, dass es den manuellen Versand verwendet und dann die Anzahl der Kerne zu einer minimalen Systemanforderung wird. Jedes Programm stürzt ab, wenn ich einen Code an den 3. physischen Kern sende, der auf einem Computer mit nur 1 oder 2 Kernen ausgeführt wird.

Da es möglich ist, virtualize zu verwenden, um mehr virtuelle Kerne als physische zu haben, und die Software nicht weiß, dass es auf einem virtualize ausgeführt wird, und stattdessen denkt, dass es so viele physische Kerne hat, würde ich sagen, dass eine solche Software nicht möglich ist.

Das heißt, es ist nicht möglich, Software zu schreiben, die immer auf weniger als N Kernen stoppt.

Wie bereits erwähnt, gibt es Softwarelösungen, die möglicherweise überprüfen können, insbesondere wenn das verwendete Betriebssystem und der verwendete Code nur einen geringen Schutz vor Race-Bedingungen bieten, wenn N Prozesse auf <N Prozessoren ausgeführt werden. Der eigentliche Trick ist Code, der fehlschlägt, wenn Sie weniger als N Prozessoren haben, aber nicht fehlschlägt, wenn Sie N Prozessoren haben, aber ein Betriebssystem haben, das möglicherweise weniger als N Prozessoren Arbeit zuweist.

Es kann sein, dass drei Threads etwas tun (Hintergründe generieren oder NPC-Bewegungen generieren) und Ereignisse an einen vierten Thread übergeben, der die Ereignisse aggregieren / filtern und das Ansichtsmodell aktualisieren soll. Wenn der vierte Thread nicht alle Ereignisse abruft (weil er nicht für einen Core geplant ist), wird das Ansichtsmodell nicht korrekt aktualisiert. Dies kann nur sporadisch vorkommen, diese Kerne müssen jedoch jederzeit verfügbar sein. Dies könnte erklären, warum Sie nicht die ganze Zeit über eine hohe CPU-Auslastung feststellen, das Spiel jedoch trotzdem nicht ordnungsgemäß funktioniert.

Ich denke, Joshua ist auf dem richtigen Weg, nur nicht zu seinem Ende.

Angenommen, Sie haben eine Architektur, in der drei Threads geschrieben sind, um so viel wie möglich zu tun. Wenn sie fertig sind, was sie tun, tun sie es erneut. Um die Leistung aufrechtzuerhalten, geben diese Threads keine Kontrolle für irgendetwas frei - sie möchten nicht die Verzögerung durch den Windows-Taskplaner riskieren. Solange es 4 oder mehr Kerne gibt, funktioniert dies einwandfrei. Andernfalls tritt ein schwerer Fehler auf.

Im Allgemeinen wäre dies eine schlechte Programmierung, aber Spiele sind eine andere Sache - wenn Sie vor der Wahl stehen zwischen einem Design, das der gesamten Hardware unterlegen ist, oder einem Design, das der ausreichend guten Hardware überlegen ist, oder einem Fehler, für das sich Entwickler für unterlegene Hardware entscheiden die Hardware benötigen.

Is it possible to write code (or complete software, rather than a piece of code) that won't work properly when run on a CPU that has less than N number of cores?

Absolut. Die Verwendung von Echtzeit-Threads wäre ein gutes Beispiel für eine Situation, in der dies nicht nur möglich ist, sondern auch der gewünschte (und häufig der einzig richtige) Weg, um die Arbeit zu erledigen. Echtzeit-Threads sind jedoch in der Regel auf den Betriebssystemkern beschränkt, in der Regel für Treiber, die gewährleisten müssen, dass ein Hardwareereignis in einem definierten Zeitraum verarbeitet wird. Sie sollten keine Echtzeit-Threads in normalen Benutzeranwendungen haben und ich bin nicht sicher, ob es überhaupt möglich ist, einen in einer Windows-Benutzeranwendung zu haben. Im Allgemeinen machen es Betriebssysteme absichtlich unmöglich, dies vom Benutzerland aus zu tun, da es einer bestimmten Anwendung ermöglicht, die Kontrolle über das System zu übernehmen.

In Bezug auf User-Land-Anwendungen: Ihre Annahme, dass die Überprüfung einer bestimmten Anzahl von Threads für die Ausführung zwangsläufig böswillig ist, ist nicht korrekt. Zum Beispiel könnten Sie zwei langfristige, leistungsintensive Aufgaben haben, die einen eigenen Kern benötigen. Unabhängig von der Geschwindigkeit des CPU-Kerns kann die gemeinsame Nutzung eines Kerns mit anderen Threads eine ernsthafte und inakzeptable Verschlechterung der Leistung bedeuten, da der Cache überlastet wird. Insbesondere für ein Spiel müssen Sie festlegen, dass jeder dieser Threads eine Affinität nur für einen bestimmten Kern für jeden von ihnen hat, und anschließend alle anderen Threads so festlegen, dass sie keine Affinität für diese 2 Kerne haben. Um dies zu tun, müssen Sie

Jeder Code, der Spinlocks mit einer bemerkenswerten Menge an Sperrkonflikten verwendet, wird eine schreckliche Leistung erbringen (in einem Ausmaß, in dem Sie für eine Anwendung wie ein Spiel "Funktioniert nicht" sagen können ), wenn die Anzahl der Threads die Anzahl der Kerne überschreitet.

Stellen Sie sich zum Beispiel einen Producer-Thread vor, der Aufgaben an eine Warteschlange sendet, die 4 Consumer-Threads bedient. Es gibt nur zwei Kerne:

Der Produzent versucht, den Spinlock zu erhalten, aber er wird von einem Verbraucher gehalten, der auf dem anderen Kern läuft. Die beiden Kerne laufen im Gleichschritt, während sich der Produzent dreht und darauf wartet, dass die Sperre freigegeben wird. Das ist schon schlimm, aber nicht so schlimm wie es wird.
Leider befindet sich der Consumer-Thread am Ende seiner Zeitmenge, sodass er vorab freigegeben wird und ein weiterer Consumer-Thread geplant ist. Es versucht, das Schloss zu erreichen, aber natürlich wird das Schloss genommen, also drehen sich jetzt zwei Kerne und warten auf etwas, das unmöglich passieren kann.
Der Produzententhread erreicht das Ende seiner Zeitscheibe und ist vorbelegt, wacht ein anderer Konsument auf. Wieder warten zwei Verbraucher auf die Freigabe einer Sperre, und dies wird erst geschehen, wenn zwei weitere Zeitquanten verstrichen sind.
[...] Schließlich hat der Verbraucher, der das Spinlock hielt, das Schloss freigegeben. Es wird sofort von dem genommen, der sich auf dem anderen Kern dreht. Es besteht eine 75% ige Chance (3 zu 1), dass es sich um einen weiteren Verbraucher-Thread handelt. Mit anderen Worten, es ist zu 75% wahrscheinlich, dass der Produzent noch festsitzt. Das bedeutet natürlich auch, dass die Verbraucher ins Stocken geraten. Ohne die Aufgaben des Produzenten haben sie nichts zu tun.

Beachten Sie, dass dies im Prinzip bei jeder Art von Sperre funktioniert, nicht nur bei Spinlocks - aber die verheerende Wirkung ist bei Spinlocks viel ausgeprägter, da die CPU die Brennzyklen beibehält, während sie nichts erreicht.

Stellen Sie sich nun vor, dass einige Programmierer zusätzlich zu den oben genannten die brillante Idee hatten, einen dedizierten Thread zu verwenden, dessen Affinität auf den ersten Kern festgelegt ist, sodass RDTSC auf allen Prozessoren zuverlässige Ergebnisse liefert (dies wird ohnehin nicht der Fall sein, aber manche Leute denken es).

Wenn ich verstehe, was Sie fragen, ist es möglich, aber es ist eine sehr, sehr schlechte Sache.

Das kanonische Beispiel für das, was Sie beschreiben, wäre die Pflege eines Zählers, der um mehrere Threads erhöht wird. Dies erfordert fast nichts an Rechenleistung, erfordert jedoch eine sorgfältige Koordination zwischen den Threads. Solange jeweils nur ein Thread ein Inkrement ausführt (bei dem es sich tatsächlich um einen Lesevorgang gefolgt von einer Addition gefolgt von einem Schreibvorgang handelt), ist sein Wert immer korrekt. Dies liegt daran, dass ein Thread immer den richtigen "vorherigen" Wert liest, einen hinzufügt und den richtigen "nächsten" Wert schreibt. Bringen Sie zwei Threads gleichzeitig in die Aktion, und beide lesen denselben "vorherigen" Wert, erhalten dasselbe Ergebnis aus dem Inkrement und schreiben denselben "nächsten" Wert. Der Zähler wurde effektiv nur einmal inkrementiert, obwohl zwei Threads glauben, dass sie es jeweils getan haben.

Diese Abhängigkeit zwischen Timing und Korrektheit wird in der Informatik als Race Condition bezeichnet .

Wettlaufsituationen werden häufig vermieden, indem Synchronisationsmechanismen verwendet werden, um sicherzustellen, dass Threads, die mit einem Teil der gemeinsam genutzten Daten arbeiten möchten, für den Zugriff in der Warteschlange stehen müssen. Der oben beschriebene Zähler könnte hierfür eine Lese- / Schreibsperre verwenden .

Ohne Zugriff auf das interne Design von Dragon Age: Inquisition kann jeder nur darüber spekulieren, warum es sich so verhält wie es ist. Aber ich werde versuchen, basierend auf einigen Dingen, die ich in meiner eigenen Erfahrung gesehen habe:

Möglicherweise basiert das Programm auf vier Threads, die optimiert wurden, sodass alles funktioniert, wenn die Threads größtenteils ohne Unterbrechung auf ihren eigenen physischen Kernen ausgeführt werden. Die "Optimierung" könnte in Form einer Neuanordnung des Codes oder der Einfügung von Ruhezuständen an strategischen Stellen erfolgen, um rassenzustandsbedingte Fehler, die während der Entwicklung aufgetreten sind, zu mindern. Auch dies ist alles eine Vermutung, aber ich habe gesehen, dass sich die Rennbedingungen mehrmals auf diese Weise "gelöst" haben, als ich zählen möchte.

Das Ausführen eines Programms auf diese Weise in einer Umgebung, die weniger leistungsfähig ist als die Umgebung, für die es optimiert wurde, führt zu Zeitänderungen, die darauf zurückzuführen sind, dass der Code nicht so schnell ausgeführt wird oder eher Kontextwechsel. Kontextwechsel erfolgen auf physische Weise (dh die physischen Kerne der CPU wechseln zwischen der Arbeit, die ihre logischen Kerne halten) und auf logische Weise (dh, das Betriebssystem in der CPU weist den Kernen Arbeit zu) wäre der "erwartete" Ausführungszeitpunkt. Das kann schlechtes Benehmen hervorrufen.

Wenn Dragon Age: Inquisition nicht den einfachen Schritt unternimmt, um sicherzustellen, dass genügend physische Kerne verfügbar sind, bevor Sie fortfahren, ist dies die Schuld von EA. Wahrscheinlich geben sie ein kleines Vermögen für Supportanrufe und E-Mails von Leuten aus, die versuchten, das Spiel mit zu wenig Hardware zu betreiben.

Windows hat hierfür eine integrierte Funktionalität: Die Funktion GetLogicalProcessorInformation befindet sich in der Windows- API . Sie können es von Ihrem Programm aus aufrufen, um Informationen zu Kernen, virtuellen Kernen und Hyperthreading abzurufen.

Die Antwort auf Ihre Frage wäre also: Ja.