Energy Efficiency Features of the Intel Skylake-SP Processor and Their Impact on Performance

TL;DR

This paper analyzes the energy efficiency features of the Intel Skylake-SP processor, revealing their effects on performance and power consumption, with implications for HPC system optimization.

Contribution

It provides an architectural analysis of Skylake-SP's energy efficiency features and their impact on performance, extending insights to future Intel architectures.

Findings

C-state latencies increased over Haswell-EP

Uncore frequency control has ~10 ms latency

Data significantly affects power consumption

Abstract

The overwhelming majority of High Performance Computing (HPC) systems and server infrastructure uses Intel x86 processors. This makes an architectural analysis of these processors relevant for a wide audience of administrators and performance engineers. In this paper, we describe the effects of hardware controlled energy efficiency features for the Intel Skylake-SP processor. Due to the prolonged micro-architecture cycles, which extend the previous Tick-Tock scheme by Intel, our findings will also be relevant for succeeding architectures. The findings of this paper include the following: C-state latencies increased significantly over the Haswell-EP processor generation. The mechanism that controls the uncore frequency has a latency of approximately 10 ms and it is not possible to truly fix the uncore frequency to a specific level. The out-of-order throttling for workloads using 512 bit wide vectors also occurs at low processor frequencies. Data has a significant impact on processor power consumption which causes a large error in energy models relying only on instructions.

Tables

Table 1. Table I: Comparison of Haswell-EP and Skylake-SP processors

Microarchitecture	Haswell-EP	Skylake-SP 6100/8100
References	[8, 9, 10, 11]	[8, 11, 12, 13]
Allocation queue	56/core	64/thread
Execute	8 micro-ops/cycle	8 micro-ops/cycle
Scheduler entries	60	97
ROB entries	192	224
INT/FP register file	168/168	180/168
SIMD ISA	AVX2	AVX-512
FPU width	2×256 Bit FMA	2×512 Bit FMA
FLOPS/cycle (double)	16	32
Load/store buffers	72/42	72/56
L1D accesses	2×32 B load +	2×64 B load +
per cycle	1×32 B store	1×64 B store
L2 B/cycle	64	64
Supported memory	4×DDR4-2133	6×DDR4-2666
DRAM bandwidth	up to 68.2 GB/s	up to 128 GB/s

Table 2. Table II: Test system details

Processor	2x Intel Xeon SP 6154 Gold
Frequency range (selectable P-states)	1.2 – 3.0 GHz
Turbo frequency	up to 3.7 GHz
AVX frequency range	2.6–3.6 GHz
AVX-512 frequency range	2.1–3.5 GHz
Energy perf. bias	balanced
Energy-efficient turbo (EET)	enabled
Uncore frequency scaling (UFS)	1.2-2.4 Ghz
Hardware Performance States (HWP)	disabled
Per-core p-states (PCPs)	enabled
RAM	12x 32GB DDR4-2666
Motherboard	Tyan S7106
Idle power (fan speed set to maximum)	78 W
Power meter	ZES LMG 450
Accuracy	0.07 % + 0.5 W

Full text

I Introduction and Background

In recent years, the number of energy efficiency features in Intel processors increased significantly. Contemporary processors support Per-Core P-States (PCPs) [1], Uncore Frequency Scaling (UFS) [1], turbo frequencies [2, Section 14.3.3], core and package C-states [3], T-states [4], power capping [5], Energy-Performance-Bias (EPB) [2, Section 14.3.4], and other mechanisms. While these features improved the energy-proportionality significantly, they also have a major influence on the performance of the processor. This can be seen when comparing the given system configuration for results submitted for the SPECpower_ssj [6] with those submitted to performance related benchmarks like SPEC CPU2017 [7]. While the former results got more energy proportional within the last decade, the latter often disable power saving mechanisms to increase performance and provide repeatable results. Furthermore, new architectural features, which boost performance, also influence the power consumption. One example is the introduction of AVX2 and FMA in Intel Haswell processors. Some workloads using these features, would increase the power consumption over the thermal design power (TDP) at nominal frequency.

