Performance of dfloat

The timings below measure the speed of the dfloat operations, to help choose between the formats and between dfloat, nfloat and arb_t. All numbers are nanoseconds per operation on one core of an Intel Xeon (Skylake-AVX512 class, 2.8 GHz, a virtual machine), measured with the programs in src/dfloat/profile. The absolute numbers vary by up to 1.5 times between runs on this machine, so only ratios within a table are meaningful.

Arithmetic#

Scalar columns: calls on independent operands through the generic ring. Vector columns: per element of a vector of length 1024 (_gr_vec_add, _gr_vec_mul and the dot product _gr_vec_dot), which use SIMD four elements at a time. Suffixes: s a strong (canonicalising) context, f a fast context (DFLOAT_FAST). nfloat is at 64, 128, 192 and 256 bits and arb_t at 53N bits.

Against nfloat, the plain expansions win clearly for N \le 2 (the d1 operations are single instructions), and the balls are comparable for N \le 2 while carrying a rigorous error bound; the vector operations and dot products are 1.5 to 3 times faster than nfloat for N \le 3. For N = 3, 4, nfloat addition and multiplication (limb arithmetic) are faster than the expansion operations, by a factor 2 for products at N = 4. Division and square root of expansions are 1.5 to 4 times faster than nfloat. The balls cost 1.2 to 1.7 times the plain numbers for products and 2 to 4 times for division and square root, whose exact residuals cost a product and a difference.

Canonicalisation (DFLOAT_STRONG) costs nothing for N = 1, a check (1 to 2 ns) for N = 2, and a dependent TwoSum chain for N = 3, 4: about 5 and 8 ns per scalar operation (60% on a plain addition, 30% on a ball addition, 25% on a ball product), and up to 100% on the cheapest vector operations, whose results are canonicalised one at a time.

Division and square roots#

A Newton–Karp–Markstein division [KM1997] (a reciprocal at half precision, one product and one correction) is slower than the long division at every N (75 against 49 ns at N = 4 in one run): the steps of the long division are cheap products of a single double with the divisor, and it needs no full-precision square. Precomputing 1/y_0 does not help either: the divisions are not on the critical path of the products. Square roots, per element, in a run on a machine about twice slower than in the table above (b denotes the ball versions):

Elementary functions#

Scalar calls through the generic ring and the vector functions _dN_vec_exp, etc., per element of a vector of length 1024; the arb_t vector versions are loops over the scalar functions.

The ball versions cost about the same as the plain ones for N \ge 2 (the radius is a static relative bound plus the propagated input radius) and up to twice as much for N = 1, where the plain kernels are a few instructions. For N = 1 the kernels are about as fast as the C library on the same machine (exp 4.6, sin 6.7, log 3.3, atan 4.8 ns), whose near-correct rounding they do not attempt. Against arb_t, the scalar functions are 20 to 40 times faster for N = 1, 3 times for N = 2 and about as fast for N = 4; the vector functions 50 to 100, 10 and 4 to 6 times. sin_cos costs about 10% more than sin; expm1 and log1p cost the same as exp and log, and the compositions (tan, pow, ...) the sum of their parts.

Polynomial multiplication#

Classical multiplication of two polynomials of length 256, which runs on _dN_vec_dot_rev, costs per coefficient product 0.54, 3.4, 9.0 and 18 ns for d1 to d4, and 3.5, 9.2, 16 and 25 ns for d1b to d4b (against 1.0, 12, 25, 61 and 8.4, 9.7, 16, 27 ns with a scalar loop); the gains start at length 16.

Complex numbers#

Calls through the generic ring, against acb_t at 53N bits:

The complex balls are several times faster than acb_t for N \le 2, faster for N = 3 and on par for N = 4. Dot products of length 64, per term (loop: a loop of complex gr_mul and gr_add):

Benchmarking notes#

On Skylake-family processors, whose JCC erratum microcode keeps jumps that cross or end on a 32-byte boundary out of the decoded-instruction cache, the speed of short hot loops (dot products, short vector operations) varies by up to 25% with the placement of the code, between builds of identical instructions. Comparisons of such loops are best made with the module assembled with -Wa,-mbranches-within-32B-boundaries.

Everything that depends on N is compiled four times and the kernels are fully unrolled, so the object code is large (about 0.9 MB of text, most of it the scalar and vector cores of the elementary functions and of division and square root). Small operations are inlined only where that pays off, and calls within the module never go through the procedure linkage table; relative to inlining everything, this saves 36% of the text without measurable loss of speed.

@misc{flint-doc-dfloat-performance,
  author       = {{The FLINT team}},
  title        = {{Performance of dfloat (dfloat.h)}},
  howpublished = {FLINT: Fast Library for Number Theory, documentation, version 3.7.0-dev},
  year         = {2026},
  url          = {https://flintlib.org/doc/dfloat/performance.html},
  note         = {Generated 2026-10-20}
}