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

[patspiper]

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.

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