http://hg.openjdk.java.net/aarch32-port/jdk9-arm3264 merged

[Bob Vandette]

> On Oct 12, 2016, at 1:01 PM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 12/10/16 17:45, Bob Vandette wrote:
> 
>> Yes, benchmarking is an ART.  There are so many variables and you
>> need to select a benchmark that best matches the type of application
>> you are interested in.  For AArch64, I don’t see these small
>> microbenchmarks like specJVM2008 all that meaningful but running
>> hadoop and specJBB takes considerable effort to setup and run to get
>> reliable results.  We also have the reporting issue that gets in the
>> way of comparing unreleased products.
> 
> Hmm.  I'm not sure I'd call SPECjvm a "microbenchmark", but never
> mind.
> 
> You're right.  However, at least to begin with it's necessary to kick
> the tyres and go for a test drive.  While I'd be a fool to base all
> decisions on such benchmarks, I'd also be a fool not to do any
> benchmarking at all.  Given that most things remain the same (the CPU,
> C++ compiler, the garbage collector, all of the runtime that's written
> in C++, etc.) I can concentrate on issues of code quality in the
> small, which is what I'd like to know right now.  I'd be fairly
> surprised if one of the ports turned out to have some magical
> advantage in larger applications which wasn't revealed in smaller
> benchmarks, but it's possible.

I’m not suggesting that you don’t try these benchmarks, just that you
need to be careful about drawing conclusions from them.  The implementation
of a single intrinsic can make one of these sub-benchmarks look great when
in real-world applications it doesn’t matter.

Bob.

> 
> Andrew.