TinyComputers.io (Posts about aes-ni)

The Pine64 Star64: RISC-V's Baseline Problem

A.C. Jokela — Thu, 10 Sep 2026 14:15:00 GMT

The Pine64 Star64 is the third RISC-V board to go through my benchmark fleet, and it makes a better showing than the one everybody would expect it to beat. That is a lower bar than it sounds.

It is built on StarFive's JH7110: four SiFive U74-MC cores at 1.5 GHz, 4 GB of RAM, and an ISA string that turns out to be the entire story. That string is rv64imafdc. Plain RV64GC. No vector extension, no scalar crypto extension, no bit-manipulation extensions, and an isa-ext field that is simply empty. This is the RISC-V baseline profile and nothing above it.

For compiling Rust that hardly matters. A compiler is integer and branch work, and baseline RV64GC does integer and branch work perfectly well. The Star64 posts 461.28 seconds on my fleet-comparable tree, tenth of eleven. For cryptography it matters enormously. The same board manages 21.7 MB/s of AES-128-GCM, roughly one hundredth of what a Cortex-A76 does on the identical benchmark.

That hundredfold gap is the most interesting number this fleet has produced, and it decomposes into two very different things. Unpacking it says something precise about where RISC-V actually stands in 2026, and the answer is not "the cores are bad."

The Hardware

The 4 GB variant: the sticker on the USB stack matches the 3.8 GiB the OS reports. The JH7110 sits under the metal lid at center; the PCIe slot along the top edge and the 40-pin header are the expansion this board leans on, since its microSD is stuck in high-speed mode.

Component	Specification
SoC	StarFive JH7110
CPU	4 × SiFive U74-MC, dual-issue in-order, 1.5 GHz
ISA	`rv64imafdc`: RV64GC baseline; no V, no K, no Z*
RAM	4 GB (3.8 GiB usable), 32-bit LPDDR4
Storage	SanDisk SN64G microSD, 59.5 GB, ext4
GPU	Imagination BXE-4-32, DRM nodes present
Video	JH7110 VPU, `/dev/video0`–`7`
Network	2 × gigabit (`st_gmac`)
OS	PinIx 2.1, kernel 5.15.131 (vendor BSP, Sept 2023)
Toolchain	rustc / cargo 1.98.1, `riscv64gc-unknown-linux-gnu`

Three practical notes for anyone setting one of these up, each of which cost me time. Root's home directory is /home/root, not /root. My first toolchain install failed outright because I assumed otherwise. The login shell is /bin/sh, so anything wanting bash has to say so explicitly. And the board ships with no Rust toolchain at all; rustup's riscv64gc-unknown-linux-gnu target installs cleanly, which is itself a quiet sign of how far RISC-V tooling has come.

The Benchmark, and Why It Has Two Numbers

My standard workload is a clean release build of ballistics-engine, three runs after cargo clean. As I wrote in the NanoPC-T6N review, that project outgrew its own benchmark. The tree the October 2025 fleet compiled was 16,639 lines, and today's main is 155,867. Numbers from the two are not the same measurement.

So every run now comes in two tiers:

Pinned: 2821bba, verified on the board at 43 .rs files / 16,639 LOC / 144 crates. Byte-for-byte the tree the archived fleet was measured against. Every fleet comparison below uses this.
HEAD: b0cfcd4, 196 files / 155,867 LOC / 243 crates. Deliberately the same commit the FreeBSD MacBook ran a couple of weeks ago, so those two HEAD figures are directly comparable to each other rather than being another orphan.

Before the HEAD tier I added an 8 GB swapfile, reasoning that 243 crates at -j4 might blow past 3.8 GB of RAM. It was never touched: zero swap use across all 2,455 samples of the run. A sensible precaution that turned out to be unnecessary, which I would rather say plainly than let you assume it rescued something.

Compilation Results

Pinned tier (2821bba):

Run	Time
1	458.17 s
2	463.08 s
3	462.59 s
Mean	461.28 s (median 462.59, σ 2.71, 0.59% CV)

HEAD tier (b0cfcd4):

Run	Time
1	2933.59 s
2	2927.88 s
3	2934.15 s
Mean	2931.88 s, 48.9 minutes (σ 3.47, 0.12% CV)

A 0.12% coefficient of variation across three 49-minute builds is the most consistent result on my bench, and the instrumentation says exactly why: nothing varied. Across 2,455 samples spanning 3.4 hours, all four cores held 1.5 GHz for 100% of under-load samples, temperature stayed between 56.9 and 70.0 °C, and swap was never touched. No thermal ceiling, no memory pressure, no clock wobble.

Left: the fleet on the pinned September-2025 tree, the only apples-to-apples axis I have. Right: the same board and toolchain against both sizes of the same project, 6.36x the build time for 9.37x the code.

The HEAD/pinned ratio of 6.36× compares against the MacBook's 5.45× on the identical commit. With clock and memory both ruled out as causes, that difference is architectural rather than environmental: the bigger tree leans harder on whatever the U74 is worse at.

Two Comparisons That Matter

Against the other RISC-V design, the Star64 wins convincingly. It beats the Orange Pi RV2 by 1.41× while carrying half the cores (four U74s against eight Ky X1s), which works out to 2.82× better per core-second. The RV2's cores bring RVV 1.0 vector units that a Rust compile never touches, while their scalar integer throughput lags well behind SiFive's. For general-purpose work, four decent cores beat eight weak ones, and it is not close.

Against ARM, it loses to a design from 2012. The quad Cortex-A53 in the Horizon X3 CM, a board I reviewed as a cautionary tale running a core Arm announced fourteen years ago, still finishes 1.22× faster. That is the honest framing of where this silicon sits on ordinary work: current-generation RISC-V application cores trailing decade-old budget ARM.

