
The state of the Rust Runtime - adamnemecek
https://docs.google.com/presentation/d/1oB3hwBByGNcgst-X0SSmRyu-uMfayeySNAJdkwwtB9Q/edit?pli=1#slide=id.p
======
cpeterso
Alex Chricton presented these slides at a Rust meetup in December 2013. A
video of the presentations is available:

[https://air.mozilla.org/rust-meetup-
december-2013/](https://air.mozilla.org/rust-meetup-december-2013/)

~~~
vanderZwan
Is there a way to download this? It won't buffer properly for me for some
reason.

(EDIT: Also, I don't know who made that video interface, but a "HD" button
where clicking does not make it obvious whether or not you set or unset the HD
option and have to wait for the video to load or not is pretty terrible)

~~~
cpeterso
I like to watch the Air Mozilla videos offline, so open Firefox's Web Console,
play the video, then copy the webm URL from the console log. :)

For this particular video:

    
    
      wget https://d3fenhwk93s16g.cloudfront.net/9r2j9t/webm.webm

------
derekchiang
It might be worth noting that both PRs described in the slides have already
been merged.

Links to the PRs (the discussions are worth a read):

1\.
[https://github.com/mozilla/rust/pull/10830](https://github.com/mozilla/rust/pull/10830)

2\.
[https://github.com/mozilla/rust/pull/10965](https://github.com/mozilla/rust/pull/10965)

------
dded
This looks like it would be interesting--if I only had a clue as to what it's
talking about.

Can someone explain to a hw guy what 1:1 is, and M:N, and green threads, etc.?
And why and when you would want to use one verses the other?

~~~
cwp
Tasks are Rust's unit of concurrency. There are two models for scheduling
tasks. 1:1 means that each task runs in it's own operating system thread, and
the OS is responsible for scheduling. M:N means that M tasks run on N threads
Typically, N is roughly one per core, and M is greater than N. The runtime is
responsible for assigning tasks to threads and scheduling multiple tasks on a
thread. "Green threads" is a term from the Java world, and it means M:N, often
with N=1, regardless of how many cores are available.

The motivation for M:N is that OS threads tend to be fairly heavy in terms of
memory usage, scheduling overhead etc. For a language that intended to enable
highly concurrent programs, it's theoretically more efficient to use one OS
thread per CPU to get maximum parallelism and layer the units of concurrency
(tasks in this case), on top of that.

The thing is, doing M:N well enough to actually achieve the theoretical gains
is difficult, and there are many cases of projects that started with M:N and
eventually ditched it and moved to 1:1.

(Edit for clarity on green threads.)

~~~
dded
Does M:N imply shared memory for all tasks on a thread?

~~~
yepguy
No, not necessarily. Rust does not allow shared memory between tasks, but Go
does, for example.

~~~
dbaupp
This is entirely wrong. You can easily pass a raw pointer (I.e. same semantics
as a C pointer) between tasks and use this to unsafely share memory (I.e. risk
of data races), or you can use one of the safe higher level wrappers in
extra::arc, that is, Arc for immutable shared memory, or RWArc or MutexArc for
lock-protected mutable shared memory.

~~~
chrismorgan
It's still worth while noting that Rust’s _modus operandi_ eschews shared
memory; to get shared memory between tasks, you've got to be fairly explicit
about it.

------
moomin
I'm curious as to what the perf figures would be for windows. My gut tells me
threads are relatively more expensive and async relatively cheaper than on
Linux.

