Raspberry Pi Zero 2 W vs Luckfox Lyra Zero W Benchmark - Is the Substitute Faster?

The question - what if the Pi substitute is slower?

The Luckfox Lyra Zero W is the substitute for the sold-out Raspberry Pi Zero 2 W, and the previous post went through the move. The setup was finished, but one thing kept nagging at us.

If the substitute also loses on performance, does the move not lose half its point?

The spec sheet was not reassuring. The Pi Zero 2 W has four 64-bit Cortex-A53 cores; the Lyra has three 32-bit Cortex-A7 cores. The A53 is a generation ahead, there are more of them, and they are 64-bit. On paper it looks like a clean sweep for the Pi.

So we simply measured it. Both boards happened to be alive on the network anyway.

Benchmark test design - keeping the conditions fair

A performance comparison means nothing unless the conditions match. We fixed the following.

• The same benchmark code - one source, unchanged, on both boards
• The same .NET version (8.0) - the Pi had .NET 9 installed, so we used self-contained builds that include the runtime to put both boards on .NET 8
• A native build for each board - linux-arm (32-bit) for the Lyra, linux-arm64 (64-bit) for the Pi. Each at its own best
• The same GC and settings - Workstation GC, InvariantGlobalization
• Two or three runs each - to see the cold/warm spread

We picked four measurements with different characters.

1. Integer work (single core) - counting primes below 100,000 by trial division.

for (int n = 2; n < 100_000; n++) {
    bool p = true;
    for (int d = 2; d * d <= n; d++)
        if (n % d == 0) { p = false; break; }
    if (p) primes++;
}

2. Floating point - accumulating sqrt and sin ten million times. This looks at the FPU.

double acc = 0;
for (int i = 1; i <= 10_000_000; i++)
    acc += Math.Sqrt(i) * 1e-7 + Math.Sin(i * 1e-6);

3. GC and allocation - allocating two million small objects to put pressure on the GC.

for (int i = 0; i < 2_000_000; i++) {
    var arr = new int[8];
    arr[0] = i; sum += arr[0];
}

4. Parallel work - the same prime search across every core. This shows the benefit of core count.

Parallel.For(2, 100_000, () => 0,
    (n, _, local) => { /* prime check */ return local + isPrime; },
    local => Interlocked.Add(ref total, local));

Running it was simple. We copied the built benchmark onto each board over SSH, ran it, and wrote down the times printed on the console.

.NET 8 benchmark results - the actual console output

Luckfox Lyra Zero W (RK3506B, A7 1.2GHz×3, 32-bit):

=== .NET 8 on Luckfox Lyra Zero W ===
Runtime : .NET 8.0.29
OSArch  : Arm, ProcArch: Arm
CPUs    : 3

[int]   primes<100k = 9592  in 83 ms
[float] 10M sqrt+sin = 1841179.442  in 1752 ms
[gc]    2M allocs  in 232 ms, gen0=42
[par]   primes<100k on 3 cores  in 232 ms
WorkingSet : 25 MB

Raspberry Pi Zero 2 W (BCM2710A1, A53 1.0GHz×4, 64-bit):

=== .NET 8 (Raspberry Pi Zero 2 W) ===
Runtime : .NET 8.0.29
OS      : Debian GNU/Linux 12 (bookworm)
OSArch  : Arm64, ProcArch: Arm64
CPUs    : 4

[int]   primes<100k = 9592  in 95 ms
[float] 10M sqrt+sin = 1841179.442  in 1955 ms
[gc]    2M allocs  in 260 ms, gen0=53
[par]   primes<100k on 4 cores  in 225 ms
WorkingSet : 32 MB

Averaged over several runs, it comes out like this.

Floating point was the most stable measurement on both boards, with under 1% spread. So “the Lyra is 10% faster in floating point” can be read as a real trend rather than measurement error.

Why it came out this way - the clock won on single-core work

Single-core performance was where we expected the Pi to win. A newer core (A53 > A7), one more core (4 vs 3), 64-bit. And yet the Lyra was consistently 10 to 12% faster across all three single-core tests.

The culprit is clock speed.