Against a Raspberry Pi 5, the Star64 is 6.02× slower. Hold onto that number; it comes back.

The Same-Silicon Control

The Milk-V Mars runs the same JH7110 SoC as the Star64 (same four U74 cores, same 1.5 GHz, same rv64imafdc) with twice the RAM. That makes it the best control I have ever had for one of these reviews, so I re-ran it.

I need to be upfront about why a re-run was necessary. When I reviewed the Mars in February, I reported 936 seconds and called it the slowest board in my fleet. That figure recorded no commit hash and no line count, so it was measured against whatever main happened to be in February 2026, a tree substantially larger than the pinned one. It was an orphan number, comparable to nothing, and the "slowest in the fleet" claim built on it was simply wrong. This is exactly the failure the T6N review warned about, and my own archive was already carrying an instance of it.

So: both boards, both tiers, the same two pinned commits, and (because the Mars needed a fresh toolchain anyway) the identical rustc 1.98.1.

	Pinned `2821bba`	HEAD `b0cfcd4`
Milk-V Mars (8 GB)	458.00 s	2932.35 s
Pine64 Star64 (4 GB)	461.28 s	2931.88 s
difference	3.28 s (0.71%)	0.48 s (0.016%)

On the long tier the two boards finish a 49-minute build within half a second of each other. That gap is 0.11× the pooled run-to-run noise, and the sign flips between tiers (the Mars is marginally ahead on the pinned tree, the Star64 marginally ahead on HEAD), which is the signature of noise rather than a real difference. These boards are the same speed.

Two things follow. First, the Mars's extra 4 GB of RAM buys it exactly nothing, consistent with the Star64 never touching swap. Second, and more useful: the ~6× deficit against contemporary ARM is a property of the JH7110 itself, not of one board's BSP, distro, kernel, or microSD. Two independent implementations landing within 0.02% of each other is about as clean a confirmation of that as this bench can produce.

The corrected fleet ordering puts the two JH7110 boards adjacent, where identical silicon belongs, and moves the actual slowest board back to the Orange Pi RV2 at 650.60 s.

Cryptography: Where the Baseline ISA Bites

Now the interesting part. Single-threaded OpenSSL 3.x, 16 KB blocks:

Left: absolute throughput on a linear scale. I deliberately did not use a log axis, because the Star64's bars really are that small and a log plot would flatter them. Right: how far behind the Cortex-A76 each algorithm falls, with the dashed line marking the 5.9x gap that is the core itself.

Algorithm	Star64 U74	i5-2435M	RK3588 A76	A76 / Star64
AES-128-GCM	21.7 MB/s	1112.4	2185.7	100.9×
AES-256-GCM	17.9	988.2	1763.9	98.3×
AES-128-CBC	31.4	575.6	1831.8	58.4×
SHA-256	35.4	251.8	1429.4	40.4×
SHA-512	63.5	361.2	376.1	5.9×
ChaCha20-Poly1305	51.0	761.9	674.4	13.2×

SHA-512 is the control, and it decomposes everything else. None of these three chips has SHA-512 acceleration: not the U74, not the Cortex-A76, not Sandy Bridge. All three run software implementations. On that even footing the U74 sits 5.9× behind the A76, and that is the honest measure of the core itself.

Every gap wider than 5.9× is the instruction set talking. AES-128-GCM's 100.9× factors cleanly into roughly 6× "the U74 is a slower core" multiplied by about 17× "the A76 has AES instructions and this chip has none."

And that 5.9× independently corroborates the compile result. The Star64 is 6.02× slower than a Raspberry Pi 5, both quad-core, measured by a completely unrelated workload, landing on the same number. When two independent measurements agree that closely, the figure is real and the decomposition holds.

The asymmetric results split along the same seam:

Operation	Star64	RK3588 A76	Gap
RSA-2048 sign	66.5 /s	269.6 /s	4.1×
ECDSA P-256 sign	211.2 /s	16,917.2 /s	80.1×

RSA-2048 is bignum arithmetic that nobody accelerates in silicon here, and its 4.1× gap sits right in the neighborhood of the core's raw deficit. ECDSA P-256's 80× gap is not silicon at all. It is OpenSSL shipping hand-tuned P-256 assembly for ARM and x86 and generic C for RISC-V. Some of RISC-V's disadvantage is missing hardware. A good deal of it is missing software investment, which is a different problem with a different fix.

The Practical Inversion

On the Star64, ChaCha20-Poly1305 runs 2.35× faster than AES-128-GCM. On the RK3588, that comparison runs the other way, with AES 3.2× ahead.

The correct cipher suite flips depending on whether the silicon has AES instructions, which is exactly the case ChaCha20 was designed for. If you are terminating TLS on a baseline RISC-V board, prefer ChaCha20. Anyone who copies an AES-first cipher preference list off an ARM server onto this hardware leaves more than half their throughput on the floor.

The Hardware Engine Nobody Can Reach

Here I have to correct my own framing, because my first pass at this section was wrong.

The JH7110 does have a hardware crypto block. The kernel registers 21 algorithms from the jh7110 driver: AES in ECB, CBC, CTR, CFB, OFB, GCM and CCM; SHA-1 through SHA-512 with HMAC variants; SM3; and RSA at priority 3000. I had written "software-only crypto" before I actually looked at /proc/crypto, and that was not true.

What is true is narrower and more annoying. openssl engine lists only dynamic: there is no AF_ALG or cryptodev bridge wired up, so userspace OpenSSL never sees any of it and falls back to pure software. The 21.7 MB/s figure is real for userspace TLS; it is what nginx or a userspace WireGuard would actually get. But it is not the ceiling of what this silicon can do. Kernel-space consumers (dm-crypt, IPsec, kernel TLS) should reach the accelerator and do considerably better.

