Programme, die behaupten, sie seien nicht "Multi-Core" -freundlich

Sie sehen diesen oder einen ähnlichen Satz, der sich von Zeit zu Zeit herumwirbelt und sich im Allgemeinen auf ein Programm bezieht, das behauptet, es sei nicht dafür ausgelegt, die Vorteile von Multi-Core-Prozessoren voll auszuschöpfen. Dies ist insbesondere bei der Programmierung von Videospielen üblich. (Natürlich haben viele Programme keine Nebenläufigkeit und benötigen diese nicht, wie z. B. einfache Skripte usw.).

Wie kann das sein? Viele Programme (insbesondere Spiele) verwenden inhärent Parallelität, und da das Betriebssystem für die Aufgabenplanung auf der CPU verantwortlich ist, nutzen diese Programme dann nicht inhärent die verfügbaren mehreren Kerne aus? Was würde es in diesem Zusammenhang bedeuten, "mehrere Kerne auszunutzen"? Verbieten diese Entwickler tatsächlich das Planen von Betriebssystemaufgaben und das Erzwingen von Affinität oder ihre eigene Planung? (Klingt nach einem großen Stabilitätsproblem).

Ich bin ein Java-Programmierer, also musste ich mich vielleicht nicht wegen Abstraktionen oder so weiter damit auseinandersetzen.

Für eine gute Parallelität ist viel mehr erforderlich, als ein paar Threads in eine Anwendung zu werfen und auf das Beste zu hoffen. Es gibt eine Reihe von Möglichkeiten, wie gleichzeitig ein Programm von peinlich parallel zu rein sequentiell ablaufen kann. Jedes Programm kann das Amdahlsche Gesetz verwenden, um auszudrücken, wie skalierbar ein Problem oder ein Algorithmus ist. Ein paar Voraussetzungen für eine peinlich parallele Bewerbung wären:

• Kein gemeinsamer Status, jede Funktion hängt nur von den übergebenen Parametern ab
• Kein Zugriff auf physische Geräte (Grafikkarten, Festplatten usw.)

Es gibt noch andere Qualifikationen, aber nur mit diesen beiden können wir verstehen, warum gerade Spiele nicht so einfach sind, wie Sie vielleicht denken, um die Vorteile mehrerer Kerne zu nutzen. Zum einen muss das Modell der Welt, das gerendert werden soll, geteilt werden, da verschiedene Funktionen Physik, Bewegung, künstliche Intelligenz usw. berechnen. Zum anderen muss jedes Bild dieses Spielmodells mit einer Grafikkarte auf dem Bildschirm gerendert werden.

Um fair zu sein, verwenden viele Spielehersteller Spiele-Engines, die von Dritten hergestellt werden. Es hat eine Weile gedauert, aber diese Spiele-Engines von Drittanbietern sind jetzt viel paralleler als früher.

Der Umgang mit effektiver Parallelität stellt größere architektonische Herausforderungen

Parallelität kann viele Formen annehmen, von der Ausführung von Aufgaben im Hintergrund bis zur vollständigen Unterstützung der Parallelität durch die Architektur. Einige Sprachen bieten Ihnen sehr leistungsstarke Funktionen für den gemeinsamen Zugriff , z. B. ERLANG . Sie müssen jedoch ganz anders darüber nachdenken, wie Sie Ihre Anwendung erstellen.

Nicht jedes Programm benötigt die Komplexität einer vollständigen Multicore-Unterstützung. Ein Beispiel hierfür ist Steuersoftware oder eine beliebige formulargesteuerte Anwendung. Wenn Sie den größten Teil Ihrer Zeit damit verbringen, auf den Benutzer zu warten, um etwas zu tun, ist die Komplexität von Multithread-Anwendungen einfach nicht so nützlich.

Einige Anwendungen eignen sich für eine peinlichere parallele Lösung, z. B. Webanwendungen. In diesem Fall beginnt die Plattform peinlich parallel und es liegt an Ihnen, keine Thread-Konflikte zu erzwingen.

Die Quintessenz:

