<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>