Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Valve wil multithreading in Linux-kernel optimaliseren om gamen beter te maken

Valve wil de kernel van Linux aanpassen om games beter te kunnen ondersteunen. Het platform stelt manieren voor om gaming op het platform te verbeteren, onder andere door multithreading beter te ondersteunen.

Het voorstel valt samen met de release van Proton 4.11 door Steam, die eerder deze week plaatsvond. Proton 4.11 is gebaseerd op WINE 4.11 en heeft, naast een hoop bugfixes en ondersteuning voor Direct3D.9, functionaliteit waarmee de cpu-load bij multithreaded games kan worden verlaagd. Daarvoor moet echter wel de Linux-kernel worden aangepast. Dat heeft Valve inmiddels voorgesteld. Het voorstel van Valve om de kernel aan te passen zou leiden tot meer dan tien procent verlaging van de cpu-load, zegt Valve. Dat testte daarvoor Tomb Raider op een high-end machine, maar volgens het bedrijf kan ook bij goedkopere systemen sprake zijn van een flinke loadverlaging.

In de nieuwe versie van Proton zit ook een experimentele nieuwe functie waarmee esync kan worden vervangen. esync was altijd de manier om multithreaded games te spelen op Linux, maar Valve wil de kernel aanpassen om multithreading in het algemeen sneller te maken in het besturingssysteem. Dat moet gebeuren door fast user-space locking-functionality of futex() uit te breiden door meer kernfunctionaliteit beschikbaar te stellen. Ook stelt Valve voor aanpassingen te doen aan glibc en lbpthread.

Er zijn al twee experimentele packages van fsync beschikbaar voor Arch en Ubuntu, die door gebruikers als bèta kunnen worden geprobeerd. Daarnaast zijn er proof-of-concept-patches uit voor glibc, die door gebruikers kunnen worden getest.

Door Tijs Hofmans

Redacteur privacy & security

02-08-2019 • 11:27

115 Linkedin

Reacties (115)

Wijzig sortering
Maar dat is toch inherent aan een code-review. Als er geen commentaar is, is het niet doorgenomen. Men heeft altijd oversights die daarin mogelijk worden rechtgezet. Mocht valve met een algemene verbetering komen (zodat alle multithreading loads er wat aan hebben), dan is het zeker de moeite waard.
Toen was programmeren nog een stuk minder functie-gebaseerd en stond alles in één grote main functie. Goto’s waren een logisch gevolg van het gebrek om stukken code op verzoek uit te voeren. Natuurlijk maakt dat goto’s niet slecht, maar er zijn nu vaak betere alternatieven.
Sommige van mjjn eerste stukken code ooit waren in Basic. GW-BASIC, GOSUB en GOTO met line numbers. Hoewel ik echt gruwel van Java moet ik toch toegeven dat we met moderne talen als Python en R een stuk verder zijn gekomen.
Wellicht kan je met gotos net een beetje meer performance uit de kernel persen, echter in het algemeen maakt die ene instructie in een applicatie maar heel weinig uit. Leesbaarheid, onderhoudbaarheid en minder fouten wegen over het algemeen zwaarder mee.
Schroeven in hout slaan met een hamer is heel soms wel nodig.:-)
Jup en soms hebben we nested for loops nodig...
Betekent niet dat het ideaal
Is :p

Maarja soms is het idd de enige manier.
En bouwen met baksteen is in nederland goed, maar in san francisco verboden wegenda aardbevingen.

Het hangt allemaal gewoon af van de onstandigheden.
bakstenen verboden ? echt ? ohh, daar had ik nog nooiit bij stilgestaan. Interessant feitje !
De consument is een groottere groep dus daar gaat de aandacht naar uit.

Ik zie dat veel mensen in IT aan de 'operations' (systeem beheer, etc.) kant nog steeds op tweakers.net kijken en dus zou tweakers.net een goede plek zijn voor introductie(s) in programmeren, etc.of alleen maar meer/betere scripting voor specifiek die mensen.
Dan kan je zo ongeveer het grootste gedeelte van je steam library weg flikkeren, net zoals nu het geval is op Mac OS Catalina.
Bijna alle 32-bit software op Linux is omdat veel Windows software nog deels met 1 been in 32-bit land staat.
Ik ben geen ontwikkelaar en al helemaal geen kernel hacker, dus ik heb geen idee wat je met "condition variables" bedoelt. Ik weet alleen dat @Vlad86 het in deze post correct heeft dat de Windows NT kernel een functie WaitForMultipleObjects heeft die de Linux kernel niet (meer) heeft. De ontwikkelaars van Valve willen deze introduceren. Zie de link in het artikel naar de Linux Kernel mailing lijst voor meer technische informatie.

[Reactie gewijzigd door rbr320 op 2 augustus 2019 17:54]

