J
Johnjoggo32
Guest
Naja ne, du baust am Anfang beim Startup deines Games einen Thread-Pool weil Threads erstellen scheiß teuer ist. Naja wie groß ist der am besten maximal? Naja Anzahl der Kerne oder kleiner. Das hat noch nichts mit Scheduling zu tun. Nur die Erstellung + das setzen der Kern-Affinität. Und nein, das OS interessiert sich nicht für das Task-Scheduling in deinem Programm. Für sowas gibt's Job-Systeme. Dein OS kennt deine Tasks nichtmal.
Wenn man mit nem Thread-Pool arbeitet haut man die Tasks in ne Queue und ein Thread was grad nichts zu tun hat holt sich die dann. So einfach. Das Problem ist die Tasks unabhängig zu bekommen und das ganze weitestgehend Lock-Frei zu halten. Aber rauszufinden wie viele Logische Kerne du hast ist in C++ kein Thema.
Wenn man dann noch witzig ist baut man die Tasks als Coroutinen damit man yielden/resumen und damit priorisieren kann. Damit bekommt man dann schon ein recht effektives solides paralleles Job-System. Wenn man jetzt noch seine Tasks gut baut ist alles gemacht. So in der Art nur in komplexer und ausgereifter macht das übrigens auch Naughty Dog für Uncharted 4.
Du brauchst halt im Endeffekt mindestens 2 Threads und einen Pool mit Core-Count - 2. 1 Render Thread, ein - n Thread als Producer sprich Game-Loop und den Pool um Asynchron Tasks durch dein Job-System zu schleusen.
Der Pool an sich ist super easy... den schreib ich dir in ca 100 Zeilen^^ (Simple Thread_Pool, C++ (clang) - rextester)
Dein OS grätscht dir recht wenig in deinem Programm rum. Das OS darf zwar beim erstellen eines Threads die Kern-Affinität setzen, aber die ändert man sowiso. (alles andere ist eher ungünstig) Und ab dann hat das OS mit deinen Threads eigentlich nichts mehr am Hut.
Zuletzt bearbeitet von einem Moderator:
