*   I compiled with clang since I'm on Mac.
  *

Thanks for clarifying, that’s what I thought .

(btw I wonder how much effect  profile guided optimization would bring in your 
experiments )



  *   My opinion is that there are probably more compelling alternatives if 
reducing binary size is the goal. Even if the tests show that Os/O2 is no 
different than O3,
  *   who knows if this will be true in the future.
  *

What alternatives do you have in mind ?

Best regards, Matthias


From: August Nagro <[email protected]>
Sent: Mittwoch, 18. Dezember 2019 14:42
To: Baesken, Matthias <[email protected]>
Cc: [email protected]; Doerr, Martin <[email protected]>; 
[email protected]; [email protected]; 
[email protected]
Subject: Re: RE: building libjvm with -Os for space optimization - was : RE: 
RFR: 8234525: enable link-time section-gc for linux s390x to remove unused code

I compiled with clang since I'm on Mac.

The Renaissance benchmark suite is also a good one that I learned about 
recently.

My opinion is that there are probably more compelling alternatives if reducing 
binary size is the goal. Even if the tests show that Os/O2 is no different than 
O3, who knows if this will be true in the future.

Regards,

- August

On Wed, Dec 18, 2019, 1:58 AM Baesken, Matthias 
<[email protected]<mailto:[email protected]>> wrote:
Hi August , thanks for pointing to your webpage,  very interesting !

We did our builds+tests/benchmarks  with  gcc  7.4.0   , what compiler+version 
did you use?

Probably I should look a bit more into Dacapo (we used that one in the past too 
sometimes).

Best regards, Matthias


>
> I published some benchmarks of OpenJDK on Mac with Ofast and O3 [1].
> Some microbenchmarks like Netty’s HttpObjectEncoder experienced >100%
> speedup with O3, and the more real-world Dacapo suite was ~15%
> improvement over O2 (which is exactly the same as Os). I did include a few
> other flags, however the speedup was primarily due to optimization level.
>
> Building with Os is the old wisdom. It used to be the case that many programs
> would be faster with the smaller binary size, but this is almost never the 
> case
> nowadays.
>
> - August
>
> [1]: http://august.nagro.us/optimized-openjdk.html

Reply via email to