Computer Abstractions and Performance

An abstraction shows what a component does while hiding the details of how it works. A browser can ask the operating system to read a file without controlling the storage device’s circuits. Defined interfaces let people design, test, and replace parts of a system without rebuilding every layer at once.

The layers and their jobs

A common ordering, from the user’s task down to physical devices, is:

1. Application software performs tasks such as editing a spreadsheet or browsing the web.
2. Systems software supplies shared services and translates programs. It includes operating systems, compilers, assemblers, linkers, and libraries.
3. The instruction set architecture (ISA) defines the machine instructions and other behavior visible to low-level software.
4. The microarchitecture, or organization, implements that ISA with a datapath, control, pipelines, and caches.
5. Digital logic builds operations and storage from gates, adders, multiplexers, and registers.
6. Circuits connect electronic components to realize that logic.
7. Devices, chiefly transistors, provide the physical switching behavior.

These boundaries are useful views of one machine. Different diagrams may group neighboring layers together. An operating system is software: the CPU executes its instructions, including privileged instructions that help it manage resources safely.

Follow one addition

Consider the C statement total = price + tax;. A compiler chooses where values live and which instructions perform the addition. It can choose an add instruction without designing an adder. A microarchitect maps that instruction onto execution hardware. A logic designer builds the adder from gates; a circuit designer deals with the electrical details behind those gates. Each person uses a simpler interface to the level below.

The physical computer has five classic components: input, output, memory, datapath, and control. The datapath operates on data. Control directs operations and coordinates memory and I/O. Together, datapath and control form the processor, or CPU.

A transistor acts as an electrically controlled switch. An integrated circuit, or chip, joins many transistors on one piece of silicon. Those switches support logic; the logic supports instructions; instructions support software.

More transistors and different speeds

Moore’s law began with Gordon Moore’s 1965 observation and was revised in 1975 to a trend of roughly doubling transistor counts every two years. Ten such doublings multiply a count by $2^{10}=1024$, over about 20 years. This is a manufacturing trend, not a physical guarantee; its pace has slowed.

Meeting an interface preserves the behavior promised by that interface. It does not fix performance, energy use, or cost. Two processors can implement the same addition instruction correctly while using different circuits, caches, and clock rates. The application gets the same computed result, yet waits a different amount of time.

A processor executes machine language, instructions encoded as bits. High-level code describes a computation in variables, expressions, loops, and functions. Translation bridges those two views, often expanding a short statement into several instructions.

The compiled-program path

For a C program, the main stages are:

An object file can contain machine code without yet being a complete runnable program. For example, a call to a function defined in another file needs the linker to resolve that reference. The loader is part of the operating system’s execution support, not another source-code translator.

Trace one C statement

Suppose price is in register x6, tax is in x7, and the compiler places total in x5. Then:

total = price + tax;

can become this RISC-V instruction:

add x5, x6, x7

The destination comes first in the assembly text. The instruction adds the values in x6 and x7 and writes the result to x5. Its 32-bit R-type encoding places the fields in a different order:

Joining the fields gives 0000000 00111 00110 000 00101 0110011, or 0x007302B3. The spaces make the fields readable; they are not stored as part of the instruction.

One source statement need not mean one instruction. Even with all operands in registers, f = (g + h) - (i + j); needs two additions and a subtraction. Loading operands from memory adds instructions. Executed instruction count therefore depends on translation and the ISA, not just the number of source lines.

Other routes to machine code

A high-level program can often be recompiled for another ISA. Its existing executable is tied to its ISA and operating-system conventions. An x86-64 executable needs recompilation, emulation, or binary translation to run on an Arm or RISC-V machine that cannot execute it natively.

Bytecode is an intermediate instruction format for a language runtime. CPython compiles Python source to bytecode and interprets it with an interpreter program. Java virtual machines commonly use just-in-time (JIT) compilation to turn frequently used bytecode into machine code while the program runs. In both cases, the physical CPU ultimately executes machine instructions.

Assembly remains text, even when a line resembles a real instruction closely. A pseudo-instruction is a convenience accepted by the assembler: RISC-V mv x5, x6 becomes addi x5, x6, 0. Exact instruction control can be useful in operating-system code and critical loops, but it gives up some of the portability and compiler freedom of high-level code.

