On some virtual machines, library returns zero number of cores.

[alexey-milovidov]

Look at ClickHouse/ClickHouse#53 (comment)

As I remember, variable 'num_core' is equal to zero here: https://github.com/anrieff/libcpuid/blob/master/libcpuid/recog_intel.c#L561

[anrieff]

Hi!
Yes, VM hosts virtualize the results of the cpuid instruction to the point it doesn't look like a real CPU anymore. libcpuid detection can be (dis)trusted to varying degrees under a VM for that reason, since it may be not very obvious what they changed about cpuid's return results.

This particular error is caused by a VM which was allotted only one "processor", thus num_core=1, however the VM host didn't change num_smt, which on the real CPU is 2. Thus 1/2 = 0. On a "real" cpu such a bug could never happen.

For the usual computing tasks, the recommended approach is to use cpu_id_t::total_logical_cpus, which is obtained underneath through OS routines and should be always correct. In most cases you wouldn't care how many actual, real cores a CPU has - and whether it has HT. We just want to launch a computation on all possible compute units. On a 4-core HT CPU, that would be 8; in a VM on the same machine, with 1 "processor" allotted, that would be 1, and total_logical_cpus will be having the correct value in both cases.

That being said, I'll change the code line to something like data->num_cores = max(num_core / num_smt, 1);. It doesn't change anything on a real CPU, and would prevent the idiotic zero return under a VM.

[alexey-milovidov]

Thanks for detailed explanation!

That being said, I'll change the code line to something like data->num_cores = max(num_core / num_smt, 1);. It doesn't change anything on a real CPU, and would prevent the idiotic zero return under a VM.

Seems fine.

[anrieff]

Fixed in e0505af