Jim,
Thanks for your ideas below:
> Some thoughts - we record some info on each scanline - mostly about the
new edges that are added. Perhaps we could keep deltas of how many edges
come and go per scanline and then sum them up at the start to figure out if
any scanline has a lot of crossings?
I
Hi Sergy,
Is this a new patch that replaces the -march flag (and has the same
performance benefits)? Are those options compatible with all of our
supported platforms?
If so, then we should file a bug and get that into 9...
...jim
On 10/1/15 10:10 AM, Sergey Bylokhov
Marlin appears to be just one week away from approval to target to JDK 9.
-phil.
Original Message
Subject:JEPs proposed to target JDK 9 (2015/10/1)
Date: Thu, 01 Oct 2015 11:16:26 -0700
From: mark.reinh...@oracle.com
To: jdk9-...@openjdk.java.net
The followin
My patch below:
><
diff -r 2b680924a73f make/lib/Awt2dLibraries.gmk
--- a/make/lib/Awt2dLibraries.gmk Wed Sep 16 18:34:38 2015 +0300
+++ b/make/lib/Awt2dLibraries.gmk Thu Oct 01 17:06:38 2015 +0300
@@ -243,7 +243,7 @@
EXCLUDES := $(LIBAWT_EXCLUDES), \
EXCL
oh and ps .. we are of course also dependent on what the version of gcc
in use knows about the CPU. The important one is whatever RE use.
All of this is tricky to get right and maintain and is one reason why
the adaptive JIT in hotspot can be a good thing.
-phil.
On 10/01/2015 09:22 AM, Phil Ra
The results of -march=native are more interesting/useful if
we also know what exact CPU this was compiled on.
Obviously we can't use that option directly in JDK builds but
it may be that we could make some judgement about whether
it is acceptable to trade slow-downs on some rarer CPUs for
speed-u
Sergey,
Thanks for having tests.
What is the units of your your results ?
I guess it is on the time axis: slower values are better.
How did you hack the gcc options in the openjdk build scripts ?
I could try on my local build too.
Bye,
Laurent
Le 1 oct. 2015 17:39, "Sergey Bylokhov" a
écrit :
I got results below after I made a hack and added -march=native to the libawt
library:
"EllipseFill.fillEllipse 1400"
8u60_RE: 6,540
9_dev: 8,457
9_hack: 6,276
So we have a window for tweaking.
- sergey.bylok...@oracle.com wrote:
> Hello,
> I built both version of jdk8 and jdk9 on my local
Hello,
I built both version of jdk8 and jdk9 on my local system, and compares output
of preprocessor and generated assemblers, both are identical. But jdk8u60 from
RE actually 20% faster than my version of jdk8. It seems that the difference is
in the compiler and/or in some compiler(gcc) options