Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maybe Rust isn’t a good tool for massively concurrent, userspace software

bitbashing.io

Post reply on HN
Print view View original

621–624 of 624 posts

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#621

Post by nitwit005 »

pdimitar wrote: post #614
nitwit005 wrote: post #295

> Some problems demand a lot of concurrency. The canonical example, described by Dan Kagel as the C10K problem back in 1999, is a web server connected to tens of thousands of concurrent users. At this scale, threads won’t cut it—while they’re pretty cheap,5 fire up a thread per connection and your computer will grind to a halt. Try it. It'll probably work fine. It may be very expensive, memory wise, but it's easy to…

It's not just that. As you increase OS thread active count, each thread starts to respond slower and slower. It's been tried, periodically. Still sucks.

Write a little program that starts up 10k threads that just wait. The other tasks on the machine won't be any slower once they're set up.

Of course, if they're doing real work they'll be using CPU time, but that's true of any scheme you might pick.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#622

Post by pdimitar »

nitwit005 wrote: post #621
pdimitar wrote: post #614

Earlier quoted context omitted.

It's not just that. As you increase OS thread active count, each thread starts to respond slower and slower. It's been tried, periodically. Still sucks.

Write a little program that starts up 10k threads that just wait. The other tasks on the machine won't be any slower once they're set up. Of course, if they're doing real work they'll be using CPU time, but that's true of any scheme you might pick.

Obviously. My point is that spawning 10_000 "processes" (green threads / fibers, really) on the Erlang BEAM VM is almost not noticeable at all f.ex. in web server mode. Everything just gets a tiny little bit laggier but chugs along nicely. Same goes for Golang's goroutines, though not exactly to the same extent (the runtime does not tolerate as huge a number as easily as Erlang's runtime).

Whereas spawning native OS threads (not sure about the 10k number, could be even more with the good hardware these days) and having them all do stuff is gonna lag a whole lot more due to context switches.

So you know, apples to apples, but some apples are much better than others.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#623

Post by balencpp »

technojamin wrote: post #222
whoknowsidont wrote: post #202

Use Erlang/Elixir for orchestration and call into rust implementations. It's an amazing combination.

Elixir/Rust is the new Python/C++, and Rustler makes the communicating between the 2 languages super easy: https://github.com/rusterlium/rustler

Yup. I think it's because Elixir has powerful LISP-like meta-programming facilities that it allows the seamless communication Rustler and Zigler provide. I haven't seen anything as good as Rustler for Python despite its popularity.

Re: Maybe Rust isn’t a good tool for massively concurrent, userspace software

#624

Post by throw10920 »

kprotty wrote: post #583
throw10920 wrote: post #569

Earlier quoted context omitted.

Thank you for your explanation of the trade-space around preemptible coroutines, that greatly helped my understanding. I am still unclear on one thing: > The runtime being a library instead of a language/compiler level feature. Custom runtimes is necessary for systems languages as they can have specialized constraints. Compilers link against dynamic libraries all the time. What prevents the compiler from linking agai…

This would imply a single/global runtime along with an unrealistic API surface; For 1) It's common enough to have multiple runtimes in the same process, each setup possibly differently and running independently of each other. Often known as a "thread-per-core" architecture, this is the scheme used in apps focused on high IO perf like nginx, glommio, actix, etc. For 2) runtime (libasync.so) implementations would have…

I did some reading up on this, and found more detail about the "unrealistic API" surface (e.g. [1]), and I think I understand the problem at least as a surface level (and agree with the conclusions of the Rust team).

So then to tie this back to my earlier question - why does this make a difference between "async declared at function definition site" vs "async declared at function call site"?

Libraries have to be written against a specific async API (tokio vs async-std, to reference the linked Reddit thread) - that makes sense. But that doesn't change regardless of whether your code looks like `async fn foo() {...}` or `async foo();`. The compiler has ahead-of-time knowledge of both cases, as well...

[1] https://old.reddit.com/r/rust/comments/f10tcq/confusion_with...

Post reply on HN