Microsoft's Professional Developers Conference is currently under way, and as usual, the technical fellows at Microsoft gave speeches about the deep architecture of Windows - in this case, Windows 7 of course. As it turns out, quite some seriously impressive changes have been made to the very core of Windows - all without breaking a single application. Thanks to BetaNews for summarising this technical talk so well.

The more fine-grained approach in Windows 7 and Windows Server 2008R2 yields some serious performance improvements: on 32-processor configurations, some operations in SQL and other applications perform 15% faster than on Vista. And remember, the new fine-grained method has been implemented without any application breakage.

In the linked article it says 15 TIMES faster, not percent. That is a big difference

Either way it is good to see Microsoft putting an effort on performance. It will keep the other operating systems on their toes as we can no longer rely on Windows being as crappy and slow as Vista.

This is also making me wonder about some of the locking semantics in the Haiku kernel. I assume we have more fine-grained locking sort of like what Win7 now has.

"While spinlocks comprised 15% of CPU time on systems with about 16 cores, that number rose terribly, especially with SQL Server. "As you went to 128 processors, SQL Server itself had an 88% PFN lock contention rate. Meaning, nearly one out of every two times it tried to get a lock, it had to spin to wait for it...which is pretty high, and would only get worse as time went on."

So this global lock, too, is gone in Windows 7, replaced with a more complex, fine-grained system where each page is given its own lock. As a result, Wang reported, 32-processor configurations running some operations in SQL Server and other applications, ended up running them 15 times faster on Windows Server 2008 R2 than in its WS2K8 predecessor -- all by means of a new lock methodology that is binary-compatible with the old system. The applications' code does not have to change."

Yes, Ryan, I think it'd be nice to address such scalability issues in the Haiku kernel, but.... not worry about them for R1, because that's too sensitive of an area to mutate in such a major way without a rather high risk.