I don’t think the GC is a showstopper IF you structure your code correctly. How can I say that when it’s known the GC has been problematic (in unusual cases) in the past? I think the problem has been fixed in 1.9, and more importantly you want to avoid the GC.
Some claim (rightly) that languages without GC (i.e. with reference counting) are better for hard real-time. Games are only soft-realtime and can handle GC, likely most games already have GC. But the games are split: a part (i.e. the game engine) is written in most certainly C++ (no GO), and another part (for sure a different process?) for game logic in e.g. C# (with GC). Even Python (that is CPython) is in some ways better than C# and Julia with reference counting, as more predictable (GC is on top of that for cycles), why Mojo keeps that aspect and will not go to full tracing GC.
BUT what you can do is structure code into two or more processes, the game engine in one with NO GC, and C# or whatever language with GC in another with game logic. Julia could replace C# there, but then only for game logic. Likely C#'s GC is better, so I’m not sure Julia’s would be good enough, but I think so for game logic process, for the other part Julia’s GC would be a problem, unless you basically disable it by not allocating, and then the game logic (Julia) part NEEDS to run in a different process. [Can people confirm more than one process actually used? Someone in the know, or simply a gamer could run their favorite game and see in the task manager if only on process started.] It’s sometimes not better to split into processes, but since you have only one master GC per process then I’m not sure it’s good with Julia’s current GC, until its GC algorithm is improved.
There ARE actually real-time GC algorithms available (e.g. in Java), but in Julia only generational. If I recall mmtk already has real-time GC, but I don’t recall what that project added to Julia.
There’s also, seemingly redundant efforts to improve the GC in Julia’s github.
Many PRs with “GC” label have been merged (recently for 1.9 or 1.10/master and 6 still open), e.g. I think this is relevant so I would develop games on 1.10/master:
- New option
--gcthreads to set how many threads will be used by the Garbage Collector ([#48600]). The default is set to N/2 where N is the amount of worker threads (--threads) used by Julia.
This one had “merge me” label (and “embarrising-bugfix” label, but no “GC” label), is on 1.9.1 backports: “Use gc alloc instead of alloc typed in lowering #48642”
This issue has been closed (so fixed I assume): v1.9 rc1 significant slowdown in garbage collection #49120
Total runtime for ´julia test.jl’ on my machine is
around 5 s for Julia 1.8
around 94 s for Julia 1.9
Other PRs may also be relevant to games, possibly this in 1.9:
Multi-threading changes
- Threads.@spawn now accepts an optional first argument: :default or :interactive. An interactive task desires low latency and implicitly agrees to be short duration or to yield frequently. Interactive tasks will run on interactive threads, if any are specified when Julia is started (#42302).
- Threads started outside the Julia runtime (e.g. from C or Java) can now become able to call into Julia code by calling jl_adopt_thread. This is done automatically when entering Julia code via cfunction or a @ccallable entry point. As a consequence, the number of threads can now change during execution (#46609).