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

[patspiper]

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

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