On 2020-01-30 21:38, August Nagro wrote:
Its been a while since I tried, but if I remember correctly I had to
delete the code that tested the compiler name / version in one of the
sh files. I set the compiler to icc via the environment variables.
The build ran for a while but then stopped
Its been a while since I tried, but if I remember correctly I had to delete
the code that tested the compiler name / version in one of the sh files. I
set the compiler to icc via the environment variables.
The build ran for a while but then stopped with an error message. I
remember it not being
On 2019-12-18 00:05, August Nagro wrote:
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
> (btw I wonder how much effect profile guided optimization would bring in
your experiments )
That's good idea; I'm also curious about PGO. I know some apps get 10-20%
performance boost, however setting up PGO is pretty inconvenient. But maybe
having it run over the DaCapo / Renaissance
* 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
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
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,
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
Hello, a small update from my side . I had (on Linux) for a couple of days
our jdk11u tests + benchmarks running with -Os instead of the usual
settings (-O3) .
With have (independent of -Os / -O3) a bit of variance in our benchmarks
( jbb15 , jvm2008, jvm98 ) .
However the
On 11/27/19 10:03 AM, Doerr, Martin wrote:
Hi Claes,
that kind of surprises me. I'd expect files which rather benefit from -O3 to be
far less than those which benefit from -Os.
Most performance critical code lives inside the code cache and is not dependent
on C++ compiler optimizations.
Hi Claes,
yeah, that makes sense.
> Hopefully we don't have to do one RFE per file.. :-)
I should have written set of files or directories or whatever.
Thanks for your input.
Best regards,
Martin
> -Original Message-
> From: Claes Redestad
> Sent: Mittwoch, 27. November 2019
Hi Martin,
On 2019-11-27 19:03, Doerr, Martin wrote:
Hi Claes,
that kind of surprises me. I'd expect files which rather benefit from -O3 to be
far less than those which benefit from -Os.
Most performance critical code lives inside the code cache and is not dependent
on C++ compiler
Hi Claes,
that kind of surprises me. I'd expect files which rather benefit from -O3 to be
far less than those which benefit from -Os.
Most performance critical code lives inside the code cache and is not dependent
on C++ compiler optimizations.
I'd expect GC code, C2's register allocation and a
Hi,
we discussed doing the opposite for Mac OS X recently, where builds are
currently set to -Os by default. -O3 helped various networking
(micro)benchmarks by up to 20%.
Rather than doing -Os by default and then cherry-pick things over to -O3
on a case-by-case basis, I'd suggest the opposite:
Hello Martin, I checked building libjvm.so with -Os (instead of -O3) .
I used gcc-7 on linux x86_64 .
The size of libjvm.so dropped from24M (normal night make with -O3)
to 18M ( test make with -Os) .
(adding the link-time gc might reduce the size by another ~ 10 % ,
15 matches
Mail list logo