All of these power-related features span a huge design space with conflicting optimization goals of performance, power capping, and energy efficiency. Users are often oblivious to the implications of these mechanisms which are typically controlled by hardware, firmware and sometimes the operating system. Therefore, they are using their systems as is, hoping that the applied settings will fit their purpose. High Performance Computing (HPC), however, has specific requirements because a single wrongly-configured core in a highly parallel program can lead to millions of cores waiting. Therefore, a detailed analysis and understanding of the possible impacts of power saving mechanisms is key to every performance and energy efficiency evaluation and optimization.

In this paper, we describe new features of Intel Skylake-SP processors, which are likely also part of future processors. In previous years, Intel followed a Tick-Tock scheme, where a new architecture and a new process are introduced alternately. Recently, this cycle has been extended with a third step where the architecture is slightly improved. This is a chance for software and performance engineers, because an adaption of software for a specific hardware has now more time to be worthwhile.

This paper is structured as follows: Section II describes relevant micro-architectural changes and energy efficiency features of the Intel Skylake-SP processor compared to the predecessor generations. In Section III, we give an overview about the test system that we use for our experiments. A short analysis of standardized mechanisms described in the Advanced Configuration and Power Interface (ACPI) is given in Section IV. Sections V-VIII present an analysis of hardware controlled energy efficiency mechanisms and their effect on runtime and power consumption. We conclude our paper with a summary and an outlook in Section IX.

II Skylake-SP Architecture and Energy Efficiency Features

The Skylake server processors introduce several new micro-architectural features, which increase performance, scalability, and efficiency. Furthermore, they uphold energy efficiency features from older architectures and introduce new ones.

II-A Microarchitecture

On the core level, which is summarized in Table I, AVX-512 (or AVX512F to be precise) is the most anticipated feature for HPC. With AVX-512, an entire cache line (64 B, one ZMM register) can now be used as input for vector instructions. Furthermore, with the new EVEX prefix, the number of addressable SIMD registers doubled to 32. Therefore, 2 kiB of data can now be held in vector registers, compared to 512 B in Haswell and Broadwell architectures. The L1D cache bandwidth has been doubled while L2 cache bandwidth is still limited to 64 B/cycle. The L2 cache size increased from 256 kiB to 1 MiB, whereas LLC slice sizes decreased from 2.5 MiB to 1.375 MiB. The increased number of store buffers can lead to a faster streamed store throughput. In addition, all codes benefit from extended out-of-order features.

The uncore also faced a major re-design. In previous architectures (starting with Nehalem-EX), cores have been connected by a ring network. The increased number of cores in Haswell and Broadwell architectures led to the introduction of a second ring with connections between both. Skylake now introduces a mesh architecture, where each core, including its LLC slice, connects to a 2D mesh, as depicted in Figure 1. The external communication (PCIe, UPI) is placed on one side of the mesh. Furthermore, two cores in the remaining mesh are replaced by integrated memory controllers (iMCs), each of which can host up to three DRAM channels. There are multiple flavors of Skylake-SP based processors with varying external connections and numbers of cores.

The cluster-on-die (CoD) feature is now called sub-NUMA clustering and enables dividing the cores into two NUMA domains. Cache coherence is implemented by MESIF and a directory-based home snoop protocol.

II-B Energy Efficiency Mechanisms

Like its predecessors, Skylake-SP processors support Per-Core P-States (PCPs) and Uncore Frequency Scaling (UFS). This enables fine-grained control over performance and energy efficiency decisions. The Energy Performance Bias (EPB) indicates, whether to balance the profile for runtime or power consumption or something in between. The Energy-Efficient Turbo (EET) mechanism was already available on the Haswell platform. All these features have been described in detail in [1].

