왜 E 코어가 Apple silicon을 빠르게 만드는가
Source: Hacker News
Observing CPU usage on startup
- Start your Apple silicon Mac from a cold boot.
- Open Activity Monitor, switch to the CPU view, and open the CPU History window.
During the first five to ten minutes you’ll see the E cores lit up with activity from processes such as:
- Spotlight indexing services
CGPDFServicemediaanalysisdBackgroundShortcutRunner- Siri components
- The initial Time Machine backup
- An XProtect Remediator scan
Meanwhile the P cores remain largely idle, leaving plenty of capacity for the apps you launch.
Seeing many processes using more than 100 % CPU can be alarming for former Intel‑Mac users, who know that heavy load on a single core can degrade foreground performance. On Apple silicon, however, those high percentages often belong to dozens of mdworker processes each taking ~50 % CPU simultaneously—something the architecture is built to handle. The visual comparison is misleading because an E core running at “100 %” operates at roughly a quarter of the frequency of a P core shown at the same percentage, making the raw numbers not directly comparable. (See the discussion on why CPU usage in Activity Monitor can be deceptive: .)
The big.LITTLE concept and Quality of Service
Apple introduced separate P and E cores to the iPhone 7 in 2016, adopting Arm’s big.LITTLE architecture (announced in 2011). The idea had been explored earlier by groups such as Cray () and elsewhere.
What distinguishes Apple silicon Macs is how threads are allocated to the two core types based on Quality of Service (QoS), a metric introduced in OS X 10.10 Yosemite (). When all cores are identical, QoS offers limited benefit over traditional scheduling priorities like POSIX nice. Background tasks still need to run, and lowering their priority merely prolongs their execution, extending the period during which they compete with user apps for CPU cycles.
QoS‑driven thread scheduling
Apple’s experience with iOS devices led to a refined approach for macOS:
- Foreground threads – preferentially scheduled on P cores when available, but can fall back to E cores if needed.
- Background threads – restricted to E cores; they are not promoted to P cores even when the E cores are heavily loaded.
This behavior is observable with tools such as St. Clair Software’s App Tamer () and the command‑line utility taskpolicy, which cannot force a background thread onto a P core.
Consequently, even if you watch numerous background processes saturate the E cores right after startup, macOS deliberately keeps the P cores idle for foreground work. Allowing background threads onto P cores would blur the foreground/background distinction, degrade app responsiveness, and reduce battery life. It also eliminates the old problem of “crashing mdworker processes” that once caused frequent beach‑balling ().
Impact on software architecture and performance
The high CPU percentages shown for background tasks can look intimidating, but they reflect a shift in software design:
- Applications are increasingly broken into discrete processes that run on demand in the background.
- An idle Mac may host over 2,000 threads across 600+ processes; the more of these run on E cores, the faster the foreground experience.
Apple’s M‑series chips have progressively increased the number of E cores. The M1 Pro and M1 Max were the last to have only two E cores; newer models feature at least four, with some offering six or eight.
Because Efficiency cores handle background work, the Performance cores remain available for the tasks that matter most to the user, delivering both speed and energy efficiency.