Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fixing stutters in Papers Please on Linux

blog.jhm.dev

Post reply on HN
Print view View original

121–130 of 202 posts

Re: Fixing stutters in Papers Please on Linux

#121

Post by dagmx »

loeg wrote: post #117
dagmx wrote: post #96

Earlier quoted context omitted.

CyberRabbi's definition of blocking is correct and what I've always seen commonly accepted. Blocking means you don't know how long it'll take, and you want to wait for it to finish. The only safe assumption is that you cannot guarantee how long it'll take. getpid is accurately therefore a blocking call. You don't know how long it'll take. You can profile and make best guesses, but you can never assuredly say how long…

Every operation in a non-RTOS is blocking by this definition, even local function calls that don’t enter the kernel, because the kernel may switch to another thread at any time. It’s utterly useless as a definition. Much more common is to divide system calls into ones that call depend on some external actor and those that don’t. Eg, recv() on a socket, blocking on a futex held by some other process, or waiting on IO…

If you call getpid, or even local functions, can the rest of your code (in a single thread) continue till getpid returns?

E.g if you do this inside a function (useless code)

int pid = getpid(); std::cout Will the output print even if the hypothetical call to getpid takes a second?

If the answer is the print will wait, then it's a blocking call.

If it was an async call, then it could happen concurrently or in parallel, and unless you waited, it would continue on in a non blocking fashion.

Waiting for a return == blocking. It may be quick but unless the spec specifies that it must be synchronous+non-blocking, the distinction between the two is moot.

Re: Fixing stutters in Papers Please on Linux

#122

Post by Aissen »

strace tip of the day: you don't need lsof, strace can keep track of open fds quite well, just use the -y flag.

       -y
       --decode-fds
       --decode-fds=path
              Print paths associated with file descriptor arguments.

       -yy
       --decode-fds=all
              Print all available information associated with file
              descriptors: protocol-specific information associated with
              socket file descriptors, block/character device number
              associated with device file descriptors, and PIDs
              associated with pidfd file descriptors.

Re: Fixing stutters in Papers Please on Linux

#123

Post by loeg »

treis wrote: post #116
CyberRabbi wrote: post #72

Earlier quoted context omitted.

