Hi,
You probably noticed that, even with one thread, the tree exploration by an alpha-beta procedure or by a MTD-f procedure when you use a hashtable, may give different results depending on the order you analyse the moves.
Did you make something special in order to have a procedure as efficient as possible regarding this point?
As far as I am concerned I did not yet try to handle this problem; as a consequence, in a multithread environment and for a given analysing depth I can obtain different results for the evaluation of the root node and I can obtain diefferent PV. It seems not to be big problem but it may mean that the efficiency of the procedure may be improved.
That is the reason of my question.
Position evaluation and order of analysed moves
Gerard,
thats what i also see in my 4-core implementation.
When running multiple times (even when i completely clear the hashtable at the start), i get different results (best move and score).
Sometimes these score-differences are "relatively" large.
This is also the reason that I played with the single-core implementation during the most recent tournament.
Next week I will start to re-test the parallel search-algorithm as a preparation for the next open Dutch tournament.
My target is to have a multi-core search ( 4 - 8 threads) and the 7p database.
Bert
thats what i also see in my 4-core implementation.
When running multiple times (even when i completely clear the hashtable at the start), i get different results (best move and score).
Sometimes these score-differences are "relatively" large.
This is also the reason that I played with the single-core implementation during the most recent tournament.
Next week I will start to re-test the parallel search-algorithm as a preparation for the next open Dutch tournament.
My target is to have a multi-core search ( 4 - 8 threads) and the 7p database.
Bert
As I analyse the problem, without a very special coding of your algorithm, it is normal to get different results in a multithread environment, as soon as you use a common hashtable. That's not a reason to not use a multithread environment but we have of course to think about a way to try and improve our proceduresBertTuyt wrote:Gerard,
thats what i also see in my 4-core implementation.
When running multiple times (even when i completely clear the hashtable at the start), i get different results (best move and score).
Sometimes these score-differences are "relatively" large.
This is also the reason that I played with the single-core implementation during the most recent tournament.
Next week I will start to re-test the parallel search-algorithm as a preparation for the next open Dutch tournament.
My target is to have a multi-core search ( 4 - 8 threads) and the 7p database.
Bert
Gérard
