Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2
On 2020-11-17 19:08, Philip Race wrote: So maybe the actual *usage* of C++11 features slows it down. I found this :- https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98 I really did not even think to measure the build time and I don't think there's any JDK build parallelism in building a specific native library. The build is parallel at a higher level but not at that lower level. There is build parallelism on multiple levels. When building an individual library, make is free to parallelize the compile task; only the link task is done singlethreaded. When determining which libraries to build, make is free to chose those available depending on tasks already finished. For instance, to build java.desktop-libs, we need to have finished java.desktop-java (since javac generates the header files needed by JNI integration). But after that, it can be compiled whenever make think it's suitable. This freedom for make to reorganize the order also means that it is hard to determine the additional cost for building a specific part. You could try to build java.desktop-java, and then run "make LOG=info java.desktop-libs" JOBS=1 to get a somewhat proper assessment of the time spent building all native libs for java.desktop. If this changes with the HarfBuzz upgrade, the HB upgrade is likely to blame. /Magnus -phil On 11/17/20, 10:00 AM, Florian Weimer wrote: * Philip Race: There is more code in the newer version but not 4 times as much ! Harfbuzz now requires c++11 features (-std=c++11) Possibly the C++ compiler you are using (you don't mention platform) is slower in this mode. It's GCC 8 on Debian buster, which defaults to C++14. And it's possible to write slow-to-compile C++ in all language modes. Is the Harfbuzz build parallelized?
Re: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the >> validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a > worst case, to be sure, but it take 10 times as long to render with the > integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs > 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using > jpackage, can make the decision for themselves. Application developers who > rely on the JDK as delivered will get whatever we choose as the default. So > we need to be sure that the benefit of doing this justifies the performance > hit. > > @kevinrushforth @prrace could you please review? > > As we discussed yesterday, it is reviewed but not ready to be approved. > We are waiting for a reply from Apple. @prrace We are waiting for it for three months already. If it is possible then not sure why other applications did not found any possible ways to force one specific GPU. What we are wating for? - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the >> validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a > worst case, to be sure, but it take 10 times as long to render with the > integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs > 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using > jpackage, can make the decision for themselves. Application developers who > rely on the JDK as delivered will get whatever we choose as the default. So > we need to be sure that the benefit of doing this justifies the performance > hit. > @kevinrushforth @prrace could you please review? As we discussed yesterday, it is reviewed but not ready to be approved. We are waiting for a reply from Apple. - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: [OpenJDK 2D-Dev] RFR: 8256321: Some "inactive" color profiles use the wrong profile class
On Fri, 13 Nov 2020 22:50:02 GMT, Sergey Bylokhov wrote: > The implementation of ICC_Profile tries to defer loading the data of the > color profile, and it uses some predefined values for some profile properties > for the standard profiles like sRGB, PYCC, etc. If the application requests > profile data then the ICC_Profile class activates the profile and uses > properties from that data. > > Deferring mechanism for all profiles was added in JDK-6793818, but > unfortunately, the color profile class was hardcoded incorrectly > "CLASS_DISPLAY" for all profiles. However, the "CIEXYZ.pf" and "PYCC.pf" > profiles should use "CLASS_COLORSPACECONVERSION". > > Later the color "profiles/xxx.pf" were replaced in the JDK, and the actual > type of the "CIEXYZ.pf" was changed to the "CLASS_ABSTRACT", but the > deferring mechanism still uses "CLASS_DISPLAY". > > As a result of this bug, the color profile reports different values > before/after activations. @prsadhuk please review this fix - PR: https://git.openjdk.java.net/jdk/pull/1211
Re: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the >> validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a > worst case, to be sure, but it take 10 times as long to render with the > integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs > 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using > jpackage, can make the decision for themselves. Application developers who > rely on the JDK as delivered will get whatever we choose as the default. So > we need to be sure that the benefit of doing this justifies the performance > hit. @kevinrushforth @prrace could you please review? - PR: https://git.openjdk.java.net/jdk/pull/1139
Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2
So maybe the actual *usage* of C++11 features slows it down. I found this :- https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98 I really did not even think to measure the build time and I don't think there's any JDK build parallelism in building a specific native library. The build is parallel at a higher level but not at that lower level. -phil On 11/17/20, 10:00 AM, Florian Weimer wrote: * Philip Race: There is more code in the newer version but not 4 times as much ! Harfbuzz now requires c++11 features (-std=c++11) Possibly the C++ compiler you are using (you don't mention platform) is slower in this mode. It's GCC 8 on Debian buster, which defaults to C++14. And it's possible to write slow-to-compile C++ in all language modes. Is the Harfbuzz build parallelized?
Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2
* Philip Race: > There is more code in the newer version but not 4 times as much ! > Harfbuzz now requires c++11 features (-std=c++11) > Possibly the C++ compiler you are using (you don't mention platform) is > slower in this mode. It's GCC 8 on Debian buster, which defaults to C++14. And it's possible to write slow-to-compile C++ in all language modes. Is the Harfbuzz build parallelized?
Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2
There is more code in the newer version but not 4 times as much ! Harfbuzz now requires c++11 features (-std=c++11) Possibly the C++ compiler you are using (you don't mention platform) is slower in this mode. -phil. On 11/17/20, 9:01 AM, Florian Weimer wrote: * Phil Race: This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library https://bugs.openjdk.java.net/browse/JDK-8247872 This has passed building and headless and headful automated tests on all platforms. Is it just me, or does the new Harfbuzz build *significantly* slower? It adds about 20 seconds to the build, compared to using the system Harfbuzz, whereas before it was around 5 seconds.
Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2
* Phil Race: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - > an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on > all platforms. Is it just me, or does the new Harfbuzz build *significantly* slower? It adds about 20 seconds to the build, compared to using the system Harfbuzz, whereas before it was around 5 seconds.
