JITWatch and my chessengine

[Sander Maassen vd Brink]

This is the email I've send to Chris:

Since about 2 years I've been working on a chess engine in Java, called chess22k. Of course, performance is very important so I am also interested in the workings of the jit-compiler. This is when I came across JITWatch and I have to say I am really impressed with all the information you get using this application!
I am trying to analyze my engine using JITWatch and get about 2000 suggestions if I let it calculate for about 30 seconds on the next best move. I know that some methods are too big to be inlined but these cannot easily be split-up in smaller methods. Suggestions about unpredictable branches are also amazing but I do not really know how to fix these.

Could you maybe have a look? :) I am also wondering how much performance gain I would be able to achieve if all methods could be inlined? 1%, 5%, ...?

The source can be found here: (if you want to do a quickrun, just execute MainTest)
https://github.com/sandermvdb/chess22k

At the moment the engine is ranked #69 at the CCRL list:
http://www.computerchess.org.uk/ccrl/4040/

I've attached my JVM logfile to this topic.

[Sander Maassen vd Brink]

And this was his response:

My initial response would be to ask if you have a stable benchmark so that you can measure the effects of any changes you make in response to the hints provided by JITWatch.

Do you know the memory allocation profile of your code? If you are allocating a lot of new heap objects then reducing that will probably give great speed improvements. You've mentioned you are seeing inlining failures due to method size. If that is happening then you are probably missing out on escape-analysis optimisations that can reduce heap allocations. You might also be missing out on loop unrolling which could give a big speedup in your case if you are performing large numbers of loop iterations.

[Sander Maassen vd Brink]

At the moment I do not have a really stable benchmark, but this would be quite easy to achieve; just let the engine calculate the best move for a minute or so using a particular position.

I am not allocating a low of new heap objects; there are almost 0 garbage collections :)

[Martijn Verburg]

Hi Sander,

Have you used JMH?

Cheers,
Martijn

On 21 December 2017 at 17:09, Sander Maassen vd Brink <san...@s22k.nl> wrote:

At the moment I do not have a really stable benchmark, but this would be quite easy to achieve; just let the engine calculate the best move for a minute or so using a particular position.

I am not allocating a low of new heap objects; there are almost 0 garbage collections :)

--
You received this message because you are subscribed to the Google Groups "JITWatch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jitwatch+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Sander Maassen vd Brink]

No I haven't used JMH. I am counting the nodes per second that are being processed.
I do use a code-coverage tool (clover) to see which lines in the code are called how many times. With Java 8 I was still able to use VisualVM to do the profiling but since Java 9 that doesn't work anymore.

On Thursday, December 21, 2017 at 10:39:00 PM UTC+1, martijnverburg wrote:

Hi Sander,

Have you used JMH?

Cheers,
Martijn

On 21 December 2017 at 17:09, Sander Maassen vd Brink <san...@s22k.nl> wrote:

At the moment I do not have a really stable benchmark, but this would be quite easy to achieve; just let the engine calculate the best move for a minute or so using a particular position.

I am not allocating a low of new heap objects; there are almost 0 garbage collections :)

--
You received this message because you are subscribed to the Google Groups "JITWatch" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jitwatch+u...@googlegroups.com.

[Chris Newland]

Hi Sander,

Would you mind re-generating your hotspot log without the PrintInlining and PrintCompilation switches? This information is present (in more detail) with the LogCompilation switch and the JITWatch parser isn't able to cope when both LogCompilation and PrintCompilation/PrintInlining are present in the same log. (PrintAssembly is fine and understood by JITWatch).

Cheers,

Chris

[Sander Maassen vd Brink]

See attachment for the logfile with the correct switches.
I've also just released a new version of my engine on github, including some suggestions from JITWatch (no real performance improvements unfortunately).

[Sander Maassen vd Brink]

This latest logfile is with only the C2 compiler enabled because that compiler will be active for actual chess matches.