Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How the Windows Subsystem for Linux Redirects Syscalls

blogs.msdn.microsoft.com

Post reply on HN
Print view View original

121–130 of 274 posts

Re: How the Windows Subsystem for Linux Redirects Syscalls

#121

Post by madez »

tacos wrote: post #112
madez wrote: post #106

Earlier quoted context omitted.

I don't want to take sides in this discussion but share an anecdote. Hey, maybe even someone knows a solution for this. I have a PC connected via on-board HDMI to a Denon AVR solely for the purpose of getting the audio to the amplifier. Windows doesn't let me use that audio interface without extending or mirroring my desktop to that HDMI port. Since there is no display connected to the AVR I don't want to extend the…

Can you use optical instead of HDMI?

TOSLINK doesn't support uncompressed surround audio, while HDMI does, and I do use it.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#122

Post by bigger_cheese »

ckaygusu wrote: post #60
bitwize wrote: post #46

Earlier quoted context omitted.

This is a recurring pattern in Windows development. Unix devs look at the Windows API and go "This syscall takes 11 parameters? GROAN." But the NT kernel is much more sophisticated and powerful than Linux, so its system calls are going to be necessarily more complicated.

I think the problem here is not a syscall taking 11 parameters, it's a syscall that merely lists what is inside a directory taking 11 parameters. ataylor_284 explained the reasons (how convincingly, I'd argue) but on the first sight that surely smells bloat. I'd also object NT kernel being more "powerful". Sure unixy kernels and NT has their differences but I don't think either one is superior.

11 parameters may seem bloated but in some cases Unix syscalls weren't designed with enough parameters whcih caused a bunch of pain necessitating things like

dup->dup2->dup3 pipe->piep2 rename->renameat->renameat2

Best practice nowadays in linux is to allow overloading syscalls via a flags parameter.

see https://lwn.net/Articles/585415/

So modern linux syscalls may be bloated too.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#123

Post by clevernickname »

zxcvcxz wrote: post #114
Koromix wrote: post #111

Earlier quoted context omitted.

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…

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…

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.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#124

Post by School-Cotton »

deprave wrote: post #65
bitwize wrote: post #47

Earlier quoted context omitted.

When it comes to system call interfaces, it's because Dave Cutler has forgotten more than many modern "kernel hackers" will ever know about how to design an OS.

I appreciate the name-dropping. Dave Cutler's skills aside, Unix predates Windows by decades, and to anyone remotely familiar with kernel development it is clear that the sheer quantity and complexity of subsystems stem from the fact that nobody but Microsoft can actually see, modify, and redistribute Windows' source code. Unless you can actually say "here's why Windows is qualitatively better" and point out specific…

Why is it valid to conflate every kernel that runs a *nix OS together under "Unix"? Is there any meaningful overarching "Unixy" way in which, say, Xnu and Linux are similar?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#125

Post by niels_olson »

trentnelson wrote: post #116
jen20 wrote: post #113

Earlier quoted context omitted.

I've never met a single person who understood what they were talking about and referred to a "UNIX kernels". It may be true that Linux was once less advanced than NT - this is no longer the case, despite egregious design flaws in things like epoll. It has simply never been true (for example) for the Illumos (nee Solaris) kernel.

I qualified it as "Linux/UNIX kernel" because I wanted to emphasize the kernel and not userspace. Solaris event ports are good, but they're still ultimately backed by a readiness-oriented I/O model, and can't be used for asynchronous file I/O.

Here's a nice graphical comparison of syscalls between Linux and Windows

http://www.visualcomplexity.com/vc/project.cfm?id=392

Are you saying the Windows flow looks like spaghetti only because the software tested software (Apache) wasn't designed for Windows?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#126

Post by e12e »

trentnelson wrote: post #119
zxcvcxz wrote: post #103

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 web…

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 softwar…

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?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#127

Post by zxcvcxz »

trentnelson wrote: post #119
zxcvcxz wrote: post #103

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 web…

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 softwar…

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

Re: How the Windows Subsystem for Linux Redirects Syscalls

#128

Post by orbifold »

cbd1984 wrote: post #91
recursive wrote: post #82

Earlier quoted context omitted.

If you're arguing in favor of linux, you probably shouldn't use any arguments that deal with getting audio setups right.

Audio on Linux works fine in my experience.

Well for various definitions of fine I guess.

Re: How the Windows Subsystem for Linux Redirects Syscalls

#129

Post by thwarted »

trentnelson wrote: post #115
piscisaureus wrote: post #104

Earlier quoted context omitted.

I wrote the windows bits for libuv (node.js' async i/o library), so I have extensive experience with asynchronous I/O on Windows, and my experience doesn't back up parent's statement. Yes, it's true that many APIs would theoretically allow kernel-level asynchronous I/O, but in practice the story is not so rosy. * Asynchronous disk I/O is in practice often not actually asynchronous. Some of these cases are documented…

You're completely missing how the NT I/O subsystem works, and how to use it optimally. > * Asynchronous disk I/O is in practice often not actually asynchronous. Some of these cases are documented ( https://support.microsoft.com/en-us/kb/156932 ), but asychronous I/O also actually blocks in cases that are not listed in that article (unless the disk cache is disabled). This is the reason that node.js always uses thread…

I disagree. Write a kernel driver on Linux and NT and you'll see how much more superior the NT I/O subsystem is.

Can programming against the userspace interface the I/O subsystem really be compared to programming against the kernel driver interface to I/O subsystem? In Linux, kernel drivers have access to structures, services, and layers that userspace doesn't. And can these be compared between a monolithic and a micro-kernel approach, other than what has been debated ad nauseam for micro/monolithic kernels in general (not just used for I/O)?

Re: How the Windows Subsystem for Linux Redirects Syscalls

#130

Post by Koromix »

zxcvcxz wrote: post #114
Koromix wrote: post #111

Earlier quoted context omitted.

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…

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…

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.

Post reply on HN