TT management ?

[Chessnut1071]

I still need millions of nodes to solve the 18-ply mate that Myriddin solved in 7 seconds examining only 75,000 + nodes. Not sure how he did that unless he's using a multiprocessor which I don't have right now.

I really appreciate all the suggestions, I'm a light year ahead of where I started over a year ago; however, everyone here else seems to be a light year ahead of me.

I think one of the reasons for this vast performance difference is the use of extensions and reductions. If all moves in the solution of this mate in 17 ply are checks, an engine that uses check extension (which Myrddin no doubt does) would find it at 9 ply. And you need an enormously smaller number of nodes to do a 9-ply search with check extension compared to an 17-ply search without one.

It would perhaps be possible to get more specific advice if you would actually post the positions you are talking about...

Actually, I can actually beat Myrddin's time and node count: - .0021 seconds ; 49,322 nodes to solution
The function is only looks at check moves for white. The reason why I think Myrddin is so fast is it uses a check pruning function in a parallel search. Check extension will also work. However, I need a generic function and pruning and special cases would be nice on a parallel processor, not my main thread.

Indeed. Shogi mating problems are usually in this form ('tsume'), and my engine HaChu can be switched to such a mode.

For Chess problems this is no requirement, though, and often considered bad form. So in Tsume mode you probably could not solve most problems. While Myrddin no doubt solves them all.

Ok, so I now have a "tsume" thread too which fires off first since I don't have extra cores. I'd like to see how Mydrrin does with a 1/2 dozen deep-ply mates not all in "tsume" mode. Maybe I'm not as slow as I thought. Looking for a real hum dinger to throw at Mydrrin's way.

[JVMerlino]

Indeed. Shogi mating problems are usually in this form ('tsume'), and my engine HaChu can be switched to such a mode.

For Chess problems this is no requirement, though, and often considered bad form. So in Tsume mode you probably could not solve most problems. While Myrddin no doubt solves them all.

Ok, so I now have a "tsume" thread too which fires off first since I don't have extra cores. I'd like to see how Mydrrin does with a 1/2 dozen deep-ply mates not all in "tsume" mode. Maybe I'm not as slow as I thought. Looking for a real hum dinger to throw at Mydrrin's way.

While I am pleased that my mediocre engine is getting some attention on this board, I promise you that it is not special in any way when it comes to search or mate-finding. In fact, there is still in place today some code from very naive and lazy design decisions that I made when I was first creating the engine 13 years ago. One example is that it requires 10MB of stack, solely due to how I pass the PV structures around the search. If I compiled Myrddin with the compiler's default stack size, it will crash almost immediately on Fine 70 (or any position where you can get very deep very quickly) because there's not enough stack. This is embarrassing, but I've never felt like fixing it.

Another example, which was in place up until my most recent release just a few months ago, was that during move generation each move was also examined to see if it gives check, and then flagged as such. I doubt any other engine of Myrddin's strength did this.

So please feel free to continue to find positions for me to throw at Myrddin. But don't be surprised if every other engine around Myrddin's rating (CCRL 2600), and even some far weaker than Myrddin, will do just as well.

[Chessnut1071]

Indeed. Shogi mating problems are usually in this form ('tsume'), and my engine HaChu can be switched to such a mode.

For Chess problems this is no requirement, though, and often considered bad form. So in Tsume mode you probably could not solve most problems. While Myrddin no doubt solves them all.

Ok, so I now have a "tsume" thread too which fires off first since I don't have extra cores. I'd like to see how Mydrrin does with a 1/2 dozen deep-ply mates not all in "tsume" mode. Maybe I'm not as slow as I thought. Looking for a real hum dinger to throw at Mydrrin's way.

While I am pleased that my mediocre engine is getting some attention on this board, I promise you that it is not special in any way when it comes to search or mate-finding. In fact, there is still in place today some code from very naive and lazy design decisions that I made when I was first creating the engine 13 years ago. One example is that it requires 10MB of stack, solely due to how I pass the PV structures around the search. If I compiled Myrddin with the compiler's default stack size, it will crash almost immediately on Fine 70 (or any position where you can get very deep very quickly) because there's not enough stack. This is embarrassing, but I've never felt like fixing it.

