Hacker News Reader

Comment by dmytroi | Hacker News Reader

Using heap as sole savior of stackless coroutines just doesn't scale. I'm working on a game engine, we can have 10-100k+ jobs running per frame, modern monitors have refresh rates of 144/240/300 Hz, so worst case: 30 million jobs per seconds! There is no time for heap - is just too slow.

So we need to preallocate everything for all systems, but hey, if you preallocate everything for worst case - you are out of RAM (on PS4/Xbox/etc).

What we need is a mix: scratchpad memory that lives longer than stack, but costs as cheap as stack. Tagged heap with stack/arena allocator comes close performance wise but not ergonomics wise.

Ergonomics of writing code with such constrains is very painful. Stack is the most ergonomical/fastest scratchpad you can have, and as soon as you have async/await/etc in a middle of your function - you need to think about unwind/rewind of every stack variable.

View on HN

Ah, thanks, so is the problem cache misses?

Java had to rewrite the memory model of the whole JVM when they introduced the concurrent package.

Even C++ has a hard time making good use of concurrency and threads because of locking.

My hunch is that because of the way memory works there is no benefit for non GC languages when implementing threads and concurrent memory over many cores.

> My hunch is that because of the way memory works there is no benefit for non GC languages when implementing threads and concurrent memory over many cores.

I've been pretty happy with Rust on multi-core servers, probably because Rust never allows mutable memory to be seen by more than one function.

I've been using async Rust at work, which turns out to particularly interesting, because most of the async executors for Rust can actually move suspended async functions between cores. So you might have dozens and dozens of async routines running across an 8 CPU pool.

There was definitely a bit of a learning curve involved, but we've only ever encountered a single concurrency-related bug, which was a deadlock. (Rust protects against memory corruption, undefined behavior and data races, but not deadlocks.)

Ok, but when you say that they can move between cores, isn't that the OS moving them?

If rust does not allow concurrent memory reads, then that's a big problem in my world.

It seems to me we have a collision between "data driven" and "parallelism on the same memory" in terms of progressing on performance and in that case since I can get parallelism with memory and execution safety with hot-deployment on a VM; the data driven approach does not fit my server side performance needs to the point where I'm able to give those other features up.

On the client, I'm all for C with arrays though.

Disclaimer: I've done some reading on Rust's concepts but not yet done any substantial coding. Corrections welcome :)

I'm not informed enough to comment on how async works exactly in Rust. However:

> If rust does not allow concurrent memory reads, then that's a big problem in my world.

Note that this is not the goal of the borrow checking system of Rust. You can read memory concurrently just fine (given immutable references to something), you're just not allowed to write to it while you're doing that.

Basically, references in Rust come as immutable (like `const` in C) and mutable, and you're only allowed to have multiple immutable or one mutable reference to the same thing at a time. If you have a mutable reference, you can derive multiple immutable ones from that, but the borrow checker will prevent you from accessing the mutable reference as long as one of the immutable ones is still active (which Rust manages with the concept of "lifetimes").

Reply on news.ycombinator.com