There's a bunch of caveats to that story. At one point (in one patch I recall) they got tired of passing around 3 floats separately for x, y, and z all the time, so they did what any reasonable programmer would do and created a "coordinate" structure.
This created one of the worst performing partches of the game ever, and they had to back all the way out. They ended up just passing the separate floats around again.
My takeaway is that GC doesn't have to be slow, it just imposes a bunch of new constraints on what can be fast.
The problem there is probably that Java cannot pass objects by value [1]. That incurs an additional layer of indirection when accessing the individual members of the struct, tanking performance.
That's not a necessity, though - you can use a GC in languages that allow you to control whether structs get allocated on the heap or on the stack, and then you don't have this issue. For example, in Go, structs can be allocated on the stack and passed by value, or they can be allocated on the heap and passed by reference, and this is under the control of the application programmer [2].
[1]: Actually, according to the Java spec, Java does not have pass-by-reference, and objects are always passed by value. However, that's just strange nomenclature - in Java parlance, "object" names the reference, not the actual range of memory on the heap.
[2]: The language spec does not guarantee this, so this is technically implementation-defined behavior. But then, there's really only one implementation of the Go compiler and runtime.
What do you mean? A 3D game with a dynamic environment doesn't sound like the best category for GC. Or do you just mean that it was a game that didn't write extreme performance optimizations.
There's a bunch of caveats to that story. At one point (in one patch I recall) they got tired of passing around 3 floats separately for x, y, and z all the time, so they did what any reasonable programmer would do and created a "coordinate" structure.
This created one of the worst performing partches of the game ever, and they had to back all the way out. They ended up just passing the separate floats around again.
My takeaway is that GC doesn't have to be slow, it just imposes a bunch of new constraints on what can be fast.
The problem there is probably that Java cannot pass objects by value [1]. That incurs an additional layer of indirection when accessing the individual members of the struct, tanking performance.
That's not a necessity, though - you can use a GC in languages that allow you to control whether structs get allocated on the heap or on the stack, and then you don't have this issue. For example, in Go, structs can be allocated on the stack and passed by value, or they can be allocated on the heap and passed by reference, and this is under the control of the application programmer [2].
[1]: Actually, according to the Java spec, Java does not have pass-by-reference, and objects are always passed by value. However, that's just strange nomenclature - in Java parlance, "object" names the reference, not the actual range of memory on the heap.
[2]: The language spec does not guarantee this, so this is technically implementation-defined behavior. But then, there's really only one implementation of the Go compiler and runtime.
Hopefully soon it will: https://openjdk.org/jeps/401
Go, GCCGO, TinyGo and TamaGo, at least.
Value types would solve that issue flawlessly.
That’s not the GC’s fault. If you wrote C++ code that malloced a vector object every time you wanted to create a new vector, it would be even worse.
That’s Java’s fault for not having value types (though that’s changing soon maybe).
Yeah but it’s a game category where is that’s viable
What do you mean? A 3D game with a dynamic environment doesn't sound like the best category for GC. Or do you just mean that it was a game that didn't write extreme performance optimizations.