Performance: CPU

The compiler is measured on twenty programs, each written four times: in the xc language, in Objective-C with ARC, in C++ and in Swift, doing the same work with the same algorithm and the same data. All are built with optimisation (-O3 for xc, Objective-C and C++, -O for Swift), every version prints a checksum, and a run only counts if all four checksums agree. Every program, in all four languages, is on the benchmark sources page; each benchmark’s name below links to its own. On x86-64 the C++ source is built twice, with clang and with GCC (g++ -O3), on both targets, so each carries a column for each C++ compiler.

Each figure is measured with the released 0.86 xcc on two machines:

arm64: an Apple MacBook Pro with an M4 Max (12 performance and 4 efficiency cores), macOS; Apple clang 17.0.0, GCC 16.2.0 and Swift 6.2;
x86-64: an AMD Ryzen 9 9955HX (16 cores, 32 threads), Linux; GCC 15.2.0, clang 21.1.8 and Swift 6.1.3; its CPU frequency governor is performance (amd-pstate-epp) for the run.

Every compiler is given the machine’s full instruction set: -march=native (x86-64) or -mcpu=native (arm64) for clang and GCC, -target-cpu native for Swift. xc needs no flag for that: with its default -msimd=auto, xcc builds each vectorised function for SSE2, AVX2 and AVX-512 and the program picks one when it starts. Nothing else is set: no link-time optimisation, no profile-guided build, no -ffast-math, on any side.

Times are seconds for the timed region, the best of five runs, each run waiting until the machine is otherwise idle.

Summary

How much faster xc’s code runs than each language’s, as the geometric mean over nineteen of the twenty benchmarks:

xc compared with	arm64 (Apple M4 Max)	x86-64 (AMD Ryzen 9 9955HX)
Objective-C	1.38× faster	1.20× faster
C++ (clang)	1.07× faster	1.08× slower
C++ (GCC)	1.15× faster	1.08× faster
Swift	1.37× faster	1.37× faster

On arm64 xc is ahead of all of them. On x86-64 xc is ahead of Objective-C, C++ (GCC) and Swift and behind C++ (clang).

The twentieth benchmark, matrix_mul_f32, is kept out of those means. xcc recognises its loop nest and replaces it with a matrix kernel of its own, which makes xc tens to hundreds of times faster at that one operation; counted in, it would dominate means that stand for ordinary code, and most programs do not multiply matrices. Its figures are under Matrix multiplies.

Per benchmark

Each row is a benchmark, each dot one language: how much faster or slower xc is than that language. Dots left of the centre line are benchmarks xc wins. Choose a release above a chart to see how it stood then; the rows stay in 0.86’s order. Releases before 0.65 were measured against Objective-C alone, apart from matrix_mul_f32, which was added later and measured against all three.

arm64

benchmark	xc	Objective-C	C++ (clang)	C++ (GCC)	Swift	xc vs the fastest of the others
`method_call`	0.88	2.31	1.10	0.18	1.07	4.9× slower
`int_muldiv`	1.18	0.95	0.95	0.78	0.95	1.52× slower
`float_math`	0.97	0.81	0.81	0.88	0.81	1.20× slower
`sort_small`	1.06	0.96	0.99	1.00	1.28	1.11× slower
`poly_dispatch`	0.55	1.13	0.56	0.49	2.04	1.10× slower
`struct_copy`	0.71	0.99	1.00	0.66	1.01	1.09× slower
`arc_array`	0.55	5.25	0.51	0.74	0.88	1.07× slower
`array_map`	1.17	1.47	1.10	4.59	1.11	1.06× slower
`mem_copy`	0.94	1.56	0.90	1.70	0.91	1.06× slower
`arc_alloc`	1.01	1.46	0.98	1.02	2.21	1.03× slower
`matrix_mul`	0.23	0.22	0.23	0.42	1.12	1.02× slower
`int_accum`	1.11	1.10	1.11	1.15	1.11	1.01× slower
`branch_mix`	1.00	1.00	1.00	1.02	1.02	the same
`hash_mix`	1.14	1.14	1.14	1.14	1.14	the same
`bit_ops`	1.18	1.18	1.18	1.19	1.18	the same
`call_depth`	0.96	0.99	1.00	1.10	1.00	1.03× faster
`array_sum`	0.83	0.90	0.90	3.20	0.90	1.08× faster
`sieve`	1.09	1.47	1.48	1.29	1.99	1.18× faster
`string_scan`	0.96	2.36	2.39	1.39	2.36	1.45× faster
`matrix_mul_f32`	0.03	9.67	9.68	9.68	9.58	349× faster

x86-64

benchmark	xc	Objective-C	C++ (clang)	C++ (GCC)	Swift	xc vs the fastest of the others
`int_muldiv`	0.50	0.34	0.34	0.17	0.34	2.9× slower
`arc_array`	1.13	3.72	0.77	0.63	0.56	2.0× slower
`sieve`	1.02	0.75	0.74	0.82	1.16	1.37× slower
`struct_copy`	0.86	0.87	0.87	0.65	0.87	1.32× slower
`sort_small`	0.92	0.72	0.72	0.82	1.11	1.29× slower
`call_depth`	0.24	0.19	0.19	0.24	0.19	1.28× slower
`array_map`	0.32	0.52	0.27	2.02	0.51	1.22× slower
`matrix_mul`	0.09	0.13	0.08	0.08	1.88	1.19× slower
`float_math`	0.74	0.74	0.73	0.67	0.73	1.10× slower
`poly_dispatch`	0.97	1.23	0.93	0.93	6.67	1.04× slower
`mem_copy`	0.35	0.34	0.34	0.38	0.54	the same
`bit_ops`	0.97	0.97	0.97	0.97	0.97	the same
`branch_mix`	0.81	0.81	0.81	0.81	0.81	the same
`int_accum`	0.97	0.97	0.97	0.97	0.97	the same
`hash_mix`	1.01	1.01	1.01	1.01	1.01	the same
`arc_alloc`	0.40	2.21	0.44	0.44	0.74	1.09× faster
`array_sum`	0.20	0.22	0.22	0.71	0.22	1.10× faster
`string_scan`	0.47	0.54	0.55	0.84	0.54	1.16× faster
`method_call`	1.31	1.90	1.58	1.59	1.81	1.21× faster
`matrix_mul_f32`	0.23	8.36	8.28	0.84	8.01	3.7× faster

