[fpc-devel] Feature announcement: Extension of TThread's interface

[patspiper]

On 28/12/12 17:46, patspiper wrote:
> On 28/12/12 17:41, patspiper wrote:
>> On 28/12/12 17:00, Ewald wrote:
>>> Once upon a time, on 12/28/2012 11:01 AM to be precise, patspiper said:
>>>> On 27/12/12 22:38, Ewald wrote:
>>>>> Hmmm, that;s indeed quite some different output you've got there. 
>>>>> Mine looks like this:
>>>>>
>>>>>     processor       : 0
>>>>>     vendor_id       : GenuineIntel
>>>>>     cpu family      : 6
>>>>>     model           : 23
>>>>>     model name      : Intel(R) Core(TM)2 Duo CPU E8600  @ 3.33GHz
>>>>>     stepping        : 10
>>>>>     microcode       : 0xa07
>>>>>     cpu MHz         : 2000.000
>>>>>     cache size      : 6144 KB
>>>>>     physical id     : 0
>>>>>     siblings        : 2
>>>>>     core id         : 0
>>>>>     cpu cores       : 2
>>>>>     apicid          : 0
>>>>>     initial apicid  : 0
>>>>>     fpu             : yes
>>>>>     fpu_exception   : yes
>>>>>     cpuid level     : 13
>>>>>     wp              : yes
>>>>>     flags           : fpu vme de pse tsc msr pae mce cx8 apic sep
>>>>>     mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2
>>>>>     ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts
>>>>>     rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est
>>>>>     tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm dtherm
>>>>>     tpr_shadow vnmi flexpriority
>>>>>     bogomips        : 6668.63
>>>>>     clflush size    : 64
>>>>>     cache_alignment : 64
>>>>>     address sizes   : 36 bits physical, 48 bits virtual
>>>>>     power management:
>>>>>
>>>>>
>>>>> (this is repeated twice, with only `processor:0` changing to 
>>>>> `processor:1`)
>>>>>
>>>>>
>>>>> Since this is the same kind of output I got on several other linux 
>>>>> distributions/architectures(--> 32 bit versus 64 bit intel), I 
>>>>> assumed it was kinda `standard`. Then again assume = ...
>>>>>
>>>>> Well, anyway, it's a bit trickier than I thought at first in that 
>>>>> case.
>>>>
>>>> I guess one way of calculating the number of processors is to 
>>>> iterate through every 'processor' in the list and add 1 if 
>>>> 'siblings' = 'cpu cores' (no hyperthreading), and 0.5 if 'siblings' 
>>>> = 2 x 'cpu cores' (hyperthreading enabled).
>>> Yeah, that could work, but then again the actual format of the data 
>>> may be different measured over several distributions: suppose all 
>>> `:` all of the sudden become `=`? Suppose that an identifier like 
>>> `processor` undergoes a slicht namechange to `processorid`?
>> A workaround for this specific type of uncertainty can use a 
>> different logic: The count of distinct (physical id, core id) lines 
>> is the actual number of cores. That way = or : will not matter 
>> anymore. This excludes identifier changes of course.
>>>
>>> As I said, I didn't know formats of /proc/cpuinfo differ over 
>>> distributions/os'es, so it isn't safe to use this approach since all 
>>> of the sudden a simly system update *might* just break your application.
>> True. A better bet would be to look for the code that produces the 
>> cpuinfo, and use that code directly.
> Try lscpu -p
More options:
nproc (returns the number of processing units available whatever that 
means).
or use libcpuid (http://libcpuid.sourceforge.net/index.html)

Example (not tested):

#include <stdio.h>
#include <libcpuid.h>

int main(void)
{
     if (!cpuid_present()) {
         printf("Sorry, your CPU doesn't support CPUID!\n");
         return -1;
     }

     struct cpu_raw_data_t raw;
     struct cpu_id_t data;

     if (cpuid_get_raw_data(&raw) < 0) {
         printf("Sorry, cannot get the CPUID raw data.\n");
         printf("Error: %s\n", cpuid_error());
         return -2;
     }

     if (cpu_identify(&raw, &data) < 0) {
         printf("Sorrry, CPU identification failed.\n");
         printf("Error: %s\n", cpuid_error());
         return -3;
     }

     printf("Processor has %d physical cores\n", data.num_cores);
     return 0;
}

Stephano
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20121228/49145988/attachment.html>