For what value of "as possible?" It's kind of a miracle that twitch game mechanics FPS work at all with typical Internet latencies, which is one of the various reasons why I'm not doing that. "As possible" in my situation, doesn't include the resources to do that.
I wish Go could use RAII or another memory scheme so they could drop GC altogether.
There's always Rust. Also, Erlang can "cheat" at GC in some ways due to immutability. Server side Swift has potential as well.
Additionally, Erlang can also make "soft real-time" guarantees because each actor has its own heap, and consequently each actor is GC'd separately.
Really depends on the use case. Obviously "real-time" in a money context is very different than gaming. For gaming GO will probably be fine but that's also depending on how the game can scale.
> There's always Rust.
I've heard good things about rust though C++ is also pretty fantastic but I guess it's not as popular anymore.
This lets you take garbage off the heap, and avoid GC all together if you want to.
I believe Go does escape analysis so you can still shuffle around pointers to local structs within a stack frame without causing a heap allocation.
edit: That being said you can't really implement something like refcounting for structs you pass around by pointer outside the local stack frame without the compiler emitting an allocation on the heap. To totally avoid using the GC you'll need to do a lot of copying. And there aren't destructors.
I guess dropping a single frame on occasion may not be that bad, and the GC parameters could be retuned (and other GC languages have lower latency), and you could minimize the amount of garbage created, but still, that's not a good situation to be in.
A good strategy for handling this in a GC'd language is using the factory / pool patterns, so during level loading you instantiate 100 "empty" projectile entities that you can re-use. When a projectile is "fired" you request a Projectile from the ProjectilePool, add its initial position/speed/whatever, then add it to the world. It goes through its trajectory, maybe hits a wall, and then you release it back to the ProjectilePool where it is cleared and can be re-used later.
But what if you need 101 projectiles...?
Of course, AAA game engines today will employ custom low-level allocation strategies in order to squeeze out the last few percentage points where they deal with dynamic data - but if your aims are more modest, and you harken back to 80's era gaming, most of those games had a nearly or entirely static memory map. Besides being a poor fit for those tiny microprocessors, dynamic allocation enables out-of-memory and fragmentation errors to exist, leading us back to the "hard limits on instancing" strategy again.
GC still incurs overhead where it has to trace, even if you've pooled everything. Reference counting pulls ahead of tracing collectors in the situation of heavy object persistence, despite being more expensive as a general allocation method. As well, it has predictable latency, which is more important for meeting real-time requirements.
(N.B. as systems parallelize, they become more bound by latency considerations. Seven workers may finish early, but delivery will still get bottlenecked by the eighth slow one.)
Just guessing =P
Watching you "manual memory all the way" dudes struggle with simple concurrency as much as you do, I'd hate to throw away a GC just for that extra teeny bit of performance.
extern crate threadpool;
use threadpool::ScopedPool;
fn main() {
let mut numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
{
let pool = ScopedPool::new(4);
for x in &mut numbers[..] {
pool.execute(move || {
*x += 1;
});
}
}
println!("{:?}", numbers);
}
error: cannot borrow `numbers` as immutable because it is also borrowed as
mutable
println!("{:?}", numbers);
^~~~~~~
note: previous borrow of `numbers` occurs here; the mutable borrow prevents
subsequent moves, borrows, or modification of `numbers` until the borrow
ends
for x in &mut numbers[..] {
^~~~~~~
note: previous borrow ends here
fn main() {
}
^
As you can see from the `extern crate`, this pool isn't a compiler built-in: it's a library. There's actually a secondary implementation of a threadpool that makes some different choices internally. But this kind of safety can be gained in whatever concurrent code you're writing, and you can write new concurrent abstractions and ensure that they don't have data races.
I think you may have missed the part where I mentioned RAII. It's a lovely scheme in C++ and a handful of other languages. You can get away from manually managing memory entirely in C++14.
- A 10GB heap with one single heap-allocated []byte will have short <1ms pauses.
- A 512MB heap with 500k heap-allocated []byte will have long pauses.