I need help, performance wall!

[Fguy64]

Maybe you can describe, how do you sort the positions before calling alpha bata?

You must have some quick evaluation or else how do you search for the more likely best moves first?

I don't sort positions, I sort moves. That's a very important distinction.

Also, there is no moveOrdering before the initial call to alphaBeta, only before the recursive calls.

I use MVV/LVA move ordering. in which captures are evaluated before regular moves. That is pretty standard. And you only need to know the current position (before the moves) not the position after.

Your strategy may indeed result in a better move ordering, but it sounds like it might be defeating the purpose, in that the work is needed to provide the ordering outweighs the work saved by using the ordering, do you see what I mean? Also, I suspect that your alphaBeta pruning might not be working as you expect, but I am not sure on that point.

I found the following site very helpful for all of this stuff.

http://web.archive.org/web/200404032117 ... /index.htm

[hgm]

First search the PV move of the previous iteration (when you are still on that PV). Next capture the most valuable piece that you can capture. That should more or less do it, all the rest is refinement.

[aberent]

First search the PV move of the previous iteration (when you are still on that PV). Next capture the most valuable piece that you can capture. That should more or less do it, all the rest is refinement.

What does PV move stand for (Principle Variation)? Can you please explain in more detail, sorry I am still learning.

[Aleks Peshkov]

If you actually sort (shuffle) whole _positions_ it is an obvious bottleneck.

[Fguy64]

First search the PV move of the previous iteration (when you are still on that PV). Next capture the most valuable piece that you can capture. That should more or less do it, all the rest is refinement.

You are talking about iterative deepening? OK, I didn't know iterative deepening was being used then yeah, I agree about searching PV first. Still, having recently gone through the ID stuff myself, I would not have expected that not searching the PV first would have been significant enough in and of itself to cause the slow numbers being posted.

[aberent]

I am not using Principle Variation or Iterative Deepening, Just vanilla Alpha Beta.

[Fguy64]

I am not using Principle Variation or Iterative Deepening, Just vanilla Alpha Beta.

OK, then my remarks at the top of this page still stand.

one Question. This process you described for ordering, is that done only once per turn, or is this ordering done at every node in the tree?

[aberent]

I am not using Principle Variation or Iterative Deepening, Just vanilla Alpha Beta.

OK, then my remarks at the top of this page still stand.

one Question. This process you described for ordering, is that done only once per turn, or is this ordering done at every node in the tree?

The ordering is done in every node in both implementations.

[aberent]

Maybe you can describe, how do you sort the positions before calling alpha bata?

You must have some quick evaluation or else how do you search for the more likely best moves first?

I don't sort positions, I sort moves. That's a very important distinction.

Also, there is no moveOrdering before the initial call to alphaBeta, only before the recursive calls.

I use MVV/LVA move ordering. in which captures are evaluated before regular moves. That is pretty standard. And you only need to know the current position (before the moves) not the position after.

Your strategy may indeed result in a better move ordering, but it sounds like it might be defeating the purpose, in that the work is needed to provide the ordering outweighs the work saved by using the ordering, do you see what I mean? Also, I suspect that your alphaBeta pruning might not be working as you expect, but I am not sure on that point.

I found the following site very helpful for all of this stuff.

http://web.archive.org/web/200404032117 ... /index.htm

Thanks that is an excellent article, specially the move ordering part.

What I am really wondering is if you know how many nodes per second does your engine search and how many nodes does it search of the starting position?

[Fguy64]

Maybe you can describe, how do you sort the positions before calling alpha bata?

You must have some quick evaluation or else how do you search for the more likely best moves first?

I don't sort positions, I sort moves. That's a very important distinction.

Also, there is no moveOrdering before the initial call to alphaBeta, only before the recursive calls.

I use MVV/LVA move ordering. in which captures are evaluated before regular moves. That is pretty standard. And you only need to know the current position (before the moves) not the position after.

Your strategy may indeed result in a better move ordering, but it sounds like it might be defeating the purpose, in that the work is needed to provide the ordering outweighs the work saved by using the ordering, do you see what I mean? Also, I suspect that your alphaBeta pruning might not be working as you expect, but I am not sure on that point.

I found the following site very helpful for all of this stuff.

http://web.archive.org/web/200404032117 ... /index.htm

Thanks that is an excellent article, specially the move ordering part.

What I am really wondering is if you know how many nodes per second does your engine search and how many nodes does it search of the starting position?

Well, what I do calculate is the number of leaf nodes, i.e. the number of times my evaluate() function is called, and I also measure the time time taken to come up with a move. Naturally, the more effective your move ordering, the more effective your alphBeta pruning is, and the fewer leaf nodes you will have to evaluate, but these improvements come at a cost of time, and this cost has to be weighed against any improvements, which I expect you understand since you talk about nodes per second.

What I use as a benchmark is a standard set of positions, in the form of fen strings, in which it is known what the optimal move is, and how many ply are required to solve the position. I know when I have made a good improvement to my algorithm when I compare my time and leaf nodes for these positions to the previous attempts.

You can find such a set of positions here.

http://www.jakob.at/steffen/hossa/testsuites/wac.html

if you PM me your email, I can send you an Excel spreadsheet I have set up for the purpose.

Anyways, in regards to your process of move ordering at every node, I would say that is indeed a big part of your problem, but some of the people who have examined your code, such as Sven, really know their stuff, so I would hav expected them to pick up on that.