High-performance numerical kernels are defined by the algebraic laws they exploit and by the architectural parameters they expose. Associativity of addition, distributivity of multiplication over addition, cache-line geometry, SIMD vector width, TLB reach, and the precise cost of data motion through the memory hierarchy jointly determine both attainable accuracy and attainable throughput.
\nAny language or environment that conceals those parameters prevents the programmer from stating the algorithm that is actually executed and from attaching a verifiable a-priori error bound to the computed result.
\n\nUnder IEEE-754 arithmetic, the parenthesisation of a sum or an inner product is part of the algorithm. Let
\ns=i=1∑nxi.\nA strictly sequential left-to-right accumulation satisfies
\n∣fl(s)−s∣≤γn−1i=1∑n∣xi∣,\nwhere
\nγk=1−kuku,\nand (u) is the unit roundoff, equal to
\nu=2−53\nfor binary64.
\nAn accumulation performed with (k) independent partial sums, the natural form under SIMD lanes or multi-threaded reduction trees, has a bound of order
\nγn/k+ki=1∑n∣xi∣.\nFor terms of like sign, the reassociated form is therefore both faster and potentially more accurate: the depth of the dependency chain shrinks from (n) to roughly (n/k+k).
\nWhen cancellation is present, both bounds become relative to
\ni=1∑n∣xi∣\nrather than to
\n∣s∣.\nThe comparison of accuracy therefore becomes data-dependent.
\nThe important point is that the parenthesisation is not an implementation detail. It is part of the numerical algorithm.
\nConsider the two computations
\nsseq=(((x1+x2)+x3)+⋯)+xn\nand
\nstree=(x1+x2)+(x3+x4)+⋯.\nThey are equal over the real numbers. They are not generally equal over floating-point numbers.
\nA four-way accumulation makes the distinction explicit:
\ndouble a0 = 0.0;
double a1 = 0.0;
double a2 = 0.0;
double a3 = 0.0;
for (std::size_t i = 0; i + 4 <= n; i += 4) {
a0 += x[i + 0];
a1 += x[i + 1];
a2 += x[i + 2];
a3 += x[i + 3];
}
double sum = a0 + a1 + a2 + a3;
The source now specifies the reassociation. The compiler does not need permission to invent it.
\nMATLAB's sum, matrix-vector product and higher-level factorisations select a parenthesisation, a blocking factor and an intermediate precision sequence that never appear in the user's text. The realised value of (k) cannot be named, the corresponding (\\gamma) constant cannot be written, and any subsequent change in the vendor's vectorisation heuristic or BLAS binding can alter the bit pattern of the result without a corresponding change in the calling code.
The same opacity governs every composite kernel: blocked LU with partial pivoting, sparse CSR or CSC matrix-vector products, and the recursive Newton-Euler algorithm for inverse dynamics all inherit an accumulation order and a temporary-materialisation policy that are external to the numerical specification written by the user.
\nCompensated summation makes the distinction even sharper. The classical TwoSum transformation is
\n(s,e)=TwoSum(a,b),\nwith
\ns=fl(a+b),e=fl((a−s)+b).\nThe residual (e) is precisely the information that ordinary floating-point addition discards. Algebraically, the expression is zero. Numerically, it need not be.
\nA compiler transformation that assumes unrestricted associativity can therefore destroy the very rounding behaviour on which the algorithm depends.
\nOn contemporary CPUs, the dominant term in the runtime of dense and sparse kernels is frequently data motion rather than arithmetic. The number of (L_1) and (L_2) misses, the number of TLB walks, the ability to issue 256-bit or 512-bit vector loads, and the arithmetic intensity in flops per byte transferred from DRAM are functions of the concrete layout, leading dimension, alignment, and reuse distance of the working set.
\nA language that represents every array as an opaque descriptor whose relevant properties are resolved only at run time makes these parameters difficult to express as part of the algorithm itself.
\nC++ allows them to become part of the interface.
\nFor example, a kernel can require contiguous storage:
\n#include <concepts>
#include <span>
#include <type_traits>
template<class T>
concept Arithmetic =
std::is_arithmetic_v<T>;
template<Arithmetic T>
double dot(
std::span<const T> x,
std::span<const T> y)
{
double result = 0.0;
for (std::size_t i = 0; i < x.size(); ++i) {
result += static_cast<double>(x[i])
* static_cast<double>(y[i]);
}
return result;
}
The abstraction is not merely syntactic. std::span expresses a non-owning contiguous range, while the template constraint restricts the domain of the kernel.
The same operation can be expressed with stronger compile-time information when the extent is known:
\n#include <array>
#include <cstddef>
#include <type_traits>
template<class T, std::size_t N>
requires std::is_arithmetic_v<T>
constexpr T dot(
const std::array<T, N>& x,
const std::array<T, N>& y)
{
T result{};
for (std::size_t i = 0; i < N; ++i) {
result += x[i] * y[i];
}
return result;
}
The loop bound is now part of the type. For sufficiently small (N), the entire computation can be evaluated during translation:
\nconstexpr std::array<double, 4> x{
1.0, 2.0, 3.0, 4.0
};
constexpr std::array<double, 4> y{
5.0, 6.0, 7.0, 8.0
};
constexpr double result = dot(x, y);
static_assert(result == 70.0);
This does not mean that every C++ numerical kernel should be written with fixed-size arrays. It means that the programmer can choose which properties belong to the static interface and which remain dynamic.
\nThe same principle applies to multidimensional layout. With std::mdspan, the shape and layout of a multidimensional view can be separated from the algorithm operating on it:
#include <mdspan>
#include <algorithm>
#include <cstddef>
template<class Matrix>
double trace(const Matrix& A)
{
double result = 0.0;
const auto n =
std::min(A.extent(0), A.extent(1));
for (std::size_t i = 0; i < n; ++i) {
result += A(i, i);
}
return result;
}
The algorithm does not have to be rewritten for row-major and column-major storage. The layout policy becomes part of the view.
\nThat distinction matters because the machine does not execute an abstract matrix. It executes loads and stores at concrete addresses.
\nPython, through NumPy, SciPy and the surrounding array-programming stack, provides an exceptionally productive interactive surface. For standard operations, this is not a weakness: NumPy delegates substantial numerical work to compiled native kernels, and Python is often an excellent orchestration language.
\nThe distinction appears when the required computation is no longer one of those standard kernels.
\nA simple NumPy expression such as
\ny = alpha * x + beta * z
looks like one operation at the language level. Depending on the expression and implementation, it can involve several native kernels and intermediate arrays.
\nA fused implementation can make the data movement more explicit:
\nimport numpy as np
def fused_axpby(alpha, x, beta, z, out):
np.multiply(x, alpha, out=out)
out += beta * z
return out
This is already better because the destination is controlled. But the programmer still does not obtain the same degree of control over the generated machine-level kernel as a C++ implementation in which the loop, layout, vectorisation constraints, and accumulation structure are directly expressed.
\nThe difference becomes larger when the algorithm itself is unusual.
\nSuppose the desired operation is a four-way reduction:
\ndef four_way_sum(x):
a0 = 0.0
a1 = 0.0
a2 = 0.0
a3 = 0.0
n = len(x)
for i in range(0, n - 3, 4):
a0 += x[i + 0]
a1 += x[i + 1]
a2 += x[i + 2]
a3 += x[i + 3]
return a0 + a1 + a2 + a3
The algorithm is now explicit, but the Python loop is not a competitive implementation of the numerical kernel. The usual answer is to move the operation into NumPy, Numba, Cython, C, C++, Rust, or another compiled layer.
\nThe language is therefore excellent at expressing the use of a numerical kernel while often being less suitable for expressing the kernel itself when its performance contract is unusually specific.
\nJulia closes much of this gap.
\nA Julia implementation can specialize a generic kernel on concrete argument types:
\nfunction dot_product(
x::AbstractVector{T},
y::AbstractVector{T}
) where {T<:AbstractFloat}
result = zero(T)
@inbounds @simd for i in eachindex(x, y)
result += x[i] * y[i]
end
return result
end
Broadcast fusion can also keep an expression at the level of one fused computation:
\ny .= α .* x .+ β .* z
rather than requiring the programmer to explicitly construct every intermediate array.
\nThis is one of Julia's major strengths. The language can preserve a high-level mathematical notation while specializing the implementation to concrete types.
\nIt does not, however, eliminate the underlying machine-level questions. Allocation, aliasing, memory locality, vectorisation, garbage collection, calling conventions, and library boundaries remain properties of the executed program.
\nC++ occupies a different point in this design space because the language does not force the numerical algorithm to remain at the level of a dynamic array expression.
\nThe programmer can state the representation, lifetime, alignment, ownership, layout, and algorithmic structure directly.
\nFor example, allocation can be removed from a numerical kernel entirely:
\ntemplate<class T>
void axpy(
T alpha,
std::span<const T> x,
std::span<T> y)
{
for (std::size_t i = 0; i < x.size(); ++i) {
y[i] += alpha * x[i];
}
}
There is no hidden allocation in the algorithm. The function receives storage owned elsewhere.
\nFor a reduction where reassociation is desirable, the algorithm can expose independent accumulators:
\ntemplate<class T>
requires std::is_floating_point_v<T>
T parallel_sum(std::span<const T> x)
{
T a0{};
T a1{};
T a2{};
T a3{};
const std::size_t n = x.size();
const std::size_t limit = n - (n % 4);
for (std::size_t i = 0; i < limit; i += 4) {
a0 += x[i + 0];
a1 += x[i + 1];
a2 += x[i + 2];
a3 += x[i + 3];
}
T result = a0 + a1 + a2 + a3;
for (std::size_t i = limit; i < n; ++i) {
result += x[i];
}
return result;
}
The compiler may vectorise this loop, but the important fact is that the mathematical reassociation is already present in the source.
\nIf a different numerical policy is required, it can be written instead:
\ntemplate<class T>
requires std::is_floating_point_v<T>
T compensated_sum(std::span<const T> x)
{
T sum = 0;
T correction = 0;
for (const T value : x) {
const T y = value - correction;
const T t = sum + y;
correction = (t - sum) - y;
sum = t;
}
return sum;
}
These two functions represent different numerical algorithms. A global compiler option does not decide which one the programmer intended.
\nThat is the crucial distinction.
\nThe compiler is free to optimise the algorithm. It is not being asked to invent the numerical policy.
\nThe same principle extends to matrix kernels. A simple blocked matrix multiplication can expose its blocking factor directly:
\ntemplate<class T>
void matmul_blocked(
std::span<const T> A,
std::span<const T> B,
std::span<T> C,
std::size_t n,
std::size_t block)
{
for (std::size_t ii = 0; ii < n; ii += block) {
for (std::size_t kk = 0; kk < n; kk += block) {
for (std::size_t jj = 0; jj < n; jj += block) {
const std::size_t i_end =
std::min(ii + block, n);
const std::size_t k_end =
std::min(kk + block, n);
const std::size_t j_end =
std::min(jj + block, n);
for (std::size_t i = ii; i < i_end; ++i) {
for (std::size_t k = kk; k < k_end; ++k) {
const T aik = A[i * n + k];
for (std::size_t j = jj; j < j_end; ++j) {
C[i * n + j] +=
aik * B[k * n + j];
}
}
}
}
}
}
}
The block size is now an algorithmic parameter rather than an implementation detail buried inside a library.
\nIt can be benchmarked against the target cache hierarchy:
\nconstexpr std::size_t block = 32;
matmul_blocked(
A,
B,
C,
n,
block);
Or selected according to the target architecture:
\ntemplate<class T>
constexpr std::size_t block_size()
{
if constexpr (sizeof(T) == 8) {
return 32;
} else {
return 64;
}
}
This is not merely about writing more code. It is about deciding which quantities belong to the numerical and architectural specification.
\nThe strongest case for C++ in this context is not that C++ is inherently faster than every other language. It is that C++ permits the numerical algorithm, representation, and machine-level policy to remain visible simultaneously.
\nA reduction policy can be represented as a type:
\nstruct SequentialReduction {
template<class T>
static T combine(T a, T b)
{
return a + b;
}
};
struct PairwiseReduction {
template<class T>
static T combine(T a, T b)
{
return a + b;
}
};
A generic algorithm can then take the policy explicitly:
\ntemplate<class T, class Reduction>
requires std::is_floating_point_v<T>
T reduce(
std::span<const T> x,
Reduction reduction)
{
if (x.empty()) {
return T{};
}
T result = x.front();
for (std::size_t i = 1; i < x.size(); ++i) {
result = reduction.combine(result, x[i]);
}
return result;
}
The important abstraction is not the class itself. It is the fact that the numerical policy is represented as a program entity that can be inspected, tested and replaced.
\nThe same design can be used for accumulation precision:
\ntemplate<class Input, class Accumulator>
Accumulator sum_as(
std::span<const Input> x)
{
Accumulator result{};
for (const Input value : x) {
result += static_cast<Accumulator>(value);
}
return result;
}
Now the distinction between binary32 input and binary64 accumulation is explicit:
\nfloat sum_f32 = sum_as<float, float>(x);
double sum_f64 = sum_as<float, double>(x);
The precision policy is no longer an implicit property of an interpreter, a BLAS implementation, or a compiler heuristic.
\nRobotics imposes a stricter requirement set than most scientific computing workloads: hard real-time deadlines, bounded and predictable memory traffic, deterministic latency from sensor interrupt to actuator command, and the ability to audit numerical residuals that enter safety-critical decisions.
\nA typical torque-control loop might execute at 1 kHz or faster. At that point, a computation that occasionally allocates, triggers garbage collection, materialises an unexpected temporary, or changes its memory-access pattern can violate the timing contract even if its average benchmark is excellent.
\nThe C++ model allows the real-time boundary to be made explicit:
\nclass Controller {
public:
explicit Controller(std::span<double> workspace)
: workspace_(workspace)
{}
void update(
std::span<const double> q,
std::span<const double> dq,
std::span<double> tau)
{
compute_dynamics(q, dq, tau);
}
private:
std::span<double> workspace_;
void compute_dynamics(
std::span<const double> q,
std::span<const double> dq,
std::span<double> tau)
{
for (std::size_t i = 0; i < tau.size(); ++i) {
tau[i] = q[i] + dq[i];
}
}
};
The controller owns no dynamic memory. The workspace is supplied from outside the control loop.
\nFor a kinematic or dynamic kernel, spatial quantities can similarly be represented using fixed-size types:
\nstruct SpatialVector {
double data[6];
};
struct SpatialInertia {
double data[36];
};
inline SpatialVector cross_motion(
const SpatialVector& a,
const SpatialVector& b)
{
SpatialVector result{};
// Fixed-size spatial operation.
return result;
}
The dimensions are part of the type. There is no dynamic matrix dimension to discover at runtime.
\nThis matters for the recursive Newton-Euler algorithm because the computational graph is sparse and highly structured. Spatial inertia, velocity and acceleration operations have fixed dimensions, predictable access patterns, and well-defined lifetimes.
\nThe implementation can therefore be tuned against a particular micro-architecture without changing the mathematical interface.
\nMATLAB's Robotics System Toolbox and Simulink Coder can emit C or C++ code. That is useful, but it does not eliminate the distinction between specifying an algorithm and generating one from a higher-level description. The generated artefacts inherit decisions made by the code generator concerning temporaries, layout, scheduling and numerical evaluation order.
\nThe generated binary must consequently be re-validated whenever the toolchain or generated implementation changes.
\nThe identical issue appears in model-predictive control, geometric collision detection, rigid-body dynamics, state estimation and numerical integration. In each case, the relevant properties are not simply \"fast\" or \"slow\". They are:
\nThe construction of a numerical kernel therefore proceeds from the algebraic law that licenses a transformation, through the concrete data layout and accumulation order that realise it, to the forward-error bound and the memory-hierarchy cost model that quantify the result.
\nAssociativity licenses tree reductions and multi-accumulator schemes.
\nDistributivity licenses transformations such as Horner's rule:
\na0+a1x+a2x2+⋯+anxn=a0+x(a1+x(a2+⋯+xan)).\nCache geometry licenses cache-aware blocking.
\nContiguity and alignment license efficient packed loads.
\nStatic extents license compile-time reasoning about dimensions.
\nConcepts and traits allow these requirements to become part of the interface rather than informal assumptions.
\nEach decision can remain under source control and can be regression-tested against both numerical residuals and performance counters.
\nThis is the distinction that matters when comparing numerical environments.
\nPython is excellent at orchestration and interactive numerical experimentation. NumPy and SciPy provide mature native kernels, and Python can express complex scientific workflows with very little code.
\nJulia goes further by making specialization and compilation central to the language. Multiple dispatch, broadcast fusion and generated specialization allow a substantial amount of numerical structure to remain visible at the language level while still reaching native performance.
\nC++ goes further in a different direction.
\nIt permits the programmer to decide exactly where the abstraction boundary lies.
\nThe programmer can write the high-level algorithm:
\ntemplate<class Matrix>
requires requires(const Matrix& A) {
A.extent(0);
A.extent(1);
A(0, 0);
}
double trace(const Matrix& A)
{
double result = 0.0;
const auto n =
std::min(A.extent(0), A.extent(1));
for (std::size_t i = 0; i < n; ++i) {
result += A(i, i);
}
return result;
}
and still specialize the representation, allocation strategy, vectorisation strategy, blocking policy and numerical accumulation scheme underneath it.
\nThat combination is what makes modern C++ particularly powerful for high-performance numerical computing.
\nThe goal is not to write everything by hand.
\nThe goal is to make the parts that matter explicit and let the compiler eliminate everything else.
\nWhen a language conceals the parenthesisation, the layout, the temporary policy and the binding to the underlying BLAS, those decisions cannot be recorded directly in the program text. The performance claim cannot be attached cleanly to a stated algorithm, and the error bound cannot be attached cleanly to a stated accumulation depth or working-set size.
\nFor interactive exploration, MATLAB remains convenient. For conventional numerical workflows, Python and Julia are both powerful alternatives, each with a different set of trade-offs.
\nBut for workloads in which the algorithm, representation, numerical semantics and temporal behaviour must all be treated as part of the specification, modern C++ provides something fundamentally different: the ability to expose the abstraction boundary itself and decide, one layer at a time, which properties belong to the mathematics, which belong to the type system, which belong to the compiler, and which belong to the machine.
\nThat is the point. MATLAB supplies neither the algorithm nor the guarantees.
", "url": "https://hanielulises.github.io/high-performance-cpp/essays/matlab-no-longer", "title": "MATLAB No Longer Has a Place in the Modern World", "summary": "High-performance numerical kernels are defined by the algebraic laws they exploit and by the architectural parameters they expose. Associativity of addition, distributivity of multiplication over addition, cache-line geometry, SIMD vector width, TLB reach, and the precise cost of data motion through the memory hierarchy jointly determine both attainable accuracy and attainable throughput.", "date_modified": "2026-08-11T00:00:00.000Z", "author": { "name": "High Performance C++" }, "tags": [ "numerical-analysis", "scientific-computing", "performance", "semantics", "robotics" ] }, { "id": "https://hanielulises.github.io/high-performance-cpp/essays/what-a-concept-does-not-say", "content_html": "A concept named Ring is satisfied by any type with +, *, and the two identities. It is not\nsatisfied only by rings. The distinction is not pedantry: the algorithms constrained by such a\nconcept are correct on the rings and undefined on everything else in its model class, and the\ncompiler cannot tell the difference.
A concept denotes a set of types; the ones for which its requirements are well-formed. The\nmathematical structure it is named after denotes a smaller set: those types whose operations\nadditionally satisfy laws. The language checks membership in the larger set and the algorithm\nrequires membership in the smaller one.
\nNothing about this is unusual or avoidable. Checking associativity would require quantifying over\nall values of a type, which the language cannot do and no reasonable extension would. The gap is\nstructural.
\nWhat is avoidable is leaving it undocumented, which is the normal state of affairs.
\nThree failures, all ordinary.
\nstd::sort requires a strict weak ordering, and a comparison over floating-point values\ncontaining NaN is not one: NaN compares false against everything, so the induced equivalence is\nnot transitive. The consequence is not a mis-sorted range. Common implementations use the\nordering to bound an inner scan, and an invalid comparison walks past the end of the range. A\nsemantic violation produces a memory error.
std::unordered_map requires a hash consistent with equality. Supply one that is not, and\nlookups fail to find elements that are present, silently, with no invariant visibly broken.
A parallel reduction over a type modelling Monoid returns a value depending on the thread\ncount, because the type's addition is not associative. Every individual component is correct.
In each case, the type satisfies the concept, the code compiles, and the defect lives in the gap.
\nThe treatment used in this reference is unremarkable and effective: the concept states the\nsyntax, and the semantic obligations are enumerated beside it with numbers.
\n// Semantic requirements (unchecked by the compiler):
// S1. op is associative on T.
// S2. identity is a two-sided identity for op.
// S3. op is a pure function of its arguments.
template <class T, class Op>
concept Monoid = /* syntax only */;
The numbering earns its place immediately. An algorithm can then say which obligations it uses (\"requires Monoid<T, Op> including S1\") which distinguishes the algorithms that reassociate\nfrom those that do not, and tells a user supplying a non-associative operation exactly which\nroutines are safe.
The obligations also become testable. A property test over a generator of representative values\ndischarges S1 probabilistically, and for double under addition it fails, correctly, which is\nthe specification: the type does not satisfy S1, and the algorithms depending on it compute an\napproximation whose bound is stated elsewhere.
Once the gap is written down, a question becomes askable that is otherwise invisible: should this\nobligation be an obligation at all, or should it be an invariant?
\nSome can be moved into the type. A normalised rational maintains gcd(p, q) == 1 on\nconstruction, so the obligation disappears. A matrix type constructed only from a Cholesky\nfactorization is positive definite by provenance. A sorted-range wrapper that permits no\nunsorted construction removes the precondition from every algorithm consuming it.
Others can be moved into a check. Symmetry of an operator is not verifiable in general but is\nverifiable probabilistically (⟨Ax,y⟩≈⟨x,Ay⟩ for a few\nrandom vectors) at the cost of a few applications, which is negligible against the iterations\nthat follow.
\nThe remainder stay as obligations, and the point of enumerating them is that the remainder is now\na short, explicit list rather than an unbounded body of assumptions distributed across the\nimplementation.
\nConcepts are usually discussed for what they added: better diagnostics, overload ordering,\nconstrained interfaces. Those are real and were worth the wait.
\nThe more useful effect is that they made the boundary visible. Before C++20, requirements were\nimplicit and the distinction between the syntactic and semantic parts of an interface was not\nexpressible at all. Now the syntactic part is in the language, which throws the semantic part\ninto relief, and the semantic part is where the defects in generic numerical code actually live.
", "url": "https://hanielulises.github.io/high-performance-cpp/essays/what-a-concept-does-not-say", "title": "What a Concept Does Not Say", "summary": "A concept named Ring is satisfied by any type with +, *, and the two identities. It is not", "date_modified": "2026-06-19T00:00:00.000Z", "author": { "name": "High Performance C++" }, "tags": [ "concepts", "semantics", "interface-design" ] }, { "id": "https://hanielulises.github.io/high-performance-cpp/essays/writing-the-reassociation", "content_html": "Almost every fast reduction in existence is licensed by a property that floating-point addition\ndoes not have. The situation is stable, well understood, and routinely misdescribed (as a\ncompiler flag, as a precision setting, as a tolerance question) when it is none of those. It is\na question about which algorithm is being executed.
\n\nA sum of n terms evaluated left to right has one parenthesisation. A sum evaluated with four\naccumulators, or eight vector lanes, or sixteen threads, has a different one. If addition were\nassociative these would agree. It is not, and they do not.
\nThe differences are not pathological. For terms of like sign they are bounded by γn−1∑∣xi∣ against γn/k+k∑∣xi∣, and the reassociated form is more accurate\nthan the sequential one: the split reduces the depth of the accumulation, and error grows with\ndepth. For terms of mixed sign with cancellation, both are unbounded relative to the true sum,\nand which is closer is not predictable.
\nSo the reassociated reduction is faster, usually more accurate, and returns a different value.\nAll three are true simultaneously, and each is sometimes reported alone as though it settled the\nmatter.
\nThe usual framing is: enable fast-math and the compiler will vectorize your reductions. This\ngets the structure exactly backwards.
\n-ffast-math grants a global permission to reassociate, to assume no NaN or infinity, to\ncontract multiplications and additions, and to treat denormals as zero. It applies to every\nfloating-point operation in the translation unit, including the ones that are correct only under\nstrict semantics: the error-free transformations in a compensated summation, for instance,\nwhich the flag deletes entirely because (a - (s - b)) + (b - b') is algebraically zero and is\nnot numerically zero, and the flag says to believe the algebra.
The result is a program whose numerical behaviour is determined by an option, in which the\nreductions that should be reassociated and the ones that must not be are treated identically, and\nin which the change is invisible at every point where it applies.
\nWrite the reassociation.
\ndouble a0 = 0.0, a1 = 0.0, a2 = 0.0, a3 = 0.0;
for (std::size_t i = 0; i + 4 <= n; i += 4) {
a0 += x[i + 0]; a1 += x[i + 1]; a2 += x[i + 2]; a3 += x[i + 3];
}
This is a different algorithm from the sequential sum, and it says so. It compiles to the fast\nform under strict semantics, because no permission is needed for a transformation the source\nalready performed. It has a stated error bound, which the flag-based version also has but which\nnobody computes because the transformation was not visible. And the compensated summation\nelsewhere in the same translation unit continues to work.
\nThe cost is that the unrolling factor is in the source, and the right factor depends on the\ntarget's arithmetic latency and throughput. That is a real cost. It is also a decision that\nsomeone has to make, and making it explicitly is better than deferring it to a heuristic that has\nno error analysis attached.
\nThis is an instance of a pattern that recurs throughout the material in this reference. A\nmathematical structure licenses an algorithmic transformation; the C++ type approximates the\nstructure; the transformation is applied anyway; the gap is a bounded error rather than a\ncorrectness failure.
\nAssociativity licenses tree reductions. Commutativity licenses unordered accumulation. An\nidentity licenses empty subranges. Distributivity licenses Horner's rule and strength reduction.\nEvery one of these is exact over the mathematical structure and approximate over the\nfloating-point type that models it.
\nThe discipline that follows is to state which law each transformation uses, and to carry the\nerror bound alongside the performance claim. A reduction that is eight times faster and produces\na different answer is a good trade in almost every case; it is a trade, and it should be recorded\nas one.
", "url": "https://hanielulises.github.io/high-performance-cpp/essays/writing-the-reassociation", "title": "Writing the Reassociation", "summary": "Almost every fast reduction in existence is licensed by a property that floating-point addition", "date_modified": "2026-04-03T00:00:00.000Z", "author": { "name": "High Performance C++" }, "tags": [ "numerical-analysis", "vectorization", "semantics" ] }, { "id": "https://hanielulises.github.io/high-performance-cpp/essays/checking-the-cost-of-an-abstraction", "content_html": "The phrase \"zero-overhead abstraction\" is used as though it described a property that C++\nabstractions possess. It describes a property that particular abstractions possess under\nparticular conditions, and the conditions are checkable. Treating the phrase as a guarantee is\nhow libraries acquire abstractions that cost twenty percent and nobody notices.
\n\nAn abstraction is free when the code generated for a concrete use is what a competent\nhand-written monomorphic version would be. That is a statement about generated instructions, and\nit is decided by reading them, not by reasoning about the language's design philosophy.
\nThree conditions have to hold. The parameterisation must be resolved during translation, so that\nno indirect call remains. The representation must be unchanged, so that no additional data\nmovement is introduced. And the abstraction must not obstruct an optimisation the concrete\nversion would have received, which is the condition that fails most often and most quietly.
\nThe first two are easy to check and are usually satisfied. static_assert(sizeof(W) == sizeof(T)) settles the second; the absence of a virtual function settles the first.
The third fails in ways that have nothing to do with the abstraction's design.
\nA wrapper type with a user-provided copy constructor is no longer trivially copyable, so an array\nof it can no longer be relocated with a memcpy, so vector growth becomes a loop of constructor\ncalls. The wrapper is still the same size. It still has no virtual functions. It costs a factor\nof several on any code that grows containers of it.
A range adaptor pipeline three deep inlines and vectorizes; the same pipeline six deep exceeds\nan inlining budget, and every element access becomes a call. Nothing about the source changed\nexcept its length.
\nA generic kernel taking two std::span parameters cannot be vectorized without a runtime overlap\ncheck, because the compiler cannot prove the spans are disjoint. The concrete version, written\nwith two local arrays, has no such problem. The abstraction did not add instructions; it removed\ninformation.
In each case, the abstraction is free by the first two criteria and expensive in fact.
\nThis suggests treating the claim the way any other performance claim is treated: as something to\nbe established for a specific abstraction in a specific use, and re-established when either\nchanges.
\nThe mechanics are unremarkable. Compile the abstract and concrete versions of a kernel and\ncompare the generated code. Keep the comparison in the build, so that a compiler upgrade or an\ninnocuous refactor that breaks it is caught when it happens rather than during the next\nperformance investigation. Assert the representational properties (size, triviality, alignment)\nnext to the type, since they are part of its interface for the code that depends on them.
\nWhat makes this worth doing is not that abstractions are usually expensive. They are usually\nfree. It is that the cases where they are not are invisible in the source, and the cost is\nattributed to something else (to the algorithm, to the machine, to the compiler) for a long\ntime before anyone looks.
\nThere is a stronger claim available, and it is the one worth making. A well-chosen abstraction is\nnot merely free; it is faster than the concrete code it replaces, because it makes a better\nimplementation feasible.
\nAn algorithm written against a concept can dispatch to a specialised path when the argument\nsupports one. A kernel taking mdspan with a layout policy can be blocked once and used for\nevery storage order. An expression template can fuse three traversals into one, removing memory\ntraffic that the concrete version has no way to avoid without being rewritten.
This is the case for abstraction in performance-oriented code, and it is a stronger case than the\ndefensive one. It also has the same evidentiary requirement: the generated code, or the\nmeasurement, or neither claim is made.
", "url": "https://hanielulises.github.io/high-performance-cpp/essays/checking-the-cost-of-an-abstraction", "title": "Checking the Cost of an Abstraction", "summary": "The phrase \"zero-overhead abstraction\" is used as though it described a property that C++", "date_modified": "2026-02-14T00:00:00.000Z", "author": { "name": "High Performance C++" }, "tags": [ "generic-programming", "performance", "method" ] } ] }