Hacker News Reader

Comment by adastra22 | Hacker News Reader

A millisecond is an eternity. It is 1/3 of the entire time allocated to a frame update in a modern game.

Various GCs can go faster now too. JEP 376 talks about hundreds-of-microsecond work done in pause now that GC no longer has to scan the whole stack.

That said: 1ms? 1ms is getting into the sorts of latency the OS and hardware impose on your program no matter what it does. For example, on x86, a SMI can take 300us, or 1000us if you're unlucky. I've seen softirqs for shitty wifi chips take a hundred milliseconds! And God help you if you take a hard page fault:

You're worried about 1ms latencies, right? So you're mlock()ing all memory? Running RT threads pinned to cores? Carefully using PI and static priorities to avoid inversions? Avoiding blocking IO everywhere, not even for graphics page-flipping? Managing thermal headroom to avoid involuntary clock collapses? And it should go without saying, but I have to ask: you're running a PREEMPT_RT kernel, right?

No? You're not doing any of these things? Then why are you worried about 1ms in GC?

Yes, I am. That’s why I develop on a systems programming language, and why systems programming and GC are not compatible.

I think this is a situation where the term systems programming is too un- or ill-defined to be anything but a semantic argument in waiting. I am not particularly fond of the broader meaning systems programming has taken on but I understand it. As a term of art for developers systems programming now encompasses:

   - infrastructure development like Docker and Kubernetes
   - general utilities programming like grep, terminal emulators, compilers, etc
   - performance sensitive artifacts like OS kernels, video/audio codecs, hardware interaction layers

and more in common usage. Without some sort of communal understanding of the taxonomy of development areas discussing things like GC in systems programming becomes tedious and often prone to arguing past people due to conflicting understanding of terminology.

I do think there are genuinely ripe areas of research and development for performance and determinism sensitive memory management and subsequent outreach to make sure the potentially effected developers and language designers actually have a chance to evaluate any advancements. But it sure seems like it would take an act of ‘developer congress’ to make sure people were talking about the same things.

What are you describing as a frame update? I am trying to be as generous as possible to your comment and thereby assuming there is a disconnect between my understanding of ‘frame update’ and yours. Genuinely curious, because that term as I am familiar with it means the entire time allotted to generating and rendering a single frame for display. If that’s what you meant, you are asserting that a ‘modern game’ is typically running at 333 fps. I am typically using the term ‘modern game’ to describe newly releasing AAA games nearly all of which struggle on many hardware configurations to achieve a steady 60 fps (which is 16 ms per frame).

e-sport competitive games target either 128Hz or 320Hz update frequency. Two rules of thumb: first if you want to actually get 60Hz every frame (e.g. on a console where 1st party validation cares about this more), then you attempt 120Hz so jitter only brings you down to 60Hz. Second, a bit more than half of your time is spent doing other things. So the amount of time you actually have to spend on world-update and/or render logic is only about half of your allocated time to start with. That's two independent factors of two there. I would have targeted 90Hz to start with, which gets you to about 3ms of actual time per frame.

Game GCs are interesting because you know that the execution is structured like this and you know how much time you have left before you have to switch back to application code for the next frame/time step. There's interesting optimizations you can make around this and could almost completely avoid user-observable GC pauses.

Exactly. This is why Minecraft Java edition was such a disastrous flop.

They're talking about modern games running on screens with high refresh rates.

Reply on news.ycombinator.com