> I don’t see the average garbage-collected language using a virtual machine allowing for a target higher than 60fps realistically. But... " average garbage-collected language using a virtual machine" doesn't describe any of C/C++, Dart, Go, Java, Python, or Rust. Nor Javascript. I get greater than 60 fps with my existing Vive three.js WebVR-ish electron/chromium linux stack. Even on an old laptop with integrated gra…
Some people seem to have skimmed over the discussions about the pros and cons of garbage collection and come away with the idea that all garbage collected languages function by stopping the world for 50-100 millisecond pauses four or five times per second, minimum. There are real performance issues that GC can create, but there's a looooooot of vigorous overstating of the issues. Slightly in those people's defense, i…
In a manually managed language, the performance of the application's memory management code is limited by the skill of the application developer. In a managed language, it's limited by the skill of the GC developer.
GCs have gotten a lot better in the past twenty years, in large part because they have the luxury of amortizing their work across a million applications. That makes it financially viable to throw a ton of person-years at your GC. That's not the case for the malloc()s and free()s in a single application.
So just through economies of scale, we should expect to see, and indeed have seen, managed languages catch up the the memory performance of the average manually managed app.