So the accurate statement is not "RISC-V is terrible at crypto." It is: this SoC's crypto acceleration is real but stranded behind missing userspace plumbing, and the ISA itself offers nothing to fall back on when it is unreachable. Fixing the plumbing is a software task, and it would move these numbers a long way for the workloads that can use it.

Thermals and Scaling: The Good News

Left top: SoC temperature across 3.4 hours of continuous compilation. Left bottom: the CPU clock over the same window: flat at the 1.5 GHz maximum for the entire run. Right: thread scaling against perfect linear.

The temperature trace has a shape worth reading. Each build ramps to a peak near 70 °C, then decays to a plateau around 62 °C and holds there. That is not cooling catching up. It is the build's own structure. The early phase compiles many independent crates across four cores and runs hot; the long tail is a single rustc doing final codegen on the main crate, one core busy and three idle. The same asymmetry showed up in the memory sampling, where peak pressure landed at load 1.00.

The sharp dips to 57 °C are the cargo clean and cache-drop gaps between runs.

Thread scaling is genuinely excellent:

Threads	Time	Events/s	Scaling
1	12.15 s	246.96	1.00×
2	6.07 s	494.19	2.00×
4	3.09 s	970.90	3.93×

Essentially perfect. Four real cores, no SMT, no floating-point units shared between siblings, no thermal limit and no memory bottleneck. This board scales about as well as it is physically possible to scale, a useful contrast with the FreeBSD MacBook, where Hyper-Threading contributed literally nothing to SIMD work because SMT siblings share the FP pipeline. The Star64 has fewer and slower cores, but the ones it has are entirely independent.

One Measurement Trap

The benchmark's own before-and-after readings showed 625 MHz and 750 MHz, which looks like severe throttling, and for about twenty minutes I believed it was. Those samples are taken between builds, while the CPU is idle and the ondemand governor has wound down. Only continuous sampling during the runs showed the truth: 100% of 677 under-load samples at the full 1.5 GHz.

An instantaneous clock reading taken at an arbitrary moment is not a measurement. That is the same lesson the MacBook's MSR readings taught me two weeks ago, on completely different hardware, and I nearly published the wrong conclusion twice.

Memory and Storage

Memory measured 5,488 MB/s read and 5,070 MB/s write. Notably (and unlike every other board in this fleet) those numbers are plausible. The JH7110's 32-bit LPDDR4 interface tops out near 11 GB/s, so ~5.5 GB/s is about half of theoretical rather than a physical impossibility. The 1 MB block size still means part of the working set is cache-resident, so treat it as an upper bound. But this is the first time in this benchmark series that sysbench's memory test has not handed me a number that beats physics.

Storage is the weak point:

Test	Result
hdparm buffered read	22.38 MB/s
dd write 1 GB	19.9 MB/s
dd read 1 GB (caches dropped)	23.5 MB/s

The card is not the problem: the controller is. The exact same SanDisk SN64G model read at 64.85 MB/s in the NanoPC-T6N. Checking /sys/kernel/debug/mmc1/ios explains it:

clock:        50000000 Hz
bus width:    2 (4 bits)
timing spec:  2 (sd high-speed)

The Star64 runs the card in SD High-Speed mode at 50 MHz, not UHS-I SDR104 at 208 MHz. Four-bit high-speed caps out near 25 MB/s in practice, which is exactly what I measured. This is a board or BSP limitation, and it means microSD performance here is about a third of what the same card delivers elsewhere.

For the compile benchmark it barely mattered: 0.12% run-to-run variance says the build was CPU-bound with its working set in page cache. For a NAS, a container host, or anything doing bulk I/O, it would be the whole story.

What Works, What Doesn't

Better than expected. The GPU has real DRM nodes (/dev/dri/card1 and renderD128, backed by the Imagination BXE-4-32), plus /dev/video0 through 7 for the video engine. That is more functional graphics support than the FreeBSD MacBook managed. Gigabit Ethernet is live via st_gmac. Four independent cores scale nearly perfectly. Nothing throttles.

Not working, or not measured. The hardware crypto engine is unreachable from userspace. The microSD controller is stuck in high-speed mode. The kernel is a vendor BSP from September 2023, with everything that implies for long-term support. And network throughput was never measured. I had a live gigabit link and simply did not set up an iperf3 peer, so that section is a gap in my testing rather than a finding about the board.

Three Things I Got Wrong

I keep a section like this in these reviews because benchmarking unfamiliar hardware generates plausible nonsense, and the nonsense is instructive.

My ISA check reported the vector extension as present. It substring-matched single-letter extensions against the full ISA string, and rv64imafdc contains a literal "v" in the rv64 prefix. Re-parsed with the prefix stripped, V is absent, isa-ext is empty, and the kernel has no vector support compiled in at all. Had I trusted that line, this entire review would have rested on a false premise about what the chip can do.

sysbench silently produced nothing. This board ships sysbench 0.4.12, whose CLI differs from the 1.0.x I use everywhere else. My 1.0-syntax invocations failed and emitted empty sections, which is worse than an error because it looks like missing data rather than a broken command. The figures above are re-runs with 0.4 syntax; the scaling ratios are sound, but the absolute numbers cannot be compared to the T6N's sysbench results.

/usr/bin/time -v reports zero for every rusage field on this board: max RSS, page faults, context switches, all zero, from a GNU time build that identifies its own version as "UNKNOWN." I lost peak-memory instrumentation and fell back to sampling free -m, which turned out to be the better instrument anyway.

The general rule, and the reason these sections keep earning their place: a benchmark number that beats the hardware's physical limits is a bug report, not a result.

Who Is This For?

