On Fri, 15 Mar 2024 13:58:05 GMT, Hamlin Li <m...@openjdk.org> wrote:
>> Hi, >> Can you help to review this patch? >> Thanks >> >> This is a continuation of work based on [1] by @XiaohongGong, most work was >> done in that pr. In this new pr, just rebased the code in [1], then added >> some minor changes (renaming of calling method, add libsleef as extra lib in >> CI cross-build on aarch64 in github workflow); I aslo tested the combination >> of following scenarios: >> * at build time >> * with/without sleef >> * with/without sve support >> * at runtime >> * with/without sleef >> * with/without sve support >> >> [1] https://github.com/openjdk/jdk/pull/16234 >> >> ## Regression Test >> * test/jdk/jdk/incubator/vector/ >> * test/hotspot/jtreg/compiler/vectorapi/ >> >> ## Performance Test >> Previously, @XiaohongGong has shared the data: >> https://github.com/openjdk/jdk/pull/16234#issuecomment-1767727028 > > Hamlin Li has updated the pull request incrementally with one additional > commit since the last revision: > > fix jni includes > If there was some kind of plan, with evidence of the intention to do > something to get this valuable tech into people's hands in a form they can > use, sure. But as you can tell, I think this may rot because no one will be > able use it. If SLEEF were included in the JDK it'd be fine. if SLEEF were a > common Linux library it'd be fine. > > The problem I see is that J. Random Java User has no way to know if SLEEF is > making their program faster without running benchmarks. They'll put SLEEF > somewhere and hope that Java uses it. Please kindly correct me if I misunderstood your points. Seems the safest solution to address your above concerns is to integrate the sleef source into jdk? Lack of sleef at either build time or runtime will make the user's code fall back to java implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/18294#issuecomment-2007692746
