3 ms·

> In every category imaginable, the NT kernel is better designed. Async IO, better power management, pageable kernel memory, stable driver API. I can't comment

> In every category imaginable, the NT kernel is better designed. Async IO, better power management, pageable kernel memory, stable driver API. I can't comment on most of these things since I don't know much coding about them, but I will definitely grant you the stable driver API. Drivers are a huge pain in the ass in Linux, and until DKMS it was pretty common for upgrading my kernel to break my wifi card, which was really annoying. > I get that Linux is popular, but no objective evaluation would claim that Linux kernel is better in any metric other than "how open source is it?" I mean, that's a pretty big feature. Didn't Linux get multicore support well before Windows almost entirely because Linux was open source and popular on servers? When something is open source, companies (or people) don't have to wait for a specific monolithic company to decide that a certain feature is worthy. > synchronous by default IO, really?? I will totally admit a lot of ignorance as I don't work in kernel spaces, but hasn't Linux had Async IO in the form of `epoll` for like 20 years? It's not the default but I feel like it's pretty commonly used. ----- Of the things I do like about Linux (outside of open source), it follows the "everything's a file" mantra from Unix. It makes it fairly fun and easy to arbitrarily glue applications together (admittedly at the cost of performance sometimes). Also, I like that you can choose different filesystems more or less arbitrarily. I don't have a Linux laptop anymore (I run macOS), but I when I did I was running ZFS on root with Ubuntu, and ZFS is pretty awesome. As far as I'm aware, with Windows you're basically stuck with NTFS.

pjmlp 5y ago
Windows NT was born with multicore support from the get go, hence why the unit of execution is threads not processes.
- tombert 5y ago
  Fair enough, a quick Google has confirmed I was wrong! This is what I get for repeating things without researching them first.
dralley 5y ago
>I will totally admit a lot of ignorance as I don't work in kernel spaces, but hasn't Linux had Async IO in the form of `epoll` for like 20 years? It's not the default but I feel like it's pretty commonly used. As an API, epoll is kind of... suboptimal. Of course, lots of great things have been built with it, but there's a reason it's being replaced with io-uring, which is a lot more similar to Windows iocp.
- monocasa 5y ago
  Eh, it's io-uring is pretty different too, which is why NT just added a clone of io-uring. https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/ https://windows-internals.com/i-o-rings-when-one-i-o-operati...
  - asveikau 5y ago
    From a high level, the philosphy of doing i/o with IOCP, posix AIO, and io-uring are the same. All of those are true async i/o rather than a readiness model like epoll/kqueue/etc. The novel thing of io-uring is using a new data structure to do it with fewer syscalls, thus less syscall overhead.
dmitrygr 5y ago
NT was multicore much earlier (1994 [1]). Linux had SOMEWHAT working SMP support in 2.0 in 1996 [2]. But really I would hardly count it as real, what with BKL. [1] http://www.os2museum.com/wp/nt-3-1-smp/comment-page-1/ http://www.os2museum.com/wp/nt-3-1-smp/comment-page-1/ [2] https://en.wikipedia.org/wiki/Linux_kernel https://en.wikipedia.org/wiki/Linux_kernel
dmitrygr 5y ago
NT had async io at release in 1993 [3] epoll() was introduced in Linux 2.5.44 [1], which was released in 2002 [2]. Epoll is not a wonderful API. Linux's real reply to NT's anync io is io_uring, which only appeared in Linux 5.1 [4] in 2019(!!) [2], and is still wildly evolving [1] https://en.wikipedia.org/wiki/Epoll https://en.wikipedia.org/wiki/Epoll [2] https://en.wikipedia.org/wiki/Linux_kernel_version_history https://en.wikipedia.org/wiki/Linux_kernel_version_history [3] https://en.wikipedia.org/wiki/Windows_NT https://en.wikipedia.org/wiki/Windows_NT [4] https://en.wikipedia.org/wiki/Io_uring https://en.wikipedia.org/wiki/Io_uring
- tombert 5y ago
  I mean, I don’t think you’re wrong; I think the main reason that people haven’t complained that much about being stuck with epoll is that a lot of this is somewhat abstracted nowadays. I’ve only used epoll once to play with it, and most of the time when I need nonblocking IO, I use Java NIO or Netty or something. I generally do not care about how pretty the underlying code powering these things is as long as it works and as long as my code is pretty. Granted, that’s not really a good excuse for Linux having a crappy system, just why I think there wasn’t ever a ton of urgency for it.
- monocasa 5y ago
  And io_uring is good enough that NT is copying the concept wholesale. https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/ https://windows-internals.com/i-o-rings-when-one-i-o-operati...
- danachow 5y ago
  epoll is not an asyncio implementation, it really doesn’t belong in any discussion about aio, it’s a relatively better poll/select. Apparently less well known is that Linux had an async io interface also introduced around the same time in 2.5 (see io_setup, io_submit, and libaio). Initially extremely limited and generally not widely used (limitations include only working on certain disk files opened O_DIRECT), however it was incrementally improved over the years until io_uring came around. glibc has had a POSIX AIO implementation for years, implemented with userspace threads since the kernel implementation was originally not suitable.
