undefined | Better HN

0 pointssteveklabnik7y ago0 comments

You can think of a task as being a thread, but it has one single allocation that’s the exact possible stack size. No more, no less. This uses less memory than spinning up a thread with the default stack size. Yes, you could use the proper APIs and get the correct size too, but you have to figure that size out by hand for each thread. It just implicitly happens with tasks.

0 comments

arve07y ago

Default stack size for new threads is 2 MB, https://doc.rust-lang.org/std/thread/#stack-size. That means total_memory_usage = 2 MB * number_of_cores, which is not so much on modern hardware.

arve07y ago

...and of course you know that, being on the Rust core team, just adding the specifics (I did not know the numbers myself).

steveklabnikOP7y ago

Hm, maybe I misunderstand what you're getting at; you're talking about one thread per core, not one thread per unit of work? Sure, if you only have that few threads, then it's not that big of a difference, but if you want to spin up a few hundred thousand of them...

arve07y ago

> you're talking about one thread per core, not one thread per unit of work?

Yes, a thread pool, consisting of one thread per core/computing unit. The units of work are then scheduled between the threads. Units of work here being some kind of IO, e.g. servicing HTTP requests.

> but if you want to spin up a few hundred thousand of them...

Hm. Thought there was a limit for work that can be done concurrently by the CPU, based on the number of cores/hyper-threads available. Found this on threads and IO performance [1], it seems to make the same point.

What kind of work load is common to spread over so many threads (on the same machine)? Does the OS switch efficiently between hundred of threads on regular CPUs? Genuinely interested.

1: https://www.jstorimer.com/blogs/workingwithcode/7970125-how-...

2 more replies

hobofan7y ago

Huh, I didn't know that!

(I also misinterpreted the context as I read the top level comment as async vs a single thread with blocking code, but after rereading it that makes more sense.)

steveklabnikOP7y ago

It's all good; it's one of the things that's specific to our implementation. Other forms may or may not do this, but I'm pretty sure that it's novel to at least Rust, and maybe C++; there's some discussion that I think it can do this in some circumstances as well.

j / k navigate · click thread line to collapse

0 comments

arve07y ago

Default stack size for new threads is 2 MB, https://doc.rust-lang.org/std/thread/#stack-size. That means total_memory_usage = 2 MB * number_of_cores, which is not so much on modern hardware.

arve07y ago

...and of course you know that, being on the Rust core team, just adding the specifics (I did not know the numbers myself).

steveklabnikOP7y ago

arve07y ago

> you're talking about one thread per core, not one thread per unit of work?

Yes, a thread pool, consisting of one thread per core/computing unit. The units of work are then scheduled between the threads. Units of work here being some kind of IO, e.g. servicing HTTP requests.

> but if you want to spin up a few hundred thousand of them...

What kind of work load is common to spread over so many threads (on the same machine)? Does the OS switch efficiently between hundred of threads on regular CPUs? Genuinely interested.

1: https://www.jstorimer.com/blogs/workingwithcode/7970125-how-...

2 more replies

hobofan7y ago

Huh, I didn't know that!

(I also misinterpreted the context as I read the top level comment as async vs a single thread with blocking code, but after rereading it that makes more sense.)

steveklabnikOP7y ago

j / k navigate · click thread line to collapse