Proposal for two new samples

[Aleksey Shipilev]

Hi Michael,

On 08/11/2015 11:32 PM, Michael Mirwaldt wrote:
> Hi Aleksey,
> you can find my source files in the attachment.

Thanks, I have mangled them quite a bit to make them more concise and
straight to the point. Please study the updated versions:
  https://bugs.openjdk.java.net/browse/CODETOOLS-7901485
  http://hg.openjdk.java.net/code-tools/jmh/rev/7073e1a4bee6

Some comments:

> Some remarks:
> 1) Branch prediction:
> 
>     a) I use the constant seed 1234 for my Random-Object.
>     This is quite arbitrary but it must be a constant.
>     It cannot be the default seed which is dependent on System.nanoTime().
>     This would lead to completely different results each time you run
> the benchmark which is confusing.
>     I do not think there is a "perfect seed" because how do you want to
> measure the degree of happitence
>     in the unsorted array?

Setting the seed is perfectly fine for stable educational tests.


>     b) I think the effort of incrementing the counter and of the modulo
> operation can be neglected.
>     Can you confirm that?

I think we can just use the loop, as explained in
JMHSample_34_SafeLooping.measureRight_1.

>     c) Count ís 1024 ^ 2 which forces int arrays of size 4MB.
>     The original value 65535 (int arrays of size 256KB) seemed to be too
> small to observe anything significant.

Yes, that size works well on a few machines I tried.

>     d) the decision value 128 seems to have the biggest effect on branch
> prediction.
>     Do not ask me why ;-)

Instead of introducing a magic number, we can use less magical zero,
since it's right in the middle for signed numbers.


> 2) Matrix copy
> The basic motivation behind the matrix copy benchmark is to make
> programmers aware
> that two dimensional arrays are technically still one dimensional arrays.
> The additional dimensions are only 'mapped' which can lead to cache
> misses if arrays are bigger than the caches.
> 
>     a) I used again the magic number 1024^2 which are 4MB.
>     Otherwise, all of the vector would fit into the cache making the
> benchmark completely useless.
> 
>     b) The code in the comment of a benchmark method is the intended code
>     that is expressed by the code in the benchmark method.
>     The benchmark should actually measure how long it takes to access a
> cell.

Again, plain loops are just as fine. And we will also keep away the
integer divisions out.

It's also not a very compelling use of @AuxCounters, purged that as well.

Thanks,
-Aleksey