Performance

Every figure on this page is from one run, committed under crates/ddust/bench/results/: each pass’s transcript and figures, the code size of each operation, and a manifest.toml that says how they were taken. The run was taken on an AWS Graviton4 (Arm Neoverse V2, a c8g.8xlarge) under Linux 6.12.53, built by rustc 1.101.0-nightly of 2026-09-27 in the bench profile (release’s settings with fat LTO, one codegen unit, panic = "abort" and no overflow checks), pinned with taskset to a core the kernel keeps other work off; the manifest records the host’s load before and after.

The name is the time the run was taken, in UTC, the pull request whose code it measured, what it measured, and the machine.

How It Is Measured

Every crate is built into one binary and measured in one run, since code layout alone moves a figure between builds by a few percent. Each operation is each crate’s fastest correct call, with the rounding mode the crate uses, and ddust is measured again in that mode where a crate’s differs from half to even. The benchmarks’ equivalence test checks every result against an exact reference; a row whose results differ is marked inexact, and is timed all the same.

Each operation runs over two sets of values:

• Predictable: 1,024 values of one sign and one count of digits, which stay in the level 1 cache: the best case for a branch on the value.
• Unpredictable: 65,536 values of random signs and counts of digits, more than a branch predictor learns, so a branch on the value mispredicts as it would in a program.

Narrow values are 64-bit at 8 decimals, a price or a quantity as most venues send one; wide values are 128-bit at 18 decimals, a token’s amount as a chain holds it. A crate with one type, as rust_decimal has, is measured at both. Beside the decimals stand the floors, i64, i128 and f64 doing the plain operation a decimal’s is built on: the cost no decimal goes below, which the reference does not check.

Each table lists the crates fastest first on the unpredictable set, with the nanoseconds per operation on each set, and the cycles, instructions and branch misses per operation on the unpredictable set. An operation is timed by throughput, independent operations over the values; the sum, the rounded product and the rounded quotients are timed by latency too, in a chain where each waits for the one before.

Adding and Comparing

A decimal of a static scale is its integer, so adding two is the integer’s add with its overflow check, and comparing two is the integer’s compare:

The checked sum, narrow, 64 bits at 8 decimals:

The checked sum, wide, 128 bits at 18 decimals:

The order, narrow, 64 bits at 8 decimals:

The order, wide, 128 bits at 18 decimals:

The fixed-point crates are within a few percent of each other and of the integer here, since each is the integer underneath; ddust’s checked add takes 9.00 instructions where the i64’s takes 7.00. The two more are the cost of Decimal’s repr(C) layout, which keeps a decimal its integer’s bytes for zerocopy and bytemuck: Rust builds an Option of such a struct in memory, where it returns an Option of a bare integer in two registers. The crates that carry a scale in each value, rust_decimal, fastnum, decimal-rs and bigdecimal, line two scales up before they add, at the cost of branches the unpredictable set mispredicts.

Multiplying

An exact product of a price at 2 decimals and a quantity at 5 is a notional at 7: the integer’s multiply with its overflow check, and nothing for the scale:

The exact product, narrow, 64 bits at 8 decimals:

A product rounded back to the factors’ scale is the exact product in an integer twice as wide, divided by $10^8$ or $10^{18}$ through a multiply by its reciprocal, and the remainder read against half the divisor for the mode; no division instruction is left in it, which just bench-assembly checks on aarch64 and x86_64:

The rounded product, narrow, 64 bits at 8 decimals:

The rounded product, wide, 128 bits at 18 decimals:

Division

A rounded quotient is $a\times 10^d/b$ in an integer twice as wide. A narrow numerator that fits in 64 bits is divided by one udiv. On aarch64, a wider one is taken from a double’s estimate, which the core’s pipelined fdiv makes in a few cycles, then corrected to the exact quotient by a comparison, or a step and a comparison, wherever a proof bounds the estimate’s error; a wide quotient, 256 bits by 128, is taken the same way:

The rounded quotient, narrow, 64 bits at 8 decimals:

The rounded quotient, wide, 128 bits at 18 decimals:

The same quotients, each dividend by one divisor, as a book is divided by one price:

The rounded quotient by one divisor, narrow, 64 bits at 8 decimals:

The rounded quotient by one divisor, wide, 128 bits at 18 decimals:

A Divisor prepared from that one divisor divides by two multiplications and a comparison, with no division at all; no other crate has one:

The rounded quotient by a prepared divisor, narrow, 64 bits at 8 decimals:

The rounded quotient by a prepared divisor, wide, 128 bits at 18 decimals:

A narrow quotient by a prepared divisor takes 3.00 ns where by the decimal it takes 5.97, and a wide one 12.4 where by the decimal it takes 16.0. Preparing it costs a division, so it pays from the second quotient on.

Rescaling

