> at 144 Hz it's still 14% of your frame time, so it's hardly negligible
A single skipped frame is not a big deal and will probably not be noticed. It will probably happen anyway due to scheduling quirks, resource contention with other processes, existing variation in frametime...
True realtime work requires no dynamic allocations whatsoever (which, notably, is not covariant with gc!), so I think ‘low’ pause times are an acceptable compromise. Where performance is a concern, you need to manually manage a lot of factors, among them GC/dynamic memory use. There's no runtime that can obviate that.
Granted, 1ms pause times are probably still not low enough for realtime audio, and there may be room for some carelessness there (audio being soft realtime, not hard realtime). But I think just being careful to avoid dynamic allocation on the audio thread is probably a worthwhile tradeoff.
A constant frame interval is better than occasional skipped frames. You don't need a super high frame rate for perceived smooth motion, but dropped frames look like stutter.
Stutter is becoming much less of a factor with variable refresh rate display technology. Modern consoles, TVs, and many monitors are being built with VRR these days, and in a few years it will probably be ubiquitous.
Unless you have a highly optimized game, you are probably not able to consistently run at a 144 Hz monitor’s native refresh rate anyway, so even without skipping frames you will see stuttering. VRR solves this problem as well.
I'm not sure if you and GP share the same notion of stutter or not. I never saw stutters when limiting the game at 24 or 30 fps while playing on a 60 Hz LCD monitor in the past. It stutters only when the fps is not constant.
VRR makes that kind of stutter essentially irrelevant, as the penalty for missing the refresh interval is basically zero. They don’t really drop frames, it’ll be displayed as soon as it’s done, so the frame will only delay for however late it actually is, instead of waiting a whole 1/60th of a second for the next refresh
Of course, we’re generally talking about much higher refresh rates, at least 120 if not more.
My display runs at 165hx and you’d be surprised how many games could hit that a lot of the time... even on my old 1080 (and certainly on the 3080 I have now).
The most frequent issue I run in to is actually games having hard FPS caps (120 typically, sometimes 150) and refusing to actually max it out.
Is that measured somewhere / have you got a reference? In my experience 120hz dropping frames (or more precisely rendering at 100 +/- 10fps) looks much smoother and nicer than constant 60 or 30fps.
Sure, yes. I was referring more to ‘general-purpose dynamic allocator’ (malloc or so). I agree custom memory management/reclamation techniques can be fine for RT; just semantics.
> A single skipped frame is not a big deal and will probably not be noticed.
Attitudes like this are why my phone sucks to use and I get nauseous in VR and GC devs spent so long in denial saying 10 ms pause times should be good enough. Yes, single dropped frames matter. If you don't think so then I don't want to use your software.
A single skipped frame usually means that we are talking about soft real time. And there it is absolutely acceptable, not in the average case, but eg. on a heavily used computer a slight drop in audio is “appropriate”, it’s not an anti-missile device.
It won’t make the normal case jittery, nauseus or anything like that. Also, in regards to your GC devs comment, I would say that attitudes like this is the problem.. The great majority of programs can do with much more than 10 ms pause times.
You're bringing up a specific professional use case in a general-purpose discussion. If you run concerts on anything other than dedicated hardware and software, you're going to have a bad time. If you record at home without low-latency devices and soft-rt software, you're going to have a bad time.
It's in the same category as "the performance of stock Camry is unacceptable for racing" - yes, plan accordingly when entering a race :-)
A single skipped frame is not a big deal and will probably not be noticed. It will probably happen anyway due to scheduling quirks, resource contention with other processes, existing variation in frametime...
True realtime work requires no dynamic allocations whatsoever (which, notably, is not covariant with gc!), so I think ‘low’ pause times are an acceptable compromise. Where performance is a concern, you need to manually manage a lot of factors, among them GC/dynamic memory use. There's no runtime that can obviate that.
Granted, 1ms pause times are probably still not low enough for realtime audio, and there may be room for some carelessness there (audio being soft realtime, not hard realtime). But I think just being careful to avoid dynamic allocation on the audio thread is probably a worthwhile tradeoff.