4 ms·

I'm incredibly biased. But that bias has come from assessing the technical details and concluding that NT really is superior, if that's any consolation. PyPar

I'm incredibly biased. But that bias has come from assessing the technical details and concluding that NT really is superior, if that's any consolation. PyParallel flogs the Windows versions of things like Go, Node and Tornado because none of those were implemented in a way that allows the NT completion-oriented I/O facilities to be optimally exploited. It's depressing, honestly. In the sense that open source software never really comes close to taking advantage of NT because there are no such paradigms on UNIX. It's also complex as hell... I came from a UNIX background and completion ports were just a bizarre black box of overcomplicated engineering -- but after taking the time to understand the why, that was just a blub paradox reaction. And it's been a couple of years now of concerted study to really start appreciating the little details.

e12e 10y ago
Now I'm curious; have you played with reactOS at all? Do they implement the same VMS paradigm? That is, if given decent hw drivers for io on ReactOS, could one expect performance on the same order of magnitude as with a new nt-derived kernel?
- trentnelson 10y ago
  I haven't actually. Although now I'm kind of curious.
  - monocasa 10y ago
    It pretty much a complete implementation down to the kernel APIs.
    - 0xcde4c3db 10y ago
      One of the (former?) main kernel developers on ReactOS, Alex Ionescu, is even a co-author on the latest editions of Windows Internals.
      - trentnelson 10y ago
        Indeed, he's got a talk at Black Hat this year about Bash on Windows on Linux, too :-)
  - zxcvcxz 10y ago
    Why did you two have this same conversation 383 days ago? https://news.ycombinator.com/item?id=9584269 https://news.ycombinator.com/item?id=9584269
    - trentnelson 10y ago
      I dunno', I don't remember everyone I reply to, certainly not over a year ago.
      - e12e 10y ago
        You and me both.
        trentnelson 10y ago
        Let's definitely reconvene in another 384 days though!
        e12e 10y ago
        Should give you enough time to test on ReactOS and report back! :-)
    - e12e 10y ago
      Haha. Well, you know what they say, if it is a good idea today, it's a good idea tomorrow too ;-)
zxcvcxz 10y ago
So no one has replicated your findings and you're better than everyone else? K. edit: TBH it looks like you're making multiple accounts to comment on your own posts to make the comments that disagree with you appear lower. You and the child above mine had this same conversation 383 days ago: https://news.ycombinator.com/item?id=9584269 https://news.ycombinator.com/item?id=9584269 This is pathetic. for posterity: https://web.archive.org/web/20160609010955/https://news.ycombinator.com/item?id=9584269 https://web.archive.org/web/20160609010955/https://news.ycom... https://web.archive.org/web/20160609014033/https://news.ycombinator.com/item?id=11866736 https://web.archive.org/web/20160609014033/https://news.ycom...
- trentnelson 10y ago
  Well now I have no idea what you're talking about. I can barely remember the password to this hacker news account let alone managing multiple identities.
- dang 10y ago
  We've banned this account for repeatedly violating the HN guidelines.
justinmk 10y ago
> things like Go, Node and Tornado [does not allow] the NT completion-oriented I/O facilities to be optimally exploited. nodejs is built on libuv[1], which uses IOCP on Windows (and epoll, kqueue, etc. on other platforms). What's non-optimal about it? [1] https://github.com/libuv/libuv https://github.com/libuv/libuv
- trentnelson 10y ago
  "The things that bothers me about all the 'async I/O' libraries out there... is that the implementation -- single-threaded, non-blocking sockets, event loop, I/O multiplex via kqueue/epoll, is well suited to Linux/BSD/OSX, but there's nothing asynchronous about it, it's technically synchronous non-blocking I/O, and it's inherently single-threaded." https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=37 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...

e12e 10y ago

Now I'm curious; have you played with reactOS at all? Do they implement the same VMS paradigm? That is, if given decent hw drivers for io on ReactOS, could one expect performance on the same order of magnitude as with a new nt-derived kernel?

trentnelson 10y ago
I haven't actually. Although now I'm kind of curious.
- monocasa 10y ago
  It pretty much a complete implementation down to the kernel APIs.
  - 0xcde4c3db 10y ago
    One of the (former?) main kernel developers on ReactOS, Alex Ionescu, is even a co-author on the latest editions of Windows Internals.
    - trentnelson 10y ago
      Indeed, he's got a talk at Black Hat this year about Bash on Windows on Linux, too :-)
- zxcvcxz 10y ago
  Why did you two have this same conversation 383 days ago? https://news.ycombinator.com/item?id=9584269 https://news.ycombinator.com/item?id=9584269
  - trentnelson 10y ago
    I dunno', I don't remember everyone I reply to, certainly not over a year ago.
    - e12e 10y ago
      You and me both.
      - trentnelson 10y ago
        Let's definitely reconvene in another 384 days though!
        e12e 10y ago
        Should give you enough time to test on ReactOS and report back! :-)
  - e12e 10y ago
    Haha. Well, you know what they say, if it is a good idea today, it's a good idea tomorrow too ;-)

zxcvcxz 10y ago

So no one has replicated your findings and you're better than everyone else? K. edit: TBH it looks like you're making multiple accounts to comment on your own posts to make the comments that disagree with you appear lower. You and the child above mine had this same conversation 383 days ago: https://news.ycombinator.com/item?id=9584269 https://news.ycombinator.com/item?id=9584269 This is pathetic. for posterity: https://web.archive.org/web/20160609010955/https://news.ycombinator.com/item?id=9584269 https://web.archive.org/web/20160609010955/https://news.ycom... https://web.archive.org/web/20160609014033/https://news.ycombinator.com/item?id=11866736 https://web.archive.org/web/20160609014033/https://news.ycom...

trentnelson 10y ago
Well now I have no idea what you're talking about. I can barely remember the password to this hacker news account let alone managing multiple identities.
dang 10y ago
We've banned this account for repeatedly violating the HN guidelines.

justinmk 10y ago

> things like Go, Node and Tornado [does not allow] the NT completion-oriented I/O facilities to be optimally exploited. nodejs is built on libuv[1], which uses IOCP on Windows (and epoll, kqueue, etc. on other platforms). What's non-optimal about it? [1] https://github.com/libuv/libuv https://github.com/libuv/libuv

trentnelson 10y ago
"The things that bothers me about all the 'async I/O' libraries out there... is that the implementation -- single-threaded, non-blocking sockets, event loop, I/O multiplex via kqueue/epoll, is well suited to Linux/BSD/OSX, but there's nothing asynchronous about it, it's technically synchronous non-blocking I/O, and it's inherently single-threaded." https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=37 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...