While tempting, you can’t generally fix this by simply patching close() with some function that converts it to an unchecked asynchronous operation. If that were the case, you could just do that in the kernel. Close() is expected to complete synchronously. This matters because posix guarantees that open()/pipe() etc. will return the lowest file descriptor not in use[1]. I.e. this should work: close(0); fd = open(“/foo…

>This matters because posix guarantees that open()/pipe() etc. will return the lowest file descriptor not in use[1]. I.e. this should work: close(0); fd = open(“/foo/bar”, …); // fd is guaranteed to be 0 On a multi threaded system that isn't guaranteed is it? Meaning, another thread could call open in-between your close & open.

What you’re getting at is that an individual thread cannot really use this property without some form of synchronization with other threads in the process. Eg, to use this property, other threads either do not allocate fds, or you take some central lock around all fd allocations. Most well-written programs do not rely on it.

Re: Fixing stutters in Papers Please on Linux

#124

Post by [deleted] »

dagmx wrote: post #121
loeg wrote: post #117

Earlier quoted context omitted.

Every operation in a non-RTOS is blocking by this definition, even local function calls that don’t enter the kernel, because the kernel may switch to another thread at any time. It’s utterly useless as a definition. Much more common is to divide system calls into ones that call depend on some external actor and those that don’t. Eg, recv() on a socket, blocking on a futex held by some other process, or waiting on IO…

If you call getpid, or even local functions, can the rest of your code (in a single thread) continue till getpid returns? E.g if you do this inside a function (useless code) int pid = getpid(); std::cout Will the output print even if the hypothetical call to getpid takes a second? If the answer is the print will wait, then it's a blocking call. If it was an async call, then it could happen concurrently or in parallel…

[deleted]

Re: Fixing stutters in Papers Please on Linux

#125

Post by CorrectHorseBat »

spijdar wrote: post #111
facorreia wrote: post #100

This reminds me of the recent Linus Tech Tips series on gaming on Linux[1]. Their conclusion is that although many games work out of the box (although usually not at launch), Linux is not ready for mainstream gamers. Not many people would have the expertise or the interest to troubleshoot the problem as OP did. [1] https://www.youtube.com/watch?v=Rlg4K16ujFw

It definitely isn't. I've been a huge linux nerd since my preteens in the late 2000s, I jumped on to squeeze more performance out of the thoroughly mediocre hardware I had access to. I wanted to program, and I found Visual Studio to be incomprehensibly dense and confusing, while Linux tools were so much simpler, with GCC, GEdit, makefiles and the like being more to my liking. I fell deep into the rabbit hole, learned…

It's not, but it really has come a far way and I'm extremely impressed. I'm kind of the other way around, I've never been more than a very casual gamer and I'm simply not interested in keeping a separate Windows pc or dual boot install for games. If I can't get it working on Linux I'm not bothering with it. Right now I can play any game I want to play with very minimal tinkering (that probably says more about me than the state of Wine/Proton, but still).

Re: Fixing stutters in Papers Please on Linux

#126

Post by slavik81 »

CyberRabbi wrote: post #120
loeg wrote: post #115

Earlier quoted context omitted.

> Today the issue was close() just happened to be too “slow.” If the amount of input devices were higher, let’s say 2x more, then the same issue would have manifested even if close() were 2x “faster.” No matter how fast you make close() there is a situation in which this issue would manifest itself. Close, on an fd for which no asynchronous IO has occurred, should be 10000x faster, or more. It’s unlikely a user will…

> I agree the algorithm leaves something to be desired, but the only reason it is user-visible is the performance bug in Linux. The only reason it wasn’t user-visible was luck. Robust applications don’t depend on luck. Something tells me you’ll think twice before calling close() in a time-sensitive context in your future performance engineering endeavors. That’s because both you and I now know that no implementation…

There's no guarantee for the runtime of any function. It's perfectly valid for the OS to swap your program instructions to disk, and then take seconds or even minutes to load it back.

It's effectively impossible to avoid depending on what you call "luck". The OS does not provide nearly enough guarantees to build useful interactive applications without also depending on other reasonable performance expectations.

Re: Fixing stutters in Papers Please on Linux

#127

Post by badsectoracula »

spijdar wrote: post #111
facorreia wrote: post #100

This reminds me of the recent Linus Tech Tips series on gaming on Linux[1]. Their conclusion is that although many games work out of the box (although usually not at launch), Linux is not ready for mainstream gamers. Not many people would have the expertise or the interest to troubleshoot the problem as OP did. [1] https://www.youtube.com/watch?v=Rlg4K16ujFw

It definitely isn't. I've been a huge linux nerd since my preteens in the late 2000s, I jumped on to squeeze more performance out of the thoroughly mediocre hardware I had access to. I wanted to program, and I found Visual Studio to be incomprehensibly dense and confusing, while Linux tools were so much simpler, with GCC, GEdit, makefiles and the like being more to my liking. I fell deep into the rabbit hole, learned…

I disagree, in my experience with the recent improvements to Wine, drivers, etc, if you have a bit of Linux knowledge you can get games work just as fine in Windows - with the possible exception of games that use anticheat malware (because frankly, software that relies on kernel-level hacks, etc is basically malware). Though personally i stick with SP games anyway.

Also...

> Like Linus says in that video, when I have time to play video games, I really don't want to pull out a debugger

...Linus is most likely blind to all the issues he may have to get games to work under Windows because he's used to them. I've been playing games on Windows for decades and it was never a plug-and-play experience (...or it was, if you consider the original PnP experience back in the 90s :-P). If games worked perfectly under Windows you wouldn't have sites like pcgamingwiki.

Hell, i remember buying Tomb Raider 2013 back when it was new and having to trace through its registry calls on Windows to get it to work properly because its launcher was broken on my PC at the time. Incidentally that was supposed to be my relaxation time when i went home after work.

(of course i do not expect Linus -or most people- to do the same, they'd most likely just drop it for some other game and wait for a fix - but i had just bought the game and i wanted to play it right then)

In my experience it is rare to have a PC game on Windows play right away without any issues. If anything when it comes to slightly older games on Windows i had to use wrappers like DXVK to get games working properly due to the broken AMD Windows drivers.

At the past i might have written here that if you want a problem-free experience stick with consoles, but judging from videos i see from channels like DigitalFoundry, it seems consoles have a ton of issues nowadays too (it isn't common but i found it amusing that some people seem to jailbreak their Switches to make games work better :-P). And these come with their own issues anyway, personally i wouldn't touch any locked down DRM riddled system anyway.

Re: Fixing stutters in Papers Please on Linux

#128

Post by spijdar »

CorrectHorseBat wrote: post #125
spijdar wrote: post #111

Earlier quoted context omitted.

It definitely isn't. I've been a huge linux nerd since my preteens in the late 2000s, I jumped on to squeeze more performance out of the thoroughly mediocre hardware I had access to. I wanted to program, and I found Visual Studio to be incomprehensibly dense and confusing, while Linux tools were so much simpler, with GCC, GEdit, makefiles and the like being more to my liking. I fell deep into the rabbit hole, learned…

It's not, but it really has come a far way and I'm extremely impressed. I'm kind of the other way around, I've never been more than a very casual gamer and I'm simply not interested in keeping a separate Windows pc or dual boot install for games. If I can't get it working on Linux I'm not bothering with it. Right now I can play any game I want to play with very minimal tinkering (that probably says more about me than…

Linux has absolutely come very far, don't get me wrong!

I'm also mostly a casual gamer, and only have my "dedicated gaming PC" because it's 7 year old hardware I've replaced with a dedicated "workstation" I bought after getting a job and saving some money.

On all my other hardware, I just run Linux, and I pretty much do the same as you -- most of my games work fine on Linux, a surprising number natively!

Linus brought this up in his video as well, that if you don't really care which games you play, you'll be fine. The problem is there are a few games I like playing or like to play with my local friend circle that just don't work well on Linux.

The problems are really stupid, too, and often not the fault of Linux per se. Garbage like Elder Scrolls Online still relying on a TLS cert signed by a CA that's been almost universally revoked, so the launcher will silently hang on linux. Bypassing this relies on either adding the (revoked for security reasons) CAs to your system's trust chain, or man-in-the-middleing the game process to force the updates regardless of the cert problems.

It's not like I really care that much about this specific game, but it's nice to play every now and again with friends. Maybe my long rambly point is, if you primarily use Linux for other reasons and occasionally play games with it, it's awesome. But if you're the average "PC gamer" whose computer is primarily for gaming, Linux will probably disappoint you.

Re: Fixing stutters in Papers Please on Linux

#129

Post by wildrhythms »

spijdar wrote: post #111
facorreia wrote: post #100

This reminds me of the recent Linus Tech Tips series on gaming on Linux[1]. Their conclusion is that although many games work out of the box (although usually not at launch), Linux is not ready for mainstream gamers. Not many people would have the expertise or the interest to troubleshoot the problem as OP did. [1] https://www.youtube.com/watch?v=Rlg4K16ujFw

It definitely isn't. I've been a huge linux nerd since my preteens in the late 2000s, I jumped on to squeeze more performance out of the thoroughly mediocre hardware I had access to. I wanted to program, and I found Visual Studio to be incomprehensibly dense and confusing, while Linux tools were so much simpler, with GCC, GEdit, makefiles and the like being more to my liking. I fell deep into the rabbit hole, learned…

Have you tried Steam's Proton compatibility layer yet? I was surprised to find many (not all) games in my library running with near 1:1 performance and stability to Windows.

Re: Fixing stutters in Papers Please on Linux

#130

Post by infogulch »

CyberRabbi wrote: post #72
touisteur wrote: post #63

Earlier quoted context omitted.

Or, io_uring the thing. One could probably wrap close() with LD_PRELOAD and not touch the binary...

While tempting, you can’t generally fix this by simply patching close() with some function that converts it to an unchecked asynchronous operation. If that were the case, you could just do that in the kernel. Close() is expected to complete synchronously. This matters because posix guarantees that open()/pipe() etc. will return the lowest file descriptor not in use[1]. I.e. this should work: close(0); fd = open(“/foo…

I did not know this, and for some reason it really annoys me. Why are our process contexts littered with useless little synchronous properties? How many other tedious and slow bookkeeping tasks does the OS have to do just to meet some outdated spec that was probably just an ossified implementation detail in the first place? I feel compelled to make it so that new fds are explicitly randomized just so you can't do this, like how Go randomizes map iteration order.
Post reply on HN