<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: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>
<br>
Stephano<br>
</body>
</html>