I've never really used Windows as a daily driver until I had to do cross-platform development for PhotoStructure[1]. My windows box is a recent XPS 15 with an m.2 SSD and core i7. My Mac is a 10 year old 17" MBP. My linux box is the cheapest core i5 I could get 2 years ago with an mSATA SSD (not m.2).
Here's this morning's CI job timings (running the same 2K tests that exercise a reasonable mixture of CPU, process management, and disk I/O):
Just saying i5 or i7 is kind of meaningless, because it can be anything between a laptop dual core to a desktop octa core these days.
What's in the 19 additional tests Windows is running? Is the Linux box a laptop as well? I'm personally having trouble believing the Core 2 Duo in your MBP outperforms a modern i7, even after potential Windows overhead.
Yeah, agreed, but these are single-core tests and even the max clock speed of intel chips doesn't seem to correlate exactly with performance. Here's more CPU details, though:
My XPS 15 is HT 4-core Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz.
The ubuntu box is HT dual-core Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz
> What's in the 19 additional tests Windows is running?
The 19 additional tests are windows-specific path validation unit tests, and take ~10ms total.
> Is the Linux box a laptop as well?
No, it's on a 3 year old cheapo mini ITX mobo.
> I'm personally having trouble believing
Me too. I've nuked and paved this box a couple times, thinking it was bad interactions with cygwin or MSYS or minGW. CPU bound stuff (like ffmpeg transcoding) is closer across windows and linux, but opening files and forking processes on Windows is just hella slow (even on my desktop windows machines).
A minor correction, the i5-6500 is a non HT quad core.
In practice, the i5-6500 is faster than the i7-6700HQ. The i5 enjoys a slightly higher turbo clock speed and less restrictions in TDP, cooling and power supply allowing it to run faster for longer so it's expected to be the fastest, but that doesn't explain the entire gap.
Have you tried using WSL instead? I found it to do excellent in CPU based tasks, but the file IO performance was a bit lacking. Apparently in the next release (along with this new terminal) filesystem performance should improve by a significant amount. Although I would still expect it to be slower than running on Windows/NTFS natively
> Fork & fs operations, certainly.... nothing to do with Windows itself.
Both of these operations are known to be very slow specifically in windows. The former's the reason why windows has always strongly favored thread-based concurrency (whereas unices tend to favor process-based concurrency)[0], the latter is well know of NTFS, it deals especially badly with lots of small files.
[0] even excluding making the entire thing blowing its gasket as Bruce Dawson triggers with appalling regularity, in fact in one of his posts he specifically notes in the introduction that windows is notorious for its slow file and process operations: https://randomascii.wordpress.com/2018/10/15/making-windows-...
FWIW these are mocha suites running under nodeJS, so if v8 had a really bad windows subsystem, that'd explain it, but as others have stated, the performance difference correlates with other cross platform runtime environments as well.
I've never really used Windows as a daily driver until I had to do cross-platform development for PhotoStructure[1]. My windows box is a recent XPS 15 with an m.2 SSD and core i7. My Mac is a 10 year old 17" MBP. My linux box is the cheapest core i5 I could get 2 years ago with an mSATA SSD (not m.2).
Here's this morning's CI job timings (running the same 2K tests that exercise a reasonable mixture of CPU, process management, and disk I/O):
Windows 10 (XPS 15):
Mac (10 year old MBP on 10.11): Ubuntu (i5, LTS 18.04): I'd suggest backing up your HD, making a USB stick with OEM Windows 10, and reinstalling just Windows (with no Lenovo bloatware): https://support.microsoft.com/en-us/help/4000735/windows-10-...[1] https://blog.photostructure.com/introducing-photostructure/