라즈베리파이 Zero 2 W vs Luckfox Lyra Zero W — 대체품이 더 빠르다?

궁금했던 것 — 대체품인데, 느리면 어쩌지

앞 글에서 품절된 라즈베리파이 Zero 2 W 대신 Luckfox Lyra Zero W로 갈아타는 과정을 정리했다. 세팅은 끝났는데 한 가지가 계속 걸렸다.

“대체품이 성능까지 밀리면, 옮긴 의미가 반감되는 것 아닌가?”

스펙표만 보면 불안했다. Pi Zero 2 W는 Cortex-A53 4코어에 64비트, Lyra는 Cortex-A7 3코어에 32비트. 코어도 A53이 한 세대 앞서고, 개수도 많고, 64비트다. 종이 위에서는 Pi의 완승처럼 보인다.

그래서 그냥 재봤다. 마침 두 보드가 다 네트워크에 살아 있었으니까.

테스트 설계 — 공정하게 맞추기

성능 비교는 조건을 맞추지 않으면 의미가 없다. 다음을 통일했다.

• 같은 벤치마크 코드 — 한 소스를 양쪽에 그대로
• 같은 .NET 버전(8.0) — Pi에는 .NET 9가 깔려 있었지만, 런타임을 포함한 self-contained 빌드로 양쪽 다 .NET 8로 맞췄다
• 각 보드의 네이티브 빌드 — Lyra는 linux-arm(32비트), Pi는 linux-arm64(64비트). 각자의 최선으로
• 같은 GC/설정 — Workstation GC, InvariantGlobalization
• 2~3회 측정 — cold/warm 편차 확인

측정 항목은 성격이 다른 네 가지를 골랐다.

1. 정수 연산 (단일코어) — 10만 이하 소수를 시분할로 센다.

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. 부동소수 연산 — sqrt와 sin을 천만 번 누적. 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 / 할당 — 소형 객체 200만 개를 할당하며 GC를 압박한다.

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

4. 병렬 처리 — 같은 소수 탐색을 전 코어로. 코어 수 이득을 본다.

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

실행은 간단하다. 빌드한 벤치마크를 SSH로 각 보드에 올리고 돌린 뒤, 콘솔에 찍힌 시간을 받아 적었다.

실행 결과 — 실제 콘솔 출력

Luckfox Lyra Zero W (RK3506B, A7 1.2GHz×3, 32비트):

=== .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비트):

=== .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

여러 번 돌린 값을 정리하면 이렇다.

부동소수는 양쪽 다 측정 편차가 1% 미만으로 가장 안정적이었다. 그러니 “Lyra가 부동소수 10% 빠름”은 오차가 아니라 실제 경향으로 봐도 된다.

왜 이렇게 나왔나 — 클럭이 이겼다

예상은 Pi의 승리였다. 더 앞선 코어(A53 > A7), 코어 하나 더(4 vs 3), 64비트. 그런데 단일코어 세 항목에서 Lyra가 일관되게 10~12% 빨랐다.

범인은 클럭이다.

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

클럭이 20% 높다. A53의 클럭당 성능(IPC) 우위가 분명히 있지만, 이 20% 클럭 차이를 뒤집을 만큼은 아니었다. 결국 단일 스레드로 꾸준히 도는 연산에서는 클럭이 높은 Lyra가 앞선다.

Pi가 만회하는 건 병렬 처리 하나뿐이다. 코어가 하나 더 많으니 (4 vs 3) 전 코어를 갈아 넣을 때만 근소하게 앞선다. 그런데 이 항목은 측정 편차가 커서, “확실히 빠르다”기보다 “비슷하다”에 가깝다.

정리하면:

• 단일 스레드 성능 → Lyra 우위 (클럭)
• 다중 스레드 최대 성능 → Pi 근소 우위 (코어 수)
• 메모리 효율 → Lyra 우위

그런데 — CPU가 빠르다고 PLC가 빠른 건 아니다

여기서 멈추면 반쪽이다. 위 숫자는 CPU 원시 성능이다. 실제 산업용 컨트롤러가 하는 일은 순수 계산이 아니라 PLC 스캔 — 입력 읽고, 로직 돌리고, 출력 쓰고, 통신하는 반복이다. 그래서 실제로 재봤다.

