As an aside, thanks for your efforts. Adding a new GC is a major effort, which improves things for all of us! :D
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.
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.
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!
Do you have a git repo i can star and check back for updates ?
Are you developing on Linux or MacOSX ?
I'm keeping a list of awesome lfe projects , even if you make it to a 'demo' stage, I'd love to list it, please consider letting me know.
I will let you know. It's extra motivation to me too! Someone else is interested!
Also problems with GC basically don't exist when running Erlang/LFE code, at least you have to put a lot of effort into getting problems with GC. A lot! And, of course, the BEAM does automatic load balancing over multiple cores which is another problem gone away. We never have to think about the class of problems like "I have my system set up to run on 2 cores, how should I modify it to run on 4?".
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 :).