Reasonable uses. As a RISC-V development and porting target, this is a sound machine. Four independent cores that scale cleanly, 4 GB of RAM, working GPU and video nodes, gigabit networking, and enough compile throughput to build real software locally instead of cross-compiling. If your goal is finding out whether your code works on RISC-V, it does that job without drama.

Poor uses. Anything crypto-heavy in userspace is off the table until the AF_ALG plumbing exists. Anything I/O-bound is throttled to a third of the microSD's capability. And anything where you simply want the work finished quickly is better served by nearly any ARM board on this list, including, remarkably, one built on a 2012-era Cortex-A53.

The honest framing is that you buy a Star64 because it is RISC-V, not because it is fast. That is a completely legitimate reason to buy one. Somebody has to run real software on this architecture for the ecosystem to mature, and the JH7110 is a reasonable place to do it. But it should be a deliberate choice rather than a value comparison you expect to win.

Conclusion

The Star64's defining characteristic is its ISA string. rv64imafdc is RISC-V's baseline, and everything above baseline (vectors, crypto, bit manipulation) is simply absent.

On integer work that costs relatively little: 5.9× behind a Cortex-A76 on software SHA-512, corroborated by 6.02× behind a Raspberry Pi 5 on compilation. Those are the numbers for the core itself, and while they are not flattering, they are not disastrous either. A 6× deficit against the best ARM cores in this price class is a gap you can live with for development work.

Where it becomes disastrous is anywhere the competition has dedicated instructions. AES-128-GCM at 100× behind is not a core-quality problem. It is an extensions problem, and it multiplies a manageable 6× disadvantage into an unusable one. That the SoC has a perfectly good crypto engine sitting unreachable behind missing userspace plumbing makes that worse rather than better: the silicon is there, and software is the thing in the way.

RISC-V's problem in this benchmark is not that its cores cannot compete. It is that the baseline profile ships without accelerators everyone else has had for a decade, and the software stack has not yet caught up to the hardware that does exist. Both are fixable. Neither is fixed on this board today.

By the numbers:

Rust clean release build, pinned tree (2821bba, 16,639 LOC): 461.28 s mean (σ 2.71), 10th of 11 on my bench
Rust clean release build, current tree (b0cfcd4, 155,867 LOC, 243 crates): 2931.88 s mean (σ 3.47)
vs. the other RISC-V design: 1.41× faster than the Orange Pi RV2 with half the cores (2.82× per core-second)
vs. its own twin: within 0.016% of the Milk-V Mars on HEAD: same JH7110, same rustc, statistically identical
vs. a 2012-era Cortex-A53: 1.22× slower than the Horizon X3 CM
SHA-512 (no hardware anywhere): 63.5 MB/s, only 5.9× behind a Cortex-A76, the honest core-to-core figure
AES-128-GCM: 21.7 MB/s, 100.9× behind: the cost of no K extension
ChaCha20-Poly1305 51.0 MB/s, 2.35× faster than AES-GCM on this board: the inversion that matters for TLS
ECDSA P-256 211.2 sign/s (80× behind, mostly missing assembly); RSA-2048 66.5 sign/s (4.1× behind)
Hardware crypto: 21 jh7110 algorithms registered in the kernel, zero reachable from OpenSSL
Thread scaling: 2.00× at 2 threads, 3.93× at 4, near perfect
Thermals: 55.7 °C idle, 70.0 °C peak, 1.5 GHz held for 100% of 677 under-load samples
microSD 22.4 MB/s: SD high-speed 50 MHz, not UHS-I; the same card does 64.85 MB/s elsewhere
Memory 5,488 MB/s read, the first sysbench memory figure in this series that does not exceed physics

Caveats. My run used rustc 1.98.1; the archived October 2025 fleet used 1.90/1.91. Commit 2821bba predates the repository having a Cargo.lock, so dependency versions resolved fresh. sysbench is 0.4.12 here and 1.0.20 elsewhere, so those absolute figures are intra-machine only. OpenSSL numbers are userspace software crypto and are not this silicon's AES ceiling. The governor was left at the as-shipped ondemand, and no performance comparison was run because sampling showed the clock already pinned at maximum. Network throughput was never measured. The February 2026 Milk-V Mars result uses this same SoC but recorded no commit or LOC, so it is excluded from every comparison here.

Review Date: September 9, 2026

Hardware Tested: Pine64 Star64, StarFive JH7110 (4 × SiFive U74-MC @ 1.5 GHz), 4 GB LPDDR4, 64 GB SanDisk microSD

OS Tested: PinIx 2.1, kernel 5.15.131 (vendor BSP)

Benchmark Workload: ballistics-engine clean release builds at commits 2821bba (fleet-comparable) and b0cfcd4 (current), rustc 1.98.1

Conclusion: Competent baseline RISC-V silicon whose cores are roughly 6× behind contemporary ARM and whose crypto is 100× behind. The first number is the hardware, the second is the missing instruction set, and a stranded on-chip accelerator sits between them waiting for someone to write the plumbing.

FreeBSD on a 2011 MacBook Pro: Fifteen Years of Progress, and Per Core It's a Tie

A.C. Jokela — Sat, 29 Aug 2026 21:30:00 GMT

Every machine I have put through this benchmark has been a single-board computer. Rockchip, Broadcom, Intel's N-series, a RISC-V pioneer that took eleven minutes to do what the others did in one. This one is not an SBC at all. It is a 13-inch MacBook Pro from early 2011, an Apple MacBookPro8,1 with a Sandy Bridge Core i5, running FreeBSD 15.1-RELEASE-p3 instead of the macOS Apple stopped shipping it years ago.

I did not add it to the fleet to find out whether a 2011 laptop is fast. I added it because it is a control. Every claim about how far single-board computers have come is implicitly a claim about what they came from, and I had never actually measured the "from." A $60 Raspberry Pi 5 against a machine that cost well north of a thousand dollars new is a clean test of how much of the last fifteen years was real.

