[ogrisel]

Actually:

> Faster evaluation function: I didn’t use the GPU for playing, only for training.

So indeed it could probably be optimized. But first I would profile as it can be the case that the bottleneck is Matrix Matrix multiplication in numpy which already delegates computation to an optimized third party library (e.g. OpenBLAS). Maybe it's worth using the GPU at play time as well.

[bainsfather]

"Maybe it's worth using the GPU at play time as well."

The difficulty there is that sending data to and from the GPU is slow. You need to avoid data transfers, which might mean trying to do everything on the GPU. But the SIMD cores on the GPU are likely to perform poorly due to all the branch statements in chess code.

[Karunamon]

This may be naive, but board state can be encoded very efficiently using FEN[1] - as an example, the starting board state only takes up 57 bytes.

[1]:https://chessprogramming.wikispaces.com/Forsyth-Edwards+Nota...

[bainsfather]

There is a delay from sending any data to/from the GPU.

Generally you aim to give the GPU a 'large' task (or many small tasks), then ask for the answer(s) in 1 batch and wait while it is transferred across.

If you have many small tasks where each answer is sent back separately, and you need that answer before requesting the next task, then you will be very slow, even if the data sent/received is small. A naive implementation of the chess algorithm here (with alpha-beta pruning (which has many if-then branches)) would be like this :/

[ogrisel]

There might still be ways to speed up at play time by evaluating batches of candidate points in the same evaluation function call in the GPU.