* Re: [RFC] Rust API for evl
2022-06-01 5:50 ` Jan Kiszka
@ 2022-06-01 8:56 ` Philippe Gerum
2022-06-05 14:49 ` Philippe Gerum
0 siblings, 1 reply; 4+ messages in thread
From: Philippe Gerum @ 2022-06-01 8:56 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai
Jan Kiszka <jan.kiszka@siemens.com> writes:
> On 31.05.22 15:37, Philippe Gerum via Xenomai wrote:
>>
>> I've been getting my feet wet with Rust for a few weeks now, assessing
>> the real-time latency figures I could get from an existing (C++)
>> application once fully rewritten in this language. It turned out that
>> performance was on par with the original implementation with memory
>> safety on top, among other upsides (like having quite some fun coding in
>> Rust in the first place).
>>
>> Having Rust as a Tier 1 language for Xenomai4/evl along with the
>> existing C interface definitely makes sense to me. The goal would be to
>> have a 'revl' interface providing the EVL services the idiomatic Rust
>> way, available as a crate on top of the FFI bindings to libevl which
>> have just landed [1].
>>
>> Whether you are a Rustacean or not, if you are willing to discuss and
>> help with this, let me know.
>>
>> [1] https://source.denx.de/Xenomai/xenomai4/evl-sys.git
>>
>
> I think this is a very interesting experiment, and I'm excited to see
> that there are apparently no RT traps in the runtime.
There are in the std:: library, but since the original C++ application
was written from the ground up with dual kernel support in mind, this
was fairly easy to locate the time critical algorithms, designing a Rust
implementation for them.
A few takeaways so far from switching this non-trivial C++ real-time
application to Rust:
- this is not about 'porting' in the usual sense, this is about
rewriting with different idioms. As far as I'm concerned, leaving
behind the OOP playbook helped a lot. Not that we cannot or should not
use constructs which are reminiscent of OOP with Rust, but its trait
system and some influence from functional programming give a lot more
than this. Besides, monomorphization is our friend performance-wise,
so using 'trait objects' all over the map may not be the best approach
- in fact, this might even go against expressiveness in some cases
IMHO.
- since we are used to tread carefully between non-rt and rt contexts in
our ecosystem, the std:: library is ok in the processing
preparation/exit phase as usual. In addition, Rust tends to allocate
as much as possible from the stack unlike the STL (not even mentioning
Boost): this shows when comparing the assembly output for some code
involving a plain vector iterator (obviously NOT with folding or any
accumulator-based construct though). IOW, the precautions we take with
C++ also apply in a Rust context, but shenanigans were much fewer in
the Rust case AFAIC, and the audit process was much easier
source-wise, navigating the standard crate implementation. Typically,
I did not stumble on unexpected 'hidden locks' even in the standard
library (std::io has some, but this is hardly unexpected there, and
not an issue anyway). Maybe I've been lucky, but Rust tends to favor
explicit over implicit in general, so there is hope.
- for the time-critical part Rust-wise, we have the 'heapless' crate
around which gives several off-the-shelf data structures which are
guaranteed not to rely on - well - heap-based allocation. Since the
application involves zero-copy messaging at its heart, the 'flume'
crate was used to exchange message envelopes locklessly with quite
good performances. The most striking aspect of all this comes when you
realize that you did not implement any explicit refcounting of these
messages but delegated it to the language via the Arc construct, and
this Just Works (TM): no leakage, no trashing, no brainer. Of course,
there may be hidden atomic operations all over the map which do not
come for free, but still, this did not cause any significant
performance degradation on armv7 compared to the C++ version where all
of this has been handcrafted.
- we can mix the Rust std and no_std environment, both coupled to libc
in a single application. The Rust EVL interface should probably go for
no_std with some runtime guard on the global allocator, so that any
jack-in-the-box dynamic allocation is either impossible by design, or
easily caught in this API.
- any language compiler should have consideration for its users like
rustc does. Obviously, rustc has to be picky by design to honor the
promise of memory safety including safe concurrency, but this always
goes with helpful error messages, smart hints. Seriously, the work
these folks did there to help newcomers is simply fascinating.
- I found using a Rust cross-toolchain targeting armv7 from a
Yocto-generated SDK a bit bumpy in a few occasions, particularly if
bindgen is involved the build process. Likewise, 'heapless' may need
some fixup in its build script. This said, meta-rust which produces
the toolchain was merged into the OE core only fairly recently (Yocto
honister was the first Yocto release to have it IIRC), armv7 is still
Tier 2 Rust-wise, so this will improve over time. In general,
targeting x86 which is Tier 1 is already a no-brainer though.
> Do you have some
> example code somewhere as well?
>
Not yet. I have started working on the 'revl' crate implementing the EVL
interface for the Rust language though. There is not much of it yet
(clock services based on the 'embedded_time' crate, little
thread-related support, sema4 and basic mutex), but I'll push what is
there in a couple of days to a public repo.
--
Philippe.
^ permalink raw reply [flat|nested] 4+ messages in thread