3 ms·

No, compilation is six times faster in Linux in almost every single language I’ve compiled using the exact same hardware setup. I/O in windows should have been

• dataflow 4y ago
  > Everyone has their favorites, I base mine on experimental data. So do I. If all you care about is raw speed, sure, Linux with ext4 might be "king". But I don't just look at speed. I also look at the design both inside and outside, the capabilities, the resilience & robustness, and a ton of other things besides raw speed. Maybe those aren't relevant to you, and that's fine. They are to other folks though. > I’m yet to be convinced NTFS doesn’t factor in. I'm not saying it doesn't "factor in" (I'm sure you could measure some % difference across any filesystem, and you should actually benchmark against FAT32 and exFAT and whatnot before blaming NTFS), but it's not the dominant factor you can blame it on. You can read more here if you're interested (you'll have to expand the hidden comments): https://github.com/microsoft/WSL/issues/873#issuecomment-425272829 https://github.com/microsoft/WSL/issues/873#issuecomment-425... > No, compilation is six times faster in Linux in almost every single language I’ve compiled using the exact same hardware setup. I have no idea what you're doing when compiling, but I'm going to guess you either have lots of tiny files that otherwise compile very quickly (thus the slowness in opening files hits you), or you're running a ton of shell scripts in your "compilation" (process spawning is slow on Windows), or you have antivirus or something turned on, or you have some compiler with quirks like GCC. If you give more details I can help you track down what is going on, but a 6x slowdown is simply not something that you can attribute to NTFS by itself. There's something else going on. I'm going to take a guess that you're using Unix-first tools that have been ported to Windows, rather than designed for tools Windows from the ground-up, and finding that there's an impedance mismatch here. Unix tools are designed around shoving every little thing into a tiny file (whether it's a data, script, or executable file), because that's the religion. Windows just isn't designed with that philosophy (e.g., it assumes you'll access the registry for configuration, load DLLs for external functionality, etc.), and hence Windows-native tools don't deal with nearly as many files as ported Linux-native tools do. There are lots of architectural differences (this is just one example), and they do come with their own advantages and disadvantages. > If SSDs didn’t solve I/O for windows then I’ll concede the I/O is garbage I'm confused... are you saying your "experimental data" is from before the SSD era? So this "6x faster" we've been arguing about your experience from over a decade ago? on hard disks? If so, that's a frustrating way to argue about these. > Simply put: Windows needs a ground-up overhaul and to stop catering to the old win32/NTOS/NTFS model. But I don’t really intend nor expect to convince anyone. It's kind of bizarre to read that given your experience seems to be from a different era (?) and when it is in fact Linux who has been forced to overhaul its I/O design from the ground-up with uring. (Compare Windows's IOCP from > 2 decades ago with Linux's epoll. The epoll model itself literally did not even make sense for disk I/O, never mind its implementation.) I could of course argue about the details all day, but I do agree with you that the case you're trying to make isn't convincing. That is, except if your case is "Linux is better for raw speed if you ignore everything else", in which case, yes I agree.