title: Is is valid to assume that Google virtual CPUs are all on 1 socket (if < 16 VCPUs?)
body: <p>We're building a high performance computing scientific application (lots and lots of computations) using Java. To the best of our knowledge, google compute engine does not provide the "true" physical socket information, nor do they have a service like AWS's dedicated hosting (<a href="https://aws.amazon.com/ec2/dedicated-hosts/" rel="nofollow noreferrer">https://aws.amazon.com/ec2/dedicated-hosts/</a>  and then see section on "affinity") where (for a fee) one could see the actual physical sockets.</p>
  
  <p>However, based on our understanding, JIT compiler will do a lot better if it knows that all the threads are really on a single physical socket. Would it be reasonable, therefore, to assume that even though google compute engines do NOT display the true underlying physical socket structure, that if we have a google compute engine that's &lt;= 16 cores, that's it's definitely (or most likely, eg >95%) coming from a single physical socket? If so, we can also then assume that the cpu numbers (when doing cat /proc/cpuinfo) correspond logically (in sequence) to the physical cpu cores/logical cores so that if we wanted our program to put two threads onto the same physical core (but two logical cores), we could just tell it to put the two threads on CPU 0 and 1 and we would know that CPU0 and CPU1 belong to the same physical CPU core, and that CPU2 and CPU3 belong to the same physical core and so on?</p>
  
  <p>If so, would it be reasonable to assume that for compute engines that are 32 VCPUs or 64 VCPUs that the number of sockets are 2 and 4 respectively? And that the result of cat proc/cpuinfo also follows a logical order, so that not only is CPU0 and CPU1 on the same phyisical CPU core, but that we can assume that CPU0 through CPU15 is on physical socket #1, and CPU16 to CPU31 is on physical socket #2 etc?</p>