That's why I'm interested in proper benchmarks before supporting a release of something with platform-specific code. The CPU extensions are ostensibly for optimizing the code where possible (the Blake3 code has a dynamic dispatch mechanism for checking CPU features at runtime to select the assembler-optimized variants), but if JNI overhead negates the gains there, then I'd agree that sticking to pure Java code here would be optimal.
On Sun, 28 Feb 2021 at 17:18, sebb <seb...@gmail.com> wrote: > > On Sun, 28 Feb 2021 at 20:14, Matt Sicker <boa...@gmail.com> wrote: > > > > I'd also be interested in benchmarking comparisons as I've been > > working on a proof of concept using Blake3 to do similarly (I have a > > pure Java implementation and a JNI version that ultimately invokes the > > reference C implementation, though I've also wondered about linking > > the reference Rust implementation). The potential advantage to linking > > in the native implementations here would be in taking advantage of > > CPU-specific extensions like SSE, AVX, NEON, etc., which aren't > > accessible from the JVM without JNI or other patches to the JDK > > itself. If the overhead turns out to be non-negligible, then we should > > probably keep the native code bindings to commons-crypto while porting > > pure Java implementations to commons-codec. > > Of course the disadvantage is that the code is not portable. > Also each OS version will need separate testing and makes releasing > binaries harder. > This is an issue we have already faced with Crypto. > And there will be versions of Java for which it will not work. > > So unless the is a great performance improvement, I don't think it's > worth the extra overheads. > > > On Sun, 28 Feb 2021 at 09:25, Bernd Eckenfels <e...@zusammenkunft.net> > > wrote: > > > > > > ... and also do benchmarking early, the native interface overhead might > > > be a problem so that pure java (intrinsic) code is much faster > > > > > > > > > -- > > > http://bernd.eckenfels.net > > > ________________________________ > > > Von: Gary Gregory <garydgreg...@gmail.com> > > > Gesendet: Sunday, February 28, 2021 2:45:26 PM > > > An: Commons Developers List <dev@commons.apache.org> > > > Betreff: Re: [crypto] Interest in adding support for cryptographic hash > > > function? > > > > > > That sounds reasonable to me. I think once we see a PR, we'll get a better > > > idea. Start small IMO. > > > > > > Gary > > > > > > > > > On Sat, Feb 27, 2021, 13:51 Alex Remily <alex.rem...@gmail.com> wrote: > > > > > > > I'd be exposing additional elements of the OpenSSL API via additions to > > > > the > > > > commons crypto API. Since I wouldn't be adding any additional > > > > dependencies, I would expect that licensing and portability would remain > > > > unchanged. Would it not? > > > > > > > > Thanks, > > > > > > > > Alex > > > > > > > > On Sat, Feb 27, 2021 at 1:08 PM Gilles Sadowski <gillese...@gmail.com> > > > > wrote: > > > > > > > > > Le sam. 27 févr. 2021 à 19:00, Bernd Eckenfels > > > > > <e...@zusammenkunft.net> a écrit : > > > > > > > > > > > > Hello, > > > > > > > > > > > > I don’t think it’s a Good idea to introduce native dependencies to > > > > > formerly pure Java projects. > > > > > > > > > > +1 > > > > > [I thought that the idea was a (pure) Java implementation.] > > > > > > > > > > > So i think native optimized hash implementations would fit better in > > > > > commons-crypto. So I would say go for it, keep in mind license > > > > > clearance > > > > > and portability. > > > > > > > > > > > > Gruß > > > > > > Bernd > > > > > > > > > > > > > [...] > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
