I understand how it happened, but it’s unsettling to see all of this work put in just for the outcome to be “performance is only a little bit worse now”. The details about why that happened were very interesting!
I don’t think it’s a fair assessment. OCaml got much closer to making the new parallel GC runtime as fast as the original single-threaded one than anyone else.
CPython added --disable-gil build option past October, as per PEP-0703. The multi-threaded GC is not generational, and it’s not certain that it’s even safe yet, which is why it’s a compile-time option.
Semgrep hit an edge case and managed to get the memory performance back just by doing GC tweaks (which have been the staple of GC-ed language programming everywhere from the start, if anything). The post doesn’t touch on the improvements from built-in parallelism support or anything else, too.
I understand how it happened, but it’s unsettling to see all of this work put in just for the outcome to be “performance is only a little bit worse now”. The details about why that happened were very interesting!
I don’t think it’s a fair assessment. OCaml got much closer to making the new parallel GC runtime as fast as the original single-threaded one than anyone else.
Haskell still requires linking with the threaded runtime and defaults to the single-threaded one.
CPython added
--disable-gilbuild option past October, as per PEP-0703. The multi-threaded GC is not generational, and it’s not certain that it’s even safe yet, which is why it’s a compile-time option.Semgrep hit an edge case and managed to get the memory performance back just by doing GC tweaks (which have been the staple of GC-ed language programming everywhere from the start, if anything). The post doesn’t touch on the improvements from built-in parallelism support or anything else, too.