Mike, I googled "calling rust from java" since Scala is similar to Java. I have only very limited experience with calling native code from Java programs, but I believe the following apply: 1) you have to do some painstaking and careful programming to make the Java Native Interface code and the Rust code compatible so the calls can go through; 2) the performance hit doesn't slow down the calls very much.
Someone wrote up a success story called "Using Rust in-process with Java" here: https://www.vortexa.com/insights/technology/rust-in-process-java/ Someone wrote a library called j4rs to help call Java from Rust and the library also supports the reverse direction from Java to Rust: https://github.com/astonbitecode/j4rs-java-call-rust https://lib.rs/crates/j4rs Incrementally rewriting part of Daffodil in Rust to speed up Daffodil is a more holistic approach than translating a DFDL schema to Rust code to parse and unparse data. A code generator backend supports only a subset of the DFDL specification because it takes a lot of time and work to support the entire specification, while Daffodil can benefit from a speedup on most platforms (except platforms where a Rust compiler isn't available) while continuing to support all DFDL schemas. John -----Original Message----- From: Mike Beckerle <mbecke...@apache.org> Sent: Tuesday, January 16, 2024 5:43 AM To: dev@daffodil.apache.org Subject: EXT: Re: Rust vs. C backend John, what do you (or anyone?) know about interfacing Rust and JVM languages like Java/Scala? A quick search pulled back nothing other than Java JNI and/or sending GPBs back and forth to micro-services. I'm wondering if incrementally rewriting parts of the existing, slow, Scala backend in Rust is feasible, or if this is not a smooth enough pathway. For example, I suspect that Daffodil's lexical analyzer could use a rewrite. It is one of the oldest pieces of code in Daffodil, and was created back when myself and others were really still Scala newbies, and we were just learning the implications for the lexical analyzer design I.e., discovering them the hard way, realizing the design was not sufficiently general, adding more tweaks (which could be suboptimal), etc. We had not yet developed the philosophy that the backend code should be "java like", and not use scala idioms that are less efficient. But if we're rewriting parts of the back-end and the rewrites are intended to be high performance, then it would seem the right language to use is something like Rust. However, this requires that we're able to call it efficiently and that the bridge from scala to that rust code is not so expensive as to eliminate the performance gain. On Fri, Jan 12, 2024, 5:52 PM Interrante, John A (GE Aerospace, US) < john.interra...@ge.com> wrote: > We developed a fork of the C backend that generated VHDL, but I can't > get into the implementation details here. I think the line between > Rust and C is two-fold: how many machine architectures Rust has been > ported to, and how often you need to call C functions from Rust, which > means having to use Rust's Foreign Function Interface. Otherwise, > Rust is better than C for new code and Daffodil should have a Rust backend. > > -----Original Message----- > From: Mike Beckerle <mbecke...@apache.org> > Sent: Friday, January 12, 2024 5:50 AM > To: dev@daffodil.apache.org > Subject: EXT: Re: Rust vs. C backend > > what I meant by "What did you mean by the phrase “basis for generating > VHDL or System Verilog?” > > I suppose I was thinking you had a fork of the C backend that created > Verilog/VHDL, but perhaps the pathway is via the C code output, which > is then translated into Verilog/VHDL? > > In any case we're hearing lots more complaints about performance of > Daffodil's scala back-end (and missing optimizations in the middle phases). > > Generating C code won't work for Cyberian software-based applications > as a memory-safe language is required in these solutions. I will have > to learn more about Rust. We need a memory safe language that lets you > control the data representations far better than Java/Scala and JVM > languages. I am curious where the line is between Rust and C, i.e., > what kinds of things are possible in C that aren't possible in Rust. > > On Thu, Jan 11, 2024 at 5:01 PM Interrante, John A (GE Aerospace, US) > < john.interra...@ge.com> wrote: > > > Hi Mike, > > > > My view is that when the goal is to generate parsers and unparsers > > from fixed format binary data DFDL schemas, compile them to native > > machine code, and execute the machine code on CPUs, Daffodil should > > generate Rust. We would have preferred Rust when we started the C > > code generator work. Rust is memory safe, type safe, etc. – but it > > was not available for our phase 1 target CPU. > > > > Creating a Rust backend makes sense, although we don’t think there > > is a Rust to hardware path – at least none that we are aware of. > > What did you mean by the phrase “basis for generating VHDL or System > > Verilog?” > > > > John > > > > From: Mike Beckerle <mbecke...@apache.org> > > Sent: Thursday, January 11, 2024 5:13 AM > > To: John Interrante <jinterra...@apache.org> > > Cc: dev@daffodil.apache.org > > Subject: EXT: Rust vs. C backend > > > > John, > > > > What's your view of generating Rust vs. Generating C from DFDL? > > > > Those of us working in Cyberia, well, the edict has been issued that > > only memory-safe languages/runtimes are allowed to reduce risk of > > cyber-attacks via things like libc flaws. > > > > Seems to me that Rust is the lowest level language that would be > > acceptable > > > > I believe ultimately, the goal is to generate a useful software > > implementation that does not compromise on performance, and to be a > > basis for generating VHDL or System Verilog. > > > > I imagine you've given this some thought you can share. > > Mike Beckerle > > Apache Daffodil PMC | > > daffodil.apache.org<http://daffodil.apache.org/> > > OGF DFDL Workgroup Co-Chair | > > www.ogf.org/ogf/doku.php/standards/dfdl/dfdl > > <http://www.ogf.org/ogf/doku.php/standards/dfdl/dfdl> > > Owl Cyber Defense | www.owlcyberdefense.com< > > http://www.owlcyberdefense.com/> > > >