The short version: it lands sixth of nine on my bench, at 131.00 seconds: behind every current ARM board with four or more modern cores, comfortably ahead of the Cortex-A53 boards and the RISC-V entry. That is the boring part. The interesting part is what happens when you normalize that number per core and per gigahertz, at which point a 2011 Intel core and a 2023 ARM core turn out to do the same amount of work to within 0.3%. Fifteen years of progress went almost entirely into core count, power, and specialized instructions, not into making an individual core meaningfully better at compiling Rust.

Along the way this machine also tried to sell me a mechanical hard drive that reads at 2.86 GB/s, and a CPU benchmark that claimed five million prime-sieve passes per second. Both were lies, and both are instructive.

The Hardware: Sandy Bridge in 2026

The MacBookPro8,1 is built on an Intel Core i5-2435M: two physical cores, four threads via Hyper-Threading, 2.4 GHz base, 3.0 GHz single-core turbo, 2.8 GHz two-core turbo. A 32 nm Sandy Bridge part with a 35 W TDP.

That core count is the whole story of where it lands. Every ARM board in this comparison has at least four cores; the RK3588 boards have eight. This machine brings two real cores to a fight against four and eight, and Hyper-Threading only partly closes the gap.

Component	Specification
CPU	Intel Core i5-2435M, 2C/4T, 2.4 GHz base / 3.0 GHz turbo
Microarchitecture	Sandy Bridge, 32 nm, 35 W TDP
ISA extensions	SSE4.2, AVX, AES-NI, PCLMULQDQ (no SHA extensions)
RAM	2 × 4 GiB DDR3-1333, dual channel (21.3 GB/s theoretical)
Storage	Seagate ST9500325ASG: 500 GB, 2.5", 5400 RPM mechanical
GPU	Intel HD Graphics 3000 (no driver under FreeBSD)
Ethernet	Broadcom BCM57765 Gigabit (present, uncabled)
Wireless	USB Realtek RTL8188EU 1T1R 802.11n
OS	FreeBSD 15.1-RELEASE-p3 amd64, ZFS on root
Toolchain	rustc / cargo 1.98.0, `x86_64-unknown-freebsd`

Two rows carry most of the weight. AES-NI and AVX are what keep this chip relevant in 2026: Sandy Bridge was the generation that introduced both, and as we will see, that timing decides several benchmarks outright. The 5400 RPM mechanical hard drive is what drags it back into the past. Nothing else on my bench has spinning rust in it.

The Benchmark, and Why It Has Two Numbers

My standard workload is a clean release-mode build of ballistics-engine, a Rust project of mine. Rust compilation stresses integer throughput, branch prediction, memory bandwidth, and parallel scaling simultaneously, and it is what I actually use these machines for.

As I wrote in the NanoPC-T6N review, that benchmark quietly outgrew itself. The October 2025 fleet sweep compiled 43 source files and 16,639 lines. Today's main is 196 files and 155,867 lines, nine times the code. Any number produced against current HEAD is meaningless next to an archived 2025 result.

So, as with the T6N, this run has two tiers:

Pinned: commit 2821bba, verified on the machine at 43 .rs files / 16,639 LOC / 144 crates. Byte-for-byte the tree the fleet was measured on. Every fleet comparison below uses this.
HEAD: commit b0cfcd4, 196 files / 155,867 LOC / 246 crates. Useful as a 2026-scale data point, comparable only to future runs of the same commit.

Each tier got an untimed warm-up build to fetch and compile dependencies, then three timed cargo build --release runs, each preceded by cargo clean and a sync.

A note for anyone repeating this on FreeBSD: the base system ships without git, sudo, or bash (they are all ports, not base), and the default login shell is tcsh, which cannot parse 2>&1. I fetched both source trees as GitHub codeload tarballs pinned to exact commit hashes rather than cloning, and wrapped every remote command in sh -c. Neither changes the source tree; both will trip you up if you assume Linux habits transfer.

Compilation Results

Pinned tier (2821bba, 16,639 LOC), fleet-comparable:

Run	Time
1	127.78 s
2	131.33 s
3	133.87 s
Mean	131.00 s (median 131.33 s, σ 3.06 s)

HEAD tier (b0cfcd4, 155,867 LOC):

Run	Time
1	711.95 s
2	718.60 s
3	712.00 s
Mean	714.18 s (median 712.00 s, σ 3.82 s)

The current tree takes 5.45× as long for 9.4× the source volume: sublinear, because a growing share of the work is dependency compilation the two trees partly share.

Against the Fleet

Clean cargo build --release, pinned tree, mean of three runs:

#	System	SoC	Cores	Arch	Mean	vs. best
1	NanoPC-T6N	Rockchip RK3588	8	arm64	52.55 s	1.00×
2	Orange Pi 5 Max	Rockchip RK3588	8	arm64	62.31 s	1.19×
3	Raspberry Pi CM5	BCM2712	4	arm64	71.04 s	1.35×
4	LattePanda IOTA	Intel N150	4	x86_64	72.21 s	1.37×
5	Raspberry Pi 5	BCM2712	4	arm64	76.65 s	1.46×
6	MacBookPro8,1 (FreeBSD)	Core i5-2435M	2C/4T	x86_64	131.00 s	2.49×
7	Banana Pi CM5-Pro	RK3576	8	arm64	167.15 s	3.18×
8	Horizon X3 CM	Sunrise X3 (A53)	4	arm64	378.81 s	7.21×
9	Orange Pi RV2	Ky X1 (RISC-V)	8	riscv64	650.60 s	12.38×

Archived figures are from the October 2025 fleet sweep on rustc 1.90/1.91; the MacBook figure is from August 2026 on rustc 1.98.0 against the same source tree. See the caveats at the end.

