Introduction

There is no portable ISO C or ISO C++ API that tells you "this is a high-performance core" and "that is an efficiency core." On heterogeneous CPUs, that information is platform-specific. So the practical answer in C or C++ is: use operating-system APIs, vendor-specific topology libraries, or sysfs-style metadata when available, and be prepared for the fact that some systems will not expose the distinction cleanly at all.

Why Standard C And C++ Cannot Tell You

The language standards know about threads as an abstraction, not about CPU performance classes. std::thread, pthread, and similar interfaces can create threads and sometimes influence affinity, but they do not define a standard way to classify hardware threads by core type.

That means the problem breaks down into two smaller tasks:

• discover processor topology from the OS
• optionally pin work to selected CPUs or let the scheduler decide

Windows: Efficiency Class And CPU Sets

On modern Windows systems, CPU-set and processor-information APIs can expose per-CPU characteristics that help distinguish more performant and more efficient cores.

A common low-level route uses GetSystemCpuSetInformation.

1#include <windows.h>
2#include <stdio.h>
3#include <stdlib.h>
4
5int main(void) {
6    DWORD len = 0;
7    GetSystemCpuSetInformation(NULL, 0, &len, GetCurrentProcess(), 0);
8
9    SYSTEM_CPU_SET_INFORMATION *buffer = (SYSTEM_CPU_SET_INFORMATION *)malloc(len);
10    if (!buffer) return 1;
11
12    if (!GetSystemCpuSetInformation(buffer, len, &len, GetCurrentProcess(), 0)) {
13        free(buffer);
14        return 1;
15    }
16
17    BYTE *ptr = (BYTE *)buffer;
18    BYTE *end = ptr + len;
19
20    while (ptr < end) {
21        SYSTEM_CPU_SET_INFORMATION *info = (SYSTEM_CPU_SET_INFORMATION *)ptr;
22        if (info->Type == CpuSetInformation) {
23            printf("CPU %u efficiency class %u\n",
24                   info->CpuSet.LogicalProcessorIndex,
25                   info->CpuSet.EfficiencyClass);
26        }
27        ptr += info->Size;
28    }
29
30    free(buffer);
31    return 0;
32}

The exact interpretation of EfficiencyClass is platform-defined, but on hybrid CPUs it is one of the stronger OS-level signals available.

Linux: Sysfs And Topology Libraries

On Linux, there is no single universal interface that works on every kernel and CPU family. Depending on the platform, useful information may appear under /sys/devices/system/cpu/, and topology libraries such as hwloc can help build a more complete picture.

A simple sysfs-style probe might inspect per-CPU metadata when the platform exposes it:

1#include <stdio.h>
2
3int main(void) {
4    for (int cpu = 0; cpu < 8; ++cpu) {
5        char path[256];
6        snprintf(path, sizeof(path), "/sys/devices/system/cpu/cpu%d/cpu_capacity", cpu);
7
8        FILE *f = fopen(path, "r");
9        if (!f) continue;
10
11        int capacity = 0;
12        if (fscanf(f, "%d", &capacity) == 1) {
13            printf("cpu%d capacity=%d\n", cpu, capacity);
14        }
15        fclose(f);
16    }
17    return 0;
18}

This is not guaranteed on every Linux system, but it illustrates the basic idea: on Linux, detection is often heuristic and platform-dependent.

The Scheduler May Still Know Better

Even if you can classify cores, manually pinning threads is not always an improvement. Modern schedulers already know about core classes on many systems and may place work better than a naïve hardcoded policy.

A practical rule:

• pin threads only when profiling shows a real benefit
• otherwise, let the OS scheduler do its job

This is especially important for mixed workloads where thermal limits, background processes, and thread wakeups make static placement less effective than it looks on paper.

Libraries Can Help More Than Raw APIs

If your project genuinely needs hardware-topology awareness, a library such as hwloc is often a better long-term option than writing one-off probes for every OS yourself. It can expose sockets, cores, caches, NUMA nodes, and other topology details more portably than custom platform parsing.

It still will not make heterogeneous-core detection perfectly uniform everywhere, but it gives you a better abstraction layer.

Distinguish Discovery From Affinity

These are separate questions:

• how do I detect fast and slow cores
• how do I bind work to the CPUs I want

Detection may use topology APIs. Affinity may use APIs such as sched_setaffinity on Linux or thread affinity functions on Windows. Do not conflate the two problems.

Common Pitfalls

• Looking for a portable standard C or C++ call that simply does not exist.
• Assuming every operating system exposes high-performance and efficiency-core metadata the same way.
• Pinning threads manually before confirming that the scheduler is actually doing a worse job.
• Mistaking logical processor count for core-type information.
• Writing detection logic that works on one CPU family and assuming it is universal.

Summary

• There is no portable standard C or C++ API for distinguishing high- and low-performance cores.
• You need OS-specific APIs, sysfs-style metadata, or topology libraries.
• Windows exposes useful CPU-set information such as efficiency class.
• Linux support is more platform-dependent and often requires sysfs inspection or hwloc.
• Detect core classes only when you truly need the information, and pin threads only after profiling proves it helps.