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
_______________________________________________
fpc-devel maillist  -  [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply via email to