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

The Rust standard library no longer has any scheduling baked into it

mail.mozilla.org

Post reply on HN
Print view View original

51–60 of 71 posts

Re: The Rust standard library no longer has any scheduling baked into it

#51

Post by pron »

mtanski wrote: post #50
pron wrote: post #40

Earlier quoted context omitted.

Video: https://www.youtube.com/watch?v=KXuZi9aeGTw Slides: http://www.linuxplumbersconf.org/2013/ocw//system/presentati...

Thanks for providing the link and it does seam like an interesting proposal. To summarize: Switching into ring0 (kernel is not that expensive) We're going to stay with the 1:1 thread model We're going to provide an new syscall to hint to the scheduler which thread to switch to. Provided we have time slice still left the scheduler can do that almost instantly since picking the task to run next is expensive (their data…

> This doesn't do anything about block IO.

I'm not too familiar with the details but I think they mention that a thread can specify a callback that will be called if it blocks on IO, and the callback can specify another thread to switch to.

Re: The Rust standard library no longer has any scheduling baked into it

#52

Post by mtanski »

pron wrote: post #36
mtanski wrote: post #4

I've also have come full circle on N:M / green threads. Now I'm back to thinking they aren't worth the effort / pain. My experience comes from C / C++ land and not Go and Rust but I think same lessons apply. In experience I ended up using a few different framework from libcoro to Mordor to raw swapcontext(). I was initially sold on the N:M model as a means of having event driven programming without the callback hell.…

Here's my experience developing a JVM lightweight thread library[1]: 1. For the scheduler, we use the JDK's superb and battle-tested ForkJoinPool (developed by Doug Lea), which is an excellent work-stealing scheduler, and continues to improve with every release. 2. For synchronization, we've adapted java.util.concurrent's constructs (we use the same interfaces so no change to user code) to respect fibers, but users a…

pron,

I saw your Quasar library before and while I hadn't had the chance to use I'm excited to try it the next time I need to write event code in the JVM.

As far as the disk IO is concerned the Java APIs are only as good as the underlying OS interfaces. And, those are not that great.

I think you're spot on with the assertion that a mostly network bound workloads can benefit from N:M scheduling. Many of the apps that we build nowadays are exactly that.

Re: The Rust standard library no longer has any scheduling baked into it

#53

Post by reginaldjcooper »

pron wrote: post #36
mtanski wrote: post #4

I've also have come full circle on N:M / green threads. Now I'm back to thinking they aren't worth the effort / pain. My experience comes from C / C++ land and not Go and Rust but I think same lessons apply. In experience I ended up using a few different framework from libcoro to Mordor to raw swapcontext(). I was initially sold on the N:M model as a means of having event driven programming without the callback hell.…

Here's my experience developing a JVM lightweight thread library[1]: 1. For the scheduler, we use the JDK's superb and battle-tested ForkJoinPool (developed by Doug Lea), which is an excellent work-stealing scheduler, and continues to improve with every release. 2. For synchronization, we've adapted java.util.concurrent's constructs (we use the same interfaces so no change to user code) to respect fibers, but users a…

That is really interesting. If it's not too much trouble to write out, could you explain what causes the latency difference between kernel wake-up and other thread wake-up?

Re: The Rust standard library no longer has any scheduling baked into it

#54

Post by pron »

reginaldjcooper wrote: post #53
pron wrote: post #36

Earlier quoted context omitted.

Here's my experience developing a JVM lightweight thread library[1]: 1. For the scheduler, we use the JDK's superb and battle-tested ForkJoinPool (developed by Doug Lea), which is an excellent work-stealing scheduler, and continues to improve with every release. 2. For synchronization, we've adapted java.util.concurrent's constructs (we use the same interfaces so no change to user code) to respect fibers, but users a…

That is really interesting. If it's not too much trouble to write out, could you explain what causes the latency difference between kernel wake-up and other thread wake-up?

I honestly don't know :) I was simply reporting my results experimenting with this (I'll try to write a blog post about it some time in the near future), so I'll defer to those with a deeper knowledge of the Linux kernel.

I have read that the Linux scheduler exploits some heuristics if it can guess how soon a blocked thread will need to be woken up, so this might have something to do with that.

Re: The Rust standard library no longer has any scheduling baked into it

#55

Post by reginaldjcooper »

pron wrote: post #54
reginaldjcooper wrote: post #53

Earlier quoted context omitted.

That is really interesting. If it's not too much trouble to write out, could you explain what causes the latency difference between kernel wake-up and other thread wake-up?

