uschindler commented on PR #12311: URL: https://github.com/apache/lucene/pull/12311#issuecomment-1560610819
Hi, > As a potential workaround I tried Uwe's suggestion to look at RAMUsageEstimator code and ran it inside this VM, it works and seems to detect the situation? > > ``` > jshell> final Object vmOption = getVMOptionMethod.invoke(hotSpotBean, "UseAVX"); > vmOption ==> VM option: UseAVX value: 0 origin: DEFAULT (read-only) > ``` We *could* do this, but on the other hand I think this is going to get spaghetti code. Especially as UseAVX is only valid for x86 CPUs, ARM doesn't has this. This is a problem of OpenJDK and we should report this what we have observed: - Very slow performance of the "default/fallback" impl. like 30x slower (do we have exact easurements) - No way to detect if vector code is correctly optimized We should make it clar that we need some way to figure out consistently at runtime if we chose our own code or the vector code based on a simple information like "works/does not work". The PREFFERED constants in Species should always contain correct values, also when Hotspot is not enabled. This means for Integers it should return 32 (plain simple), as this is the maximum vector bit size. It is a bug to return some arbitrary defaults for preferred sizes if AVX is disabled or C2 disabled. About the current Lucene impl: The user has to opt in by passing `--enable-modules jdk.incubator.vector`. If the user is doing this he should be prepared that it might go wrong. We should not do too much detection logic. If somebody figures out it gets slow like hell, they can remove that option. That's all what incubators are about! When this is fixed in later versions (e.g., during preview) we should be able to detect the lane sizes correctly and all works fine. I disagree to work around bugs in incubation features of OpenJDK, sorry. The current hack with the system property would in reality also not be needed, it is mainly there to support people running tests, so I would keep it. Butit is not our responsibility to detect hardware features in Lucene code, it should work out of box. In the release notes with the PR merged we should clearly state that people have to opt in and they should test, and report back if it works well for them. We should clearly say that in some ancient hardware combinations or misconfigured VM environments it may cause havoc to enable it (slowness). So please lets stop here and not implement hardware detection for opt-in only preview images! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
