PPA Trade-offs and Amdahl's Law

PPA stands for performance, power and area, the three things every chip design trades against each other. A faster core usually takes more silicon and burns more energy, so an architect's daily question is not "can this be faster?" but "is this gain worth what it costs?" Amdahl's law gives the first half of the answer: it says how much a change can possibly gain, given how much of the run time it touches. This article explains the three costs, works through Amdahl's law on real measurements, and shows how architects compare a feature's gain against its price.

13 min read | Beginner

What You'll Learn

• Define performance, power and area and explain why they conflict
• Apply Amdahl's law to find the most a change can gain
• Compare a feature's speedup with its area and power cost
• Decide when to optimize the common case and when not to

The Three Costs

Performance is how fast the chip does its job, measured as described in The Performance Equation.

Area is how much silicon the design takes, measured in square millimeters. It matters because it is cost. Chips are cut from a round wafer that costs the same whatever is on it, so a larger die means fewer chips per wafer. Worse, wafers have random defects, and a larger die is more likely to contain one, so a larger share of the chips must be thrown away. Cost therefore rises faster than area.

Power is the energy used per second, in watts. It has two parts. Dynamic power is spent when signals switch between 0 and 1, and it follows a well-known relation:

dynamic power = activity x capacitance x voltage^2 x frequency

Activity is how many signals switch per cycle, and capacitance grows with the amount of circuitry. Voltage is squared, which is why lowering it saves so much. Leakage power is the small current that flows through transistors even when they are not switching. It is spent as long as the block is powered, so large idle blocks, such as big caches, still cost energy.

Power matters for two reasons. A phone has a battery, so total energy limits how long it lasts. And every watt becomes heat: a chip can only run as fast as its cooling allows. A phone may hold a few watts for long periods, and a large server chip a few hundred. Modern high-end chips are usually limited by heat before anything else.

Why the Three Conflict

Performance costs the other two, in several ways. A larger branch predictor, a larger cache or an extra execution unit adds area directly, and all of them use power. A higher clock frequency usually needs a higher voltage, so dynamic power rises with roughly the cube of frequency when both change together. That cube is the reason a chip cannot simply be clocked twice as fast: it would use about eight times the power, far more than the cooling can remove.

The same rule works in reverse, and it is the reason multicore chips exist. Two cores at 80 percent of the frequency and voltage each use about half the power of one full-speed core (0.8 cubed is about 0.5), so together they use about the same power as one core, and give up to 1.6 times its throughput if the work can be shared between them.

The three goals also depend on the market. A server chip wants peak performance within a power limit. A phone wants the most work per joule. A sensor chip that costs a few cents wants the smallest possible area and leakage, and speed hardly matters. There is no best processor, only the best processor for a set of limits, and PPA is how those limits are written down.

Amdahl's Law

Before spending effort on a change, an architect wants to know the most it can gain. Gene Amdahl stated the answer in 1967. If a change speeds up only a fraction of the run time, the rest stays as slow as before, and the rest sets a limit on the overall gain.

Let f be the fraction of the run time that benefits, and s the speedup of that part. The new time is the unaffected part plus the improved part:

new time = (1 - f) + f / s
speedup  = 1 / ((1 - f) + f / s)

Even if the improved part became infinitely fast, f / s would be zero and the speedup would stop at 1 / (1 - f). A change touching half of the run time can never give more than a factor of 2. Touching 90 percent gives at most a factor of 10.

A worked example: a program spends 40 percent of its time in a loop that a new instruction makes 5 times faster. These numbers are assumptions for this example. Speedup = 1 / (0.6 + 0.4 / 5) = 1 / 0.68 = 1.47. A 5 times faster loop gave less than a 1.5 times faster program, and even an infinitely fast loop would give only 1 / 0.6 = 1.67.

Amdahl on a Real Measurement

Here is the law on a measured program. A matrix multiplication on a simple five-stage processor lost about 31 percent of its cycles to branch flushes, the cycles wasted when a taken branch throws away the instructions fetched after it. What is the best that any branch improvement could do?

Perfect branch handling would remove all 31 percent, so the speedup cannot exceed 1 / 0.69 = 1.45. That is a useful ceiling. It costs nothing to compute, and it tells the team that no branch predictor, however clever, can make this program 2 times faster on this design. A predictor that removes three quarters of the flushes would give 1 / (0.69 + 0.31 x 0.25) = 1.3.

The ceiling also depends on the program. In a checksum, flushes took about a fifth of the cycles, so the limit is about 1.25. In a simple array loop, they took a third, and the limit is 1.5.

Memory Latency, Seen the Same Way

Amdahl's law works in the other direction too: it shows what a slowdown of one part costs. In one test, every data access of a memory copy program was made to wait longer:

The cycles grow in a straight line, because each access adds its wait. One extra cycle on each access made the run about 15 percent longer, and four extra cycles about 59 percent longer. The same delay hardly touched a checksum, whose run grew by only about 9 percent with four extra cycles, because it rarely uses memory. The fraction of time in the affected part decides everything, in both directions.

Comparing Gain With Cost

Once the gain is known, it must be weighed against the price. A real example is forwarding, a pipeline feature that passes a result straight to the next instruction instead of waiting for it to be written to the registers (Data Hazards and Forwarding explains it). A small five-stage core was built with and without it, on the same programs and the same gate library:

Forwarding added about 2.5 percent to the area and gave a speedup between about 1.17 and 1.7. Almost any design would accept that: a gain many times larger than the cost. It is an easy case. Most decisions are much closer, and that is where a simple rule helps:

• Divide the percent gain by the percent of added area and added power. A feature that gives 10 percent more speed for 5 percent more area looks good; one that gives 2 percent for 20 percent does not.
• Compare it with what else the area could buy. The same silicon might be spent on more cache, or a second core, or just a cheaper chip.
• Count the costs that do not show up in square millimeters: verification effort, schedule risk, and the extra complexity every later design inherits.

A measure often used for processors is performance per watt, which is the same as work per joule. A related one for low-power design is energy-delay product, energy multiplied by time, which stops a design from "winning" just by running very slowly at low energy.

Optimize the Common Case

Amdahl's law leads to the oldest rule in computer design: make the common case fast. Effort spent on something that happens rarely cannot pay back, however clever it is. That is why designers measure before they design, using the CPI stacks and instruction mixes covered earlier in this chapter.

The rule has two limits. First, the common case must be measured on the right programs. A feature can be common in a benchmark and rare in the real product, which is why Workloads and Benchmarks matters. Second, the rare case still has to work correctly. An exception, a misaligned access or a page fault happens rarely, so it can be slow, but it must never be wrong, and it often takes a large share of the verification effort.

Amdahl's law also explains the limit of parallel computing. If 5 percent of a program must run on one core, the speedup from any number of cores cannot exceed 1 / 0.05 = 20. With 8 cores the speedup is 1 / (0.05 + 0.95 / 8) = 5.9, and with 64 cores it is only 15.4. Each extra core gives less, and the small serial part becomes the bottleneck. Multicore Processors and Shared Memory returns to this.

Reading a PPA Target

A product plan usually states targets such as "2,000 CoreMark at 200 MHz, under 15 mW, under 0.2 mm² in this process". (Those numbers are only an illustration.) Each target limits the others. As the design develops, the team tracks all three, because a late gain in one is often paid for in another: a timing fix adds buffers, and so area and power; a power fix adds clock gating, and so a little area and verification. Keeping margins in each of the three budgets, and reviewing them regularly, is a large part of an architect's work on a real project, as What Computer Architects Do describes.

Common Mistakes