Mid-table. It is 1.71× slower than a Raspberry Pi 5, 1.81× slower than a LattePanda IOTA, and 2.49× off the leading NanoPC-T6N, while being 1.28× faster than a Banana Pi CM5-Pro and 4.97× faster than the RISC-V Orange Pi RV2. For scale, the AMD AI Max+ 395 desktop in the same archived sweep did the pinned tree in 13.71 s.

The Number That Actually Matters

A 2011 laptop losing to a 2023 Raspberry Pi is not a story. Losing by only 1.71× is.

The gap is almost entirely core count. Rust compilation parallelizes well across crates, and the Pi 5 brings four Cortex-A76 cores where this machine brings two Sandy Bridge cores plus SMT. So normalize it.

The Pi 5 spends 306.6 core-seconds on the build (4 cores × 76.65 s). The MacBook spends 262.0 (2 cores × 131.00 s), 1.17× fewer per core. But the i5 is also running at 2.8 GHz against the A76's 2.4 GHz, and once you divide that out the two land at 1.003×. A 0.3% difference.

Per core, per gigahertz, a 2011 Sandy Bridge core and a 2023 Cortex-A76 do the same amount of Rust compilation.

That needs one honest caveat: count the i5's four SMT threads instead of its two physical cores and the ratio flips to 0.59×, because SMT threads are not cores. The defensible reading is per physical core, and on that basis fifteen years of core design produced parity, not progress.

This is the clearest evidence I have for where SBC progress actually came from. It is not that ARM cores became dramatically faster than 2011 x86 cores. It is that you can now buy eight of them, on one die, drawing a tenth of the power, for eighty dollars.

I want to be careful about the efficiency claim, because I never measured power. The machine stayed on AC and reported a 0 mA discharge rate throughout. On nominal TDP alone (35 W against the Pi 5's ~12 W and the N150's ~6 W), this laptop does less work for several times the energy. Treat that as an order-of-magnitude statement, not a measurement.

Cryptography: A Tale of Two Instruction Sets

Here the comparison stops being about core counts and starts being about what silicon designers chose to put in hardware. Single-threaded OpenSSL 3.5.6, 16 KB blocks, against the NanoPC-T6N's Cortex-A76:

Algorithm	i5-2435M	RK3588 (A76)	Ratio	Winner
AES-128-CBC	575.6 MB/s	1831.8 MB/s	3.18×	Cortex-A76
AES-128-GCM	1112.4 MB/s	2185.7 MB/s	1.96×	Cortex-A76
AES-256-GCM	988.2 MB/s	1763.9 MB/s	1.78×	Cortex-A76
SHA-256	251.8 MB/s	1429.4 MB/s	5.68×	Cortex-A76
SHA-512	361.2 MB/s	376.1 MB/s	1.04×	Cortex-A76
ChaCha20-Poly1305	761.9 MB/s	674.4 MB/s	1.13×	Sandy Bridge

That pattern is not noise, and it is not "newer is faster."

SHA-256 is the blowout, and it is an instruction-set gap rather than a performance gap. ARMv8 gained dedicated SHA-256 instructions. Sandy Bridge has none. Intel did not ship SHA extensions until Goldmont and Ice Lake, years later. The A76 does SHA-256 in hardware while the i5 grinds it out in general-purpose integer code. No clock speed closes 5.68×.

SHA-512 is the control that proves the point. Neither chip accelerates SHA-512, so both run software implementations, and they land within 4% of each other. Take away the instruction-set advantage and a 2011 Intel core matches a 2023 ARM core almost exactly. That is the same conclusion the compile normalization reached, arrived at from a completely different direction.

ChaCha20-Poly1305 is the one outright win, and it comes from AVX. ChaCha20 was designed to be fast in software on SIMD units, and Sandy Bridge's AVX serves it well enough to beat the A76 by 13%. This is exactly why ChaCha20 exists: it is what you reach for when you cannot count on AES hardware.

AES sits in between, and the i5 does have hardware for it. Disabling AES-NI isolates the contribution:

AES-128-CBC	Throughput
AES-NI enabled	575.6 MB/s
AES-NI disabled	296.9 MB/s
Speedup	1.94×

Under 2× looks disappointing for dedicated hardware until you remember that CBC encryption is inherently serial: every block depends on the one before it, so the pipelined AES-NI units can never be filled. Parallelizable GCM tells the real story at 1112 MB/s, nearly 4× the unaccelerated CBC figure. AES-NI works fine; CBC just cannot use it.

Asymmetric operations round it out: RSA-2048 at 743.7 signs/s and 24,962 verifies/s; ECDSA P-256 at 22,696 signs/s and 7,426 verifies/s.

Practically: as a TLS terminator this machine is respectable, roughly a gigabit of AES-GCM on a single core. As anything that hashes heavily (content-addressed storage, a Git server, bulk checksumming), it is badly handicapped against any ARMv8 board.