Fnoord 5y ago
It really depends on your goals, your use case. In begin of AMD64 a lot of Windows software was single threaded 32 bit still, while on Debian with APT you had a working 64 bit environment. It was mostly userland which could not handle the amount of max cores found in even consumer grade multicore AMD64. Even recently many games did not take advantage of multiple cores, while AMD has been strong performance wise multiple cores, Intel was best single core until Zen 3 recently. Windows would be unable to perform well (use max cores) on AMD64 by AMD. You can see it now too. Intel gets slight performance boost with Windows 11 compared to 10 while AMD loses performance. Which AMD said they will address in October.
- dboreham 5y ago
  NT was 64-bit before AMD64 hardware shipped (running on Alpha).
  - Fnoord 5y ago
    This is a dishonest take on my post. I was talking about 64 bit in the context of AMD64. Not 64 bit in general. Alpha is irrelevant in this discussion.
DeathArrow 5y ago
You can use other file systems on Windows, too. There's even an ext3 driver for Windows.

pjmlp 5y ago

Windows NT was born with multicore support from the get go, hence why the unit of execution is threads not processes.

tombert 5y ago
Fair enough, a quick Google has confirmed I was wrong! This is what I get for repeating things without researching them first.

dralley 5y ago

>I will totally admit a lot of ignorance as I don't work in kernel spaces, but hasn't Linux had Async IO in the form of `epoll` for like 20 years? It's not the default but I feel like it's pretty commonly used. As an API, epoll is kind of... suboptimal. Of course, lots of great things have been built with it, but there's a reason it's being replaced with io-uring, which is a lot more similar to Windows iocp.

monocasa 5y ago
Eh, it's io-uring is pretty different too, which is why NT just added a clone of io-uring. https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/ https://windows-internals.com/i-o-rings-when-one-i-o-operati...
- asveikau 5y ago
  From a high level, the philosphy of doing i/o with IOCP, posix AIO, and io-uring are the same. All of those are true async i/o rather than a readiness model like epoll/kqueue/etc. The novel thing of io-uring is using a new data structure to do it with fewer syscalls, thus less syscall overhead.

dmitrygr 5y ago

NT was multicore much earlier (1994 [1]). Linux had SOMEWHAT working SMP support in 2.0 in 1996 [2]. But really I would hardly count it as real, what with BKL. [1] http://www.os2museum.com/wp/nt-3-1-smp/comment-page-1/ http://www.os2museum.com/wp/nt-3-1-smp/comment-page-1/ [2] https://en.wikipedia.org/wiki/Linux_kernel https://en.wikipedia.org/wiki/Linux_kernel

dmitrygr 5y ago

NT had async io at release in 1993 [3] epoll() was introduced in Linux 2.5.44 [1], which was released in 2002 [2]. Epoll is not a wonderful API. Linux's real reply to NT's anync io is io_uring, which only appeared in Linux 5.1 [4] in 2019(!!) [2], and is still wildly evolving [1] https://en.wikipedia.org/wiki/Epoll https://en.wikipedia.org/wiki/Epoll [2] https://en.wikipedia.org/wiki/Linux_kernel_version_history https://en.wikipedia.org/wiki/Linux_kernel_version_history [3] https://en.wikipedia.org/wiki/Windows_NT https://en.wikipedia.org/wiki/Windows_NT [4] https://en.wikipedia.org/wiki/Io_uring https://en.wikipedia.org/wiki/Io_uring

tombert 5y ago
I mean, I don’t think you’re wrong; I think the main reason that people haven’t complained that much about being stuck with epoll is that a lot of this is somewhat abstracted nowadays. I’ve only used epoll once to play with it, and most of the time when I need nonblocking IO, I use Java NIO or Netty or something. I generally do not care about how pretty the underlying code powering these things is as long as it works and as long as my code is pretty. Granted, that’s not really a good excuse for Linux having a crappy system, just why I think there wasn’t ever a ton of urgency for it.
monocasa 5y ago
And io_uring is good enough that NT is copying the concept wholesale. https://windows-internals.com/i-o-rings-when-one-i-o-operation-is-not-enough/ https://windows-internals.com/i-o-rings-when-one-i-o-operati...
danachow 5y ago
epoll is not an asyncio implementation, it really doesn’t belong in any discussion about aio, it’s a relatively better poll/select. Apparently less well known is that Linux had an async io interface also introduced around the same time in 2.5 (see io_setup, io_submit, and libaio). Initially extremely limited and generally not widely used (limitations include only working on certain disk files opened O_DIRECT), however it was incrementally improved over the years until io_uring came around. glibc has had a POSIX AIO implementation for years, implemented with userspace threads since the kernel implementation was originally not suitable.

Fnoord 5y ago

It really depends on your goals, your use case. In begin of AMD64 a lot of Windows software was single threaded 32 bit still, while on Debian with APT you had a working 64 bit environment. It was mostly userland which could not handle the amount of max cores found in even consumer grade multicore AMD64. Even recently many games did not take advantage of multiple cores, while AMD has been strong performance wise multiple cores, Intel was best single core until Zen 3 recently. Windows would be unable to perform well (use max cores) on AMD64 by AMD. You can see it now too. Intel gets slight performance boost with Windows 11 compared to 10 while AMD loses performance. Which AMD said they will address in October.

dboreham 5y ago
NT was 64-bit before AMD64 hardware shipped (running on Alpha).
- Fnoord 5y ago
  This is a dishonest take on my post. I was talking about 64 bit in the context of AMD64. Not 64 bit in general. Alpha is irrelevant in this discussion.

DeathArrow 5y ago

You can use other file systems on Windows, too. There's even an ext3 driver for Windows.