Another example, which was in place up until my most recent release just a few months ago, was that during move generation each move was also examined to see if it gives check, and then flagged as such. I doubt any other engine of Myrddin's strength did this.

So please feel free to continue to find positions for me to throw at Myrddin. But don't be surprised if every other engine around Myrddin's rating (CCRL 2600), and even some far weaker than Myrddin, will do just as well.

fen]1n3r2/6pp/ppkp4/1p4b1/1q2PB2/5Q2/PPP3PP/R4RK1 w - - 0 1[[/fen]

Can you find a forced 9-move mate from this position. Puzzle from Chess.Com May 3, 2010. Author gives 1. Pe5+ as the starting sequence. My engine may have a bug since I can't seem to find 1. Pe5 as a forced mate.

[JVMerlino]

[fen]1n3r2/6pp/ppkp4/1p4b1/1q2PB2/5Q2/PPP3PP/R4RK1 w - - 0 1[/fen]

Using ChestUCI I have confirmed that there is no mate in 9 (or mate in 10) in this position.

[Joerg Oster]

TT is a very indirect lookup from a hash to a position.
I wish people started to research more into storing the tree in memory all the time.

Sounds wasteful at first glance - but pruning and walking the positions becomes much faster - and nothing is forgotten ever, making cooperation possible where alphabeta is limited.
It is only usable starting from 32gb of ram - and with the use of memory mapped IO and pcie 4.0 SSDs there is no reason to not go to 512GB or beyond.

Once you can do IO with a few GB/s you can grow and read a tree without performance loss.

I tend to agree.
Keeping the whole search tree in memory is probably the way to go.

Instead of storing only the best value, or the average, why not maintain both?
In tactical and endgame positions, best value is probably superior.

In TB positions one might try to sort moves by their dtz value.
And many more things to try and discover ...

[Chessnut1071]

[fen]1n3r2/6pp/ppkp4/1p4b1/1q2PB2/5Q2/PPP3PP/R4RK1 w - - 0 1[/fen]

Using ChestUCI I have confirmed that there is no mate in 9 (or mate in 10) in this position.

"Guash dhat phuck arella peck arhuba" - that's Alien for "I'm going to kill somebody." I spent 8 days tearing my engine apart trying to find that nonexistent bug. That puzzle won a prize too. Gerrrrrrrrhhhhh!

[JVMerlino]

What was the complete solution presented for the puzzle?

[Chessnut1071]

What was the complete solution presented for the puzzle?

Checkmate in 9 moves! - Chess Forums - Chess.com
1. e5 c7
2. exd6 kd7
3. Qb7+ Ke6
4. Rae1+ Kf5
5. Bxg5+ Kxg5
6. Qe7+ Rf6
7. Re5+ Kg6
8. Qe8* Kh6
9. h5# 1 - 0

I’m not sure how that got through visual screening.

[Chessnut1071]

What was the complete solution presented for the puzzle?

Checkmate in 9 moves! - Chess Forums - Chess.com
1. e5 c7
2. exd6 kd7
3. Qb7+ Ke6
4. Rae1+ Kf5
5. Bxg5+ Kxg5
6. Qe7+ Rf6
7. Re5+ Kg6
8. Qe8* Kh6
9. h5# 1 - 0

I’m not sure how that got through visual screening.

whoops 1. e5 Kc7

[JVMerlino]

What was the complete solution presented for the puzzle?

Checkmate in 9 moves! - Chess Forums - Chess.com
1. e5 c7
2. exd6 kd7
3. Qb7+ Ke6
4. Rae1+ Kf5
5. Bxg5+ Kxg5
6. Qe7+ Rf6
7. Re5+ Kg6
8. Qe8* Kh6
9. h5# 1 - 0

I’m not sure how that got through visual screening.

whoops 1. e5 Kc7

Black's first two moves in the above are inferior.
1...d5 is by far the best reply. Black is still lost, but a forced mate is much farther away.
Also 2...Kc8 holds off the mate at least three moves longer than 2...Kd7. In other words, 2...Kd7 leads to Mate in 7, but 2...Kc8 is at least a Mate in 10.