5 ms·

This is impressive, but it adds yet another very complex io api to the Linux list. Compared to this Windows is looking more and more impressive and their api i

This is impressive, but it adds yet another very complex io api to the Linux list. Compared to this Windows is looking more and more impressive and their api is decades old. I’m sure this is higher performing in some benchmark setup, but very little cpu time is spent on kernel overhead for any heavy io application. It would be nicer just to have a clean set of flexible asynchronous apis that all shared a relatively simpler model.

devbug 8y ago
It takes ~20 LOC to setup scaleable asynchronous I/O w/ IOCP. It's been like that since 1996. So that's the benchmark as far as I'm concerned.
- iforgotpassword 8y ago
  It really wasn't all that great during the first couple years. And it still has a few annoying caveats today. The advertised flexibility (port sharing etc) most probably wasn't the only reason for http.sys back in the day :) EDIT: that is not to say that it is as horrible to use as epoll (at least in multithreaded programs), but my favorite has to be kqueue.
yxhuvud 8y ago
You should wait with your complaining until the userspace convenience methods are in place. This looks amazingly powerful with lots of applications.
unmole 8y ago
> but very little cpu time is spent on kernel overhead for any heavy io application I would really like to see some backing for that claim. In I/O heavy applications that I've seen (Think performance enhancing proxies), syscalls easily account for over half the CPU cycles.
- grandinj 8y ago
  most of that is spent in the network stack, not the userspace->kernel layer
  - cma 8y ago
    https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update https://www.epicgames.com/fortnite/forums/news/announcements... That was directly from userspace->kernel getting slowed down, to send on the network.

5 ms·

This is impressive, but it adds yet another very complex io api to the Linux list. Compared to this Windows is looking more and more impressive and their api i

by grandinj 8y ago

devbug 8y ago
It takes ~20 LOC to setup scaleable asynchronous I/O w/ IOCP. It's been like that since 1996. So that's the benchmark as far as I'm concerned.
- iforgotpassword 8y ago
  It really wasn't all that great during the first couple years. And it still has a few annoying caveats today. The advertised flexibility (port sharing etc) most probably wasn't the only reason for http.sys back in the day :) EDIT: that is not to say that it is as horrible to use as epoll (at least in multithreaded programs), but my favorite has to be kqueue.
yxhuvud 8y ago
You should wait with your complaining until the userspace convenience methods are in place. This looks amazingly powerful with lots of applications.
unmole 8y ago
> but very little cpu time is spent on kernel overhead for any heavy io application I would really like to see some backing for that claim. In I/O heavy applications that I've seen (Think performance enhancing proxies), syscalls easily account for over half the CPU cycles.
- grandinj 8y ago
  most of that is spent in the network stack, not the userspace->kernel layer
  - cma 8y ago
    https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update https://www.epicgames.com/fortnite/forums/news/announcements... That was directly from userspace->kernel getting slowed down, to send on the network.