Apple silicon's performance advantage comes not just from its powerful P cores, but from a sophisticated architecture that strategically allocates background tasks to Efficiency cores, keeping foreground applications running smoothly.
Why Apple's Efficiency Cores Are the Unsung Heroes of Mac Performance
If you use an Apple silicon Mac, you've likely been impressed by its performance across various workloads. Whether working with images, audio, video, or building software, we've experienced a significant speed increase since the introduction of the M1 chip. While most attribute this performance boost to the Performance cores, much of the actual advantage comes from the often-overlooked Efficiency cores and how they manage background tasks.
The Architecture Behind the Performance
Apple's silicon implements a big.LITTLE architecture, separating CPU cores into Performance (P) cores and Efficiency (E) cores. This isn't a novel concept—Apple first introduced it with the iPhone 7 in 2016, building on ARM's big.LITTLE announced in 2011 and prior work at companies like Cray. What makes Apple's implementation particularly effective is its thread allocation system based on Quality of Service (QoS).
QoS has been part of macOS since OS X 10.10 Yosemite, but it became central to performance with Apple silicon. The system makes a fundamental distinction between foreground and background threads:
- Foreground threads run on P cores when available but can also use E cores when necessary
- Background threads are restricted to E cores, even if this means they take longer to complete
This design explains why, after starting up an Apple silicon Mac, you see Activity Monitor showing E cores at maximum capacity while P cores remain mostly idle. Background processes like Spotlight indexing, CGPDFService, mediaanalysisd, and others run on E cores, leaving P cores free for user applications.
Visual Deception and Technical Reality
One of the most confusing aspects for users accustomed to Intel Macs is seeing processes using more than 100% CPU. This can appear alarming, especially when multiple mdworker processes each show 50% CPU usage simultaneously. However, this represents a misunderstanding of the architecture.
Part of the confusion stems from a misleading visualization: when E cores and P cores both show 100% in Activity Monitor, they're not actually operating at the same performance level. The E cores at 100% are likely running at a frequency approximately one-quarter of those shown at the same 100% on P cores. This visual comparison is fundamentally false and creates unnecessary concern.
The Strategic Advantage
The restriction of background tasks to E cores provides several key advantages:
- Performance isolation: User applications aren't competing with background processes for CPU resources on the high-performance cores
- Battery efficiency: Background tasks complete on lower-power cores, extending battery life
- Responsiveness: Even with numerous background processes running, the system remains responsive to user input
This architecture explains why we no longer experience the spinning beachball of death caused by runaway mdworker processes that plagued Intel Macs. Instead, macOS efficiently manages workloads by distributing them appropriately between core types.
The Evolution of Apple's Design
Apple has continued to refine this approach with each M-series generation. The M1 Pro and Max were the only chips with just two E cores; every subsequent model has included at least four, with some featuring six or eight. This increase in E core capacity allows for more background tasks to run efficiently without impacting foreground performance.
The modern macOS architecture has evolved to embrace this design philosophy, breaking down monolithic applications into discrete processes that can run in the background on demand. An idle Mac now runs over 2,000 threads across more than 600 processes, with the majority of these background tasks handled by E cores.
Technical Implications
This architecture has significant implications for software development:
- Applications must be designed with the understanding that background tasks will run on less powerful cores
- Developers need to consider how their applications interact with the QoS system
- The traditional approach of using nice scheduling priorities is less effective than designing tasks appropriate for specific core types
Tools like St. Clair Software's App Tamer and the command-line tool taskpolicy demonstrate that background threads cannot be promoted to run on P cores, confirming the intentional nature of this architecture.
Conclusion
Apple's silicon performance advantage comes not just from raw processing power but from a sophisticated architecture that strategically allocates workloads. By restricting background tasks to Efficiency cores, Apple ensures that Performance cores remain available for foreground applications, resulting in a system that remains responsive even under heavy background loads.
The next time you see your Mac's E cores maxed out after startup, remember that this represents efficient design rather than a problem. The system is working as intended, with background processes handled appropriately while keeping your applications running smoothly.
Comments
Please log in or register to join the discussion