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