임베디드 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 토론
56- Animats
이것은 매우 가벼운 CPU 부하에서의 테스트입니다. 따라서 선점(preemption)이 없는 비동기 방식도 작동할 수 있습니다. 상당한 계산이 진행되고 있다면, 그렇게 잘 작동하지 않을 것입니다.
오실로스코프에서 측정할 때 유용한 값은 최악의 인터럽트 지연 시간입니다. 하드 실시간 제약 조건이 있다면 이것이 중요합니다. 그들은 표준 편차를 측정했지만 최악의 경우는 측정하지 않았습니다. 일반적인 테스트 설정은 입력 신호(일반적으로 구형파)가 입력 핀으로 들어가고, 인터럽트가 금지되지 않았다면 인터럽트가 발생하고, 태스크가 시작되어 출력 핀을 켜는 것입니다. 오실로스코프에서 입력에서 출력까지의 지연을 관찰하고 이상치를 찾습니다.
전적으로 실행 완료(run to completion) 방식으로 실행한다면, 이상치는 가장 긴 계산 태스크에 의해 결정됩니다. 계산 태스크가 있다면 이것은 문제입니다.
역사적으로 QNX가 빛을 발하는 부분이 바로 여기입니다. 인터럽트가 처리되고 스레드를 스케줄합니다. 인터럽트 레벨에서 일어나는 일은 대략 스레드 활성화뿐입니다. 스레드가 출력 핀을 켭니다. 오실로스코프에서 스케줄링 이상치를 볼 수 있습니다. 최상의 경우 지연 시간은 인터럽트 레벨에서 작업을 수행하는 것보다 높지만, 최악의 경우 지연 시간은 낮은 우선순위 스레드가 계산에 바인딩되어 있어도 일정합니다.
이것이 실시간과 "준실시간" 스케줄링의 차이입니다.
- CupricTea
제목이 바뀌어야 합니다. 비동기 Rust는 RTOS가 아닙니다. RTOS는 선점형 멀티스레딩인 반면, 비동기는 양보 지점(yield point)에서 협력적으로 수행됩니다.
아마도 "임베디드 비동기 Rust vs. C RTOS"가 더 적절할 것입니다.
- bfrog
그런데 요즘은 Zephyr만 빼고는 아무것도 중요해 보이지 않습니다. Zephyr는 거의 Linux처럼 빠른 속도로 확산되고 있습니다. 이제 지구상의 모든 공급업체가 이를 지원하며, 이들은 돈을 따라갑니다.
Rust는 일부 지역에서 약간의 지원을 받고 있는 것 같습니다.
AI 시대에는 언어가 더 이상 중요하지 않다고 생각합니다.
- joshchngs
이 기사는 이제 거의 5년이 되었으며, 임베디드 Rust 용어로는 상당히 오래된 것입니다. 전반적인 환경은 크게 변하지 않았다고 생각하지만, 세부 사항에 의존하는 것은 주의해야 합니다.
- aw1621107
(2022)