• Lyra: 1.2GHz
• Pi Zero 2 W: 1.0GHz

That is 20% higher. The A53 clearly has a per-clock (IPC) advantage, but not enough to overturn a 20% clock gap. For work that runs steadily on a single thread, the higher-clocked Lyra comes out ahead.

The Pi claws it back in exactly one place: parallel work. With one more core (4 vs 3) it edges ahead when every core is loaded up. And even there the spread is wide enough that the honest reading is “about the same” rather than “clearly faster.”

In short:

• Single-thread performance → Lyra ahead (clock)
• Peak multi-thread performance → Pi slightly ahead (core count)
• Memory efficiency → Lyra ahead

But a fast CPU does not mean a fast PLC scan

Raw CPU performance is all those numbers are, and stopping here would be half the story. What an industrial controller actually does is not pure computation but a PLC scan - read the inputs, run the logic, write the outputs, handle communication, repeat. So we measured that as well.

We put our industrial PLC software (Senbrix) on both boards and ran exactly the same project, the control logic for a beer-pouring game machine. Both boards had CAN expansion boards attached (analog input plus digital IO), with relay outputs actually switching. We added instrumentation to the runtime to measure the scan cycle processing time, so we could read the time for a single scan live.

(In fairness: the Lyra was also driving a DSI dashboard on the same CPU, so we turned that off and measured both boards with only the PLC runtime running.)

A reversal. The Lyra was more than 10% faster on raw CPU work, and yet the Pi runs the actual PLC scan 1.7 times faster.

Why the flip? A scan is not one computation loop but a structure where several threads run at once - the scan thread, the user control logic thread, and the communication handling thread all turning together. In pure single-core work the higher-clocked Lyra led, but in a real runtime with threads interleaving, the Pi’s extra core (4 vs 3) shares the work out better. The CPU usage gap, Lyra 19% vs Pi 9%, has the same explanation. On three cores the threads elbow each other; on four there is room.

But here is what actually matters - neither board takes even a millisecond per scan. Whether it is 0.3 ms or 0.6 ms, both are overwhelmingly fast against industrial control cycles, which usually run in the single to tens of milliseconds. And real response latency is dominated not by scan time but by waiting on external communication such as CAN or Modbus. That is why there was no perceptible difference at all when we drove the expansion boards and relays for real.

In short:

• Raw CPU → Lyra ahead (clock)
• Real PLC scan → Pi ahead (core count), but both under 1 ms
• Real control response → no difference (I/O dominates)

In a single chart the reversal is obvious. On the three CPU metrics the Pi bar sits above the baseline (the Lyra) - slightly slower. Then on the far right, for the PLC scan alone, the Pi bar drops away. The one that looks better on paper and the one that is actually faster split by metric, and that is the point of this comparison.

Recap: Lyra vs Pi performance

The Luckfox Lyra Zero W, brought in to replace a sold-out Pi, does not lose on performance either. Raw CPU work was in fact more than 10% faster, and while the Pi led on the real PLC scan thanks to its core count, both stay under a millisecond, so neither falls short for industrial control. Wins and losses split by metric, and there is nowhere you could say we gave up performance because it is a substitute.

• If computing performance was the worry - you can relax. The clock actually puts it ahead.
• That said, this is against this particular benchmark. A workload that needs a GPU, an NPU, or a specific accelerator is a different story. For pure CPU plus .NET control logic, the Lyra is more than enough.

We moved thinking we would have to put up with some slowness because it was a substitute, and when we measured, there was nothing to put up with. A choice forced on us by a stock shortage turned out not to be a bad one - that is the conclusion of this comparison.

Raw CPU goes to the Lyra and the PLC scan to the Pi, but both stay under a millisecond, so neither falls short for industrial control.

Test environment summary - both boards on .NET 8.0.29, identical benchmark source, Workstation GC, InvariantGlobalization. The Lyra ran a framework-dependent linux-arm (32-bit) build and the Pi a self-contained linux-arm64 (64-bit) build, so the runtime version matched. Two to three runs per metric.

Contact

• Email: [email protected]
• Instagram: https://www.instagram.com/going.sen/
• Website: https://intosen.com/kr/consult/