Processor Detection

I haven't blogged in a while because I've been busy with uni and trying to get as much programming done as i can.

I've been working on the processor detection code as it is very important to allow OGE to scale depending on the hardware its running on. It has two possible methods of detecting the information it needs but it depends on the compiler and the operating system that it runs on.

In Visual C++ 2008, it will compile with the newer windows API that provides package/core/logical information. This is only available on windows XP SP3, Vista and Windows Server 2008 (possibly some others that i am not aware of). OGE will check to see if this is available when it is running, if it not, i will revert to the secondary approach.

The secondary approach retrieves the number of logical processors an OS API call, it will then attempt to retrieve the rest of the information from the CPU itself using cpuid. Combining all of this information it can work out the number of cores, although currently it can't work out the number of packages from this.

If both approaches fail, it will default to 1 package, 1 core and 1 logical processor.

On Linux, the primary method is to read in /proc/cpuinfo and parse it to find out all of the processor information it needs. If for some reason it can't do this, it will revert to the secondary approach which is the same as on windows.

Mac support still needs to be done but that can wait till later.

With using these approaches and the features of each compiler, i realise that there is a very specific situation that will result in only the logical processors being detected. This will occur if OGE is compiled using visual studio 2005 as 64bit AND it is executed on a computer that has windows XP SP2 or earlier AND an Intel multi-core processor.

The reason is that visual studio 2005 does not allow use of inline assembly when compiling 64 bit applications, so __cpuid intrinsic must be used. The flaw with it is that it only accepts one input value in EAX, and part of detecting the number of cores requires that ECX be set to 0. This means we can't compile this in, and instead say that it could not be done. As this is the secondary approach, if the target computer is running XP SP3, vista etc it won't ever use this as it will use the primary approach instead. The problem only occurs on Intel multi-core processors because there only they can have hyper-threading.

This is unlikely to ever cause problems as it can be solved in many different ways, such as using visual studio 2008 to compile 64 bit applications (it has __cpuidex intrinsic allowing ECX to be specified).

It has been interesting implementing this, but has taken far too long as well. I will happy to get on with a new task.