Not that I really want to enter into the meat of this debate, but Windows Server 2012 supports 640 logical processors (cores or threads,) not 256. Install the Hyper-V role and that number drops to 320.
- Jake Oshins
Windows Kernel Team
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@osr.com
Sent: Tuesday, November 20, 2012 6:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Spinlock vs RWLocks
Hmmm… let me think… “that well exceeds the one described by unsigned short type”… UCHAR… USHORT… what WOULD that number be? USHORT’s half an ULONG… and we’re talking C in kernel mode here… Hmmmm… 65536? Yes, I think that’s what you meant. 65536! More than 65535 CPUs? Why would I do that? Windows only supports 256 CPUs per system.
But… I’ll play along for fun, because well, it’s still morning here and I haven’t left for the office yet. So, here’s my answer: If that’s the environment that my software is targeting… why, yes. If not in-house, then certainly at a test site with which I’m partnering.
I guess I don’t understand your entire point (hey, THAT’s a first, huh?).
The way WE write software is we create a set of functional requirements, define a design that we expect will meet those requirements, write the software, and then test our software to determine – as far as practical – that our implementation and design in fact DO meet the stated functional requirements. The requirements, of necessity, include supported target environments and performance metrics, if performance is part of the goal.
One place where I *will* differ, if only slightly, from Mr. Tippet is that in some cases, or for some releases, or for some operations, performance is completely secondary to functionality. The product has to work properly, even if it exhibits crappy performance. In these cases, I’ve found that it actually works to have a performance goal that’s entirely subjective. For example, the goal might be “doing xyz in environment abc must work, and performance can’t totally suck” – My experience is that three or four engineers locked in a room can generally come to a consensus on when performance of an operation does and does not “totally suck.” Yes, this is a VERY LOW performance goal… but it’s still a valid goal. And YES, you might get customers who disagree when it comes to whether the exhibited performance in their environment “totally sucks” or not. In that case, you explain to them that functionality and not performance was the goal for the product/release/feature and whether you ever plan to enhance the performance in this area.
In general, when we have customers that report our software behaving in ways other than those we’ve specified, performance or otherwise, we first ask: “Is this product running in a way we intended and in a supported environment?” If it’s not, we explain that to the customer.
If you try to dig a hole with an axe, and you break that axe handle, it’s REALLY not a problem the axe manufacturer should have to deal with. You can complain all you want about how the axe is inefficient, and how the handle should not have broken, but the bottom line is the problem lies with YOU not with the axe – you’re using the wrong tool for the job.
It’s no different in the world of software. In the real world, there’s zero need to complicate things further. You just make your job harder, and you gain nothing.
Peter
OSR
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer