如何使用C获取Linux中的CPU数量?
Linux 中有没有可以获取可用 CPU 数量的 API? 我的意思是,在不使用 /proc/cpuinfo 或任何其他 sys-node 文件的情况下...
我发现使用 sched.h 实现了此实现:
int GetCPUCount()
{
cpu_set_t cs;
CPU_ZERO(&cs);
sched_getaffinity(0, sizeof(cs), &cs);
int count = 0;
for (int i = 0; i < 64; i++)
{
if (CPU_ISSET(i, &cs))
count++;
else
break;
}
return count;
}
但是,没有使用通用库的更高级别吗?
Is there an API to get the number of CPUs available in Linux?
I mean, without using /proc/cpuinfo or any other sys-node file...
I've found this implementation using sched.h:
int GetCPUCount()
{
cpu_set_t cs;
CPU_ZERO(&cs);
sched_getaffinity(0, sizeof(cs), &cs);
int count = 0;
for (int i = 0; i < 64; i++)
{
if (CPU_ISSET(i, &cs))
count++;
else
break;
}
return count;
}
But, isn't there anything more higher level using common libraries?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(9)
https://linux.die.net/man/3/get_nprocs
https://linux.die.net/man/3/get_nprocs
此代码(取自此处)应该适用于两者Windows 和 *NIX 平台。
This code (drawn from here) should work on both windows and *NIX platforms.
您在开头提到的
sched_affinity()
版本仍然比/proc/cpuinfo
和/或_SC_NPROCESSORS_ONLN
更好,因为它只计算可用的 CPU给定进程(某些进程可能会被外部进程调用的 sched_setaffinity() 禁用)。唯一的变化是使用CPU_COUNT()
而不是在循环中执行CPU_ISSET
。sched_affinity()
version you mention in the beginning is still better than/proc/cpuinfo
and/or_SC_NPROCESSORS_ONLN
since it only counts CPUs available for a given process (some may be disabled bysched_setaffinity()
invoked by an outside process). The only change would be usingCPU_COUNT()
instead of doingCPU_ISSET
in a loop.使用 /proc/cpuinfo 是最干净、最可移植的解决方案。如果打开失败,您可以简单地假设 1 个 cpu 或 2 个 cpu。出于微优化之外的目的(例如选择要运行的理想线程数)而依赖于了解 cpu 数量的代码几乎肯定会做一些愚蠢的事情。
_SC_NPROCESSORS_ONLN
解决方案依赖于非标准(glibc 特定的)sysconf
扩展,该扩展比/proc
具有更大的依赖性(所有 Linux系统有/proc
,但有些系统有非 glibc libcs 或缺少_SC_NPROCESSORS_ONLN
的旧版本 glibc)。Using
/proc/cpuinfo
is the cleanest and most portable solution. In case the open fails, you could simply assume 1 cpu or 2 cpus. Code that depends on knowing the number of cpus for a purpose other than micro-optimizing (e.g. choosing the ideal number of threads to run) is almost surely doing something dumb.The
_SC_NPROCESSORS_ONLN
solution depends on a non-standard (glibc-specific)sysconf
extension, which is a much bigger dependency than/proc
(all Linux systems have/proc
, but some have non-glibc libcs or older versions of glibc that lack_SC_NPROCESSORS_ONLN
).涉及
sysconf(...)
或get_nprocs()
的答案对于遵守由 cpu 亲和性限制的任务的处理器数量来说都是不正确的。您需要这样的方法来获取任务可用的处理器数量:
None of the answers that involve
sysconf(...)
orget_nprocs()
are correct for honouring the number of processors restricted to a task by cpu affinity.You need something like this to get the number of processors available to a task:
就我个人而言,对于最近的 Intel cpu(不是一般的 x86,只是 Intel),我使用
EAX=0Bh
cpuid
叶子。请参阅维基百科,了解有关您获得的信息的一些详细信息关于当前套接字(又名封装)中的核心。在多插槽系统上,这可能是系统范围物理/逻辑核心数量的一半或四分之一。英特尔有输出:
或者,更简洁地说:
输出:
Personally for recent Intel cpus (not x86 in general, just Intel) I use the
EAX=0Bh
cpuid
leaf. See Wikipedia for some details on what info you get about the cores in the current socket aka package. On a multi-socket system, this might be half or a quarter of the system-wide number of physical / logical cores. Intel has a whitepaper on enumerating CPUs with details on what to check in case of multi-socket systems. This code doesn't do that, it just checks one sub-leaf (ECX=1).Output:
Or, more concisely:
Output:
在 Linux (Ubuntu) 上:(
假设当前进程具有默认的 CPU 关联性。)
On Linux (Ubuntu):
(Assuming the current process has the default CPU affinity.)
另一种扫描 sys 文件系统下的 cpu* 目录的方法:
Another method scanning cpu* directories under sys file system: