Does this have much effect on Kandria’s latency results? Shirakumo tries to put a positive spin on things, but her results show that SBCL’s existing GC isn’t up to the task for real-time games (or many networked apps, for that matter).
As an aside, thanks for your efforts. Adding a new GC is a major effort, which improves things for all of us! :D
I have yet to benchmark it again; my setup was sloppy as I had to run the same part of the game over and over, because record/replay didn't work. (Nor do I have the time and energy now; have to survive the last semester of university now.) But I suspect it should help, by reducing the sweeping and scavenging times which were pretty bad.
I'm not sure I agree with the comment about "up to the task for real-time games", but maybe my standards are low for video games, and I have an abnormally fast machine and am likely biased there too.
Rightly or wrongly, 60fps is becoming what 30fps used to be, and gamers can tell the difference (as can normal people with VR). It is what it is.
This latency problem is why I’m dabbling with raylib and LFE of all things. The BEAM cannot hold a candle to SBCL for performance code, but the GC latency can be managed better.
Anyway, I don’t want to go on a tangent, since I really appreciate your efforts; there are plenty of domains that the new SBCL GC will be a big deal for.
I wish I had anything interesting to say. I'm currently experimenting with it to see if it's a useful approach to build a game that can sustain a solid 90fps.
Just pushing triangles isn't a problem (so far), but I'm still unclear how much of the engine logic will need to live in a low level language versus within LFE. The BEAM also presents certain architectural possibilities (especially for simulation), that are completely atypical for games.
It's promising enough that I'll continue pursuing this; we'll see where I end up in a few more months. Sorry I can't give more meat than that!
Can I ask a newbish question: will this new GC be available on all OS:s and CPU architectures, or only on some? I don't see anything in the paper about being limiting to some certain platform, so my hopes are high :).
It should be pretty portable, porting is just a matter of time and interest. The main thing is that the compiler needs to use a (more precise, lower overhead) software write barrier rather than using the (coarser, slower) hardware write barrier which was around the longest. I also have to wonder how well the bit-scanning algorithms fare on big-endian, or is that taking "all CPU architectures" too far?