I have run Daffodil using Graal VM for Java 21. It's slower than regular
Java 21. Not massively, but enough that I set it aside immediately. Don't
ask me the tests I ran tho. I can't recall. This was about a year ago.
I looked into Scala Native a short time back. I was unable to get it to
work for
I'm curious if a non-source-generated solution would work, specifically
Scala Native and Graal? That is, there are non-JVM targets that can be
built from the Scala source, and they can be extremely performant. The
current hotness is the "billion row challenge" (
https://github.com/gunnarmorling/1br
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.
> >
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
> > Sent: Friday,
than C for
> new code and Daffodil should have a Rust backend.
>
> -Original Message-
> From: Mike Beckerle
> 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
re: 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 h
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 wo