Nicht alle Anwendungen sind wirklich betroffen, wenn nicht mehrere Threads (und damit Kerne) ausgenutzt werden. Für diejenigen, die dadurch verletzt werden, sind die Berechnungen manchmal nicht für eine parallele Verarbeitung geeignet, oder der Aufwand für die Koordinierung würde die Anwendung anfälliger machen. Leider ist die parallele Verarbeitung immer noch nicht so einfach, wie es gut sein sollte.

Viele Programme (insbesondere Spiele) verwenden von Natur aus Parallelität.

Nein, eigentlich ist es umgekehrt. Die meisten Apps sind in einer einzigen Thread-Denkweise geschrieben, und die Entwickler haben nie die notwendigen Änderungen vorgenommen, um Parallelität zu unterstützen.

In C, C ++ und C # müssen Sie die Anwendung explizit anweisen, neue Threads und / oder Prozesse zu starten.

Ich denke, Sie konzentrieren sich zu sehr auf die Planung der Threads und nicht genug auf die Datenverarbeitung innerhalb der potenziellen Threads. Das Teilen von Daten über Threads und / oder Prozesse hinweg erfordert eine gewisse Form der Synchronisation. Wenn Sie eine Anwendung so ändern, dass mehrere Threads verwendet werden, diese Synchronisierung jedoch nicht vorhanden ist, werden Sie wahrscheinlich viele schwer auffindbare Fehler im Code feststellen.

Bei den Multithread-Anwendungen, an denen ich gearbeitet habe, habe ich mich im Allgemeinen nie um den Versand und nur um die Datensynchronisierung gekümmert. Die einzige Zeit, in der ich mir Sorgen um den Versand machen musste, war, als ich wegen falscher Datensynchronisation den Rennbedingungen nachjagte.

Wenn eine Anwendung angibt, dass sie nicht mehrere Kerne verwenden kann, bedeutet dies im Allgemeinen, dass keine Synchronisierung vorhanden ist, um die Datenmanipulation zu schützen.

Hier geht es nicht so sehr um mehrere Kerne, sondern um mehrere Threads. Das Betriebssystem plant möglicherweise, dass ein Thread auf einem beliebigen Kern ausgeführt wird, und diese Planung ist für das geplante Programm transparent. Viele Programme werden jedoch nicht mit mehreren Threads geschrieben, sodass sie nur auf einem Kern gleichzeitig ausgeführt werden können.

Warum sollte ich ein Single-Thread-Programm schreiben? Sie sind einfacher zu schreiben und leichter zu debuggen: Eine Sache passiert nach der anderen (anstatt dass mehrere Dinge gleichzeitig passieren und sich gegenseitig in die Quere kommen). Oder Ihr Programm ist möglicherweise nicht auf Multi-Core-Computer ausgerichtet (wie dies bei alten Spielen der Fall war). In einigen Fällen kann ein Multithread-Programm sogar langsamer als eine Singlethread-Version ausgeführt werden, wenn der Overhead durch Kontextwechsel und Kommunikation zwischen Threads die Geschwindigkeit überwiegt, die durch die parallele Ausführung erzielt wird (einige Teile des Programms sind möglicherweise nicht parallelisierbar).

Dies ist keine vollständige Antwort. Es ist eine warnende Geschichte.

Eines Tages dachte ich, ich würde den Studenten in meinem parallelen Programmierkurs eine parallele Kurzübersicht zeigen. Quicksort sollte gut passen, dachte ich. Ich habe zwei Fäden benutzt. Lief es auf meinem Single-Core-Computer. Die Ergebnisse waren:

• 14 Sekunden für eine Singlethread-Version.
• 15 Sekunden für die 2-Thread-Version.

Das war ungefähr das, was ich erwartet hatte.

Dann habe ich es auf einem neueren Dual-Core-Rechner ausprobiert.

• 11 Sekunden für die Singlethread-Version.
• 20 Sekunden für die 2-Thread-Version.

Die beiden Threads teilten sich eine Warteschlange verbleibender Aufgaben. Es scheint, dass die Felder des Warteschlangenobjekts zwischen dem Cache eines Kerns und dem des anderen hin und her verschoben wurden.