3 ms·

You have 1ms pauses easily from simply the OS context-switching away from your program, so as I mentioned, unless you explicitly tune your OS, you have this kin

by kaba0 3y ago

You have 1ms pauses easily from simply the OS context-switching away from your program, so as I mentioned, unless you explicitly tune your OS, you have this kind of pauses, no matter the language, even if it’s hand-written assembly. Regarding the non-normal language: with hard real-time you wouldn’t want to allocate willy-nilly and rust doesn’t yet have generics for allocators (correct me if I’m wrong on this, I am not up-to-date here), so careless usage of the standard lib, or other crates is a no-go. For illustrative purposes, this is the same with C++ and `noexcept`. > Some slippery definitions here I don’t see the slippery part - it is a slope, though. Depending on what’s the latency requirements and to what percentile should it happen, you can use Rust (and other low-level languages) on the lower end (audio processing), some managed languages in the middle (many kind of games are absolutely fine with that - a single drop of frame is more than fine, hence the soft rt), and pretty much any managed language on the high end.

hollerith 3y ago
>You have 1ms pauses easily from simply the OS context-switching It is routine for Rust code to run without an OS (e.g., on microcontrollers).
- kaba0 3y ago
  A subset of Rust. You can’t just write ordinary Rust for microcontrollers.
  - deleted 3y ago
    [deleted]
  - estebank 3y ago
    It depends on what you call "ordinary Rust", I guess. You can use an allocator on embedded, but likely won't want to. There are static types that provide the same APIs as the allocating data structures you'd miss[1]. Granted, you're not gonna be able to take any random crate that isn't designed for such an environment, but that's a different problem, and there's a fledging ecosystem of no_std crates out there. Despite all those caveats, you can still write very high level code in embedded Rust, even async/await state machines![2] 1: https://docs.rust-embedded.org/book/collections/index.html https://docs.rust-embedded.org/book/collections/index.html 2: https://interrupt.memfault.com/blog/embedded-async-rust https://interrupt.memfault.com/blog/embedded-async-rust

by kaba0 3y ago

hollerith 3y ago

>You have 1ms pauses easily from simply the OS context-switching It is routine for Rust code to run without an OS (e.g., on microcontrollers).

kaba0 3y ago
A subset of Rust. You can’t just write ordinary Rust for microcontrollers.
- deleted 3y ago
  [deleted]
- estebank 3y ago
  It depends on what you call "ordinary Rust", I guess. You can use an allocator on embedded, but likely won't want to. There are static types that provide the same APIs as the allocating data structures you'd miss[1]. Granted, you're not gonna be able to take any random crate that isn't designed for such an environment, but that's a different problem, and there's a fledging ecosystem of no_std crates out there. Despite all those caveats, you can still write very high level code in embedded Rust, even async/await state machines![2] 1: https://docs.rust-embedded.org/book/collections/index.html https://docs.rust-embedded.org/book/collections/index.html 2: https://interrupt.memfault.com/blog/embedded-async-rust https://interrupt.memfault.com/blog/embedded-async-rust