OA foundation benchmark

Independent foundation, competitive on its real workloads

OA's foundation is an original implementation designed around OA's admitted product workloads. It was written from scratch; it is not an STL source port, compatibility layer, or renamed wrapper surface. The result is not a small synthetic win hidden behind one score: 27 of 32 recorded foundation cases are at parity or ahead on this host, while the remaining overheads stay visible below.

This is fixed-host engineering evidence, not a universal performance claim. OA still uses explicit OS, compiler, C-runtime, and Vulkan adapters where they are the correct boundary. The separate linked-binary and full platform-independence matrix remains qualification work.

Foundation, not oa::std

Std is the short navigation label, not a namespace. The public vocabulary lives directly under oa: oa::Vector, oa::String, oa::Result, oa::HashMap, and oa::SharedPtr. The former pre-1.0 oa::Vec spelling has been removed.

Measured protocol

Every ratio is OA latency divided by its equivalent host operation. Below 1.0 favors OA. A complete process range crossing 1.0 is treated as parity, even when the median falls on one side.

Foundation results

The full result is split by behavior so the table remains readable without collapsing the campaign into an average. First are runtime calls, bounded values, text views, and algorithms.

The checked clock and mutex ABI boundaries retain measurable call overhead. Sort is at parity; find/count is a stable win. These results keep checks and failure semantics enabled.

Sequences, text, variants, and callables

Vector bulk append is the intended high-throughput path and is at parity. The reserved single-element loop exposes an optimizer control-flow gap rather than hiding it behind the bulk result. String wins in both reserved-push and geometric-growth workloads.

Lookup and ownership

The hash tables are the largest general-foundation win. Shared ownership needs one explicit qualification: on this glibc/libstdc++ host, copy/release avoids atomic reference-count work until a thread has existed. OA keeps thread-safe counts in both process states. Once the host uses its thread-safe path, OA make/release and copy/release are at parity.

Brace formatting and record output

oa::format, oa::print, and oa::write use a bounded, literal brace-format syntax familiar from Python and {fmt}. This is OA's deliberately smaller dialect, not a source port or a claim of complete std::format or {fmt}compatibility. The benchmark compares identical formatted output with the toolchain's std::format.

1#include <oa/core/std/print.h>
2
3const oa::String message = oa::format("epoch={} loss={:.4f}", epoch, loss);
4OA_RETURN_IF_ERROR(oa::print("epoch={} loss={:.4f}", epoch, loss));
5OA_RETURN_IF_ERROR(oa::print(oa::PrintStream::Error, "failed: {}", reason));
6OA_RETURN_IF_ERROR(oa::write("\rprogress={:.1f}%", percent));
7OA_RETURN_IF_ERROR(oa::flush());
8

Each row is the median paired OA/standard-library latency ratio across seven fresh processes. Integer formatting used 58.9% of host time, padded hexadecimal plus boolean used 66.8%, and fixed-precision floating point used 91.3%. The mixed record's 1.003× median crosses parity over its complete 0.975–1.011× range, so it is recorded as parity, not a regression.

The accepted optimization keeps those checks intact: fixed literal syntax can fold at the call site, records through 128 bytes use bounded inline staging, and floating conversion writes directly into checked caller storage. No unchecked formatter, precision change, locale mutation, or hosted C++ dependency was added to obtain the result.

Host memory is now part of the foundation

The old raw-assembly memory path was removed. OA now uses legal exact-bounds compiler copies for dynamic blocks through 256 B, tuned platform operations where they remain best, and a separate oa::memcpyStream policy only when the destination will not be consumed soon. That separation keeps ordinary copy behavior predictable while admitting cache-aware wins for one-way uploads.

Dynamic copy with reusable buffers

Fixed compile-time OA and compiler-copy rows reduce to the same instructions. The dynamic dispatcher is retained for the stable 8 B and 32 B gains; large ordinary copies continue through libc and return to parity.

Cache-cold one-way streaming

The sweep rotates chunks through separate 256 MiB source and destination arenas—32 times the host's 8 MiB last-level cache. Each ratio cell includes the median followed by the complete seven-process range; throughput columns are absolute medians.

The qualified x86 non-temporal window runs from 1 KiB through 4 MiB. Nine rows in that window are stable wins; 2 KiB is best at 0.653×. From 64 KiB through 4 MiB, streaming uses 79.2–83.9% of libc time except the 256 KiB row at 86.1%. The 4 KiB range crosses parity and is classified as flat. Below and above the window, fallback restores parity.

Equality, ordering, and overlap

Each cell reports the median OA / libc ratio followed by its complete process range.

memcmp and both overlapping memmove directions measured at a1.000×median at all four representative sizes. Constant-work equality has a stricter security contract than libc's early-exit comparison, so its result is not presented as a semantic speedup. Platform fill and zero also remain faster than the rejected hand-vectorized paths.

Measured decisions, including the rejected ones

Correctness before timing

Evidence boundary

This checkpoint qualifies one compiler, host library, machine, workload, and date. It does not establish cross-platform superiority, complete hostile-input resilience, or linked-binary independence from libstdc++ or libc++. YAML, VMA, private third-party link closure, no-exception/no-RTTI builds, longer fuzzing, allocator-fault campaigns, and the full compiler and platform matrix retain their own qualification gates.

Reproduce

Use a fixed power policy and record thermal conditions. Release comparison requires immutable commits, rotating or alternating samples, median and spread, and passing correctness gates. A single process is useful for profiling, not release evidence.

cmake --build build/release --target BenchStd TestOaStd -j
ctest --test-dir build/release -R '^TestOaStd$' --output-on-failure
taskset -c 2 ./bin/release/test/core/std/benchStd \
  --items 32768 --warmups 5 --samples 21

# Formatting evidence was recorded separately on CPU 3.
taskset -c 3 ./bin/release/test/core/std/benchStd \
  --items 32768 --warmups 5 --samples 21

cmake --build build/release --target BenchMemory TestMemory -j
taskset -c 2 ./bin/release/test/core/memory/benchMemory --quick --copy
taskset -c 2 ./bin/release/test/core/memory/benchMemory --quick --primitives
taskset -c 2 ./bin/release/test/core/memory/benchMemory --streaming

# Run each campaign as at least seven fresh processes.