[OpenJDK Rasterizer] Marlin #4

[Phil Race]

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 Race wrote:
> 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-ups on more common CPUs. But you need to be careful
> not to (a) prevent JDK running at all on the older CPU which
> lacks some instruction, or (b) optimising for today's CPUs at
> the expense of the next generation or two, which is more likely to
> be where JDK 9 is run ..
>
> -phil.
>
>
>
>
> On 10/01/2015 09:17 AM, Laurent Bourgès wrote:
>>
>> 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" <sergey.bylokhov at oracle.com 
>> <mailto:sergey.bylokhov at oracle.com>> 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.bylokhov at oracle.com 
>> <mailto:sergey.bylokhov at oracle.com> wrote:
>> >
>> > > 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 used by default.
>> > >
>> > > ----- james.graham at oracle.com <mailto:james.graham at oracle.com> wrote:
>> > >
>> > > > As far as why the software loops are slower...
>> > > >
>> > > > Did any command line options change for compiling IntArgbPre.c?
>> > > Touch
>> > > >
>> > > > the file and rebuild and verify if the compiler options are the 
>> same
>> > >
>> > > > (and that both builds use the same compiler)...
>> > > >
>> > > >                     ...jim
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/graphics-rasterizer-dev/attachments/20151001/e410bf6b/attachment.html>