임베디드 Rust RTOS vs C RTOS: 실제 성능 비교
Embedded Rust RTOS vs. C RTOS
Tweede golf 블로그에서 Embassy(Rust)와 FreeRTOS(C)를 STM32F446 마이크로컨트롤러에서 비교했습니다. 두 시스템에서 동일한 애플리케이션(버튼 인터럽트, LED 깜빡임, 메시지 큐를 통한 UART 출력)을 구현하고, 인터럽트 지연 시간, 프로그램 크기, RAM 사용량, 프로그래밍 용이성을 측정했습니다. 결과적으로 Rust/Embassy는 인터럽트 지연 시간에서 더 나은 성능을 보였고, 프로그램 크기와 RAM 사용량에서도 우세했습니다. C/FreeRTOS는 전통적인 RTOS 방식으로, 코드 작성이 더 간단하지만 성능과 메모리 효율성에서 뒤처졌습니다.
인터럽트 지연 시간 측정에서 Embassy는 FreeRTOS보다 약 2배 빠른 응답을 보였으며, 이는 async 실행기가 인터럽트 컨텍스트에서 직접 waker를 호출할 수 있기 때문입니다.
HN 토론
24- Animats
그건 CPU 부하가 매우 낮은 상황에서의 얘기입니다. 그래서 선점 없는 비동기 방식이 작동할 수 있는 거죠. 상당한 계산이 진행 중이라면 그렇게 잘 작동하지 않을 겁니다.
오실로스코프로 측정해볼 만한 유용한 수치는 최악의 인터럽트 지연 시간입니다. 하드 실시간 제약이 있다면 이것이 중요합니다. 그들은 표준 편차를 측정했지만 최악의 경우는 측정하지 않았습니다. 일반적인 테스트 설정은 입력 신호(보통 구형파)가 입력 핀으로 들어가고, 인터럽트가 방지되지 않았다면 인터럽트가 발생하고, 태스크가 시작되어 출력 핀을 켜는 방식입니다. 오실로스코프에서 입력에서 출력까지의 지연을 관찰하고 이상치를 찾아보는 겁니다.
완전히 실행-완료 방식으로만 돌아간다면, 이상치는 가장 긴 계산 태스크에 의해 결정됩니다. 계산 태스크가 있다면 이것이 문제가 됩니다.
역사적으로 QNX가 빛을 발하는 부분이 바로 여기입니다. 인터럽트가 처리되고 스레드를 스케줄링합니다. 인터럽트 레벨에서 일어나는 일은 대략 스레드 활성화뿐입니다. 그 스레드가 출력 핀을 켭니다. 스케줄링 이상치를 오실로스코프에서 볼 수 있습니다. 최상의 지연 시간은 인터럽트 레벨에서 작업을 수행하는 것보다 높지만, 최악의 지연 시간은 낮은 우선순위 스레드가 계산에 바빠도 일정합니다.
이것이 실시간과 '준실시간' 스케줄링의 차이입니다.
- CupricTea
제목이 바뀌어야 합니다. 비동기 Rust != RTOS입니다. RTOS는 선점형 멀티스레딩인 반면, 비동기는 yield 지점에서 협력적으로 수행됩니다.
아마도 '임베디드 비동기 Rust vs. C RTOS'가 더 적절하겠네요.
- joshchngs
이 기사는 이제 거의 5년이 되었는데, 임베디드 Rust 용어로는 꽤 오래된 것입니다. 전반적인 환경이 그렇게 많이 바뀌지는 않았다고 생각하지만, 세부 사항에 의존하기에는 주의해야 할 것 같습니다.