A value rounded from 8 or 18 decimals to 2, a price to cents, divides by a power of ten the compiler knows, through a multiply by its reciprocal:

To cents, narrow, 64 bits at 8 decimals:

To cents, wide, 128 bits at 18 decimals:

Text

Reading takes a number of up to 32 bytes into 32 vector lanes at once, puts its digits in their steps’ places by one lookup, and makes the number by multiplies in the lanes, with no branch on its length, so the unpredictable set costs nearly what the predictable one does. Each crate reads the text exactly, and refuses a digit past its scale; fin_decimal rounds one instead, and is marked so:

Reading, narrow, 64 bits at 8 decimals:

Reading, wide, 128 bits at 18 decimals:

Writing splits the steps into their 32 digits by multiplies, and makes each window of the text by one lookup into them; Display, through a formatter, is measured where a crate has nothing faster:

Writing, narrow, 64 bits at 8 decimals:

Writing, wide, 128 bits at 18 decimals:

Floats

A decimal becomes the nearest double. Steps below $2^{53}$ at up to 22 decimals take one conversion and one division by an exact power of ten, Clinger’s fast path; past them, a division of the steps by a power of five makes the double’s 53 bits and the bits that round them. The predictable set’s steps have 17 and 28 digits, past $2^{53}$, so at narrow width it is the slower one here. The crates marked inexact compute the double in floating point, rounding more than once:

To a double, narrow, 64 bits at 8 decimals:

To a double, wide, 128 bits at 18 decimals:

A double becomes the decimal nearest its exact binary value, by the mode. The product of the double and the power of ten, and its residual, which a fused multiply-add computes exactly, decide the rounding below $2^{52}$; past it, the double’s bits are scaled exactly. The crates marked inexact multiply in floating point, or round the double’s shortest text:

From a double, narrow, 64 bits at 8 decimals:

From a double, wide, 128 bits at 18 decimals:

Latency

A chain makes each operation wait for the one before, by taking its operands at an index the previous result decides: what a calculation that feeds on its own results costs, where throughput is what a loop over independent values costs. The index takes a byte that depends on both halves of each result, so a compiler that inlines the operation into the chain still computes all of it.

The checked sum, in a chain, narrow, 64 bits at 8 decimals:

The checked sum, in a chain, wide, 128 bits at 18 decimals:

The rounded product, in a chain, narrow, 64 bits at 8 decimals:

The rounded product, in a chain, wide, 128 bits at 18 decimals:

The rounded quotient, in a chain, narrow, 64 bits at 8 decimals:

The rounded quotient, in a chain, wide, 128 bits at 18 decimals:

The rounded quotient by one divisor, in a chain, narrow, 64 bits at 8 decimals:

The rounded quotient by one divisor, in a chain, wide, 128 bits at 18 decimals:

The rounded quotient by a prepared divisor, in a chain, narrow, 64 bits at 8 decimals:

The rounded quotient by a prepared divisor, in a chain, wide, 128 bits at 18 decimals:

A Mix, and Code Size

A program mixes operations, and what each brings into the instruction cache is then a cost of its own. The mix runs a sum, an order, a rounded product, a rounded quotient and a value to cents in turn over the same values, with the level 1 instruction cache’s misses and the front end’s stalled cycles per operation:

The mix, narrow, 64 bits at 8 decimals:

The mix, wide, 128 bits at 18 decimals:

Each operation’s code, in instructions, with every function it calls but the panics and ddust’s cold paths, which a value past 19 decimals or a result past its integer reaches; read from the release build’s disassembly on aarch64:

A call through a pointer, which core::fmt makes, is not followed: a crate that writes text through Display counts only the code around the formatter. ddust’s reader and writer count their general paths, for a number past 32 bytes or 30 decimals, beside their vector ones.

What to Keep off a Hot Path

• A wide division where a narrow one does. A D128 quotient costs about three times a D64’s, and a chain of them two to three times; a quantity, a price or a cash amount fits a D64.
• Dividing many values by one decimal. A Divisor prepared once divides with no division.
• A conversion to a double inside a calculation. It is correctly rounded and cheap, but the double is rarely the decimal, and a calculation that goes through one loses the exactness ddust keeps.

How It Was Checked

The benchmarks’ equivalence test checks every result against an exact reference, on both sets and at both widths. The kernels that divide only by constants, the add, the compare, the rounded product, the rescale, the reader, the writer and both float conversions, are held by just bench-assembly to contain no division instruction and call no division routine, on aarch64 and x86_64. Each figure is the median of the five passes’ medians: 124 of the run’s 782 times spread past 2% across the passes, half of them operations under two nanoseconds, where 2% is under a twentieth of one, and the run’s summary.toml keeps each one’s range. It runs with:

just bench-run 18 baseline graviton4 --passes 5