Anonymous MSFT developer admits Linux is faster than Windows
Linux is far faster than Windows. That's old news. It's why Linux runs 90 percent of the world's top 500 fastest supercomputers, while Windows runs 1 percent of them. What's new "news" is that an alleged Microsoft operating system developer recently admitted that Linux is indeed much faster, and explained why that's the case.
This anonymous, supposed Windows kernel programmer first made his comments on a Hacker News conversation thread. He then followed up with further comments on Marc Bevand's Zorinaq blog. Bevand is a senior software engineer for Adconion, who specializes in high-performance computing (HPC).
The alleged Microsoft developer opened by saying, "Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening. The cause of the problem is social. There's almost none of the improvement for its own sake, for the sake of glory, that you see in the Linux world."
It's not that Windows developers don't want to improve their operating system's performance; the problem is that Microsoft's software development culture discourages improvements. The alleged programmer wrote:
Granted, occasionally one sees naive people try to make things better. These people almost always fail. We can and do improve performance for specific scenarios that people with the ability to allocate resources believe impact business goals, but this work is Sisyphean. There's no formal or informal program of systemic performance improvement. We started caring about security because pre-SP3 Windows XP was an existential threat to the business. Our low performance is not an existential threat to the business.
See, component owners are generally openly hostile to outside patches: If you're a dev, accepting an outside patch makes your lead angry (due to the need to maintain this patch and to justify in shiproom the unplanned design change), makes test angry (because test is on the hook for making sure the change doesn't break anything, and you just made work for them), and PM [project manager] is angry (due to the schedule implications of code churn). There's just no incentive to accept changes from outside your own team. You can always find a reason to say "no", and you have very little incentive to say "yes".
There's also little incentive to create changes in the first place. On linux-kernel, if you improve the performance of directory traversal by a consistent 5 percent, you're praised and thanked. Here, if you do that and you're not on the object manager team, then even if you do get your code past the Ob owners and into the tree, your own management doesn't care. Yes, making a massive improvement will get you noticed by senior people and could be a boon for your career, but the improvement has to be very large to attract that kind of attention. Incremental improvements just annoy people and are, at best, neutral for your career. If you're unlucky and you tell your lead about how you improved performance of some other component on the system, he'll just ask you whether you can accelerate your bug glide.
From where he sits, Microsoft is also losing its top talent to the competition. He wrote, "Another reason for the quality gap is that that we've been having trouble keeping talented people. Google and other large Seattle-area companies keep poaching our best, most experienced developers, and we hire youths straight from college to replace them. You find SDEs [Microsoft Software Development Engineer] and SDE IIs maintaining hugely import systems. These developers mean well, and are usually adequately intelligent, but they don't understand why certain decisions were made, don't have a thorough understanding of the intricate details of how their systems work, and most importantly, don't want to change anything that already works."
On top of that, he claimed, Microsoft "junior developers also have a tendency to make improvements to the system by implementing brand-new features instead of improving old ones. Look at recent Microsoft releases: we don't fix old features, but accrete new ones. New features help much more at review time than improvements to old ones. (That's literally the explanation for PowerShell. Many of us wanted to improve cmd.exe, but couldn't.)"
For sheer snark, it's hard to beat his thoughts on the NT File System (NTFS): "Oh god, the NTFS code is a purple opium-fueled Victorian horror novel that uses global recursive locks and SEH [Structured Exception Handling] for flow control. Let's write ReFs [ Resilient File System] instead. (And, hey, let's start by copying and pasting the NTFS source code and removing half the features! Then let's add checksums, because checksums are cool, right, and now with checksums we're just as good as ZFS [Z File System] ? Right? And who needs quotas anyway?)"
None of these "revelations" are really that new. Anyone who'd followed Mini-Microsoft, an anonymous insider's view of life in Microsoft's development cubicle farms, or has read comments from disgruntled ex-Microsoft developers such as Hamilton Verissmo, knows about Microsoft's development bureaucracy getting in the way of innovation. As Brian Cody, a former Microsoft engineer, told Forbes Magazine in 2012, being a successful Microsoft software developer "was always much less about how I could become a better engineer and much more about my need to improve my visibility among other managers".
In short, Microsoft has become an "old" company. It's no surprise that today, Microsoft focuses more on playing catch-up with tablets and smartphones with misfires such as Windows 8 Metro than actually improving its fundamental software performance.
People are reacting to this new look inside Microsoft as it if were shocking. It's not. As the developer himself added, as the story began to spread through the blogosphere, it "has gotten out of control. I was much too harsh, and I didn't intend this as some kind of massive exposé. This is just grumbling".
In a particular, he semi-apologized for his NTFS comments: "NTFS does use SEH internally, but the filesystem is very solid and well tested. The people who maintain it are some of the most talented and experienced I know. (Granted, I think they maintain ugly code, but ugly code can back good, reliable components, and ugliness is inherently subjective.)"
In an attempt to spin the sum of complaints in a more positive way, he added, "Windows and Microsoft still have plenty of technical talent. We do not ship code that someone doesn't maintain and understand, even if it takes a little while for new people to ramp up sometimes. While I have read and write access to the Windows source and commit to it once in a while, so do tens and tens of thousands of other people all over the world. I am nobody special ... We almost never make decisions individually, and while I maintain that social dynamics discourage risk taking and spontaneous individual collaboration, I want to stress that we are not insane, and we are not dysfunctional. The social forces I mentioned act as a drag on innovation, and I think we should do something about the aspects of our culture that I highlighted, but we're far from crippled. The negative effects are more like those incurred by mounting an unnecessary spoiler on a car than tearing out the engine block. What's indisputable fact is that our engineering division regularly runs and releases dependable, useful software that runs all over the world. No matter what you think of the Windows 8 UI, the system underneath is rock solid, as was Windows 7, and I'm proud of having been a small part of this entire process."
Rock solid? The monthly Microsoft patch Tuesdays and the constant out of schedule zero-day fixes, such as May's IE 8 fix, leaves me doubting, as always, Windows' security and stability, but what else can a Microsoft employee say? In any case, when it comes to speed, Linux, not Windows, as he himself still admitted, remains the clear champ.
Related stories