The instruction set architecture (ISA) is the contract between hardware and the lowest-level software. It tells a machine-language programmer what operations exist and what those operations mean. A processor’s internal design can change while that contract remains stable.

What the contract specifies

An ISA defines instructions and their binary encodings, programmer-visible registers, addressing behavior, supported data types, and the architectural mechanisms used to reach I/O. A compiler targets these features when it turns a computation into instructions.

An implementation is a physical design that obeys the ISA. Its microarchitecture describes internal choices such as execution units, pipeline stages, cache sizes, and branch prediction. Those choices strongly affect execution time.

The distinction is about the promised behavior. A program must receive the specified multiplication result. It usually does not need to know how the multiplier was built to obtain that result.

Why an ISA alone is not enough for binary compatibility

The application binary interface (ABI) adds the operating-system interface and binary conventions to the user-level ISA. It specifies calling conventions, such as argument registers, along with data layout and system-call conventions. Two machines can execute the same instruction encodings yet disagree about how a function receives an argument.

Binary compatibility requires the program’s ISA features and ABI to be supported. Even within the x86 family, which began with Intel’s 8086 in 1978, operating-system support and execution modes matter. Backward compatibility has preserved many older programs while processor implementations have changed, but sharing a family name is not a guarantee that every historical executable runs in every environment.

One architecture, many implementations

Intel and AMD implement x86-64 with different internal designs. Arm and RISC-V likewise support implementations with very different power budgets and performance. RISC-V began at the University of California, Berkeley, in 2010 and is an open, royalty-free ISA. Its base integer sets include RV32I and RV64I; standard extensions include M for integer multiplication and division, and F and D for floating-point operations.

A program using an optional extension needs an implementation that supports it. The existence of a shared base does not make every extension universal. The RISC-V addition example illustrates the same hardware/software boundary found in Arm and x86, although their instructions and encodings differ.

Instruction richness and execution time

An ISA can express more work in one instruction, reducing instruction count. That instruction may also take more cycles or demand a longer cycle. The relevant calculation is the whole product:

A richer instruction set is not enough to establish which machine is faster. Nor does a shared ISA establish equal speed: compatible processors can use different clocks, caches, and execution units to produce the same required results.

A person waiting for a file conversion wants a short response time. A service processing many conversions also needs high throughput. These measures answer different questions, even when both describe the same computer.

Choose the quantity that matches the task

Response time, also called execution time or latency, runs from the task’s start to its completion. It includes computing, memory and storage accesses, I/O, and relevant operating-system activity. If the task waits in a queue after submission, that wait contributes to the user’s response time.

Throughput is completed work per unit of time. Its units might be requests per second or jobs per hour. A machine can complete many jobs per hour while each individual job still takes a long time.

Adding processors can raise throughput by running independent tasks at once. It need not shorten a task’s own computation, although it can reduce time spent waiting for a free processor. A faster processor often helps both measures.

Compare performance in the right direction

For the same task, define:

If A takes 10 s and B takes 15 s, A’s performance relative to B is:

A is 1.5 times as fast. B’s performance is two thirds of A’s. Put the larger execution time over the smaller one when reporting how many times as fast the faster machine is.

For an improvement, speedup is old time divided by new time. A build falling from 60 s to 48 s has speedup:

Its time reduction is:

The performance rose by 25%, while time fell by 20%. These percentages use different denominators. Saying “20% faster” can obscure which quantity changed; the ratio and the measured times make the claim clear.

Equal throughput can hide unequal waits

A service completing 1,200 requests per minute delivers 20 requests per second. That rate could come from processing one request every 50 ms, with each request taking 50 ms. It could also come from processing ten requests in parallel, each taking 500 ms: ten completions every half second again gives 20 per second.

The second arrangement has the same throughput but ten times the per-request processing time. A throughput result alone cannot establish the latency a user experiences. Compare the same completed work, state the time interval, and retain the units when moving between minutes and seconds.

A stopwatch measures everything between start and finish. The CPU performance equation measures processor work. Keeping those views separate prevents a processor upgrade from receiving credit for waiting time it cannot remove.

