The Yin and Yang of power and performance for asymmetric hardware and managed software

Abstract

Abstract-On the hardware side, asymmetric multicore processors present software with the challenge and opportunity of optimizing in two dimensions: performance and power. Asymmetric multicore processors (AMP) combine general-purpose big (fast, high power) cores and small (slow, low power) cores to meet power constraints. Realizing their energy efficiency opportunity requires workloads with differentiated performance and power characteristics.On the software side, managed workloads written in languages such as C#, Java, JavaScript, and PHP are ubiquitous. Managed languages abstract over hardware using Virtual Machine (VM) services (garbage collection, interpretation, and/or justin-time compilation) that together impose substantial energy and performance costs, ranging from 10% to over 80%. We show that these services manifest a differentiated performance and power workload. To differing degrees, they are parallel, asynchronous, communicate infrequently, and are not on the application's critical path.We identify a synergy between AMP and VM services that we exploit to attack the 40% average energy overhead due to VM services. Using measurements and very conservative models, we show that adding small cores tailored for VM services should deliver, at least, improvements in performance of 13%, energy of 7%, and performance per energy of 22%. The yin of VM services is overhead, but it meets the yang of small cores on an AMP. The yin of AMP is exposed hardware complexity, but it meets the yang of abstraction in managed languages. VM services fulfill the AMP requirement for an asynchronous, non-critical, differentiated, parallel, and ubiquitous workload to deliver energy efficiency. Generalizing this approach beyond system software to applications will require substantially more software and hardware investment, but these results show the potential energy efficiency gains are significant.

Don't race the memory bus: taming the GC leadfoot

“…As a result, memory operations to load and trace the references dominate collector instructions, and incur more memory cycles per instruction than compute-bound mutator workloads. Motivated by this specialized GC workload, several studies have explored offloading GC work to: (i) dedicated slow cores [15,43], (ii) GPUs [33], and (iii) even specialized hardware [8][9][10] Here, we explore the direct power impact of Dalvik's concurrent collector on the Android mobile platform. Mobile devices use sophisticated power management strategies in both hardware and software, with only simple communication among the layers.…”

“…Further, measuring energy can only be achieved by measuring the power at the circuit level as the product of measured current I and the the voltage drop V across the CPU. However, measuring total AC current to the device with a clamp ammeter is not precise enough to measure the effects of workload on CPU power [15]. Evenso, measuring power on the SoC level does not account solely for workload on the cores since it also includes power consumed by other on-chip components (modem, GPU, sensors, etc.…”

“…Sartor and Eeckhout [43] explored tradeoffs with separating JVM threads (e.g., garbage collector) and its effect on performance for a multi-socket server environment (8-core Intel Nehalem). For managed run-time systems on general purpose platforms, there is much recent interest in fine-grained power and to understand the energy needs of VM components [15,47]. Occasionally, GC has been evaluated as an asymmetric activity that can be isolated on a separate core [15,43].…”

“…For managed run-time systems on general purpose platforms, there is much recent interest in fine-grained power and to understand the energy needs of VM components [15,47]. Occasionally, GC has been evaluated as an asymmetric activity that can be isolated on a separate core [15,43]. However, their methodology relies on dedicated hardware which is impractical for modern mobile devices.…”

“…Prior work has explored this tradeoff for general-purpose platforms [15,23,40,43], including surveying energy management across the stack [32]. Nevertheless, interactions across layers on mobile devices have not been directly addressed, even as such devices are more sensitive to energy and thermal conditions.…”