RFR: JDK-8315278: Patch 'print-targets' target to print targets separated by new line
Currently 'make print-targets' print all targets on the same line separated by space. That isn't only terribly to read but hard to "grep". Printing each target on a separate line seems much better. Tested on: Linux x64, Windows x64 and MacOS AArch64 - Commit messages: - Print targets in separate lines Changes: https://git.openjdk.org/jdk/pull/15479/files Webrev: https://webrevs.openjdk.org/?repo=jdk=15479=00 Issue: https://bugs.openjdk.org/browse/JDK-8315278 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/15479.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15479/head:pull/15479 PR: https://git.openjdk.org/jdk/pull/15479
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and >> upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the >> performance data below. >> >> >> **Arrays.sort performance data using JMH benchmarks for arrays with random >> data** >> >> |Arrays.sort benchmark | Array Size | Baseline >> (us/op)| AVX512 Sort (us/op) | Speedup | >> |--- | --- | --- | --- | --- >> | >> |ArraysSort.doubleSort | 10 | 0.034 | 0.035 >> | 1.0 | >> |ArraysSort.doubleSort | 25 | 0.116 | 0.089 >> | 1.3 | >> |ArraysSort.doubleSort | 50 | 0.282 | 0.291 >> | 1.0 | >> |ArraysSort.doubleSort | 75 | 0.474 | 0.358 >> | 1.3 | >> |ArraysSort.doubleSort | 100 | 0.654 | 0.623 >> | 1.0 | >> |ArraysSort.doubleSort | 1000| 9.274 | 6.331 >> | 1.5 | >> |ArraysSort.doubleSort | 1 | 323.339 | 71.228 >> | **4.5** | >> |ArraysSort.doubleSort | 10 | 4471.871| >> 1002.748| **4.5** | >> |ArraysSort.doubleSort | 100 | 51660.742 | >> 12921.295 | **4.0** | >> |ArraysSort.floatSort| 10 | 0.045 | 0.046 >> | 1.0 | >> |ArraysSort.floatSort| 25 | 0.103 | 0.084 >> | 1.2 | >> |ArraysSort.floatSort| 50 | 0.285 | 0.33 >> | 0.9 | >> |ArraysSort.floatSort| 75 | 0.492 | 0.346 >> | 1.4 | >> |ArraysSort.floatSort| 100 | 0.597 | 0.326 >> | 1.8 | >> |ArraysSort.floatSort| 1000| 9.811 | 5.294 >> | 1.9 | >> |ArraysSort.floatSort| 1 | 323.955 | 50.547 >> | **6.4** | >> |ArraysSort.floatSort| 10 | 4326.38 | 731.152 >> | **5.9** | >> |ArraysSort.floatSort| 100 | 52413.88| >> 8409.193| **6.2** | >> |ArraysSort.intSort | 10 | 0.033 | 0.033 >> | 1.0 | >> |ArraysSort.intSort | 25 | 0.086 | 0.051 >> | 1.7 | >> |ArraysSort.intSort | 50 | 0.236 | 0.151 >> | 1.6 | >> |ArraysSort.intSort | 75 | 0.416 | 0.332 >> | 1.3 | >> |ArraysSort.intSort | 100 | 0.63| 0.521 >> | 1.2 | >> |ArraysSort.intSort | 1000| 10.518 | 4.698 >> | 2.2 | >> |ArraysSort.intSort | 1 | 309.659 | 42.518 >> | **7.3** | >> |ArraysSort.intSort | 10 | 4130.917| >> 573.956 | **7.2** | >> |ArraysSort.intSort | 100 | 49876.307 | >> 6712.812| **7.4** | >> |ArraysSort.longSort | 10 | 0.036 | 0.037 >> | 1.0 | >> |ArraysSort.longSort | 25 | 0.094 | 0.08 >> | 1.2 | >> |ArraysSort.longSort | 50 | 0.218 | 0.227 >> | 1.0 | >> |ArraysSort.longSort | 75 | 0.466 | 0.402 >> | 1.2 | >> |ArraysSort.longSort | 100 | 0.76| 0.58 >> | 1.3 | >> |ArraysSort.longSort | 1000| 10.449 | 6 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > Clean up parameters passed to arrayPartition; update the check to load > library Good. Thank you. - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698380569
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Tue, 29 Aug 2023 20:44:32 GMT, Srinivas Vamsi Parasa wrote: > > > Hi, We already have correctness tests. See > > > test/jdk/java/util/Arrays/Sorting.java > > > The latest version you can find in PR > > > https://github.com/openjdk/jdk/pull/13568/files > > > > > > Does test/jdk/java/util/Arrays/Sorting.java trigger usage of this intrinsic > > without additional flags? @vamsi-parasa can you check? > > Sure Vladimir (@vnkozlov). Will check if > test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without > additional flags and let you know. Hi Vladimir, Just verified that the test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags as shown in the output snapshot below:  - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698322922
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Tue, 29 Aug 2023 20:36:04 GMT, Vladimir Kozlov wrote: > > Hi, We already have correctness tests. See > > test/jdk/java/util/Arrays/Sorting.java > > The latest version you can find in PR > > https://github.com/openjdk/jdk/pull/13568/files > > Does test/jdk/java/util/Arrays/Sorting.java trigger usage of this intrinsic > without additional flags? @vamsi-parasa can you check? Sure Vladimir (@vnkozlov). Will check if test/jdk/java/util/Arrays/Sorting.java is triggering the intrinsic without additional flags and let you know. - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698103318
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and >> upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the >> performance data below. >> >> >> **Arrays.sort performance data using JMH benchmarks for arrays with random >> data** >> >> |Arrays.sort benchmark | Array Size | Baseline >> (us/op)| AVX512 Sort (us/op) | Speedup | >> |--- | --- | --- | --- | --- >> | >> |ArraysSort.doubleSort | 10 | 0.034 | 0.035 >> | 1.0 | >> |ArraysSort.doubleSort | 25 | 0.116 | 0.089 >> | 1.3 | >> |ArraysSort.doubleSort | 50 | 0.282 | 0.291 >> | 1.0 | >> |ArraysSort.doubleSort | 75 | 0.474 | 0.358 >> | 1.3 | >> |ArraysSort.doubleSort | 100 | 0.654 | 0.623 >> | 1.0 | >> |ArraysSort.doubleSort | 1000| 9.274 | 6.331 >> | 1.5 | >> |ArraysSort.doubleSort | 1 | 323.339 | 71.228 >> | **4.5** | >> |ArraysSort.doubleSort | 10 | 4471.871| >> 1002.748| **4.5** | >> |ArraysSort.doubleSort | 100 | 51660.742 | >> 12921.295 | **4.0** | >> |ArraysSort.floatSort| 10 | 0.045 | 0.046 >> | 1.0 | >> |ArraysSort.floatSort| 25 | 0.103 | 0.084 >> | 1.2 | >> |ArraysSort.floatSort| 50 | 0.285 | 0.33 >> | 0.9 | >> |ArraysSort.floatSort| 75 | 0.492 | 0.346 >> | 1.4 | >> |ArraysSort.floatSort| 100 | 0.597 | 0.326 >> | 1.8 | >> |ArraysSort.floatSort| 1000| 9.811 | 5.294 >> | 1.9 | >> |ArraysSort.floatSort| 1 | 323.955 | 50.547 >> | **6.4** | >> |ArraysSort.floatSort| 10 | 4326.38 | 731.152 >> | **5.9** | >> |ArraysSort.floatSort| 100 | 52413.88| >> 8409.193| **6.2** | >> |ArraysSort.intSort | 10 | 0.033 | 0.033 >> | 1.0 | >> |ArraysSort.intSort | 25 | 0.086 | 0.051 >> | 1.7 | >> |ArraysSort.intSort | 50 | 0.236 | 0.151 >> | 1.6 | >> |ArraysSort.intSort | 75 | 0.416 | 0.332 >> | 1.3 | >> |ArraysSort.intSort | 100 | 0.63| 0.521 >> | 1.2 | >> |ArraysSort.intSort | 1000| 10.518 | 4.698 >> | 2.2 | >> |ArraysSort.intSort | 1 | 309.659 | 42.518 >> | **7.3** | >> |ArraysSort.intSort | 10 | 4130.917| >> 573.956 | **7.2** | >> |ArraysSort.intSort | 100 | 49876.307 | >> 6712.812| **7.4** | >> |ArraysSort.longSort | 10 | 0.036 | 0.037 >> | 1.0 | >> |ArraysSort.longSort | 25 | 0.094 | 0.08 >> | 1.2 | >> |ArraysSort.longSort | 50 | 0.218 | 0.227 >> | 1.0 | >> |ArraysSort.longSort | 75 | 0.466 | 0.402 >> | 1.2 | >> |ArraysSort.longSort | 100 | 0.76| 0.58 >> | 1.3 | >> |ArraysSort.longSort | 1000| 10.449 | 6 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > Clean up parameters passed to arrayPartition; update the check to load > library I looked on my testing log and I see that this test was run on machines which do not have avx512. I am re-running jdk/util tests with -Xcomp flag on avx512 machines. My testing with -Xcomp flag on avx512 machines passed. - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698106526 PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698272873
Re: RFR: 8303427: Fixpath confused if unix root contains "/jdk"
On Tue, 29 Aug 2023 04:11:24 GMT, Julian Waters wrote: > The GitHub Actions failures look terrifying, but all of them are just a > failing JTReg download for some reason (Not related to the change). Will > recompile with this change and report back as soon as I can I hit rerun and it seems have worked > Works normally on both master and the experimental JDK-8288293 branch Thank you for testing! I'm still running through more scenarios. - PR Comment: https://git.openjdk.org/jdk/pull/15461#issuecomment-1698220159
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Tue, 29 Aug 2023 20:36:04 GMT, Vladimir Kozlov wrote: > Hi, We already have correctness tests. See > test/jdk/java/util/Arrays/Sorting.java > > The latest version you can find in PR > https://github.com/openjdk/jdk/pull/13568/files Hello Vladimir (@iaroslavski), Thank you for providing the link to the correctness tests! Thanks, Vamsi - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698101345
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Tue, 29 Aug 2023 19:32:44 GMT, iaroslavski wrote: > Hi, We already have correctness tests. See > test/jdk/java/util/Arrays/Sorting.java > > The latest version you can find in PR > https://github.com/openjdk/jdk/pull/13568/files Does test/jdk/java/util/Arrays/Sorting.java trigger usage of this intrinsic without additional flags? @vamsi-parasa can you check? - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698092741
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v29]
On Tue, 29 Aug 2023 17:32:26 GMT, Srinivas Vamsi Parasa
wrote:
>>> The reason this PR is focused on Linux is because the AVX512 sort and
>>> partitioning routines are based on Intel’s x86-simd-library
>>> (https://github.com/intel/x86-simd-sort) which was originally developed
>>> with GCC as the target compiler. Thus, this PR has restricted itself to
>>> Linux as the code was tested using GCC/Linux platforms. Additionally, the
>>> x86_64 library is compiled for AVX512 using file specific compilation
>>> pragmas (`#pragma GCC target("avx512dq", "avx512f")`). This feature is
>>> absent for Windows/MSVC++ compiler.”
>>
>> That is why I am questioning this approach to have additional separate C++
>> code library - too much dependencies on other tools.
>>
>> As I suggested before try to disassemble this library and use assembler code
>> in VM new stubs. You can create specialized
>> stubGenerator_x86_64_array_sort.cpp file for it. Then you don't need to
>> depend on C++ compiler or OS.
>
> The shared library approach is being followed currently as an initial
> implementation to demonstrate the value of AVX512 sorting. This will be
> followed up in future with support for Windows as well.
> If it is ok with you, the shared library approach could be pursued for now to
> be later replaced with specialized assembly stubs (which are agnostic to OS
> and compiler) when AVX512 sort is enabled for Windows. Please let us know.
I am okay with such incremental approach. Please, file RFE to replace library
with stubs in a future (it could be still separate library but with assembler
code).
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309316767
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Tue, 29 Aug 2023 19:28:17 GMT, Alan Bateman wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Clean up parameters passed to arrayPartition; update the check to load >> library > > The changes to DualPivotQuicksort will need detailed review to ensure that > this is understandable and maintainable, there is a lot here to study. > > The addition of libx86_64 and having the stub generation call out to this > library also needs discussion to make sure there is an agreement on how this > would be integrated. @AlanBateman If it helps, the changes made by @vamsi-parasa to DualPivotQuickSort.java don't change the logic as written in Java. They only carve out the functionality into separate Java methods retaining the meaning exactly as before. These Java methods are then optimized through a stub. - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698079501
Re: building individual test issue
Thank you Vladimir, but I'm 100percent positive that patches are applied, i could add my build log but it is quite lengthy , the extract is: I: Running env PATH=/usr/sbin:/usr/bin:/sbin:/bin dpkg-buildpackage -rfakeroot -us -uc -uc -us dpkg-buildpackage: info: source package openjdk-lts dpkg-buildpackage: info: source version 11.0.19+7~us1-0ubuntu1~18.04.1.1692386031.126726.1 dpkg-buildpackage: info: source distribution bionic-security dpkg-buildpackage: info: source changed by Vladimir Petko < vladimir.pe...@canonical.com> dpkg-source --before-build jdk11u-jdk-11.0.19-7 dpkg-buildpackage: info: host architecture amd64 dpkg-source: info: applying system-pcsclite.diff dpkg-source: info: applying hotspot-mips-align.diff dpkg-source: info: applying icc_loading_with_symlink.diff dpkg-source: info: applying icedtea-override-redirect-compiz.diff dpkg-source: info: applying libpcsclite-dlopen.diff dpkg-source: info: applying jexec.diff dpkg-source: info: applying default-jvm-cfg.diff dpkg-source: info: applying adlc-parser.diff dpkg-source: info: applying multiple-pkcs11-library-init.diff dpkg-source: info: applying s390x-thread-stack-size.diff dpkg-source: info: applying s390x-opt.diff dpkg-source: info: applying jdk-getAccessibleValue.diff dpkg-source: info: applying jtreg-location.diff dpkg-source: info: applying jdk-i18n-pt_BR.diff dpkg-source: info: applying disable-doclint-by-default.diff dpkg-source: info: applying 8199220.diff dpkg-source: info: applying machine-flag.diff dpkg-source: info: applying zero-x32.diff dpkg-source: info: applying hotspot-disable-exec-shield-workaround.diff dpkg-source: info: applying atk-wrapper-security.diff dpkg-source: info: applying dnd-files.diff dpkg-source: info: applying hotspot-libpath.diff dpkg-source: info: applying reproducible-properties-timestamp.diff dpkg-source: info: applying reproducible-javadoc-timestamp.diff dpkg-source: info: applying Don-t-optimize-fdlibm-fork-for-Zero-on-linux-sparc-Z.patch dpkg-source: info: applying keep-gtk2-as-default.patch dpkg-source: info: applying riscv64.diff dpkg-source: info: applying reproducible-character-data.diff dpkg-source: info: applying reproducible-module-info.diff dpkg-source: info: applying reproducible-copyright-headers.diff dpkg-source: info: applying reproducible-build-user.diff dpkg-source: info: applying reproducible-build-jmod.diff dpkg-source: info: applying hotspot-test-fix-npe-on-missing-file.patch dpkg-source: info: applying disable-thumb-assertion.patch dpkg-source: info: applying update-assertion-for-armhf.patch dpkg-source: info: applying log-generated-classes-test.patch dpkg-source: info: applying update-permission-test.patch dpkg-source: info: applying ldap-timeout-test-use-ip.patch dpkg-source: info: applying test-use-ip-address.patch dpkg-source: info: applying exclude-broken-tests.patch debian/rules clean dh_testdir dh_testroot dh_prep I'm building with "debuild -uc -us " maybe it is not enough? On Tue, Aug 29, 2023 at 11:04 PM Vladimir Petko < vladimir.pe...@canonical.com> wrote: > Hi, > > Yes, patches from debian/patches. They can be applied with quilt[1] > and only patches listed in series are needed. > > Best Regards, > Vladimir. > > [1] https://linux.die.net/man/1/quilt > > On Wed, Aug 30, 2023 at 1:19 AM Mykhaylo Lodygin > wrote: > > > > Hello Vladimir, thank you for your attention, > > did you mean set of patches located in debian/patches ? those are > patched (all in the series file) or some other? > > Mykhaylo > > > > On Mon, Aug 28, 2023 at 11:11 PM Vladimir Petko < > vladimir.pe...@canonical.com> wrote: > >> > >> Hi, > >> > >> I believe this was due to building OpenJDK from Debian original > >> tarball that does not contain bundled libraries. Building from it > >> requires applying Debian patches via `quilt push -a` and using > >> configure arguments from `debian/rules`. > >> > >> Best Regards, > >> Vladimir. > >> > >> On Tue, Aug 29, 2023 at 1:02 AM David Holmes > wrote: > >> > > >> > On 28/08/2023 9:54 pm, Mykhaylo Lodygin wrote: > >> > > Hello colleagues, > >> > > I've build JDK locally successfully, but got several tests "FAILED". > >> > > >> > What did you build? images? what about test-images? > >> > > >> > > Tried to run one of the failing test separately with "make test > >> > > TEST="". > >> > > Were unable to do so due to build error - the compiler was > unfamiliar to > >> > > include path to winscard.h, fixed with configuration option: > >> > > bash configure --with-extra-cflags="-I/usr/include/PCSC" > >> > > >> > What test(s), on what platform? > >> > > >> > > next error was incapability of linker to link with libjpeg - fixed > with > >> > > adding --with-libjpeg=system to configure. > >> > > the issue was solved, but a new one was added with missing libgif. > >> > > I was curious and tried a test that "Passed", thinking that > "failure" > >> > > could had happen due to inability to build the test. Tried > >> > > sun/util/calendar/zi/Beyond2037.java but got a
Re: building individual test issue
Hi, Yes, patches from debian/patches. They can be applied with quilt[1] and only patches listed in series are needed. Best Regards, Vladimir. [1] https://linux.die.net/man/1/quilt On Wed, Aug 30, 2023 at 1:19 AM Mykhaylo Lodygin wrote: > > Hello Vladimir, thank you for your attention, > did you mean set of patches located in debian/patches ? those are patched > (all in the series file) or some other? > Mykhaylo > > On Mon, Aug 28, 2023 at 11:11 PM Vladimir Petko > wrote: >> >> Hi, >> >> I believe this was due to building OpenJDK from Debian original >> tarball that does not contain bundled libraries. Building from it >> requires applying Debian patches via `quilt push -a` and using >> configure arguments from `debian/rules`. >> >> Best Regards, >> Vladimir. >> >> On Tue, Aug 29, 2023 at 1:02 AM David Holmes wrote: >> > >> > On 28/08/2023 9:54 pm, Mykhaylo Lodygin wrote: >> > > Hello colleagues, >> > > I've build JDK locally successfully, but got several tests "FAILED". >> > >> > What did you build? images? what about test-images? >> > >> > > Tried to run one of the failing test separately with "make test >> > > TEST="". >> > > Were unable to do so due to build error - the compiler was unfamiliar to >> > > include path to winscard.h, fixed with configuration option: >> > > bash configure --with-extra-cflags="-I/usr/include/PCSC" >> > >> > What test(s), on what platform? >> > >> > > next error was incapability of linker to link with libjpeg - fixed with >> > > adding --with-libjpeg=system to configure. >> > > the issue was solved, but a new one was added with missing libgif. >> > > I was curious and tried a test that "Passed", thinking that "failure" >> > > could had happen due to inability to build the test. Tried >> > > sun/util/calendar/zi/Beyond2037.java but got a very similar error of >> > > inability to link with liblcms2-2. >> > > I'm flabbergasted, hence my questions are: does "make test" target is >> > > expected to rebuild JDK's code? does my approach of adding options to >> > > configure script is proper one? How come a test could be "Passed" while >> > > running it separately results in inability to build the test? >> > >> > As Erik indicated we need more information/details. >> > >> > Cheers, >> > David >> > >> > >> > > Thank you. >> > > Mykhaylo Lodygin
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Tue, 29 Aug 2023 16:57:11 GMT, Srinivas Vamsi Parasa wrote: > > My testing passed. But I am not sure correctness of code is fully tested. > > For now we have only JMH benchmark for this new code. Do we have JDK test > > which can check correctness of this code? > > Hi Vladimir, will add the JDK tests to check for correctness and let you know Hi, We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698014609
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and >> upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the >> performance data below. >> >> >> **Arrays.sort performance data using JMH benchmarks for arrays with random >> data** >> >> |Arrays.sort benchmark | Array Size | Baseline >> (us/op)| AVX512 Sort (us/op) | Speedup | >> |--- | --- | --- | --- | --- >> | >> |ArraysSort.doubleSort | 10 | 0.034 | 0.035 >> | 1.0 | >> |ArraysSort.doubleSort | 25 | 0.116 | 0.089 >> | 1.3 | >> |ArraysSort.doubleSort | 50 | 0.282 | 0.291 >> | 1.0 | >> |ArraysSort.doubleSort | 75 | 0.474 | 0.358 >> | 1.3 | >> |ArraysSort.doubleSort | 100 | 0.654 | 0.623 >> | 1.0 | >> |ArraysSort.doubleSort | 1000| 9.274 | 6.331 >> | 1.5 | >> |ArraysSort.doubleSort | 1 | 323.339 | 71.228 >> | **4.5** | >> |ArraysSort.doubleSort | 10 | 4471.871| >> 1002.748| **4.5** | >> |ArraysSort.doubleSort | 100 | 51660.742 | >> 12921.295 | **4.0** | >> |ArraysSort.floatSort| 10 | 0.045 | 0.046 >> | 1.0 | >> |ArraysSort.floatSort| 25 | 0.103 | 0.084 >> | 1.2 | >> |ArraysSort.floatSort| 50 | 0.285 | 0.33 >> | 0.9 | >> |ArraysSort.floatSort| 75 | 0.492 | 0.346 >> | 1.4 | >> |ArraysSort.floatSort| 100 | 0.597 | 0.326 >> | 1.8 | >> |ArraysSort.floatSort| 1000| 9.811 | 5.294 >> | 1.9 | >> |ArraysSort.floatSort| 1 | 323.955 | 50.547 >> | **6.4** | >> |ArraysSort.floatSort| 10 | 4326.38 | 731.152 >> | **5.9** | >> |ArraysSort.floatSort| 100 | 52413.88| >> 8409.193| **6.2** | >> |ArraysSort.intSort | 10 | 0.033 | 0.033 >> | 1.0 | >> |ArraysSort.intSort | 25 | 0.086 | 0.051 >> | 1.7 | >> |ArraysSort.intSort | 50 | 0.236 | 0.151 >> | 1.6 | >> |ArraysSort.intSort | 75 | 0.416 | 0.332 >> | 1.3 | >> |ArraysSort.intSort | 100 | 0.63| 0.521 >> | 1.2 | >> |ArraysSort.intSort | 1000| 10.518 | 4.698 >> | 2.2 | >> |ArraysSort.intSort | 1 | 309.659 | 42.518 >> | **7.3** | >> |ArraysSort.intSort | 10 | 4130.917| >> 573.956 | **7.2** | >> |ArraysSort.intSort | 100 | 49876.307 | >> 6712.812| **7.4** | >> |ArraysSort.longSort | 10 | 0.036 | 0.037 >> | 1.0 | >> |ArraysSort.longSort | 25 | 0.094 | 0.08 >> | 1.2 | >> |ArraysSort.longSort | 50 | 0.218 | 0.227 >> | 1.0 | >> |ArraysSort.longSort | 75 | 0.466 | 0.402 >> | 1.2 | >> |ArraysSort.longSort | 100 | 0.76| 0.58 >> | 1.3 | >> |ArraysSort.longSort | 1000| 10.449 | 6 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > Clean up parameters passed to arrayPartition; update the check to load > library Hi, We already have correctness tests. See test/jdk/java/util/Arrays/Sorting.java The latest version you can find in PR https://github.com/openjdk/jdk/pull/13568/files - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698016905
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and >> upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the >> performance data below. >> >> >> **Arrays.sort performance data using JMH benchmarks for arrays with random >> data** >> >> |Arrays.sort benchmark | Array Size | Baseline >> (us/op)| AVX512 Sort (us/op) | Speedup | >> |--- | --- | --- | --- | --- >> | >> |ArraysSort.doubleSort | 10 | 0.034 | 0.035 >> | 1.0 | >> |ArraysSort.doubleSort | 25 | 0.116 | 0.089 >> | 1.3 | >> |ArraysSort.doubleSort | 50 | 0.282 | 0.291 >> | 1.0 | >> |ArraysSort.doubleSort | 75 | 0.474 | 0.358 >> | 1.3 | >> |ArraysSort.doubleSort | 100 | 0.654 | 0.623 >> | 1.0 | >> |ArraysSort.doubleSort | 1000| 9.274 | 6.331 >> | 1.5 | >> |ArraysSort.doubleSort | 1 | 323.339 | 71.228 >> | **4.5** | >> |ArraysSort.doubleSort | 10 | 4471.871| >> 1002.748| **4.5** | >> |ArraysSort.doubleSort | 100 | 51660.742 | >> 12921.295 | **4.0** | >> |ArraysSort.floatSort| 10 | 0.045 | 0.046 >> | 1.0 | >> |ArraysSort.floatSort| 25 | 0.103 | 0.084 >> | 1.2 | >> |ArraysSort.floatSort| 50 | 0.285 | 0.33 >> | 0.9 | >> |ArraysSort.floatSort| 75 | 0.492 | 0.346 >> | 1.4 | >> |ArraysSort.floatSort| 100 | 0.597 | 0.326 >> | 1.8 | >> |ArraysSort.floatSort| 1000| 9.811 | 5.294 >> | 1.9 | >> |ArraysSort.floatSort| 1 | 323.955 | 50.547 >> | **6.4** | >> |ArraysSort.floatSort| 10 | 4326.38 | 731.152 >> | **5.9** | >> |ArraysSort.floatSort| 100 | 52413.88| >> 8409.193| **6.2** | >> |ArraysSort.intSort | 10 | 0.033 | 0.033 >> | 1.0 | >> |ArraysSort.intSort | 25 | 0.086 | 0.051 >> | 1.7 | >> |ArraysSort.intSort | 50 | 0.236 | 0.151 >> | 1.6 | >> |ArraysSort.intSort | 75 | 0.416 | 0.332 >> | 1.3 | >> |ArraysSort.intSort | 100 | 0.63| 0.521 >> | 1.2 | >> |ArraysSort.intSort | 1000| 10.518 | 4.698 >> | 2.2 | >> |ArraysSort.intSort | 1 | 309.659 | 42.518 >> | **7.3** | >> |ArraysSort.intSort | 10 | 4130.917| >> 573.956 | **7.2** | >> |ArraysSort.intSort | 100 | 49876.307 | >> 6712.812| **7.4** | >> |ArraysSort.longSort | 10 | 0.036 | 0.037 >> | 1.0 | >> |ArraysSort.longSort | 25 | 0.094 | 0.08 >> | 1.2 | >> |ArraysSort.longSort | 50 | 0.218 | 0.227 >> | 1.0 | >> |ArraysSort.longSort | 75 | 0.466 | 0.402 >> | 1.2 | >> |ArraysSort.longSort | 100 | 0.76| 0.58 >> | 1.3 | >> |ArraysSort.longSort | 1000| 10.449 | 6 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > Clean up parameters passed to arrayPartition; update the check to load > library The changes to DualPivotQuicksort will need detailed review to ensure that this is understandable and maintainable, there is a lot here to study. The addition of libx86_64 and having the stub generation call out to this library also needs discussion to make sure there is an agreement on how this would be integrated. - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1698011712
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and >> upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the >> performance data below. >> >> >> **Arrays.sort performance data using JMH benchmarks for arrays with random >> data** >> >> |Arrays.sort benchmark | Array Size | Baseline >> (us/op)| AVX512 Sort (us/op) | Speedup | >> |--- | --- | --- | --- | --- >> | >> |ArraysSort.doubleSort | 10 | 0.034 | 0.035 >> | 1.0 | >> |ArraysSort.doubleSort | 25 | 0.116 | 0.089 >> | 1.3 | >> |ArraysSort.doubleSort | 50 | 0.282 | 0.291 >> | 1.0 | >> |ArraysSort.doubleSort | 75 | 0.474 | 0.358 >> | 1.3 | >> |ArraysSort.doubleSort | 100 | 0.654 | 0.623 >> | 1.0 | >> |ArraysSort.doubleSort | 1000| 9.274 | 6.331 >> | 1.5 | >> |ArraysSort.doubleSort | 1 | 323.339 | 71.228 >> | **4.5** | >> |ArraysSort.doubleSort | 10 | 4471.871| >> 1002.748| **4.5** | >> |ArraysSort.doubleSort | 100 | 51660.742 | >> 12921.295 | **4.0** | >> |ArraysSort.floatSort| 10 | 0.045 | 0.046 >> | 1.0 | >> |ArraysSort.floatSort| 25 | 0.103 | 0.084 >> | 1.2 | >> |ArraysSort.floatSort| 50 | 0.285 | 0.33 >> | 0.9 | >> |ArraysSort.floatSort| 75 | 0.492 | 0.346 >> | 1.4 | >> |ArraysSort.floatSort| 100 | 0.597 | 0.326 >> | 1.8 | >> |ArraysSort.floatSort| 1000| 9.811 | 5.294 >> | 1.9 | >> |ArraysSort.floatSort| 1 | 323.955 | 50.547 >> | **6.4** | >> |ArraysSort.floatSort| 10 | 4326.38 | 731.152 >> | **5.9** | >> |ArraysSort.floatSort| 100 | 52413.88| >> 8409.193| **6.2** | >> |ArraysSort.intSort | 10 | 0.033 | 0.033 >> | 1.0 | >> |ArraysSort.intSort | 25 | 0.086 | 0.051 >> | 1.7 | >> |ArraysSort.intSort | 50 | 0.236 | 0.151 >> | 1.6 | >> |ArraysSort.intSort | 75 | 0.416 | 0.332 >> | 1.3 | >> |ArraysSort.intSort | 100 | 0.63| 0.521 >> | 1.2 | >> |ArraysSort.intSort | 1000| 10.518 | 4.698 >> | 2.2 | >> |ArraysSort.intSort | 1 | 309.659 | 42.518 >> | **7.3** | >> |ArraysSort.intSort | 10 | 4130.917| >> 573.956 | **7.2** | >> |ArraysSort.intSort | 100 | 49876.307 | >> 6712.812| **7.4** | >> |ArraysSort.longSort | 10 | 0.036 | 0.037 >> | 1.0 | >> |ArraysSort.longSort | 25 | 0.094 | 0.08 >> | 1.2 | >> |ArraysSort.longSort | 50 | 0.218 | 0.227 >> | 1.0 | >> |ArraysSort.longSort | 75 | 0.466 | 0.402 >> | 1.2 | >> |ArraysSort.longSort | 100 | 0.76| 0.58 >> | 1.3 | >> |ArraysSort.longSort | 1000| 10.449 | 6 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > Clean up parameters passed to arrayPartition; update the check to load > library @mcimadamore Does Panama have anything to offer over hard coded stubs? - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1697957043
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v29]
On Tue, 29 Aug 2023 16:02:57 GMT, Vladimir Kozlov wrote:
>> If it's tied to GCC as well, then we should probably include that in the
>> condition here unless it's also expected to work with Clang.
>> (`TOOLCHAIN_TYPE` = `gcc`)
>
>> The reason this PR is focused on Linux is because the AVX512 sort and
>> partitioning routines are based on Intel’s x86-simd-library
>> (https://github.com/intel/x86-simd-sort) which was originally developed with
>> GCC as the target compiler. Thus, this PR has restricted itself to Linux as
>> the code was tested using GCC/Linux platforms. Additionally, the x86_64
>> library is compiled for AVX512 using file specific compilation pragmas
>> (`#pragma GCC target("avx512dq", "avx512f")`). This feature is absent for
>> Windows/MSVC++ compiler.”
>
> That is why I am questioning this approach to have additional separate C++
> code library - too much dependencies on other tools.
>
> As I suggested before try to disassemble this library and use assembler code
> in VM new stubs. You can create specialized
> stubGenerator_x86_64_array_sort.cpp file for it. Then you don't need to
> depend on C++ compiler or OS.
The shared library approach is being followed currently as an initial
implementation to demonstrate the value of AVX512 sorting. This will be
followed up in future with support for Windows as well.
If it is ok with you, the shared library approach could be pursued for now to
be later replaced with specialized assembly stubs (which are agnostic to OS and
compiler) when AVX512 sort is enabled for Windows. Please let us know.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309151742
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Tue, 29 Aug 2023 16:04:58 GMT, Vladimir Kozlov wrote: > My testing passed. But I am not sure correctness of code is fully tested. For > now we have only JMH benchmark for this new code. Do we have JDK test which > can check correctness of this code? Hi Vladimir, will add the JDK tests to check for correctness and let you know. - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1697820155
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Mon, 28 Aug 2023 23:35:56 GMT, Erik Joelsson wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Clean up parameters passed to arrayPartition; update the check to load >> library > > make/modules/java.base/Lib.gmk line 240: > >> 238: >> 239: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, >> x86_64)+$(INCLUDE_COMPILER2), true+true+true) >> 240: $(eval $(call SetupJdkLibrary, BUILD_LIB_X86_64, \ > > As this is a C++ lib, consider using g++ for linking by setting: > > TOOLCHAIN := TOOLCHAIN_LINK_CXX Thanks Erik. Will update Lib.gmk to use g++ for linking. > make/modules/java.base/Lib.gmk line 247: > >> 245: LDFLAGS := $(LDFLAGS_JDKLIB) \ >> 246: $(call SET_SHARED_LIBRARY_ORIGIN), \ >> 247: LDFLAGS_linux := -Wl$(COMMA)--no-as-needed, \ > > This is set by default since JDK-8314554. Thanks Erik. Will update Lib.gmk accordingly. - PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309118874 PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309118373
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v29]
On Mon, 28 Aug 2023 23:28:44 GMT, Erik Joelsson wrote:
>> Hi Erik,
>>
>> The reason this PR is focused on Linux is because the AVX512 sort and
>> partitioning routines are based on Intel’s x86-simd-library
>> (https://github.com/intel/x86-simd-sort) which was originally developed with
>> GCC as the target compiler. Thus, this PR has restricted itself to Linux as
>> the code was tested using GCC/Linux platforms.
>> Additionally, the x86_64 library is compiled for AVX512 using file specific
>> compilation pragmas (`#pragma GCC target("avx512dq", "avx512f")`). This
>> feature is absent for Windows/MSVC++ compiler.”
>>
>> Thanks,
>> Vamsi
>
> If it's tied to GCC as well, then we should probably include that in the
> condition here unless it's also expected to work with Clang.
> (`TOOLCHAIN_TYPE` = `gcc`)
> The reason this PR is focused on Linux is because the AVX512 sort and
> partitioning routines are based on Intel’s x86-simd-library
> (https://github.com/intel/x86-simd-sort) which was originally developed with
> GCC as the target compiler. Thus, this PR has restricted itself to Linux as
> the code was tested using GCC/Linux platforms. Additionally, the x86_64
> library is compiled for AVX512 using file specific compilation pragmas
> (`#pragma GCC target("avx512dq", "avx512f")`). This feature is absent for
> Windows/MSVC++ compiler.”
That is why I am questioning this approach to have additional separate C++ code
library - too much dependencies on other tools.
As I suggested before try to disassemble this library and use assembler code in
VM new stubs. You can create specialized stubGenerator_x86_64_array_sort.cpp
file for it. Then you don't need to depend on C++ compiler or OS.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14227#discussion_r1309054538
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and >> upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the >> performance data below. >> >> >> **Arrays.sort performance data using JMH benchmarks for arrays with random >> data** >> >> |Arrays.sort benchmark | Array Size | Baseline >> (us/op)| AVX512 Sort (us/op) | Speedup | >> |--- | --- | --- | --- | --- >> | >> |ArraysSort.doubleSort | 10 | 0.034 | 0.035 >> | 1.0 | >> |ArraysSort.doubleSort | 25 | 0.116 | 0.089 >> | 1.3 | >> |ArraysSort.doubleSort | 50 | 0.282 | 0.291 >> | 1.0 | >> |ArraysSort.doubleSort | 75 | 0.474 | 0.358 >> | 1.3 | >> |ArraysSort.doubleSort | 100 | 0.654 | 0.623 >> | 1.0 | >> |ArraysSort.doubleSort | 1000| 9.274 | 6.331 >> | 1.5 | >> |ArraysSort.doubleSort | 1 | 323.339 | 71.228 >> | **4.5** | >> |ArraysSort.doubleSort | 10 | 4471.871| >> 1002.748| **4.5** | >> |ArraysSort.doubleSort | 100 | 51660.742 | >> 12921.295 | **4.0** | >> |ArraysSort.floatSort| 10 | 0.045 | 0.046 >> | 1.0 | >> |ArraysSort.floatSort| 25 | 0.103 | 0.084 >> | 1.2 | >> |ArraysSort.floatSort| 50 | 0.285 | 0.33 >> | 0.9 | >> |ArraysSort.floatSort| 75 | 0.492 | 0.346 >> | 1.4 | >> |ArraysSort.floatSort| 100 | 0.597 | 0.326 >> | 1.8 | >> |ArraysSort.floatSort| 1000| 9.811 | 5.294 >> | 1.9 | >> |ArraysSort.floatSort| 1 | 323.955 | 50.547 >> | **6.4** | >> |ArraysSort.floatSort| 10 | 4326.38 | 731.152 >> | **5.9** | >> |ArraysSort.floatSort| 100 | 52413.88| >> 8409.193| **6.2** | >> |ArraysSort.intSort | 10 | 0.033 | 0.033 >> | 1.0 | >> |ArraysSort.intSort | 25 | 0.086 | 0.051 >> | 1.7 | >> |ArraysSort.intSort | 50 | 0.236 | 0.151 >> | 1.6 | >> |ArraysSort.intSort | 75 | 0.416 | 0.332 >> | 1.3 | >> |ArraysSort.intSort | 100 | 0.63| 0.521 >> | 1.2 | >> |ArraysSort.intSort | 1000| 10.518 | 4.698 >> | 2.2 | >> |ArraysSort.intSort | 1 | 309.659 | 42.518 >> | **7.3** | >> |ArraysSort.intSort | 10 | 4130.917| >> 573.956 | **7.2** | >> |ArraysSort.intSort | 100 | 49876.307 | >> 6712.812| **7.4** | >> |ArraysSort.longSort | 10 | 0.036 | 0.037 >> | 1.0 | >> |ArraysSort.longSort | 25 | 0.094 | 0.08 >> | 1.2 | >> |ArraysSort.longSort | 50 | 0.218 | 0.227 >> | 1.0 | >> |ArraysSort.longSort | 75 | 0.466 | 0.402 >> | 1.2 | >> |ArraysSort.longSort | 100 | 0.76| 0.58 >> | 1.3 | >> |ArraysSort.longSort | 1000| 10.449 | 6 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > Clean up parameters passed to arrayPartition; update the check to load > library My testing passed. But I am not sure correctness of code is fully tested. For now we have only JMH benchmark for this new code. Do we have JDK test which can check correctness of this code? - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1697743981
Re: RFR: 8309130: x86_64 AVX512 intrinsics for Arrays.sort methods (int, long, float and double arrays) [v30]
On Mon, 28 Aug 2023 21:27:25 GMT, Srinivas Vamsi Parasa wrote: >> The goal is to develop faster sort routines for x86_64 CPUs by taking >> advantage of AVX512 instructions. This enhancement provides an order of >> magnitude speedup for Arrays.sort() using int, long, float and double arrays. >> >> This PR shows upto ~7x improvement for 32-bit datatypes (int, float) and >> upto ~4.5x improvement for 64-bit datatypes (long, double) as shown in the >> performance data below. >> >> >> **Arrays.sort performance data using JMH benchmarks for arrays with random >> data** >> >> |Arrays.sort benchmark | Array Size | Baseline >> (us/op)| AVX512 Sort (us/op) | Speedup | >> |--- | --- | --- | --- | --- >> | >> |ArraysSort.doubleSort | 10 | 0.034 | 0.035 >> | 1.0 | >> |ArraysSort.doubleSort | 25 | 0.116 | 0.089 >> | 1.3 | >> |ArraysSort.doubleSort | 50 | 0.282 | 0.291 >> | 1.0 | >> |ArraysSort.doubleSort | 75 | 0.474 | 0.358 >> | 1.3 | >> |ArraysSort.doubleSort | 100 | 0.654 | 0.623 >> | 1.0 | >> |ArraysSort.doubleSort | 1000| 9.274 | 6.331 >> | 1.5 | >> |ArraysSort.doubleSort | 1 | 323.339 | 71.228 >> | **4.5** | >> |ArraysSort.doubleSort | 10 | 4471.871| >> 1002.748| **4.5** | >> |ArraysSort.doubleSort | 100 | 51660.742 | >> 12921.295 | **4.0** | >> |ArraysSort.floatSort| 10 | 0.045 | 0.046 >> | 1.0 | >> |ArraysSort.floatSort| 25 | 0.103 | 0.084 >> | 1.2 | >> |ArraysSort.floatSort| 50 | 0.285 | 0.33 >> | 0.9 | >> |ArraysSort.floatSort| 75 | 0.492 | 0.346 >> | 1.4 | >> |ArraysSort.floatSort| 100 | 0.597 | 0.326 >> | 1.8 | >> |ArraysSort.floatSort| 1000| 9.811 | 5.294 >> | 1.9 | >> |ArraysSort.floatSort| 1 | 323.955 | 50.547 >> | **6.4** | >> |ArraysSort.floatSort| 10 | 4326.38 | 731.152 >> | **5.9** | >> |ArraysSort.floatSort| 100 | 52413.88| >> 8409.193| **6.2** | >> |ArraysSort.intSort | 10 | 0.033 | 0.033 >> | 1.0 | >> |ArraysSort.intSort | 25 | 0.086 | 0.051 >> | 1.7 | >> |ArraysSort.intSort | 50 | 0.236 | 0.151 >> | 1.6 | >> |ArraysSort.intSort | 75 | 0.416 | 0.332 >> | 1.3 | >> |ArraysSort.intSort | 100 | 0.63| 0.521 >> | 1.2 | >> |ArraysSort.intSort | 1000| 10.518 | 4.698 >> | 2.2 | >> |ArraysSort.intSort | 1 | 309.659 | 42.518 >> | **7.3** | >> |ArraysSort.intSort | 10 | 4130.917| >> 573.956 | **7.2** | >> |ArraysSort.intSort | 100 | 49876.307 | >> 6712.812| **7.4** | >> |ArraysSort.longSort | 10 | 0.036 | 0.037 >> | 1.0 | >> |ArraysSort.longSort | 25 | 0.094 | 0.08 >> | 1.2 | >> |ArraysSort.longSort | 50 | 0.218 | 0.227 >> | 1.0 | >> |ArraysSort.longSort | 75 | 0.466 | 0.402 >> | 1.2 | >> |ArraysSort.longSort | 100 | 0.76| 0.58 >> | 1.3 | >> |ArraysSort.longSort | 1000| 10.449 | 6 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one > additional commit since the last revision: > > Clean up parameters passed to arrayPartition; update the check to load > library > Hi @vamsi-parasa , Please find below the perf data collected over “Linux” with following JMH options. java -jar target/benchmarks.jar -p builder=RANDOM -f 1 -wi 1 -i 10 -w 30 -jvmArgs "-XX:+UnlockDiagnosticVMOptions -XX:DisableIntrinsic=_arraySort,_arrayPartition" ArraysSort.Long.testSort Baseline numbers are with stock JDK.  Best Regards, Jatin - PR Comment: https://git.openjdk.org/jdk/pull/14227#issuecomment-1697715820
Re: building individual test issue
Hello Vladimir, thank you for your attention, did you mean set of patches located in debian/patches ? those are patched (all in the series file) or some other? Mykhaylo On Mon, Aug 28, 2023 at 11:11 PM Vladimir Petko < vladimir.pe...@canonical.com> wrote: > Hi, > > I believe this was due to building OpenJDK from Debian original > tarball that does not contain bundled libraries. Building from it > requires applying Debian patches via `quilt push -a` and using > configure arguments from `debian/rules`. > > Best Regards, > Vladimir. > > On Tue, Aug 29, 2023 at 1:02 AM David Holmes > wrote: > > > > On 28/08/2023 9:54 pm, Mykhaylo Lodygin wrote: > > > Hello colleagues, > > > I've build JDK locally successfully, but got several tests "FAILED". > > > > What did you build? images? what about test-images? > > > > > Tried to run one of the failing test separately with "make test > > > TEST="". > > > Were unable to do so due to build error - the compiler was unfamiliar > to > > > include path to winscard.h, fixed with configuration option: > > > bash configure --with-extra-cflags="-I/usr/include/PCSC" > > > > What test(s), on what platform? > > > > > next error was incapability of linker to link with libjpeg - fixed > with > > > adding --with-libjpeg=system to configure. > > > the issue was solved, but a new one was added with missing libgif. > > > I was curious and tried a test that "Passed", thinking that "failure" > > > could had happen due to inability to build the test. Tried > > > sun/util/calendar/zi/Beyond2037.java but got a very similar error of > > > inability to link with liblcms2-2. > > > I'm flabbergasted, hence my questions are: does "make test" target is > > > expected to rebuild JDK's code? does my approach of adding options to > > > configure script is proper one? How come a test could be "Passed" while > > > running it separately results in inability to build the test? > > > > As Erik indicated we need more information/details. > > > > Cheers, > > David > > > > > > > Thank you. > > > Mykhaylo Lodygin >
Re: building individual test issue
Hello David, > What did you build? images? what about test-images? you've meant "make images" - i'm getting lots of errors about missing methods from library liblcms2-2 (undefined reference to `cmsCloseProfile', undefined reference to `cmsSaveProfileToMem') test-images target is seems to be missing at all, since i'm getting make: *** No rule to make target 'test-images'. Stop. > What test(s), on what platform? on ubuntu18.04LTS, i've started with what I reckon the smallest one (among "failing" set) java/util/TimeZone/Promiscuous.java On Mon, Aug 28, 2023 at 4:02 PM David Holmes wrote: > On 28/08/2023 9:54 pm, Mykhaylo Lodygin wrote: > > Hello colleagues, > > I've build JDK locally successfully, but got several tests "FAILED". > > What did you build? images? what about test-images? > > > Tried to run one of the failing test separately with "make test > > TEST="". > > Were unable to do so due to build error - the compiler was unfamiliar to > > include path to winscard.h, fixed with configuration option: > > bash configure --with-extra-cflags="-I/usr/include/PCSC" > > What test(s), on what platform? > > > next error was incapability of linker to link with libjpeg - fixed with > > adding --with-libjpeg=system to configure. > > the issue was solved, but a new one was added with missing libgif. > > I was curious and tried a test that "Passed", thinking that "failure" > > could had happen due to inability to build the test. Tried > > sun/util/calendar/zi/Beyond2037.java but got a very similar error of > > inability to link with liblcms2-2. > > I'm flabbergasted, hence my questions are: does "make test" target is > > expected to rebuild JDK's code? does my approach of adding options to > > configure script is proper one? How come a test could be "Passed" while > > running it separately results in inability to build the test? > > As Erik indicated we need more information/details. > > Cheers, > David > > > > Thank you. > > Mykhaylo Lodygin >
Integrated: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note
On Tue, 22 Aug 2023 11:09:39 GMT, Pavel Rappo wrote: > Please review this trivial PR. This pull request has now been integrated. Changeset: a4e97aa4 Author:Pavel Rappo URL: https://git.openjdk.org/jdk/commit/a4e97aa4ebe6fcfc3ed9e45ed81df1d55e52d621 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note Reviewed-by: rriggs, azvegint, kevinw - PR: https://git.openjdk.org/jdk/pull/15385
Re: building individual test issue
Hello Erik, thank you for your reply. I'm trying to build JDK-11 for ubuntu 18.04LTS, got sources by applying "apt sources openjdk-11-jdk" command, hence it is canonical's repo my configuration is: '--with-jvm-variants=server --with-boot-jdk=/usr/lib/jvm/java-11-openjdk-amd64 --disable-precompiled-headers --with-jvm-features=zgc,shenandoahgc --with-extra-cflags='-Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/openjdk-lts-11.0.19+7=. -fstack-protector-strong -Wformat -fno-stack-protector -Wno-deprecated-declarations -Wdate-time -D_FORTIFY_SOURCE=2' --with-extra-cxxflags='-Wdate-time -D_FORTIFY_SOURCE=2 -g -fdebug-prefix-map=/build/openjdk-lts-11.0.19+7=. -fstack-protector-strong -Wformat -fno-stack-protector -Wno-deprecated-declarations -Wno-deprecated-declarations' --with-extra-ldflags='-Xlinker -z -Xlinker relro -Xlinker -Bsymbolic-functions' --disable-ccache --with-jtreg=/usr --with-vendor-name=Ubuntu --with-vendor-url=https://ubuntu.com/ --with-vendor-bug-url=https://bugs.launchpad.net/ubuntu/+source/openjdk-lts --with-vendor-vm-bug-url= https://bugs.launchpad.net/ubuntu/+source/openjdk-lts --with-version-pre= --with-version-build=7 --with-version-opt='post-Ubuntu-0ubuntu1~18.04.1' --with-copyright-year=2023 --with-debug-level=release --with-native-debug-symbols=external --enable-unlimited-crypto --with-zlib=system --with-giflib=system --with-libpng=system --with-libjpeg=system --with-lcms=system --with-pcsclite=system --disable-warnings-as-errors --disable-javac-server --with-harfbuzz=system --with-stdc++lib=dynamic --with-num-cores=4'. On Mon, Aug 28, 2023 at 3:51 PM wrote: > Hello Mykhaylo Lodygin, > > What you describe sounds strange. If you successfully built the JDK and > ran tests, then nothing should be rebuilt when trying to run tests again. > > What operating system are you running this on? > > Which JDK src did you clone? > > What was your original configure command line? > > /Erik > > On 8/28/23 04:54, Mykhaylo Lodygin wrote: > > Hello colleagues, > > I've build JDK locally successfully, but got several tests "FAILED". > > Tried to run one of the failing test separately with "make test > > TEST="". > > Were unable to do so due to build error - the compiler was unfamiliar > > to include path to winscard.h, fixed with configuration option: > > bash configure --with-extra-cflags="-I/usr/include/PCSC" > > next error was incapability of linker to link with libjpeg - fixed with > > adding --with-libjpeg=system to configure. > > the issue was solved, but a new one was added with missing libgif. > > I was curious and tried a test that "Passed", thinking that "failure" > > could had happen due to inability to build the test. Tried > > sun/util/calendar/zi/Beyond2037.java but got a very similar error of > > inability to link with liblcms2-2. > > I'm flabbergasted, hence my questions are: does "make test" target is > > expected to rebuild JDK's code? does my approach of adding options to > > configure script is proper one? How come a test could be "Passed" > > while running it separately results in inability to build the test? > > Thank you. > > Mykhaylo Lodygin >
Re: RFR: 8314753: Remove support for @beaninfo, @ToDo, @since.unbundled, and @Note [v2]
On Tue, 22 Aug 2023 14:55:18 GMT, Pavel Rappo wrote: >> Please review this trivial PR. > > Pavel Rappo has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into 8314753 > - Initial commit Looks good, thanks. - Marked as reviewed by kevinw (Committer). PR Review: https://git.openjdk.org/jdk/pull/15385#pullrequestreview-1599820441