The Turbo Boost Max 3.0 (TBM3) feature was introduced with Broadwell-E processors. Its basic idea is to improve single thread performance by executing the workload on the processor core that delivers the best power and performance. Due to variations in their manufacturing process, single processors and cores can have varying efficiency characteristics. This facilitates higher turbo frequencies on some cores and lower on others, which in turn influences the performance of a single thread depending on the hardware core that executes it. However, currently none of the currently available Xeon Scalable Processors supports this feature. An anticipated feature of Skylake processors is Hardware Duty Cycling (HDC) [2, Section 14.5], also known as SoC Duty Cycling. HDC implements a more coarse grained duty cycling in comparison to T-states. In contrast to clock gating, HDC uses C-states with power gating. However, this feature is targeted at mobile and desktop processors and is not described in more detail in this document.

II-C Hardware-Controlled P-States (HWP)

Introduced with the Broadwell generation of Intel processors, Hardware-Controlled P-States (alias Hardware Power Management (HWPM) or SpeedShift), move the decision of frequency and C-state usage from the operating system to the processor [2, Section 14.4]. This removes the perturbation of an OS control loop, which interrupts the workload regularly. Furthermore, it increases the responsiveness because the hardware control loop can be executed more frequently without perturbation. While the Broadwell processors hardware acts mostly autonomously, Skylake-SP processors provide interfaces for a collaboration with the OS through interrupts [2, Section 14.4.6]. With the HWP interface, the OS can define a performance and power profile, and set a minimal, efficient, and maximal frequency. Under Linux, the tool x86_energy_policy can be used to interact directly with the hardware interface. HWP is accompanied by an incremental counter register MSR_PPERF, which holds the Productive Performance Count (PCNT) that should increase only if a cycle has been used efficiently.

II-D AVX-512 Frequency

Current Intel processors are unable to use all of their components concurrently at reference frequency. With the doubling of the SIMD width to 512 bit, the power consumption of SIMD execution units now varies even more. This relates to both their static and dynamic power consumption. The former is reduced by disabling those components of the execution units that calculate upper parts of the register. Therefore, the possible dynamic power consumption will increase with (a) the width of the vector, (b) the shape of the processed data, (c) the complexity of the operation, and (d) the frequency and voltage that the execution unit uses. Still, the average power consumption has to stay within the given TDP limit in the long-term. Since the processor core will use the full SIMD width given by the program and cannot change the processed data or operation, the only remaining option for lowering power consumption is dynamic voltage and frequency scaling (DVFS) via PCPs and UFS. This leads to three different frequency ranges that have to be considered: normal frequencies, AVX frequencies, and AVX-512 frequencies. Each ranges from a guaranteed reference to a possible turbo frequency, which depends on the number of active cores. However, these names can be misleading, since AVX instructions can be distinguished into heavy and light instructions. For example, AVX frequencies are applied to workloads that use floating-point (FP) and integer multiplication with 256 bit vector width, but also workloads that use light AVX-512 instructions (i.e., without FP and INT MUL). Likewise, AVX-512 frequencies are used for workloads with heavy AVX-512 instructions.

However, frequency changes are not processed instantaneously as Mazouz et al describe in [14]. Therefore, a different mechanism has to be implemented to lower the power consumption before the frequency is changed. According to Agner [8], initial AVX or AVX-512 instructions will be issued slower if they have not been used recently.

III Test System Setup

For our analysis we use a system equipped with two 18-core Intel Xeon-SP 6154 Gold processors with HyperThreading support running Ubuntu 18.04.1 with a Linux 4.17.0-3 kernel. An overview on the system is given in Table II.

With HWP enabled, even memory-bound workload run at the maximum allowed frequency, which is not what we would expect. According to our measurements, the PCNT register MSR_PPERF (see Section II-C) increases with every cycle even for workload that are stalled most of the time (e.g., pointer-chasing or streamed data access in DRAM). We therefore did not use HWP. EET also does not seem to influence compute-bound/memory-bound workloads and therefore left at the default setting (enabled). We use the acpi_cpufreq driver and the userspace governor to control core frequencies and the msr kernel module to change uncore frequencies. The only available C-states on our system are C1 (HLT), C1E (HLT+DVFS) and C6 (power gating). The power limits given by RAPL are 240 W over a period of 1 second and 200 W over a period of 100 seconds.