Elapsed time and processor time

Elapsed time, or wall-clock time, includes computing, waiting for files or the network, and intervals when other processes run. CPU time records processor time charged to the task. User CPU time runs the program’s code; system CPU time runs operating-system code on its behalf.

Suppose the Unix time command reports “real 2.50 s, user 1.80 s, sys 0.20 s.” The program used:

of CPU time. For this single-threaded timing example, the remaining 0.50 s represents time not charged as CPU execution, such as waiting or being scheduled out. If a processor improvement halves the CPU part while that waiting stays fixed, elapsed time becomes:

Halving the full 2.50 s would incorrectly speed up the waiting too. CPU performance often focuses on user time; system performance is judged using elapsed time under controlled system load.

For a parallel program, CPU time is summed across its threads and cores. Four cores working for most of one second can produce 3.6 s of user time during 1.0 s of elapsed time. In that case, subtracting summed CPU time from elapsed time does not measure waiting.

Clock rate is the reciprocal of period

A clock gives synchronous hardware a timing rhythm. The clock period is seconds per cycle; the clock rate is cycles per second:

At 4 GHz, the rate is four billion cycles per second. One cycle lasts:

At 2.5 GHz the period is 400 ps. In the opposite direction, 312.5 ps per cycle gives:

Time and frequency prefixes use decimal powers. Binary memory prefixes use powers of two. Labels such as “GB” are sometimes used loosely for binary quantities, so inspect the meaning before converting a size.

Interpret a measurement as a run

A processor’s advertised frequency is not a record of every moment of execution. Boosting, power management, and thermal throttling change frequency. Cache contents and background activity also change measured time. Repeating a measurement and reporting a typical value, such as the median, helps distinguish a stable result from an unusually favorable run. Use timing and frequency measurements from the same execution interval when connecting them to cycle counts.

A clock cycle is a unit of processor time, not an instruction. Some instructions need many cycles, and overlapping execution can complete several instructions per cycle. Begin with the total cycles needed by the whole program.

Divide cycles by cycles per second

If a program needs a known number of cycles, its CPU time is:

For six billion cycles at 3 GHz:

The units explain the division: cycles divided by cycles per second leaves seconds. Multiplying cycles by frequency would produce cycles squared per second, not a duration. Multiplying by the period works because its unit is seconds per cycle.

The same equation can find another unknown. Multiply time by frequency to recover cycles; divide cycles by the target time to find the needed frequency. Keep the frequency in Hz when the time is in seconds, or cancel matching billion-scale factors explicitly.

When a faster clock requires more cycles

Processor A runs a program in 10 s at 3 GHz. Its cycle budget is:

A proposed design B increases that cycle count by 20%. B must therefore execute:

To finish in 9 s, B needs:

The clock-rate ratio is four thirds, about 1.33. The actual speedup is only ten ninths, about 1.11, because B needs more ticks to finish the work. Treating the old cycle count as unchanged would predict a clock rate too low to reach the target.

Compare a tradeoff without choosing a program size

Let a design multiply the old cycle count by a factor $a$ and the old clock rate by a factor $b$. Then:

The design is faster when the cycle-count growth factor is smaller than the frequency growth factor. If both grow by the same factor, CPU time is unchanged. This ratio is useful when a design proposal reports percentage changes but gives no absolute cycle count.

Why the period has a physical limit

Between registers, signals travel through combinational logic and must settle before their results are captured. The slowest required path is the critical path. Circuit technology and the amount of work assigned to a stage limit how short a safe clock period can be.

A designer can divide work into shorter pipeline stages to allow a faster clock, but the reorganization can also change cycle count. More GHz is therefore a statement about tick frequency. To establish a performance improvement, pair it with the cycles the program actually needs under that design.

Cycles per instruction (CPI) is the program’s total CPU cycles divided by its executed instruction count. It is an average over a run, so it can be fractional and depends on which instructions execute and how they interact with the machine.

Add the cycles before taking the average

For instruction classes with counts $C_i$ and class CPIs $c_i$:

Equivalently, multiply each class CPI by its fraction of the instruction count and add the contributions. The fractions must describe executed instructions, not source lines or the number of instruction types.

Suppose ALU instructions take 1 cycle, loads/stores take 4, and branches take 2. A mix of 50%, 30%, and 20% gives:

For five billion instructions at 3 GHz, total cycles are 10.5 billion and CPU time is 3.5 s. The unweighted mean of the three class costs, about 2.33, is wrong: the classes do not appear equally often.

More instructions can still mean fewer cycles

Two compiler versions use the same class costs:

Version 1 executes 800 million instructions. Its cycle contributions are 400, 1,200, and 200 million, totaling 1,800 million. Its CPI is:

Version 2 executes 850 million instructions. Its contributions are 600, 600, and 200 million, totaling 1,400 million. Its CPI is:

At 3 GHz, the times are 0.60 s and about 0.467 s. Version 2 is about 1.29 times as fast despite executing 50 million more instructions. Replacing many expensive memory instructions with more cheap ALU instructions can make that trade worthwhile.

CPI belongs to a workload on a machine

Memory stalls, cache misses, branch behavior, and compiler choices change effective CPI. A single “processor CPI” cannot describe every program. Hardware performance counters or a simulator can measure instruction and cycle totals for the workload being analyzed.

Instructions per cycle (IPC) uses the same totals in the opposite order:

An IPC of 2.5 gives CPI 0.4. Multiple instructions can overlap in a processor that issues and completes several instructions per cycle. An average below one does not mean an individual instruction’s full journey finishes in a fraction of a clock tick.

The CPU performance equation brings the three timing factors together:

Here $I$ counts executed instructions and $f$ is the clock rate in effect during execution. Instructions times cycles per instruction gives cycles. Dividing by cycles per second then gives seconds.

Calculate a time and recover an unknown

A program executes two billion instructions at CPI 1.5 on a 2.5 GHz processor. First find the cycle total, then convert it to time:

To infer CPI from measured time, rearrange the same equation:

For 1.6 billion instructions in 0.8 s at 3.2 GHz, there are 2.56 billion cycles. Dividing by 1.6 billion instructions gives CPI 1.6.

Compare complete products

Two processors run the same compiled program with the same instruction count. A has 4 GHz and CPI 1.8; B has 2.5 GHz and CPI 1.0. Their time per instruction is:

B is 1.125 times as fast. Its lower CPI more than offsets its slower clock. Instruction count cancels here because it is equal; it would not cancel if the two programs followed different instruction sequences.

Likewise, a compiler option that cuts instruction count by 10% but raises CPI by 15%, at the same frequency, changes time by:

Time rises by 3.5%. The instruction reduction alone points in the wrong direction.

Connect design choices to the factors

The links are useful for analysis, not independent controls that can always be adjusted without consequences. A cache reduces memory-wait cycles, lowering effective CPI. Pipelining overlaps successive instructions and can lower effective CPI or allow a shorter clock period. Such changes may introduce other costs that appear in the measured totals.

Keep the measurement interval consistent

Measure CPU time, instruction count, cycles, and frequency for the same work. Counters or simulation provide instruction and cycle counts. A product’s rated GHz is not the frequency record for a run that boosts or throttles. When frequency varies, the matching average is total counted cycles divided by the CPU time for that interval.

The equation predicts CPU execution time. Waiting for storage or the network belongs in elapsed time and must be included separately when that is the result the user needs.

A useful performance claim concerns work that matters to the user. A benchmark runs a chosen workload to measure performance. A benchmark suite samples several workloads when one application cannot represent the whole need.

Read the kind of SPEC result

SPEC CPU 2026, released in May 2026, follows SPEC CPU 2017. Its suites exercise processors, memory systems, and compilers. SPECspeed measures completion time for one copy of a program; that copy can itself use multiple threads. SPECrate measures throughput using multiple copies. Integer and floating-point suites serve different workload types, and the product also supports energy metrics.

A single-program speed ratio compares reference time with measured time:

A reference time of 3,000 s and measured time of 250 s gives 12. Higher is better. A rate ratio includes the number of copies completed in the measured interval. Compare like metrics and the same suite version; a speed score and a rate score answer different questions.

Summarize ratios with a geometric mean

For positive ratios, the suite uses:

Ratios 2, 8, and 4 give a product of 64 and a cube root of 4. Their arithmetic mean is about 4.67, a different result.

The geometric-mean comparison does not depend on which reference machine sets the ratios. Suppose X takes 10 s and 40 s on two programs, while Y takes 20 s and 25 s. Reference times of 100 s for both give ratios 10 and 2.5 for X, and 5 and 4 for Y. The geometric means are 5 and about 4.47, so X leads by about 1.12.

Change the reference times to 50 s and 200 s: X gets ratios 5 and 5, Y gets 2.5 and 8. Their geometric means stay 5 and about 4.47. The arithmetic means instead change from 6.25 versus 4.5 to 5 versus 5.25, reversing the ranking. Reference normalization must not decide which machine appears faster.

Why MIPS can reward slower code

MIPS, million instructions per second, is:

Instructions do different amounts of useful work across ISAs. Even on one machine, MIPS changes with the program, and a higher instruction rate can accompany a longer execution time.

At 3 GHz, let ALU, load/store, and branch instructions cost 1, 4, and 2 cycles. Code Q executes 400, 300, and 100 million of them: 800 million instructions, 1,800 million cycles, 0.60 s, about 1,333 MIPS. Code P executes 1,500, 100, and 100 million: 1,700 million instructions, 2,100 million cycles, 0.70 s, about 2,429 MIPS. P retires instructions faster but finishes the task later.

Peak rates describe ideal hardware capacity. Real workloads may reach much less because of dependencies, memory waits, and other limits. Use actual task time to judge task performance; frequency, MIPS, and peak rates explain only selected pieces of it.

Amdahl’s law starts by dividing the original execution time into an affected part and an unaffected part. Speed up only the affected time, then add the pieces back together. This avoids applying a local improvement to work it cannot change.

Build the new time from old times

If the affected part becomes $s$ times as fast:

Let $f$ be the affected fraction of the original execution time. Dividing by the original time gives the speedup form:

A 120 s program spends 90 s on floating-point work and 30 s elsewhere. Thus the affected fraction is 0.75. Making floating point three times as fast reduces its time to 30 s:

The floating-point work gains a factor of three; the complete program gains a factor of two. The unchanged 30 s explains the gap.

Work backward from a target

To finish the same task in 40 s, the unchanged work still needs 30 s. Only 10 s remain for the original 90 s floating-point part. Therefore:

A target of 30 s would leave zero time for that work. No finite acceleration makes a positive amount of affected work take exactly zero time. As the local speedup grows without bound, the overall speedup approaches:

Here the limit is 4, approached from below. With an unaffected fraction of one half, the limit is 2. When all the work is affected, there is no unchanged positive time to impose such a finite ceiling.

Optimize where the time goes

The principle make the common case fast means identifying where execution time is actually spent. Profiling measures that distribution. Doubling a part responsible for 60% of time gives:

A tenfold improvement to a 10% part gives only:

A large local factor can lose to a modest improvement applied to more of the task.

The affected fraction must be a time fraction. If loads/stores are 30% of instructions but take 60% of the cycles, their time fraction at a fixed clock rate is 0.60. Counting instructions equally would miss their larger cost.

Apply the same split to waiting

For a task with 2.00 s of CPU work and 0.50 s of fixed file waiting, doubling CPU speed gives 1.50 s overall. Its speedup is about 1.67. The same time budget works for hardware, software, and I/O improvements: identify exactly which original time changes before applying the factor.

More cores shorten a task only when work can run at the same time. Divide a fixed task’s original single-core time into a serial part and a parallel part, then consider what additional cores can change.

Amdahl’s law for a fixed-size task

Let $p$ be the parallel fraction of the original single-core time. With perfect division across $N$ cores and no overhead:

For a parallel fraction of 0.95, the serial fraction is 0.05. Eight cores give:

At 100 cores the speedup is about 16.8; at 1,000 cores it is about 19.6. The serial 5% keeps the fixed-size speedup below 20 regardless of how many cores are added.

Parallel efficiency is speedup divided by core count. The eight-core efficiency is about 0.74, or 74%. At 100 cores it is about 17%. A larger speedup can come with lower efficiency because each additional core contributes less to the fixed task.

Why measured gains can be smaller

The ideal model gives the parallel work equal shares and no coordination cost. Real programs communicate and synchronize, and some cores receive more work than others.

For 100 equal units of independent work on four identical cores, a balanced assignment gives 25 units to each. If one receives 40 units while the rest finish earlier, completion waits for that busiest core. The speedup is 100 divided by 40, or 2.5, even before adding communication costs. Adding the other cores’ early finishing times together would not give the completion time: the last required result determines it.

A single-threaded program has no parallel fraction to distribute. More cores can still run other programs and improve system throughput, but they do not divide that program’s instruction stream automatically.

Fixed work and growing work ask different questions

Strong scaling holds total problem size fixed and asks how much faster more processors can finish it. Weak scaling grows total work in proportion to processor count so that work per processor stays about constant. A larger simulation can use a finer grid while retaining roughly the same workload per processor.

Gustafson’s law describes scaled work when serial time stays fixed while parallel work grows. Its serial fraction $s$ is measured on the parallel run, unlike Amdahl’s original single-core fraction:

For a measured serial fraction of 0.05 on 100 cores, scaled speedup is 95.05. This does not contradict Amdahl’s limit of 20 for a fixed task whose original serial fraction was 5%. The task size and the fraction’s measurement basis differ.

Parallel software must expose independent work, balance it, and coordinate the results. More hardware provides capacity; the program’s structure determines how much of that capacity shortens its completion time.

CMOS processors consume energy when signals switch and also through leakage while powered. Dynamic energy is associated with switching; static power is drawn even without useful switching. Their relative shares depend on the chip and its workload.

Voltage has a squared effect

The energy associated with a transition scales with capacitance and the square of supply voltage. A common expression uses one half of capacitance times voltage squared; a full charge-and-discharge pulse scales with capacitance times voltage squared. For average dynamic power, use:

Here $C$ is capacitive load, $V$ is supply voltage, $f$ is clock frequency, and $\alpha$ describes switching activity under the chosen counting convention. Some conventions absorb a factor of one half into the activity factor. Ratio calculations work cleanly when the activity convention is kept consistent.

For unchanged capacitance and activity, lowering both voltage and frequency by 20% gives:

The new dynamic power is 51.2% of the original. Lowering voltage alone by 10% gives a factor of 0.81, a 19% reduction in dynamic power and energy per transition.

Lower voltage also slows transistor switching. Dynamic voltage and frequency scaling (DVFS) adjusts voltage and frequency together so the circuitry can still operate at its chosen speed.

Power and energy answer different questions

Power is a rate, measured in watts; one watt is one joule per second. Energy for a task is average power multiplied by duration:

B draws more power while running but uses less energy to complete the task. Cooling must handle the rate of heat production; battery use and electricity consumption accumulate energy over time.

For fixed work with the same transition count, voltage, and activity, lowering frequency alone spreads those transitions over more time. Dynamic power falls, but dynamic task energy is unchanged. Lowering voltage reduces the energy of each transition as well. If static power persists throughout the longer run, slowing down can even increase that part of task energy.

Leakage and idle hardware

Nominally off transistors still pass leakage current. Smaller devices and lower threshold voltages make leakage an important design issue. Power gating disconnects the supply to an idle region to reduce its static draw.

A lightly loaded server can still use a substantial fraction of its peak power. Making consumption follow useful work, called energy proportionality, is a design goal. Finishing a task quickly and entering a low-power state can save energy by shortening the interval over which leakage and other background power are paid. Performance and energy efficiency can therefore improve together.

For decades, smaller transistors brought both more devices and faster switching within a manageable heat budget. The power wall appeared when voltage could no longer keep falling enough to support that pattern. It changed the way designers turned new transistors into useful performance.

The ideal Dennard scaling relationship

In the ideal scaling model developed by Robert Dennard and colleagues in 1974, let a factor $k>1$ describe the shrink. Dimensions, capacitance, voltage, and delay are divided by that factor. Frequency can multiply by the factor. Dynamic power per transistor therefore changes by:

Area per transistor also falls by the square of the shrink factor. The same area can hold that many more transistors, offsetting the lower power per device. Power density, watts per unit area, remains approximately constant in this ideal model.

For a factor of 1.4, capacitance and voltage fall to about 0.71 of their original values and frequency rises by 1.4. Power per transistor falls to about 0.51. About 1.96 times as many transistors fit, so total power in the same area stays roughly unchanged.

Why voltage stopped tracking size

Transistors need a usable switching threshold. Reducing threshold voltage too far sharply increases leakage. By the mid-2000s, supply voltage could no longer shrink in step with transistor dimensions. At nearly fixed voltage, a higher frequency raises dynamic power, and packing more active transistors into an area raises the heat that must be removed.

The historical figures show the scale of the earlier change: desktop clocks rose from around 10 MHz in the early 1980s to 3.8 GHz in 2004, while supply voltages fell from roughly 5 V toward 1 V. Those are broad historical values, not universal specifications. Around 100 W was already a difficult cooling budget for many mainstream designs of that period.

Intel’s 2004 cancellation of the planned 4 GHz Pentium 4 and Tejas design marked that turn toward power-conscious designs and dual cores. Clock rates subsequently remained on the scale of a few gigahertz instead of following the earlier rapid climb. Microarchitecture continued to improve single-core performance, but frequency increases supplied much less of the gain.

Manage the thermal budget

Thermal design power (TDP) is a thermal-design target used to size a cooling solution under specified operating conditions. It is not an instantaneous power measurement or a universal maximum. When thermal limits are reached, throttling lowers operating speed to reduce heat.

If a chip contains more hardware than its power budget can run together at full speed, some regions must be slowed or switched off. Dark silicon names this gap between available transistors and simultaneously usable active hardware.

Moore’s law and Dennard scaling describe different trends: transistor counts versus power-aware scaling behavior. The breakdown of the latter did not mean transistor counts stopped growing. The obstacle to indefinitely raising frequency is chiefly power and heat, not a sudden inability of transistors to switch any faster.

A multicore processor places several cores on one chip. Each core runs an instruction stream, while cores share main memory and often some caches. Mainstream desktop and laptop designs moved toward dual cores around 2005–2006 as raising a single core’s clock became increasingly costly in power.

Compare two slower cores with one faster core

Consider one core at 4 GHz and 1.2 V versus two cores at 3 GHz and 1.0 V. Keep capacitance per core and switching activity the same for this comparison. Relative dynamic power is:

With equal work per cycle and enough independent work for both cores, ideal throughput changes by:

The pair offers about 50% more throughput for about 4% more dynamic power. The squared voltage reduction makes the extra core affordable in this model. Static power, shared memory limits, and coordination costs still matter when assessing a complete chip.

For a sequential program using only one new core, performance falls to three quarters of the original at equal work per cycle. It takes four thirds as long. Combining the two 3 GHz rates into “6 GHz” would conceal that outcome: neither core ticks at 6 GHz.

Software must expose the work

Before the power wall, higher frequency and hardware overlap often accelerated existing code without major changes. Extra cores need independent instruction streams. A program gains from them by dividing its work into concurrent tasks, balancing the assignments, and coordinating results. Parallel libraries can provide that structure, but the work still must have a useful parallel form.

Instruction-level parallelism overlaps instructions within a stream, using hardware and compiler techniques such as pipelining and multiple issue. Thread-level parallelism runs different threads across cores. These are different sources of concurrency: the first does not ensure that a program can occupy every core.

Independent server requests naturally provide many streams, so multicore can improve throughput even when each request remains sequential. Shortening one request’s computation needs parallelism inside that request. Its serial fraction then imposes the Amdahl limit.

Spend transistors on efficient kinds of work

More transistors can support larger caches, several general-purpose cores, or specialized hardware. GPUs and domain-specific accelerators target workloads such as graphics, machine learning, and video encoding. Chips can also mix fast, high-power cores with smaller, more efficient cores, as in Arm big.LITTLE designs.

Under a fixed power budget, performance per watt compares useful performance with power draw. SPEC CPU 2026 also supports energy measurements alongside performance metrics. A good design decision considers the workload’s completion time, its energy cost, and the power the system can sustain.