Hacker News Reader

Comment by zxcvcxz | Hacker News Reader

You should also mention that you're the author of Windows only software that directly exploits certain features specific to Windows. An implementation of python that according to http://pyparallel.org/ out-performs pretty much every other technology. Is that correct? I'm also wondering if anyone has replicated these results? From what I can find not a single person has replicated your tests.

According to your own website pretty much every other technology runs better on Linux than it does on windows (http://pyparallel.org/wrk-rps-comparison2.svg).

It could be said you're a little biased, seeing as your software only targets Windows.

View on HN

We detached this subthread from https://news.ycombinator.com/item?id=11866402 and marked it off-topic.

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.

> 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

"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-...

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?

I haven't actually. Although now I'm kind of curious.

It pretty much a complete implementation down to the kernel APIs.

One of the (former?) main kernel developers on ReactOS, Alex Ionescu, is even a co-author on the latest editions of Windows Internals.

Indeed, he's got a talk at Black Hat this year about Bash on Windows on Linux, too :-)

Why did you two have this same conversation 383 days ago?

https://news.ycombinator.com/item?id=9584269

I dunno', I don't remember everyone I reply to, certainly not over a year ago.

You and me both.

Let's definitely reconvene in another 384 days though!

Should give you enough time to test on ReactOS and report back! :-)

Haha. Well, you know what they say, if it is a good idea today, it's a good idea tomorrow too ;-)

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

This is pathetic.

for posterity:

https://web.archive.org/web/20160609010955/https://news.ycom...

https://web.archive.org/web/20160609014033/https://news.ycom...

We've banned this account for repeatedly violating the HN guidelines.

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.

I only have superficial experience with it, but from what I can tell there is a huge mismatch between IOCP and the UNIX readiness/poll model, and from my experience most server programs are written primarily for the latter.

You need to design your server code somewhat differently to take advantage of IOCP. What many UNIX-like softwares do instead is bend IOCP or WaitForMultipleObjects() to behave like Linux. It works, but the performance is not there.

Note that I haven't checked the code for any of the softwares in your chart so I could be wrong.

Oh man, seeing UNIX people use WaitForMultipleObjects() as if it were select() (or, gasp, trying to use it for socket server stuff) just kills me.

It's actually a really sophisticated multi-semaphore behind the scenes; but that sophistication comes at an inevitable performance penalty, because the wait blocks are in a linked list and it's generally expensive (in comparison to say, a completion packet being queued to a port) to satisfy that wait (the kernel needs to check lots of things and do locking and unlocking and linked list manipulation).

Here's what I don't understand: If IOCP gives us such a great performance boost why don't I see people using it, even on Windows systems? The first thing that comes to mind is that IOCP can likely only maintain high performance under certain edge-cases that aren't pertinent to the real world, second is that the other I/O models are needed not for unix, but for other aspects of the language its self where IOCP is not appropriate. So IOCP likely causes overhead. I don't know much about it so maybe someone can explain. It sounds revolutionary if it can be applied to the real world and not just edge cases.

People are used to the POSIX readiness model, that's all. And you can kind of make it work on Windows, even though the performance is not great. OTOH, porting an IOCP-oriented application to Linux will give you catastrophic performance because you need to use many threads to replicate the async model on top of the synchronous Linux I/O calls.

And for some reason, people get very defensive when you point out some of the advantages the NT kernel has over Linux. I mean, I use Linux, I don't like to use Windows but I have no problem admitting the IOCP model is better and async I/O on Linux is a sad broken mess. Denying it only serves to keep it that way.

IOCP is the top item on my (short) list of things Windows simply does better. The performance boost you see from designing a server for IOCP from the ground up is jaw-dropping. However, it's hard to grok because it's a very different model, most servers are proprietary code, and the MSDN documentation is barely sufficient (at least, back when I was writing IOCP-based servers in '09).

Yeah, I had to figure out how to leverage all the new threadpool stuff with async sockets from scratch for PyParallel, none of the MSDN docs detailed how AcceptEx() and ConnectEx() and DisconnectEx() and all that jazz were meant to be used with CreateThreadpoolIo(), StartThreadpoolIo() etc.

Even bought a couple of Microsoft books and they only covered it at the file I/O level, too. And the last Winsock book is reaaaaaally getting old.

Also, registered I/O is a similar jump in jaw-dropping performance. Disable completion notifications, pre-register all of your buffers on large pages, and use timers to schedule bulk de-queuing of all available completion events.

You definitely need a feedback loop in there to fine-tune the timings, but holy hell does it fly. You basically get a guaranteed-max-latency state machine (given bandwidth, computational cost of request processing, and number of clients connected).

Inertia and the fact that select/epoll/kqueue loops are "good enough".

Bingo.

Not only that but exploiting NT optimally takes a lot of knowledge about a lot of very low-level kernel details, which you sort of need to make a concerted effort to really learn, which is made harder by no official access to (recent) source code.

So I genuinely think there are just fewer programmers out there that specialize in this sort of stuff. There's definitely a correlation between well-above-the-average programmers trending toward open source contribution, but not really the same level of intellectual curiosity about NT/Windows.

One thing I've noticed is that all the people that grok really low level NT kernel details usually end up as reverse engineering experts.

Oh, except for the OSR internals list, that is usually overflowing with clue (both now and historically).

It also requires enjoying programming on Windows and buying all the Microsoft Press books that have tons of healthy information how the whole stack works.

Which doesn't work in the free (as in beer) culture world of modern UNIX.

So only those of us that feel like rewarding the work of others do get the information how everything works.

The simplest explanation is that the performance benefit of using Windows and implementing just about any Windows-specific design is outweighed by the cost of the Windows licensing fees, when compared to a measurably worse-performing Linux or FreeBSD solution that costs nothing. So very few bother to treat Windows versions of "backend" software as anything but an afterthought.

It's not even the licencing fees in my opinion. It's that it has had the equivalent of 200 Potterings run amok in it for 30 years. There are so many things that will eclipse any advantage from IO completion ports.

Not really... the license model provides support and creates fairly standard releases by which you can more easily leverage. If licensing or selling software is your thing. If all you need is something good enough and cheap then licensing could get in the way

I guess you should also mention on each of your comments that you are extremely biased against and paranoid about Microsoft and that you actively target any popular Microsoft article posted here in order to inject something negative, whether it's relevant or not.

Heh.

Reply on news.ycombinator.com