IV Transition Latencies and ACPI State Behavior

Traditional energy efficiency mechanisms are defined in the Advanced Configuration and Power Interface (ACPI) [15]. This includes sets of P-, C-, and T-states, which can be used to lower power consumption.

IV-A Performance States/P-States/PCPs

One of the traditional energy saving strategies is to reduce the core frequency of processors. Previous work illustrates that an external mechanism is responsible for setting core frequencies in Haswell-EP processors [1]. The mechanism applies changes to the P-state at a regular interval. The duration of a frequency change depends on the timing of the change request in comparison to the mechanism’s internal update interval. The Skylake-SP processor shows a similar behavior (see Figure 2).

IV-B Power States/C-States

Intel changed several details in their C-state implementation. Out of five available C-states on Haswell systems, only four remain on Skylake-SP processors since C3 is not defined in the kernel sources. The remaining core C-states are C0, C1, and C6. Additionally, the operating system can request C1E.

Our measurement methodology reuses a previous work from [3] and [16]. One CPU (caller) wakes another CPU (callee). We define the C-state transition latency as the time between initiating the wake-up at caller and the callee becoming active. To measure the start timestamp, we log the kernel tracepoint sched:sched_wake_idle_without_ipi on the caller CPU, which is closest to the wake-up event generated in the function set_nr_and_not_polling. The return to an active state is monitored using the power:cpu_idle event on the callee CPU. To generate the wake-up events, we use a thread signal, as shown in Listing 1. To increase the accuracy, the measurement is repeated 100 times for each combination of C-state and P-state.

Figure 3 shows that a local wake-up call to a core in C6 results in a 42 µs latency for the lowest core frequency and about 33 µs for the nominal frequency. The same is true for a remote active state (not depicted). If the second socket is idling, the wake-up latency is mostly between 46 and 48 µs. However, sometimes the latency reaches 55 µs. Compared to the Haswell EP platform, the latencies increased significantly.

IV-C Throttling States/T-States

Like their predecessors, Intel Skylake processors also support clock modulation as a mechanism to lower power consumption and to prevent thermal damage. The interface to control these mechanisms through software remained unchanged. Using a previously established methodology [4] we conclude that the performance characteristics are similar to the Haswell-EP architecture [1]: Each core independently controls its own T-state. In contrast to the Sandy Bridge architecture, no DVFS is applied. The highest T-state (with the most cycles being skipped) is not implemented. The lower T-states skips more cycles than defined.

V Uncore Frequency Scaling/UFS

The UFS feature enables processors to change the frequency of non-core components during runtime independently from core frequencies [1]. By default, the uncore frequency is guided by a hardware control loop. It can also be controlled through an interface via the model specific register (MSR) UNCORE_RATIO_LIMIT [17]. After booting, this register holds descriptions of the minimal and maximal uncore frequency available. Writing to the register during runtime can narrow the configuration space to a subset or only one frequency setting by providing the same value for both entries.

We investigate several performance characteristics as depicted in Figure 4: First, the latency $t_{delay}$ between the initiation and the execution of a frequency change. Second, the period $t_{gap}$ in which the processor is unavailable due to switching voltage and frequency. Third, the latency $t_{controlloop}$ until the internal scaling mechanism recognizes a change of the workload.

We extend the FTaLaT methodology to determine the transition latency [14]. Originally, the performance of a CPU-bound workload is measured after a processor core frequency change until it reflects the performance expected for the target frequency. In our setup, we use a pointer-chasing algorithm that accesses data in the last level cache (LLC) and read the time stamp counter (TSC) after every access. As soon as one iteration took more than 20,000 cycles, we assume a frequency change. We measure $t_{delay}$ and $t_{gap}$ using the TSC information and calculate the average access latency to LLC before and after the frequency switch.