I honestly don't know :) I was simply reporting my results experimenting with this (I'll try to write a blog post about it some time in the near future), so I'll defer to those with a deeper knowledge of the Linux kernel. I have read that the Linux scheduler exploits some heuristics if it can guess how soon a blocked thread will need to be woken up, so this might have something to do with that.

I was worried it might be an empirical result :) thanks for responding, though, and I'd love to see the post when it's finished

Re: The Rust standard library no longer has any scheduling baked into it

#56

Post by mcguire »

qznc wrote: post #39
bsdetector wrote: post #6

Earlier quoted context omitted.

Half a year ago: "I wouldn't be surprised to see Rust at least abandon M:N soon though once they start really optimizing performance." With Rust I'm sure they'll drop M:N, if not now then eventually, like essentially everybody else in CS history . It seems great on a superficial level, but when you really start caring about performance and latency and fairness it's the pits. My question is when Go will drop it. Imagi…

I consider 64bit machines the final nail in the coffin of N:M for next decade. Since you can spawn millions of kernel threads the argument of easier-than-callbacks in favor of N:M disappears.

In practice, though, I've never seen a situation with a single server running more than a thousand kernel threads end well.

My experience may be limited, though.

Re: The Rust standard library no longer has any scheduling baked into it

#57

Post by jlouis »

qznc wrote: post #34
EvanMiller wrote: post #21

Earlier quoted context omitted.

The Erlang VM is a successful implementation of N:M. It addresses some but not all of the issues you mentioned. * IIRC each new process consumes 284 bytes so it's not "spending lots of memory on creating stacks for your green threads" * Synchronization is a non-issue as everything is message-passing. * Disk I/O is blocking, but the VM has dedicated disk threads. * Dealing with 3rd party code is a problem, which is wh…

C integration is the killer for N:M threading. C libraries do blocking IO, are not wrapped into a VM, are not compiled for segmented stacks, use thread-local storage, etc. You can work around this problems, which increases complexity. For close C integration, you are basically forced to adopt Cs view of threading.

This is why the R17 release of Erlang might get "dirty schedulers" for this kind of work. Essentially it gives you background thread pools where such work can be carried out.

Currently, you can call C functions directly, but it is not meant for long-running tasks which can block and so on.

Re: The Rust standard library no longer has any scheduling baked into it

#58

Post by jlouis »

pcwalton wrote: post #14
jerf wrote: post #11

Earlier quoted context omitted.

"I don't know Erlang's stance on this." Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. Not only that it isn't "stop the world" but that it's also fairly tr…

> Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. This is the same as Rust.

I don't think so. If Rust has a single large shared heap for all proceses, then the approach is different. Rust can avoid GC and it can also implement proper incremental GC. But none of those things are as trivial as in Erlang, where you can use stop-the-world GCs and still avoid pause times.

Re: The Rust standard library no longer has any scheduling baked into it

#59

Post by jlouis »

qznc wrote: post #39
bsdetector wrote: post #6

Earlier quoted context omitted.

Half a year ago: "I wouldn't be surprised to see Rust at least abandon M:N soon though once they start really optimizing performance." With Rust I'm sure they'll drop M:N, if not now then eventually, like essentially everybody else in CS history . It seems great on a superficial level, but when you really start caring about performance and latency and fairness it's the pits. My question is when Go will drop it. Imagi…

I consider 64bit machines the final nail in the coffin of N:M for next decade. Since you can spawn millions of kernel threads the argument of easier-than-callbacks in favor of N:M disappears.

The problem with kernel threads are they require kernel context. This is usually at least 4-8 kilobytes of memory. Which is about 8-16 times as much as an Erlang process...

Re: The Rust standard library no longer has any scheduling baked into it

#60

Post by pcwalton »

jlouis wrote: post #58
pcwalton wrote: post #14

Earlier quoted context omitted.

> Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. This is the same as Rust.

I don't think so. If Rust has a single large shared heap for all proceses, then the approach is different. Rust can avoid GC and it can also implement proper incremental GC. But none of those things are as trivial as in Erlang, where you can use stop-the-world GCs and still avoid pause times.

> If Rust has a single large shared heap for all proceses, then the approach is different.

Rust does not use one shared heap. Tasks cannot share memory (except through ARCs, which manage their own memory through atomic reference counting and so avoid garbage collection pauses). Garbage collection is completely local to a task, so while one task is collecting garbage other tasks are free to run.

Post reply on HN