[RFC] Rust API for evl

[RFC] Rust API for evl

[Philippe Gerum]

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

-- 
Philippe.

Re: [RFC] Rust API for evl

[Jan Kiszka]

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. Do you have some
example code somewhere as well?

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux

Re: [RFC] Rust API for evl

[Philippe Gerum]

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.

Re: [RFC] Rust API for evl

[Philippe Gerum]

Philippe Gerum <rpm@xenomai.org> writes:

> Jan Kiszka <jan.kiszka@siemens.com> writes:
>> 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.

The first bits of the revl API have landed at [1]. This work is a
starting point, a tentative implementation of a limited set of features
ATM, which should be considered as RFC material.

[1] https://source.denx.de/Xenomai/xenomai4/revl.git

-- 
Philippe.