Login Registrieren
Games World
      • Von AndPod Schraubenverwechsler(in)
        Zitat von DaStash
        Kennt ihr noch die Vobis Rechner, die man auf Knopfdruck übetakten konnte? Was war das, vonn 100 auf 133 Mhz?
        MfG


        Ich kenn den noch mit 16 auf 20Mhz
      • Von Johnjoggo32 Freizeitschrauber(in)
        Zitat von Olstyle
        Du gehst davon aus dass ein einziger, logisch eher serieller Task "künstlich" in Threads geteilt wird. Da macht es Sinn nicht zu viel zu teilen. Wenn man aber grundsätzlich erst mal nur lose verbundene Aufgaben hat welche schon logisch einen separaten Thread bedeuten gibt es keinen Grund zu versuchen das Scheduling dieser selbst umzusetzen, denn dafür ist das OS ja da (was sich dann auch über sowas wie "ist das ein HW Kern oder ein SMT Kern?" Gedanken macht).
        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.
      • Von Olstyle Moderator
        Du gehst davon aus dass ein einziger, logisch eher serieller Task "künstlich" in Threads geteilt wird. Da macht es Sinn nicht zu viel zu teilen. Wenn man aber grundsätzlich erst mal nur lose verbundene Aufgaben hat welche schon logisch einen separaten Thread bedeuten gibt es keinen Grund zu versuchen das Scheduling dieser selbst umzusetzen, denn dafür ist das OS ja da (was sich dann auch über sowas wie "ist das ein HW Kern oder ein SMT Kern?" Gedanken macht).
      • Von Johnjoggo32 Freizeitschrauber(in)
        Ich frag mich immer wie sowas passieren kann wo doch die C++ API diese wunderbare Funktion std::hardware_concurrency() stellt, die unter Windows und Linux auch noch sinnvoll implementiert ist. Einen Thread-Pool von der Größe zu bauen kann doch nicht so schwer sein. Array aus Threads die in einer Loop hängen und los. Man man man...
      • Von Krabonq Software-Overclocker(in)
        Zitat von DaStash

        Hat mit Sicherheit nichts gebracht außer auf dem kleinen, grünen Display am Gehäuse.
        Der Knopf hatte, zumindest zunächst, durchaus seine Berechtigung:
        Turbo-Taste – Wikipedia
  • Print / Abo
    Apps
    PCGH Magazin 10/2019 PC Games 10/2019 PC Games MMore 09/2019 play³ 10/2019 Games Aktuell 09/2019 XBG Games 01/2018
    PCGH Magazin 10/2019 PC Games 10/2019 PC Games MMORE Computec Kiosk