Got a new PC @ work. IT dept. did a quite good job in terms of annoyance: This is a compile run (Makefile etc.) ran on the new PC (Core i5-8500, 8GB, SSD, Win10):
cygwin> time make
...
real 12m42.805s
user 1m33.628s
sys 3m45.193s
The very same job on the old one (Core i7-3770, 8GB, HDD, Win7):
cygwin> time make
...
real 6m58.280s
user 1m13.999s
sys 1m59.115s
Yes, I know, cygwin is known to be slower than native, just for comparison the same job natively (Core i5-6500T, 8GB, SSD, Debian)
> time make
...
real 1m50.209s
user 5m50.816s
sys 0m40.377s
>
No, I didn't swap any of these results. Native debian beats cygwin - that's what one would expect anyway (factor 3 to 6, WTF?), but 7yr old machine beats 1/2yr old machine by nearly a factor of two, even though the new machine has a SSD and the old one doesn't?
My first guess would be they imaged the HDD instead of doing a clean install; this means all the TRIM/AHCI/NVMe goodness is not working as it should. Also, if you're doing anything creative, 16GB should be your minimum. If it's an imaged build it's very possible they left the BIOS untouched; this would mean probably XMP is not optimized, possibly not even enabled. Or maybe just plain cheap, slow RAM that doesn't take advantage of the i5-8500's much greater memory BW. Also, if they're running APU graphics vs GPU can really affect creative/encoding performance.
I may be totally wrong; I'm a lot better at optimizing AMD than Intel. But those are the common bollocks pitfalls I'd be looking for myself, anyways.
This is probably due to the NTFS backing of Cygwin on windows more than anything. NTFS stores all tiny little files inside the MFT which is write blocked. So every time you write a pissy little file out (compiling and VCS stuff does this lots!) it has to lock the MFT, extend and then write the file, then unlock it. This causes MFT contention which reduces the effective IOPS to the disk to virtually nothing even if the thing is fast. In fact mechanical disks can suck less because the kernel has time to order the writes while it's waiting for the disk to go round!
If you want to compile stuff on Windows, do it in a VM with ext4. When you create the VM allocate the entire disk up front so it's one file on NTFS. Do the development work inside the VM!
As an example of the performance difference you can get out of this, check out of an extremely LARGE SVN repo:
NTFS direct = 24 minutes
ext4 in VM = 54 seconds.
You can use fsutil to speed this up a bit (
https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/fsutil )
> fsutil behavior set mftzone 4 (uses 800 megs for MFT allocation speeding up fragmented writes)
> fsutil behavior set disable8dot3 1 (halves fragmented writes)
Yes that's how fucking awful NTFS is as a filesystem. It needs to BURN. That and the Zw API call latency are the number 1 reasons windows is so fucking shit for server and development applications.
This shit costs serious amounts of money but no one is aware of it or the consequences and no one at MSFT gives a shit either. It's also why WSL1 is so fucking slow for reference and quite frankly a joke of a tool.
The thing about the Creality price point is that it's in reach of the average fuckwit and cheap enough for an impulse buy. That has both its good and bad sides.
Yeah and there lots of average fuckwits out there. I keep getting asked about mine from people who see it and instantly want one. These are the sort of people who fuck up the simplest Ikea furniture and can't even manage their Apple account on their phone. What do you say to them?
You say "It's fucking awesome; you really should buy one... or two." Then you direct them to the printer on banggood using your affiliate link.
I like your style