4 ms·

Alice ML “threads” are more like Erlang threads than C# threads. They're lightweight userspace threads and you can have thousands of them. That's quite scalable

by PeCaN 10y ago

Alice ML “threads” are more like Erlang threads than C# threads. They're lightweight userspace threads and you can have thousands of them. That's quite scalable. Also, that's not a new idea. Blocking-style code with async I/O scaling was pioneered by Oz in 1991. (It did it a little bit differently from Alice ML.)

Const-me 10y ago
“They're lightweight userspace threads and you can have thousands of them.” — can I use 1000 lightweight userspace threads to run 1000 concurrent kernel-space IO operations on files or sockets, one thread each?
- PeCaN 10y ago
  Yes, that's precisely the point.
  - Const-me 10y ago
    MS implemented IOCP in Windows NT in 1994, then BSD implemented kqueue in 2000, then Linux implemented epoll in 2002 (they all functionally very similar). That means outside Windows, asynchronous event-based IO was only possible after 2002 (that’s when the first version of libevent was released). And yet you’re telling me the ML threads in 2000 were capable of high-performance async IO? You sure about that? In 2000, which kernel API you think that runtime used for IO?
    - PeCaN 10y ago
      Yes, and VMS had asynchronous system traps for I/O in 1977.² ³ And yes, of course? Erlang could do scalable async I/O in 1988. Alice ML and Erlang both emulate async I/O by having a few OS level threads each switching between a large number of userspace/VM threads. They queue I/O operations then preempt VM threads when results are ready. For a while that was the only sane way around the clusterfuck that is async I/O on *nix. It still scales fine and I think there's rather little interest in converting either Alice ML or Erlang to libevent/libev/libuv. ¹ The initial Erlang VM was very slow, but the I/O model was there. BEAM was created in 1992 and was fast enough for Ericsson to use in production. ² NT and VMS were both designed by David Cutler, who is more or less the father of asynchronous I/O at the OS level. ³ Incidentally, if you think async I/O in 1977 was advanced, you should look at AS/400 or VOS sometime.
      - Const-me 10y ago
        > It still scales fine Only 1024 sockets per select because FD_SETSIZE constant? How’s that scales fine? You have 10k sockets = you need 10 native threads, with 10 native stacks, on a quad code machine each of them is guaranteed to be out of CPU cache when IO completes. Not fine, very inefficient. > there's rather little interest in converting either Alice ML or Erlang to libevent/libev/libuv. Well, Erlang developers don’t care about windows. And for BSD, Linux and Solaris they already support native event-based async IO for many years. They call the feature “kernel poll”. > if you think async I/O in 1977 was advanced I aware on some systems it was widely used. Just not on the mainstream *nix systems where that Alice ML ran in 2000.
    - srean 10y ago
      BTW Windows got it thanks to Dave Cutler whom they poached from VMS. VMS, I hear, head and shoulders above everyone in concurrent I/O at that time. Concurrency story on the unix side has always been weaker in comparison. That's bit of a shame because the _logical_ virtual machine that C targeted, the PDP, had instruction level support for coroutines. BTW you don't really need kernel support for concurrency although it helps a great deal if you have. One way to do it would be to compile coroutines to an eventloop runtime and break read and writes into smaller concurrent chunks.

by PeCaN 10y ago

Const-me 10y ago

“They're lightweight userspace threads and you can have thousands of them.” — can I use 1000 lightweight userspace threads to run 1000 concurrent kernel-space IO operations on files or sockets, one thread each?

PeCaN 10y ago
Yes, that's precisely the point.
- Const-me 10y ago
  MS implemented IOCP in Windows NT in 1994, then BSD implemented kqueue in 2000, then Linux implemented epoll in 2002 (they all functionally very similar). That means outside Windows, asynchronous event-based IO was only possible after 2002 (that’s when the first version of libevent was released). And yet you’re telling me the ML threads in 2000 were capable of high-performance async IO? You sure about that? In 2000, which kernel API you think that runtime used for IO?
  - PeCaN 10y ago
    Yes, and VMS had asynchronous system traps for I/O in 1977.² ³ And yes, of course? Erlang could do scalable async I/O in 1988. Alice ML and Erlang both emulate async I/O by having a few OS level threads each switching between a large number of userspace/VM threads. They queue I/O operations then preempt VM threads when results are ready. For a while that was the only sane way around the clusterfuck that is async I/O on *nix. It still scales fine and I think there's rather little interest in converting either Alice ML or Erlang to libevent/libev/libuv. ¹ The initial Erlang VM was very slow, but the I/O model was there. BEAM was created in 1992 and was fast enough for Ericsson to use in production. ² NT and VMS were both designed by David Cutler, who is more or less the father of asynchronous I/O at the OS level. ³ Incidentally, if you think async I/O in 1977 was advanced, you should look at AS/400 or VOS sometime.
    - Const-me 10y ago
      > It still scales fine Only 1024 sockets per select because FD_SETSIZE constant? How’s that scales fine? You have 10k sockets = you need 10 native threads, with 10 native stacks, on a quad code machine each of them is guaranteed to be out of CPU cache when IO completes. Not fine, very inefficient. > there's rather little interest in converting either Alice ML or Erlang to libevent/libev/libuv. Well, Erlang developers don’t care about windows. And for BSD, Linux and Solaris they already support native event-based async IO for many years. They call the feature “kernel poll”. > if you think async I/O in 1977 was advanced I aware on some systems it was widely used. Just not on the mainstream *nix systems where that Alice ML ran in 2000.
  - srean 10y ago
    BTW Windows got it thanks to Dave Cutler whom they poached from VMS. VMS, I hear, head and shoulders above everyone in concurrent I/O at that time. Concurrency story on the unix side has always been weaker in comparison. That's bit of a shame because the _logical_ virtual machine that C targeted, the PDP, had instruction level support for coroutines. BTW you don't really need kernel support for concurrency although it helps a great deal if you have. One way to do it would be to compile coroutines to an eventloop runtime and break read and writes into smaller concurrent chunks.