To measure $t_{controlloop}$ we run the pointer-chasing algorithm that accesses cache lines from level 1 cache multiple times to train the CPU towards low uncore usage and therefore low uncore frequency. We then run this algorithm within an LLC data set and measure the same performance data as before. We assume that running the algorithm within the LLC leads to a higher frequency setting and therefore requires an uncore frequency transition. Finally, we use the reported average latencies to verify that the assumed low and high frequencies have been applied. All workloads are executed at a 2.4 GHz core frequency. Figure 5 presents the results.

Figure 5a suggest that about 20 % of the samples for each source/target frequency pair will have a short $t_{gap}$ of 3 to 4 µs. However, these 20 % also correlate with outliers in the reached target performance in terms of cycles per access. For these samples, the gap detection did not work. They are therefor considered outliers and are not used in the further analysis. The remaining results for $t_{gap}$ are in the range of 14.5 to 16 µs with no clear pattern for different source and target frequencies. $t_{delay}$ shows a wide range of measured values, which range from 0 to 1.5 ms (Figure 5b). We assume that the same mechanism as for P-state changes applies, but the resolution of the uncore mechanism is about 3 times lower. Figure 5c shows that the default control loop for setting the uncore frequency adds another 9.8 ms to the delay. Therefore, the uncore frequency will only be adapted 10 ms after a changed workload pattern, which can have a significant impact on regularly altering workloads. According to the measured access times before and after the frequency switch, the control loop changed the uncore frequency from 1.4 to 2.4 GHz, which corresponds to access times of 119 and 83 cycles, respectively. A possible optimization to prevent the uncore from clocking down without MSR access would be to use the second hardware threads to access the LLC.

VI Power Limiting Mechanisms

The impact of power limiting can be analyzed by maximizing power consumption of the test system. FIRESTARTER [18] is a full-system stress test, which targets a high power consumption for memory, processor, and GPU accelerators. To adapt to the Skylake architecture we introduced AVX-512 instructions to FIRESTARTER, added 512-bit wide broadcast instructions, and changed the memory access parameters. We use Linpack and the mprime stress test111Intel implementation and compiler 18.0.2, 65k elements (Linpack); mprime 29.4 build 7; FIRESTARTER 1.7.3 as reference for comparison. For all three workloads we compare the core cycle rate and AC power consumption as well as their variation over the full execution, all of which was recorded with lo2s [19]. Turbo frequency is enabled, all remaining parameters set to their default values. According to the RAPL interface all workloads hit the maximal TDP of 200 W per processor. However, the dynamic behavior differs between the three workloads.

Linpack consists of alternating phases of computation and synchronization [18]. The stable peak power consumption is only reached during computation phases, whereas power consumption during synchronization is reduced to $<$430 W. Whenever the computational phase starts, there is a $\sim$1 s spike of $\sim$665 W, using the turbo headroom from the previous underutilization. During computational phases, power consumption averages 620 W with some noise between 573 W and 664 W at the measured 50 ms intervals. The effective core frequencies vary between threads and time within the computational phases from 2.6 GHz to 3.2 GHz, while being stable at 3.7 GHz throughout the synchronization phases.

Tests with mprime use in-place large FFTs, which are the most power consuming on our system. mprime executes different specific FFT functions, that slightly differ in power consumption and core frequency. Overall power varies between 619 W and 645 W with an average of 634 W and core frequency varies from 2.7 GHz to 3.1 GHz, both mostly depending on the currently executed functions.

FIRESTARTER runs a constant architecture-specific workload resulting in a high power consumption and low core frequency. There is a trend of increase in power consumption from 625 W to 629 W for the first 7 minutes, likely caused by the temperature leveling out. Later, power remains between 627 W and 631 W, while the frequency differs between the two packages at 2.55 GHz / 2.67 GHz. FIRESTARTER does not reach the average power level of mprime, but triggers a significantly lower frequency. As future work, FIRESTARTER should be extended to make use of both AVX-512 and 256 bit wide AVX in order to use port 0 and 1 to compute 256 bit per cycle.