Hyper-Threading Does Nothing Here (And That's Fine)

Intra-machine scaling, stress-ng --cpu with the matrixprod method:

Threads	Bogo-ops/s	Scaling
1	1378.90	1.00×
2	2077.40	1.51×
4	2077.78	1.51×

Hyper-Threading contributes exactly nothing: 2077.40 to 2077.78 is noise. That is not a fault. matrixprod is floating-point and SIMD-bound, and on Sandy Bridge, SMT siblings share the floating-point execution units. Two threads already saturate them.

Do not generalize this to the compile benchmark. Rust compilation is mixed integer, branch, and pointer-chasing work with frequent memory stalls, precisely the profile SMT was built to exploit. The compile results do benefit from four threads. These two measurements answer different questions about the same chip, and conflating them would be an easy way to draw a badly wrong conclusion.

The 1→2 scaling of 1.51× rather than 2.00× is also explainable: single-threaded work runs at the 3.0 GHz one-core turbo, two-threaded work at the 2.8 GHz two-core ceiling. Correct for that and real two-core scaling is about 1.62×.

Storage: The 5400 RPM Anchor

The system disk is a Seagate ST9500325ASG: 500 GB, 2.5-inch, spinning at 5400 RPM, confirmed by the drive's own rotationrate field rather than inferred from the model number.

Raw sequential read via diskinfo -t, bypassing the filesystem:

Zone	Throughput
Outside tracks	77.2 MB/s
Middle tracks	65.7 MB/s
Inside tracks	40.2 MB/s

A textbook ZCAV curve, 1.92× falloff from outer to inner tracks, because the outer edge of the platter passes under the head faster. Seek times are what you would expect and worse: 33.3 ms full stroke, 23.8 ms half, 18.5 ms quarter. An NVMe drive services a request roughly a thousand times faster.

At the filesystem level, on ZFS with compression off: 74.8 MB/s write, 75.0 MB/s read, tracking the outer-track raw number closely.

Getting that read figure honestly took two attempts. The first returned 2.86 GB/s, thirty-six times what the drive can physically do. The ZFS ARC was the culprit: the 1 GB test file fit entirely inside a 2040 MB cache, so the read never touched a platter. Setting primarycache=none after writing does not fix it, because the data is already cached. Only creating the dataset with compression=off and primarycache=none from the outset forces real I/O. I threw the first number away.

For a compile box the mechanical disk matters far less than it looks. cargo build is CPU-bound once sources are on disk, the working set fits in ARC, and run-to-run standard deviation was only 3.06 s on a 131 s mean: no I/O stalls. Swapping in an SSD would barely move the compile numbers. Cold boots, big checkouts, and anything touching many small files are a different conversation entirely.

Thermals: Riding Tjmax With a Lazy Fan

Sustained load, four stress-ng workers for 120 seconds, sampled every 10 seconds:

Time	Die temp	Fan	Delivered clock
10 s	81 °C	1996 RPM	2800 MHz
20 s	92 °C	2540 RPM	2800 MHz
30 s	100 °C	3646 RPM	2800 MHz
40 s	99 °C	5170 RPM	2700 MHz
50 s	94 °C	6200 RPM	2800 MHz
60–100 s	92–98 °C	~6200 RPM	2800 MHz
110 s	100 °C	6200 RPM	2800 MHz

Idle is 45 °C with the fan at its 2000 RPM floor and the CPU parked at 1200 MHz. Thirty seconds into load the die is at Tjmax, 100 °C, because the SMC fan curve is reactive and takes about 50 seconds to reach its 6200 RPM maximum. The fan chases the heat rather than anticipating it.

And yet the delivered clock holds 2800 MHz for the entire run, with a single 10-second sample at 2700. That 2800 figure is the two-core turbo ceiling straight out of MSR_TURBO_RATIO_LIMIT: the chip is delivering its rated maximum multi-core turbo while sitting at its thermal limit. Across 221 samples taken during the compile runs the mean delivered clock was 2757 MHz, with 86.9% of samples at or above 2800.

One methodological warning, because it nearly cost me the whole thermal analysis. On x86, dev.cpu.N.freq is useless for this. It reported 2401 MHz for the entire benchmark, because it reflects the requested P-state, not what the silicon delivers. The real number comes from IA32_PERF_STATUS (MSR 0x198, bits 15:8), read with cpucontrol. Early on I took a single such reading, got multiplier 11 (1100 MHz) and briefly concluded the machine was throttling catastrophically. Sustained sampling showed that was an idle-sample artifact: I had caught the core between compile jobs. One instantaneous MSR read is not a measurement. It took 221 of them to get the right answer, which was nearly the opposite of the first one.

The verdict: this fifteen-year-old cooling system, aged thermal paste and all, is still doing its job. Loudly, with zero margin, at the edge of Tjmax, but doing it. Compile throughput is not meaningfully thermally limited.

What Doesn't Work

FreeBSD on Apple hardware is functional, not complete.

No GPU acceleration. The Intel HD Graphics 3000 shows up as a PCI device, but no i915/DRM module loads and no /dev/dri nodes exist: Sandy Bridge (gen6) support has been dropped from current drm-kmod. This is a console-and-SSH machine, not a desktop.

The internal WiFi is not in use. The Broadcom BCM4331 probes and attaches via bwn_pci0/bhnd0, but the active interface is a USB Realtek RTL8188EU: a 1T1R 802.11n 2.4 GHz dongle, about the slowest wireless configuration still sold. Every byte of this testing crossed that link.

Networking is therefore uncharacterized, deliberately. The BCM57765 gigabit port is present and well supported but had no cable in it, and the machine was reachable only over that wireless dongle for the entire test window. Benchmarking a NIC with no cable, or reporting throughput across a link that tops out near 150 Mbps of PHY rate, would produce a number describing the dongle rather than the machine. I ran no network benchmark and I am reporting none. Treat this machine's networking as genuinely unknown: there is no reason to expect the BCM57765 to disappoint, but this review does not demonstrate it.

The battery is at 85.7% of design capacity (4944 of 5770 mAh after fifteen years), which is frankly remarkable, though it reports "discharging" at 0 mA while on AC, an ACPI quirk of this hardware.

Two Results I Threw Out

Benchmarking old hardware invites plausible-looking nonsense. Two numbers here went in the bin rather than into the tables.

sysbench CPU is broken on this FreeBSD build. It reported 5,176,529 events/s single-threaded with --cpu-max-prime=20000. The NanoPC-T6N scored 967 on the identical test. A 5000× gap is not a performance difference: computing primes to 20,000 five million times a second would need something like 10¹¹ operations per second from one 2.8 GHz core. sysbench 1.0.20 accepts the flag and dutifully echoes "Prime numbers limit: 20000" back at you, but its event accounting in this build is wrong. Every sysbench CPU number was discarded; the CPU comparison rests on the compile benchmark and OpenSSL instead.

sysbench memory measures cache, not DRAM. It reported 40.4 GB/s read. This machine has 2 × 4 GiB of DDR3-1333 in dual channel, a theoretical ceiling of 21.3 GB/s. Beating physics by 1.9× means the working set never left cache. The T6N run flagged the same failure mode, which suggests it is a property of the benchmark rather than of either machine.

The general rule, and the reason I keep writing these sections: a benchmark number that beats the hardware's physical limits is a bug report, not a result. Three of the numbers this machine initially handed me (2.86 GB/s from a 5400 RPM disk, 5.2 million prime passes per second, 40 GB/s from DDR3-1333) were all physically impossible, and all three looked perfectly ordinary sitting in a terminal.

Who Is This For?

Reasonable uses. As a home build server, a network service host, or a FreeBSD and ZFS learning machine, this is genuinely useful hardware. It compiles a 16,000-line Rust project in about two minutes, terminates roughly a gigabit of AES-GCM on one core, has 8 GB of RAM (more than most boards on my bench), plus a real SATA bus, a real gigabit NIC, a keyboard, and a screen. It also has an uninterruptible power supply bolted to the bottom of it that still holds 86% of its original charge, which no SBC here can say.

Poor uses. Anything hash-heavy loses badly to any ARMv8 board. Anything needing a GPU or a desktop is out. Anything power- or space-constrained is better served by a $60 Pi. Anything depending on fast random I/O is throttled by a 5400 RPM disk with 33 ms full-stroke seeks.

The honest framing is that this machine's value is that it already exists. Nobody should go buy a 2011 MacBook Pro for this: a Raspberry Pi 5 beats it on speed, power, size, and noise simultaneously, for a fraction of what this cost new. But a laptop otherwise headed for a drawer or a recycler, given a current OS, lands mid-pack in a fleet of 2026 single-board computers. That is a better argument for FreeBSD on old Apple hardware than any benchmark table I could build.

Conclusion

Fifteen years of progress turn out to be real, but much narrower than the marketing implies. Per core and per gigahertz, this Sandy Bridge chip and a Cortex-A76 compile Rust at the same rate to within 0.3%. The SHA-512 result, where neither side has hardware acceleration and the two land within 4%, says the same thing from a different angle. What changed was not that cores got dramatically better. It was core density, power efficiency, and the arrival of specialized instructions. The 5.68× SHA-256 gap is not Intel being slow; it is Intel not having shipped the instruction yet in 2011.

The MacBookPro8,1 slots in sixth of nine at 131.00 seconds: behind every current ARM board with four or more modern cores, comfortably ahead of the A53-class boards and the RISC-V entry. Thermally maxed out but not throttled. Storage-limited in ways that barely touch this workload. Network-limited in a way an Ethernet cable would fix.

It is also, fifteen years on, still doing useful work. That was not the result I expected when I plugged it in.

By the numbers:

Rust clean release build, pinned tree (2821bba, 16,639 LOC): 131.00 s mean (σ 3.06 s), 6th of 9 on my bench
Rust clean release build, current tree (b0cfcd4, 155,867 LOC, 246 crates): 714.18 s mean (σ 3.82 s)
Per core per GHz vs Cortex-A76: 1.003×, a statistical tie
AES-128-GCM 1112.4 MB/s; AES-256-GCM 988.2 MB/s; ChaCha20-Poly1305 761.9 MB/s; SHA-256 251.8 MB/s
AES-NI contribution on AES-128-CBC: 575.6 vs 296.9 MB/s (1.94×)
ECDSA P-256 22,696 sign/s; RSA-2048 743.7 sign/s, 24,962 verify/s
Storage: 77.2 / 65.7 / 40.2 MB/s outer/middle/inner; 33.3 ms full-stroke seek; 74.8 MB/s ZFS write
CPU scaling (FP-bound): 1.51× at 2 threads, 1.51× at 4: SMT contributes nothing to SIMD work
Thermals: 45 °C idle, 100 °C peak, 2800 MHz two-core turbo sustained throughout
Discarded as physically impossible: sysbench CPU, sysbench memory, and a first-attempt 2.86 GB/s disk read

Caveats. My run used rustc 1.98.0; the archived fleet used 1.90/1.91 and the T6N used 1.97.1. Commit 2821bba predates the repository having a Cargo.lock, so dependency versions resolved fresh. coretemp and asmc were loaded mid-run, between HEAD runs 1 and 2, and observed temperatures dropped from ~98 °C to ~90 °C across that window, but runs 1, 2, and 3 came in at 711.95, 718.60, and 712.00 s, statistically identical, so the perturbation had no measurable effect. Power was never measured; efficiency statements rest on nominal TDP. Network throughput was never measured. No random-I/O benchmark was run.

Review Date: August 29, 2026

Hardware Tested: Apple MacBookPro8,1 (13-inch, early 2011), Intel Core i5-2435M, 8 GB DDR3-1333, 500 GB Seagate ST9500325ASG 5400 RPM HDD

OS Tested: FreeBSD 15.1-RELEASE-p3 amd64, ZFS on root

Benchmark Workload: ballistics-engine clean release builds at commits 2821bba (fleet-comparable) and b0cfcd4 (current), rustc 1.98.0

Conclusion: A fifteen-year-old laptop that lands mid-pack against 2026 single-board computers, and a useful reminder that most of what we call CPU progress has been core count, power, and specialized instructions rather than raw per-core throughput.