Hacker News new | past | comments | ask | show | jobs | submit login

A select quote:

> Memory mapped I/O is also an incredibly important feature for I/O performance, and there's almost no reason to use traditional I/O on 64-bit. However, it's a no-go with M:N scheduling because the page faults block the thread.

This is more or less why Java switched to native threads a decade and a half ago. Although in that case, it was page faults from hitting swap rather than memory-mapped IO. And in both cases, compatibility with existing native code which makes blocking system calls was also a consideration. It's reassuring that Rust is following a path well-worn by other serious languages.

Now it's just a question of waiting for Go and Node to do the same.




Note, be very careful with "mmap is the fastest way to do IO". That's not true 90% of the time. mmap is the fastest way to do IO when the OS already has file contents in memory and it's more than a few pages so setup of mmap() call is cheaper than memcopying data from kernel space. However mmap is terrible for cold IO. The problem is that mmap is IO-by-sideeffect-of-pagefaults. One has to use madvise() very carefully to make sure that the OS reads useful parts of a file during a pagefault. mmap style of IO is also susceptible to access-pattern bugs, eg even the Linux toolchain gets it deadly wrong and ends up doing IO backwards: https://blog.mozilla.org/tglek/2010/05/27/startup-backward-c....

mmap is even worse on Windows. Windows has no madvise(), OSX equivalent is pathetic. OSX and Windows read mmaped files in bizzarely small chunks, etc.

mmap has the worst error-handling semantics of all IO methods. Linux gives you a super-hard-to-wrap SIGBUS, Windows forces use of slightly-less-horrific SEH http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...


Google has been pushing for performance improvements in native threads for a similar reason. If that's successful, I think the plan is for Go to switch too, but I can't find any links about it atm.


https://www.youtube.com/watch?v=KXuZi9aeGTw

That might be the talk you are thinking about. I am keeping an eye on this. If we can have our cake and eat too w.r.t green threads and performance I will be very happy.


And this is not an issue with Erlang?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: