Microseconds to Nanoseconds

A Microsecond Is a Very Long Time Inside a CPU

Profilers hand back microseconds. The memory hierarchy those microseconds were spent in is documented in cycles and nanoseconds — a cache-latency table quotes 4 cycles for L1, a memory kit is sold as CL16, an architecture manual gives a misprediction penalty of 17 cycles. Before any of that explains a hot loop, the profiler's µs figure has to come down to the scale the hardware is described at, and the arithmetic is a single multiplication.

Conversion factor: 1 µs = 1,000 ns, so multiply the microsecond figure by 1,000. A function the profiler attributes 0.08 µs to is 80 ns — about one full trip out to DRAM, or roughly 320 cycles on a 4 GHz core.

What the Nanosecond Column Is Made Of

The clock sets the exchange rate

One cycle is 0.333 ns at 3 GHz, 0.25 ns at 4 GHz and 0.2 ns at 5 GHz. Nanoseconds only become cycles once you know which clock the core was actually running at during the measurement.

Each cache level is roughly a decade apart

An L1 hit lands around 1 ns, L2 a few nanoseconds, a local L3 slice near 10 ns, and a full DRAM round trip near 80 ns. Missing one level costs more than everything the instruction itself does.

CAS latency is only the last leg

DDR4-3200 CL16 works out to exactly 10 ns of column access, yet the load that triggered it still waits about 80 ns overall — address translation, the controller queue and the row activation all happen first.

A wrong branch throws away the pipeline

Measured penalties on recent x86 cores sit around 16 to 21 cycles — near 4 ns at 4 GHz. Small in isolation, decisive in a loop that mispredicts on a third of its iterations.

From a Profiler Line to a Cycle Count

The point of the conversion is to find out whether a measured cost is plausible for the work the code claims to be doing.

Enter the per-call cost from the profile

Type the microsecond figure — 0.004, 0.08, 1.2 — and the nanosecond value appears as you type. Small numbers keep up to eight decimals, and anything below a millionth of the unit switches to scientific notation rather than rounding away.

Divide by the cycle time of your core

Nanoseconds become cycles when you multiply by the clock in GHz: 80 ns on a 3.2 GHz part is 256 cycles. Compare that with the hierarchy table below and the bottleneck usually names itself.

Reverse it for a datasheet figure

Press the swap control (↔) to run ns → µs when the number starts life in the hardware documentation — a 350 ns interrupt path or a 45 ns memory spec that has to be weighed against a microsecond-scale budget.

Move the value into your model

The copy control puts the bare digits on the clipboard, which is what a spreadsheet cell or a back-of-envelope cost model wants — no unit suffix to strip out first.

Remember the clock moves: turbo, thermal limits and frequency scaling mean the core rarely spends a whole benchmark at its nameplate speed, so a cycle count derived from nanoseconds is an estimate unless you sampled the frequency alongside the timing.

The Memory Hierarchy in Cycles, Nanoseconds and Microseconds

Representative access costs on a modern out-of-order x86 core, using a 4 GHz clock so that one cycle is exactly 0.25 ns. Exact values move with microarchitecture, cache size and memory configuration; the ratios between rows are what stay stable.

Access	Cycles at 4 GHz	Nanoseconds	Microseconds
Register-to-register operation	1	0.25 ns	0.00025 µs
L1 data cache hit	4	1 ns	0.001 µs
L2 cache hit	14	3.5 ns	0.0035 µs
Branch misprediction flush	17	4.25 ns	0.00425 µs
L3 hit, local slice	40	10 ns	0.01 µs
DRAM load, DDR4-3200 CL16	320	80 ns	0.08 µs
Remote-socket DRAM load	560	140 ns	0.14 µs

Read the last column and the scale problem becomes obvious: the slowest row on this list is barely a seventh of a microsecond. A profiler entry of 1 µs is not one memory access gone wrong, it is thousands of operations — which is why chasing individual instructions rarely moves a microsecond-scale number, and changing the data layout so the loop stops missing cache usually does.

Handy When You Are Working at This Scale

Type in whichever box has the number

Both fields are editable, so a cache-latency table in ns and a profiler export in µs can be reconciled row by row without swapping direction each time.

Turn the pair around for hardware specs

The swap control gives ns → µs, the direction that suits datasheets, timing diagrams and anything quoted straight out of an architecture manual.

Fractions of a nanosecond survive

Eight decimals of output mean a 0.25 ns cycle time or a 0.00025 µs instruction cost still reads as a number instead of rounding to nothing.

Step out to ms or s when the trace does

Searchable dropdowns on both sides cover every time unit, so a whole-run wall-clock figure and a per-instruction cost stay on one page.

What Performance Engineers Ask About This Scale

How do I turn a cycle count into nanoseconds for my clock speed?

Divide the cycles by the clock in GHz. Forty cycles at 4 GHz is 40 ÷ 4 = 10 ns; the same forty cycles at 2.5 GHz is 16 ns. Going the other way, multiply nanoseconds by the GHz figure. The consequence catches people out: a cache-latency number quoted in cycles gets worse in real time on a downclocked core, and every published latency table is silently tied to whatever clock the author measured at.

Why are cache latencies published in cycles rather than nanoseconds?

Because caches are built into the core's clock domain, so their latency is a fixed number of cycles by design and does not change when the frequency does. Quoting cycles makes the figure portable across every part in a family. Main memory is the opposite case — the DRAM runs on its own clock, so its latency is genuinely a physical duration and is quoted in nanoseconds. That mismatch is exactly why a DRAM miss costs more cycles on a fast core than a slow one.

What does CL16 at DDR4-3200 actually work out to?

DDR4-3200 transfers at 3,200 MT/s from a 1,600 MHz bus clock, so one memory cycle is 0.625 ns. Sixteen of them is exactly 10 ns of CAS latency, which is the reason CL16 at 3200 and CL14 at 2800 feel so similar — 14 ÷ 1400 gives the same 10 ns. It is also why a raw CL number tells you nothing on its own: divide it by half the transfer rate in MHz to get the time.

Is a microsecond really "a thousand cache misses"?

Not quite, and the correction is worth carrying around. At roughly 80 ns per DRAM round trip, a microsecond is about twelve full misses, not a thousand. The thousand figure fits L1 hits, which land near 1 ns each. Both readings say the same useful thing from different ends: a single microsecond of unexplained time in a profile is an enormous amount of hardware activity, and it will never be explained by one slow instruction.

Can I measure a nanosecond-scale event from application code?

Not directly. A monotonic clock read costs on the order of 20 to 30 ns by itself, so timing a 1 ns cache hit with two of them measures the timer rather than the code. The working method is to run the operation a few million times inside a loop, measure the whole loop in microseconds or milliseconds, and divide — which is what a benchmark harness does for you. Anything finer needs hardware performance counters, where the core itself does the counting.