That's just in case you have to go back because of recursive problems that I have seen pop up in Entropia Universe, seen this since the days when the game was called Project Entropia. Obviously there wasn't this particular chip wasn't around back then but problems like this did exist.
When I design and code schedulers for games and other multimedia applications, I code for general code base and have additional libraries and routines to use with the special instructions if they exist, I don't hard code it for AMD 3D Now or any other specialized instruction set, which can lead you down a bad path for compatibility purposes. There was only 1 CPU that I had trouble with and that was a bugged engineering sample that I received from Intel, the very first X5600 Xeon, not the ones you find on the market today which I had to release a patch for game developers to use to patch their game engines so it would work seamlessly.
Usually, what I see isn't an affinity situation anymore, that was around 12 years ago when I saw that problem, it's more with timing issues when people overclock now and errors due to this nature. Granted, overclocking is great if you keep your system cool but it can also wreak havoc on schedulers because the system clock isn't stable under heavy load (conventional electronics this is true, like Intel i7, etc).
Put it this way, if I have trouble with the max load on a system causing problems in my schedulers, Microsoft then too will also have said problems. If you're curious as to what the actual problem that screws up a scheduler it's when the internal cache on the CPUs aren't updated in time with new data or Microsoft Windows doesn't receive a hardware interrupt from one or more cores in the time it expects it. That's not so much anything I can do about that so I do my best to code for a case like that.
I do also code for Linux on occasion, when I do schedulers in that, there isn't too much of a problem in that regard, it's just that when everything (or almost everything) is open source, it makes it hard to code for every distribution out there, especially when people change how the kernel works which is a pain in the arse.
This is another reason why big developers don't develop for the eight thousand + Linux distros out there, too much variation and very lax standards (wait? they have standards?!?).
I was working on a UNIX like operating system, free like Linux or FreeBSD but copyrighted and offered as a blob file download, no source. This would be my reasoning, don't want people branching off and making distros like Linux. The idea of Linux is great, it's how it is being handled by the community that is the sticking point.
Realistically speaking, there is a free blob (binary only) library that can be used in Linux that could allow Crytek to extend their product line of Cry Engine 2 and 3 into Linux, thus, MindArk could then also product native clients of Entropia Universe. There is one thing good I will say about Linux, they're a lot more stable in kernels when overclocked than Microsoft is, thus I don't have to worry so much about coding for worse case scenarios.
By the way, the job of the hardware abstraction layer (HAL) is to provide a virtual means for the operating system to interface with low level hardware. Some of the early drivers for the Bulldozer CPUs from AMD weren't that great and led to timing issues. This could also cause system to halt in certain applications, although, I didn't personally see that happen to me or anyone else I knew but it was released by AMD and they were working on it, apparently they solved it, that particular problem about 2 months after the initial release. It affected Windows XP, XP-64 and Vista x86 / x64 only. Wasn't a problem on 7 or 8.