양쪽에 우리가 만드는 산업용 PLC 소프트웨어(Senbrix)를 올리고, 완전히 똑같은 프로젝트(맥주 게임기 제어 로직)를 돌렸다. 두 보드 모두 CAN 확장보드(아날로그 입력 + 디지털 IO)를 물리고, 릴레이 출력까지 실제로 동작하는 상태다. 여기에 런타임에 스캔 사이클 처리 시간을 측정하는 계측을 넣어, 한 스캔이 도는 데 걸리는 시간을 실시간으로 뽑았다.

(공정하게: Lyra는 DSI 대시보드가 CPU를 함께 쓰고 있어서 이를 끄고, 양쪽 다 “PLC 런타임만” 도는 조건으로 맞춰 측정했다.)

반전이다. CPU 원시 연산은 Lyra가 10% 넘게 빨랐는데, 실제 PLC 스캔은 Pi가 1.7배 빠르다.

왜 뒤집혔을까. 스캔은 단일 계산 루프가 아니라 여러 스레드가 동시에 도는 구조다 — 스캔 스레드, 사용자 제어 로직 스레드, 통신 처리 스레드가 같이 돌아간다. 순수 단일코어 연산에서는 클럭 높은 Lyra가 앞섰지만, 여러 스레드가 얽히는 실제 런타임에서는 코어가 하나 더 많은 Pi(4 vs 3)가 일감을 더 잘 나눠 가진다. CPU 점유율이 Lyra 19% vs Pi 9%로 벌어진 것도 같은 이유다. 3코어는 스레드들이 서로 밀치고, 4코어는 여유가 있다.

그런데 정작 중요한 건 이거다 — 둘 다 스캔이 1밀리초도 안 걸린다. 0.3ms든 0.6ms든, 산업 현장의 제어 주기(보통 수~수십 ms) 관점에서는 둘 다 압도적으로 빠르다. 게다가 실제 응답 지연은 이 스캔 시간이 아니라 CAN·Modbus 같은 외부 통신 대기가 지배한다. 확장보드와 릴레이를 직접 돌려봤을 때 체감 차이가 전혀 없었던 이유다.

정리하면:

• 순수 CPU → Lyra 우위 (클럭)
• 실제 PLC 스캔 → Pi 우위 (코어 수) — 하지만 둘 다 1ms 미만
• 실제 제어 응답 → 차이 없음 (I/O가 지배)

한 그래프로 보면 반전이 선명하다. CPU 세 항목은 Pi 막대가 기준선(Lyra) 위 — 조금씩 느리다. 그런데 맨 오른쪽 PLC 스캔만 Pi 막대가 뚝 떨어진다. “종이 스펙이 좋은 쪽”과 “실제로 빠른 쪽”이 항목마다 갈린다는 게 이 비교의 핵심이다.

결론

품절된 Pi를 대체하러 데려온 Luckfox Lyra Zero W는, 성능에서도 밀리지 않았다. 순수 CPU 연산은 오히려 10% 넘게 빨랐고, 실제 PLC 스캔은 코어 수 덕에 Pi가 앞섰지만 양쪽 다 1밀리초 미만이라 어느 쪽도 산업 제어에 부족하지 않다. 항목마다 이기고 지는 게 갈릴 뿐, “대체품이라 성능을 포기했다”고 할 구석은 없었다.

• 연산 성능이 걱정이었다면 — 안심해도 된다. 클럭 덕에 오히려 낫다.
• 다만 이건 이 특정 벤치마크 기준이다. GPU·NPU·특정 가속기가 필요한 워크로드라면 이야기가 달라진다. 순수 CPU + .NET 제어 로직이라면 Lyra가 충분하고도 남는다.

“대체품이라 성능은 좀 참아야겠지”라고 생각하고 옮겼는데, 재보니 참을 것도 없었다. 재고 문제로 어쩔 수 없이 넘어온 선택이 결과적으로 나쁘지 않았다는 것 — 이게 이번 비교의 결론이다.

테스트 환경 요약 — 양쪽 모두 .NET 8.0.29, 동일 벤치마크 소스, Workstation GC, InvariantGlobalization. Lyra는 linux-arm(32비트) 프레임워크 종속 빌드, Pi는 linux-arm64(64비트) self-contained 빌드로 런타임 버전을 통일했다. 각 항목 2~3회 측정.