Energy efficiency mechanisms have a significant effect on processor stress tests. FIRESTARTER utilizes the full package power for core frequencies at or above 2.4 GHz. Depending on the core frequency, available budgets are shifted to the uncore. Mprime reaches the given TDP at higher frequencies, typically around the nominal of 3.0 GHz. Even if the uncore frequency is fixed by using the MSR 0x620 and the specifications would allow lowering the core frequencies instead: the power limit is reached, the processor lowers the uncore clock. Therefore, the specified uncore frequency must be regarded as a recommendation under power constrained circumstances. On Haswell-EP processors, disabling the turbo mechanism during power-constrained workloads may increase core frequencies [1, Table IV]. According to our measurements on the Skylake-SP platform, this effect emerges now when requesting a frequency that is below the nominal frequency (e.g., 2.9 GHz) and cannot be observed if the EPB is set to performance. While the impact of the frequency increase (in this case 20 MHz) is limited, the effect itself is counter-intuitive. Therefore, it serves as an example for complex interactions within the microarchitecture that have unexpected side effects.

VII Performance Impact of AVX Frequency Transitions

As discussed in Section II, Intel Skylake-SP processors operate on three frequency ranges: standard, AVX and AVX-512. Switching between these is hardware-controlled and influences the performance of the executed workload:

• •

When switching from one category of instructions (i.e., normal or AVX) to more demanding instructions (i.e., AVX or AVX-512), the out-of-order (OoO) engine is throttled to prevent thermal damage during frequency transition.

• •

When switching from one category of instructions (i.e., AVX, AVX-512) to less demanding instructions, the processor remains within the reduced frequency range for a short period of time to avoid unnecessary frequency changes.

To gather information about these state changes, we use a modified version of FIRESTARTER that repetitively switches between High (power) and Low (power) workloads in defined intervals. High executes the standard workload of FIRESTARTER. In contrast, the Low phase utilizes long running instructions like mfence and cpuid. Figure 6 illustrates these transitions as $t_{\texttt{lvl\,high}}$ and $t_{\texttt{lvl\,low}}$, respectively. A manual Score-P [20] instrumentation exposes changes between Low and High and allows us to record two additional counters:

• •

The CORE_POWER.THROTTLE event represents the cycles where the out-of-order engine is throttled.

• •

The CORE_POWER.LVL2_TURBO_LICENSE event represents the cycles spent in AVX-512 frequencies.

Initially, we use the nominal frequency of the processor and run one thread per core with a period of 2 s (50 % Low) for five minutes (150 iterations)222taskset -c 0-35 ./FIRESTARTER -l 50 -p 2000000 -t 300. The measurements show that the total number of cycles spent with a throttled OoO-engine varies between the threads, ranging between 28 and 34 million. This translates to 62 µs and 75 µs for each of the 150 iterations.

Also the number of cycles that are spent in AVX-512 frequency during Low varies between 1.5 and 1.9 million (555 µs to 704 µs at AVX-512 frequency of 2.7 GHz). With a reduced period of 2 ms, the band narrows down to 1.8 to 1.9 million cycles of AVX-frequency range during each Low phase. With an unbalanced workload (e.g., 1 ms period with 80 % of the time being spent in Low), a worst-case scenario can be created (see Figure 7). A similar situation can occur if an application calls a highly optimized mathematical routine in a loop, while doing additional non-AVX instructions between these calls.

This shows, that the AVX frequency mechanisms can have a significant and non-obvious influence on the performance of applications, in particular during transitions. Throttling of AVX instructions and a latency of several hundred microseconds for restoring non-AVX frequency need to be considered. To avoid out-of-order throttling, we reduced the frequency of the system to 1.2 GHz, which is lower than any documented AVX frequency. Even in this situation, the instruction issue is throttled according to the PMC measurements. However, the measured OoO-throttling cycles have a lower variance compared to measurements at higher core frequencies.

VIII Data-Dependent Power Consumption

