<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 28/12/12 17:41, patspiper wrote:<br>
</div>
<blockquote cite="mid:50DDBDB8.90301@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 28/12/12 17:00, Ewald wrote:<br>
</div>
<blockquote cite="mid:50DDB406.9000703@yellowcouch.org"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Once upon a time, on 12/28/2012
11:01 AM to be precise, patspiper said:<br>
</div>
<blockquote cite="mid:50DD6E12.6050504@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 27/12/12 22:38, Ewald wrote:<br>
</div>
<blockquote cite="mid:50DCB1D8.2030109@yellowcouch.org"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Hmmm, that;s indeed quite some
different output you've got there. Mine looks like this:<br>
<br>
<blockquote>processor : 0<br>
vendor_id : GenuineIntel<br>
cpu family : 6<br>
model : 23<br>
model name : Intel(R) Core(TM)2 Duo CPU E8600
@ 3.33GHz<br>
stepping : 10<br>
microcode : 0xa07<br>
cpu MHz : 2000.000<br>
cache size : 6144 KB<br>
physical id : 0<br>
siblings : 2<br>
core id : 0<br>
cpu cores : 2<br>
apicid : 0<br>
initial apicid : 0<br>
fpu : yes<br>
fpu_exception : yes<br>
cpuid level : 13<br>
wp : yes<br>
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<br>
bogomips : 6668.63<br>
clflush size : 64<br>
cache_alignment : 64<br>
address sizes : 36 bits physical, 48 bits virtual<br>
power management:<br>
</blockquote>
<br>
(this is repeated twice, with only `processor:0` changing
to `processor:1`)<br>
<br>
<br>
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 = ...<br>
<br>
Well, anyway, it's a bit trickier than I thought at first
in that case.<br>
</div>
</blockquote>
<br>
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).<br>
</blockquote>
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`?<br>
</blockquote>
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.<br>
<blockquote cite="mid:50DDB406.9000703@yellowcouch.org"
type="cite"> <br>
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.<br>
</blockquote>
True. A better bet would be to look for the code that produces the
cpuinfo, and use that code directly.<br>
</blockquote>
Try lscpu -p<br>
<br>
Stephano<br>
</body>
</html>