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.rsfiles / 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.