Skylake-SP processors are the first x86 standard processors, besides the Xeon Phi, to support 512 bit wide vector operations. Together with the increased number of cores, this leads to a significantly increased number of bits that can change in a processor within a single cycle. A possible consequence is that power consumption may vary depending on the input data, even with a fixed set of instructions. To test this, we designed an OpenMP-parallel benchmark, which only uses data in 512-bit-wide registers, and execute it on all cores. The benchmark places $value_{1}$ in zmm[0-7] and $value_{2}$ in zmm[8-15] and executes $value_{2}=value_{2}\oplus value_{1}$ in a loop for several seconds. This forces the processor to use the AVX frequency, since vxorps can be considered a “light” AVX-512 instruction. Moreover, we measured that core frequency and the instruction rate are constant during the experiment. We repeated the workload for multiple frequencies while collecting at least 50 power samples for each frequency/$value_{1}$/$value_{2}$ combination.

In order to visualize the effect, we generated traces using Score-P with power measurements. Figure 8 shows that the power consumption strongly correlates with the used data. Only depending on the number of set bits in $value_{1}$ and $value_{2}$, the power consumption ranges from 362 W to 420 W for a 3 GHz setup.

For the further analysis, we use the mean of the measurements, while disregarding the first 10 and last 5 power measurements, as they may contain transitions. The population count of $value_{1}$ defines how many bits in the target registers zmmm[8-15] will toggle with every instruction, independent of the setting of $value_{2}$. The power consumption increase correlates with that count. Furthermore, the power consumption increases for each bit set in $value_{2}$ if $popcnt(value_{2})>popcnt(value_{1})$. Here, the additional bits ($popcnt(value_{2})-popcnt(value_{1})$) within the register will not change with the operation, but will be read as, and written to be, one instead of zero.

We use linear regression to determine the power consumption increase per bit set of $value_{1}$ per core. For 2.4 GHz and 3.0 GHz, the power consumption of the system increases by 1.69 mW and 3.13 mW per bit set in $value_{1}$, respectively. The costs for each additional bit in $value_{2}$ are 0.46 mW and 0.80 mW for 2.4 GHz and 3.0 GHz, respectively.

When comparing the share of data-dependent power costs against the base system power consumption, the shape of the used data can cause a difference of up to 78 W at turbo frequency. If we subtract a base power consumption for active cores and uncore components (C1 state), the power costs of the single instruction increases by more than 30 % with all bits being set, independently of the frequency. This far-reaching implication of this insight is that any accurate instruction-based power and energy model for this processor needs to consider input data.

IX Conclusion and Future Work

In this paper, we have described details of the Skylake-SP energy efficiency mechanisms and how they influence performance and power consumption. We demonstrated that neither the P-state nor the T-state mechanism has been improved over the Haswell-EP platform. Furthermore, the C-state latencies have increased. The uncore frequency also has a significant influence on performance, as the default mechanism takes about 10 milliseconds to adapt to application behavior changes. Another transparent mechanism, AVX-512 frequencies, will stall the out-of-order engine for about 70 µs after the first AVX-512 instruction has been issued. Moreover, AVX-512 frequencies will be applied more than 600 µs after the last instruction has been issued. This may lead to pathological cases in which the processor is constantly switching between two non-optimal configurations. Another effect concerns the wider AVX-512 registers: the dynamic part of the power consumption increased significantly. We demonstrated that–depending on the input data–the power consumption of a workload can differ by more than 18 % for the whole system (or more than 30 % if only the dynamic power on top of C1 is considered). This is a major challenge and may significantly limit the usefulness of any instruction-based energy model that is unaware of the input data. Our future work will consider the analysis of competitor systems and the influence of energy efficiency features on latencies and bandwidths. Furthermore, we will investigate the processor energy counters more closely and extend the system stress test FIRESTARTER.

Acknowledgments

This work is supported in part by the European Union’s Horizon 2020 program in the READEX project (grant agreement number 671657) and by the German Research Foundation (DFG) within the CRC 912 - HAEC.

Used Code

The used code is available at https://github.com/tud-zih-energy/2019-HPCS-Skylake-EE.