and text messages, and browsing the
Web) implemented on different devices (such as cellphones, MP3 players,
laptops, and PCs) and observed two
notable results: There is a significant
difference in energy efficiency, often
10- to a hundredfold, across different
systems performing the same task.
And there are variations in the user
experience across devices, but even
when focused on duplicating the functionality of the best-performing system, these experiments showed it was
impossible to do so at the same energy
level on a different worse-performing
system.
Why do some designs introduce
additional inefficiencies over and
above the actual energy required for
a given task? My observation is that
these inefficiencies are often introduced when the system design must
reconcile complex trade-offs that are
difficult to avoid. For example, systems are often designed for the most
general case, most aggressive workload performance, and worst-case
risk tolerance. Such designs can lead
to resource overprovisioning to better handle transient peaks and offer redundancy in the case of failure.
Moreover, individual components of a
broader system are often designed by
different teams (even by different vendors) without consideration for their
use with one another. Individual functions of a system are also designed
modularly, often without factoring
their interactions with one another,
adding further inefficiencies. Further,
traditional designs focus primarily on
system performance. This approach
has sometimes led to resource-waste-ful designs to extract small improvements in performance; with today’s
emphasis on energy costs, these small
improvements are often overshadowed by the costs of power and heat
extraction. Similarly, additional inefficiencies are introduced when the
system design takes a narrow view of
performance (vs. actual end-user requirements) or fails to address total
cost of ownership, including design
and operational costs.
General-purpose solutions. General-purpose systems often provide a better consumer experience; for example,
most users prefer to carry a single converged mobile device rather than sev-
An insidious
problem is when
each layer of the
stack makes worst-
case assumptions
about other layers
in the stack, leading
to compound
inefficiencies.
eral separate devices (such as phone,
camera, and MP3 player or GPS unit).
Additionally, the exigencies of volume
economics further motivate vendors
to develop general-purpose systems;
a product that sells in the millions of
units is usually cheaper to make than,
say, a product that sells in the hundreds of units.
By definition, general-purpose
systems must be designed to provide
good performance for a multitude of
different applications. This requirement results in designers using the
“union” of maximum requirements of
all application classes. For example, a
laptop that targets a DVD-playback application might incorporate a high-resolution display and powerful graphics
processor. When the same laptop is
used for another task (such as reading
email), the high-power characteristics
of the display and graphics processor
might not be needed. However, when
the laptop is designed for both workloads, most designs typically include
a display with the characteristics of
the most aggressive application use,
in this case, a high-resolution display
that plays DVD movies well. Lacking
adequate design thought into how energy consumption might be adapted
to different kinds of tasks, such an approach often leads to significant power inefficiencies. Another example is
in the data center, where optimizing
for both mission-critical and non-mis-sion-critical servers in the same facility can lead to significant inefficiencies in terms of cooling costs. Similar
conflicting optimizations occur when
legacy solutions must be supported
on newer systems.
Planning for peaks and growth.
Most workloads go through different
phases when they require different
performance levels from the system.
For example, several studies have reported that the average server utilization in live data centers can be low
(often 10%–30%). Mobile systems have
also been found to spend a significant
fraction of their time in idle mode or
using only a small fraction of their resources.
However, most benchmarks (the
basis of system design) are typically
structured to stress worst-case performance workloads irrespective of how
the system is likely to be used in prac-