condition variables hebben onderaan een os plementatie. deze implementatie is onderandere ook futex wat in de verbeter voorstel is aangegeven.
leg eens uit: waar komt die 10% vandaan.
blijkbaar wordt nu 10% van de tijd verspild. Is de GPU 10% van de tijd niets aan het doen? Is de CPU 10% van de tijd niets aan het doen? Is de CPU 10% van de tijd kernel taken aan het doen? Als de CPU 10% niets doet, gaat de klok naar beneden?
blijkbaar wordt nu 10% van de tijd verspild.
Ja... en door dingen slimmer te doen (vaak door minder code uit te voeren, of betere algoritmes te gebruiken) maar toch hetzelfde resultaat te hebben is het dus mogelijk 10% processortijd te winnen.

Als simpel voorbeeld, stel je moet 300 getallen onder de 1000 sorteren. Dat kun je doen door
- ze in de lucht te gooien, en als ze vallen kijken of ze op de goede volgorde liggen ( dat zal uiteindelijk wel een keer gebeuren - dit is uiteraard niet de slimste manier ^^ ).
- 1 te pakken, en de volgende op de juiste plek ertussen te leggen
- je zou ook een tabelletje kunnen maken en aankruisen welke getallen je gehad hebt ( als je ze allemaal gehad hebt zie je in de tabel de sortering ).
- je zou het samen kunnen doen met 3 vrienden (ieder soorteert z'n eigen 100 getallen) en op het einde lopen "mergen" jullie de tussen-sorteer resultaten.

In alle gevallen eindig je met hetzelfde resultaat, maar de ene manier zal handiger/sneller zijn dan de andere. Dit soort verbeteringen is dus waar die 10% vandaan komt.
Is de GPU 10% van de tijd niets aan het doen? Is de CPU 10% van de tijd niets aan het doen?
GPU: Misschien, hangt ervan af hoe veel "rekenwerk" de CPU naar de GPU kan sturen - en hoe snel de GPU is, en of de bottleneck bij de cpu of de gpu ligt.
CPU: Door optimalisaties is het mogelijk om 10% tijd te winnen...
Is de CPU 10% van de tijd kernel taken aan het doen?
Ik denk dat je bedoelt waar die 10% winst vandaan komt. Je zou naar de preciese verbeteringen moeten kijken, maar omdat het gaat om verbeteringen aan de kernel zal daar in ieder geval een deel van de winst (efficientere afhandeling) vandaan komen.
Als de CPU 10% niets doet, gaat de klok naar beneden?
Misschien... maar voor games is het waarschijnlijker dat de game naar een hogere framerate gaat (en die 10% winst dus daarvoor gebruikt wordt). Tenzij je vsync aanzet en je al op 60fps zit, in dat geval denk ik dat je cpu op dezelfde klok blijft (game = high performance), maar met een lage cpu-belasting.

Je wilt in principe voor een game niet dat de klok naar beneden gaat, omdat de cpu de 'rekenopdracht' zo snel mogelijk bij de gpu moet afleveren, zodat die asap kan beginnen. Misschien is de gpu net snel genoeg om het totaal op 16ms (=60fps) te houden, bij een lagere klok zou die dan niet meer snel genoeg zijn. Da's net niet wat je wil, voor een game.

[Reactie gewijzigd door rboerdijk op 3 augustus 2019 11:19]

ik kan de CPU ook volladen, met een of andere simulatie. Maar bij 'gewoon' gebruik lukt dat dus niet. En ik heb ook nog nooit gezien dat de totale bezetting zeg 85% was, als ik drie van de vier (hyperthreading) cores vol laat simuleren en verder niets doe.

Dus ik geloof niet dat 10% winst in willekeurige applicaties een verkoopargument is.
10% improvement is voor een stukje veelgebruikte kernel code best heel netjes, vooral omdat applicaties die code nog wel eens heel vaak willen aanroepen. En dit is het dus ook altijd waard, vooral met de aanpassing in het artikel, als men zo het aantal IO operations wat kan terug dringen door een native kernel functie aan te maken, das goeie winst. Bijvoorbeeld je zag dat WSL (eigenlijk een soort linux kernel emulatie laag) een heel stuk trager was voor alles wat met de kernel moest, dus dat maakt wel degelijk heel veel uit. git was bijvoorbeeld niet vooruit te branden, nog erger dan gewoon native op Windows.

Daarbij het gaat hier om tijd (dus zeg iets van 1 ms duurde duurt nu 0.9 ms), niet om het percentage wat je systeem monitor aangeeft voor het gebruik van de CPU of verschillen daar in, dat wil je eigenlijk altijd op 100% hebben als er een taak bezig is.
10% verbeteren in een stukje kernel code is toch iets heel anders dan 10% performance overall.
Absoluut, maar omdat de kernel al in zo'n ver gevorderde staat van optimalisatie is, kun je niet meer de woeste published paper level 100x speedup halen. Er zit niet zo veel meer in, dus zou 10% nog steeds zeer netjes zijn.
Jij hebt het over een simulatie, ik heb het over dagelijks gebruik (in het weekend niet, door de week meerdere malen).

We hebben met mijn werk een half jaar geleden duizenden euro's geïnvesteerd in een nieuwe server, puur om de tijd van het indrukken van "F5" (run incl. debug) tot het zien van de applicatie te reduceren van ergens tussen de 15 en 40 seconden (extreme gevallen daargelaten) naar 2 tot 5 seconden.

Verder is er nauwelijks merkbaar verschil; dit betrof een latency die alleen optrad bij de eerste start. Scheelt effectief dus misschien 10 of hooguit 20 minuten op een dag, per ontwikkelaar; maximaal 5%. Maar geloof me, die paar duizend euro gaan we dit jaar nog terug verdienen.

Wat ik hiermee wil zeggen is: Die 10% lijkt misschien niet veel, maar kan het verschil maken tussen (in ons geval) irritatie of geen irritatie. Of voor een gamer tussen net wél speelbaar en net níet speelbaar. Daarbij is het zoals het hier beschreven is "gratis" winst. Goed voor de stroomrekening.

Tenzij er duidelijke nadelen of risico's zijn: Altijd doen.
10% winst is huge, zo huge zelfs dat niemand dit gelooft algemeen te zijn, zelfs de auteur niet van dit artikel. Mijn Raspberry Pi gebruikt ook nooit meer dan 10% CPU, want hij ligt stof te happen in de schuif.
Toch zal het nog wel even duren voordat je Threadripper goed belast wordt door games; op vier of vijf grote engine-onderdelen na (physics/rendering/audio/engine/netwerk) zijn games lastig verder te verdelen over processorkernen.
Moderne engines gebruiken een job-based system ipv een task-based system: ze delen al het werk op in kleine jobs die vervolgens door een willekeurige cpu core verwerkt kan worden. De cores worden op deze manier beter benut.
idd. ik zit ook elk jaar op de wipwap om te switchen. het komt steeds dichterbij
Geweldig! Aangezien de source opensource zal zijn, valt hij in te zien en kunnen wij er wellicht iets van leren!
Ik maak me niet zo'n zorgen voor de toekomst van Linux. Ik bedoel: als het niets toevoegt dan wordt het niet gemerged. Als het later blijkt tegen te vallen, wordt het er weer uitgesloopt.
Er is hier genoeg 'hot air' in het commentaar om een groene energie centrale draaiend te houden.
Ik denk dat hij Tim Sweeney bedoelde, die zat al een tijdje bezig hoe slecht Windows 8 en 10 is en hoe UWP een "closed platform" ging creëren.

Destijds kon je alleen UWP installeren via de Windows Store, en Microsoft had al plannen voor een UWP only OS (Windows 10 S). Ergens ironisch sinds Gears Of War 4 een van de betere UWP games waren op de store. Er waren ook een aantal problemen met UWP zoals locked framerate, forced fullscreen, geen raw input etc etc Meeste hiervan zijn ondertussen al verholpen.

Terwijl Tim Sweeney dus zwaar van zijn neus aan het maken was op Twitter enzo, was Valve al druk bezig met Steam op Linux te krijgen (inclusief hun gefaalde Steam Machines, een poging die misschien meer succes had als ze Proton ervoor hadden ontwikkeld). Timmetje zijn responds op Linux was "the equivalent of moving to Canada when one doesn't like US political trends".

Vreem genoeg is de Epic GameStore geschreven in Electron, een handig framework om multiplatform apps te ontwikkelen, maar toch is EGS niet op Linux te krijgen (ook al hebben ze wat games in de store toegevoegd die dat wel zijn, via Steam dan). Overigens support Unreal Engine niet alleen Linux porting maar kan je ook developen op Linux. Toch is geen enkel van Epic hun eigen games verkrijgbaar op Linux zonder Wine of dergelijke te draaien.
Het is duidelijk dat Epic even hard als Valve vreest dat Windows een gesloten platform word met alleen de Windows Store als toegang, maar ondertussen gaan ze niet 'all in' zoals Valve.

Er is duidelijk nood aan competite voor Windows, Direct3D was bijna dood als het niet was voor Valve en hun OpenGL optimalisatie die hun games beter deed draaien op Linux. Ze zien het niet als "moving to Canada" maar eerder "like a club held over MS's heads", misschien word het tijd dat Epic het ook zo begint te zien.

Op dit item kan niet meer gereageerd worden.


Apple iPhone 11 Microsoft Xbox Series X LG OLED C9 Google Pixel 4 CES 2020 Samsung Galaxy S20 4G Sony PlayStation 5 Nintendo Switch Lite

'14 '15 '16 '17 2018

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2020 Hosting door True