This is apparently for improving the performance of Wine emulator on Linux mainly, not native Linux games like the headline suggests.
> Wine emulator
Wine stands for "Wine Is Not an Emulator".
Implement mechanism to wait on any of several futexes
31–40 of 158 posts
Re: Implement mechanism to wait on any of several futexes
#32Linux Gaming with Steam is actually quite nice these days. I spent about 3 years using an Ubuntu desktop for all my gaming at home. Most of the games I played installed via steam and worked great on Linux.
The only reason I switched back to a Windows Desktop was that there were just one or two games I specifically wanted to try, but couldn't install to Linux. And once I had switched back (and paid the price for Windows) there were no games that needed Linux, so no motivation to go back.
Re: Implement mechanism to wait on any of several futexes
#33Earlier quoted context omitted.
Depressing to see reviewers waste review bandwidth bringing up issues such as "wasted newline" and "incorrect comment format". Do kernel developers not use auto-formatters?
On the contrary, I think the feedback provided was excellent and far better than just saying “Doesn’t conform to our style guidelines, please try again”. Bravo Peter. This may be someone’s first submission and they may consequently not be aware of style guides, tools which can help lint, etc?
The technical review was great. The tone of the review left a lot to be desired.
Re: Implement mechanism to wait on any of several futexes
#34Linux Gaming with Steam is actually quite nice these days. I spent about 3 years using an Ubuntu desktop for all my gaming at home. Most of the games I played installed via steam and worked great on Linux. The only reason I switched back to a Windows Desktop was that there were just one or two games I specifically wanted to try, but couldn't install to Linux. And once I had switched back (and paid the price for Windo…
The article is discussing optimizing Proton, a version of Wine embedded in Steam, meaning you can (try to) play Windows-only games on Linux with minimal effort. It works quite well, though graphically intensive games are more likely to experience glitches or slowdown from the translation.
Re: Implement mechanism to wait on any of several futexes
#35Earlier quoted context omitted.
Depressing to see reviewers waste review bandwidth bringing up issues such as "wasted newline" and "incorrect comment format". Do kernel developers not use auto-formatters?
In a project like the kernel consistent style is important and the kernel has tools (Coccinelle spatches, checkpatch.pl) to help developers comply with it. There are standards that need to be followed and the bar is the same for everyone.
But why can't the committer just reformat (and otherwise improve) the patch when accepting? Why make the extra round-trips to the submitter?
Re: Implement mechanism to wait on any of several futexes
#36This looks to me like the main change is to make it easier to create mutexes with timeouts. Isn’t a mutex timing out an indication that: a) a lock wasn’t needed in the first place or b) the program is incorrect? It feels more like they just want the api to match win32 better but most of the multithreaded programming I’ve done lately has just used go’s channels so I totally could be missing something.
Correctness isn't always the right thing to do. Games, in particular, are full of code that approximates the right thing and falls back to less and less correct solutions. It's more important to be fast than right in a lot of cases. Dropping frames can have a significant negative experience for players. Dropping an AI pathing algorithm, particle physics computation, or other background task can often be fine or even unnoticed.
Re: Implement mechanism to wait on any of several futexes
#37Earlier quoted context omitted.
In a project like the kernel consistent style is important and the kernel has tools (Coccinelle spatches, checkpatch.pl) to help developers comply with it. There are standards that need to be followed and the bar is the same for everyone.
But why can't the committer just reformat (and otherwise improve) the patch when accepting? Why make the extra round-trips to the submitter?
Because it takes a lot of time for maintainers to format every PR.
Re: Implement mechanism to wait on any of several futexes
#38Earlier quoted context omitted.
On the contrary, I think the feedback provided was excellent and far better than just saying “Doesn’t conform to our style guidelines, please try again”. Bravo Peter. This may be someone’s first submission and they may consequently not be aware of style guides, tools which can help lint, etc?
The technical review was great. The tone of the review left a lot to be desired.
The technical review wasn't technical. It was a human roleplaying as a code formatter. The technical content was entirely found in the comment about ABI compatiblity.
I didn't see any discussion about tradeoffs, alternative approaches, or a survey of what other systems do for this kind of functionality, or detailed benchmark results.
The tone was roughly what I'd want people to give me in a code review -- the only problem is that it was trivial, and could have been summarized as "Fix the style, check it with $tool"
Re: Implement mechanism to wait on any of several futexes
#39Earlier quoted context omitted.
4.11 is newer than 4.2
I have no idea why this took me so long to realize. Must be the versions I'm used to seeing but my brain parsed `4.11` as `4.1.1`. Weird. Thanks for pointing out the obvious for those of us who missed it!
You parse it the same way I usually do. As a decimal fraction, 4.2 > 4.11... however, version numbers aren't decimal fractions.
In any case, you're not alone.
Re: Implement mechanism to wait on any of several futexes
#40Earlier quoted context omitted.
In a project like the kernel consistent style is important and the kernel has tools (Coccinelle spatches, checkpatch.pl) to help developers comply with it. There are standards that need to be followed and the bar is the same for everyone.
But why can't the committer just reformat (and otherwise improve) the patch when accepting? Why make the extra round-trips to the submitter?
Why would someone accept a patch that did not follow publicly available guidelines?