The fastest results are where the runtime does the work: string_scan, method_call and struct_copy are byte scanning, dynamic dispatch and aggregate copies. The slowest show where xcc’s code generation has most to gain:

Vectorisation. On arm64, int_muldiv and float_math are vectorised by both compilers, and clang’s loops are tighter; matrix_mul has matched clang there since 0.73. On x86-64 matrix_mul is still behind, because clang keeps the second matrix’s rows in registers across the outer loop.
Reference counting on x86-64. arc_array, where C++ reads elements without retaining them.
x86-64 loops and calls. sieve and sort_small, where clang’s loops are still tighter (in 0.74 sort_small was 2.6× behind; 0.75 rotates its inner loop), call_depth, where clang’s call sequence is shorter, and int_muldiv, where GCC hoists the arithmetic that does not depend on the repetition out of it.

Matrix multiplies

A dense matrix multiply written as three plain loops, C[i][j] the sum over k of A[i][k] · B[k][j] in float or double, runs as a kernel the compiler writes itself (from 0.71). The results are the loops’, to the last bit, and -fno-matmul turns it off. The kernel depends on the machine:

Apple M4 and later (SME): the multiply runs on the matrix unit. From 0.72 it works on a 2×2 block of the unit’s tiles at once, and under :goal(speed), which matrix_mul_f32 uses, it leaves out a NaN check that only affects the bits of a NaN (the inputs have none).
x86-64: the widest vector unit the processor has (SSE2, AVX2 or AVX-512), chosen when the program starts; the Ryzen 9 9955HX picks AVX-512.

matrix_mul_f32 measures it: a 128×128 float multiply, 10,000 times. (matrix_mul multiplies u32 values, which the matrix unit does not take, so it stays a vectorised loop.)

`matrix_mul_f32`	xc	Objective-C	C++ (clang)	C++ (GCC)	Swift
arm64, Apple M4 Max	27 ms	9.7 s	9.7 s	9.7 s	9.6 s
xc is		352× faster	352× faster	352× faster	349× faster
x86-64, AMD Ryzen 9 9955HX	229 ms	8.4 s	8.3 s	837 ms	8.0 s
xc is		36× faster	36× faster	3.7× faster	35× faster

The GPU and the network

par blocks, which run on every CPU thread, on GPUs and across machines, have pages of their own: Performance: GPU (including plain loops made parallel by --par-auto) and Performance: networked.

Release to release

How fast xc’s code is in each release, relative to 0.62: above 1× is faster. The thin lines are single benchmarks (labelled where they moved by more than twelve percent), the thick line the geometric mean (without matrix_mul_f32). Releases shown: 0.62, 0.63, 0.64, 0.65, 0.66, 0.7, 0.71, 0.72, 0.73, 0.74, 0.75, 0.8, 0.85, 0.86. arc_alloc, method_call changed in 0.64’s benchmark set and are left out of this history.

arm64: xc's speed relative to 0.62

x86-64: xc's speed relative to 0.62

What is being compared, and what is not

The compiler that ships. The xc numbers come from the xcc in the download.

The same work in every language. Every version keeps its data where the xc version keeps it (local arrays, not static ones, which clang optimises differently) and leaves nothing a compiler can remove: an object that could be put on the stack outlives its iteration, a call whose target could be resolved at compile time takes its class at run time, and results are folded in so no loop has a closed form. Where the original’s point is reference-counted objects, the C++ version uses std::shared_ptr and the Swift version a class, so they pay for reference counting too.

Different runtimes on the two targets. The Objective-C column is Apple’s Foundation on arm64 and GNUstep with libobjc2 on x86-64, and Swift is 6.2 on the Mac and 6.1 on Linux. These are different implementations, so a language’s times compare within a target and not across one. Swift on Linux is markedly slower on poly_dispatch and array_map than on the Mac; the runs were repeated on an idle machine and reproduce.

Timed regions of about one second. Each benchmark times its own inner loop rather than the process, so start-up and data set-up are excluded.

Alignment noise on x86-64. xcc aligns every loop head on x86-64 to a 32-byte boundary and the start of .text to 64 bytes, so an unrelated change elsewhere cannot move a loop across a fetch boundary; see Optimisation.

Reproducing

The sources are in benchmark/src, one .xc, .m, .cpp and .swift per program, and the runner builds and times them all:

python3 benchmark/run.py --opt O3 --repeats 5
python3 benchmark/page.py

The x86-64 legs cross-build xc here and build the other languages on the configured Linux host; without one the runner measures this machine only. --langs measures some of the languages and adds them to the results already there. Results land in benchmark/<version>/results.json, and page.py turns them into this page.