The two different threading models have different costs/benifits. Native threads are much faster at context switching then green threads, however, native threads have a significant startup cost where as spawning green threads is nearly cost-free.
Native threads are natively supported by the OS, so managing them requires calls to the OS, the main reason why it's slow. However, it comes with a few advantages. The main advantage of native threads is that they are preemptive - they can be scheduled based on ticks (i.e. number of microseconds spent running the thread), even if they are in the middle of a loop. Also, they can be run on different CPUs, the OS takes care of all CPU flags/registers/etc., they are actual OS structures, ...
http://msdn.microsoft.com/en-us/library/windows/desktop/dd62...
http://www.linuxplumbersconf.org/2013/ocw/proposals/1653 https://www.youtube.com/watch?v=KXuZi9aeGTw
No, native threads have a much higher context switch overhead. The downside of green threads is the lack of parallelism, you can only use one CPU core. This is why decent languages multiplex green threads over OS threads (M:N). The mistake rust made was trying to make that distinction transparent.
Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not. On top of this, the whole stack is copied upon a context switch.
[1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.8.9...
>Some of the actual context switch in native threads is performed by the CPU, where as with green threads it is not
Exactly. Native threads have a context switch, green threads don't.