New Architectures in Computer Chess

[Gerd Isenberg]

Actually his "comparison" was only for move generation with rotated bitboards. That means the make/unmake overhead is a biggie. He failed to include the other advantages of bitboards and only emphasized the weakest point. And then there are magic bitboards without the extra overhead of maintaining the rotated occipied-squares data.

The only interesting point I saw was the recursive see data that, done correctly, might eliminate a bit of overhead. Maybe.

The 15*12 mailbox was new to me. I am still in the "mental dust" phase to figure out what advantage the odd rank size of 15 exactly has, despite the fact of a most dense solution where

Code: Select all

delta = offset + sq1 - sq2 

are unique with respect to distance and direction.

While reading the thesis, my mind is somehow swinging between brilliancy and disappointment. I need to read things multiple times until I get it. Still too early for me for a conclusion. I think my initial recommendation is true - even if there were some disappointments and disputed issues.

The 32 and 64-bit Loops are strong engines, mailbox as well as magic bitboards. I am not aware of any other program that can switch between both approaches that easily, while I believe that this information hiding and abstraction of the board representation (or architecture) will penalize bitboards more or less.

[Gerd Isenberg]

Came in the mail over the summer... so Yes I have it.

Guess possible request for an expertise or university cooperation - or did you or your university pay some bucks?

[bob]

Came in the mail over the summer... so Yes I have it.

Guess possible request for an expertise or university cooperation - or did you or your university pay some bucks?

It just showed up in the mail in an envelope.

[bob]

According to Fritz, Chrilly used the New Technology approach in Hydra as well.

The approach used in Hydra is documented in several papers and doesn't have anything to do with what you describe. (It's hardly original, and traces back to the Ken Thompson system in Belle).

I guess Fritz completely misunderstood those papers if he made such a claim.

Read the thesis! 2.1.1 The Chess Machine Hydra, Page 11.

Due to the simplicity and the ease of implementation, this computer-chess architecture could be implemented into the existing Hydra project [three papers referred] in a short time.... (since 2006)

According to a statement by Donninger, the efficiency increment ...

It seems that we are somehow talking apples and oranges. The Belle approach was hardware based, using the same sort of technology used in Hydra (much older and less dense of course). Belle was based on the "intelligent square" approach with a complex finite-state-machine used to extract victims, aggressors, etc. A loop is not practical in such an implementation, so I am not sure what Chrilly nor the author is suggesting, since it really doesn't make any sense in the context of the hydra FPGA hardware approach...

[Gerd Isenberg]

It seems that we are somehow talking apples and oranges. The Belle approach was hardware based, using the same sort of technology used in Hydra (much older and less dense of course). Belle was based on the "intelligent square" approach with a complex finite-state-machine used to extract victims, aggressors, etc. A loop is not practical in such an implementation, so I am not sure what Chrilly nor the author is suggesting, since it really doesn't make any sense in the context of the hydra FPGA hardware approach...

Hydra is not only FPGA, but even the FPGA search improved - according to Chrilly, as mentioned by Fritz Reul on page 11 of his thesis. So your paper is probably preliminary and outdated. Don't ask me how and by how much, I only quoted Fritz Reul.

[bob]

It seems that we are somehow talking apples and oranges. The Belle approach was hardware based, using the same sort of technology used in Hydra (much older and less dense of course). Belle was based on the "intelligent square" approach with a complex finite-state-machine used to extract victims, aggressors, etc. A loop is not practical in such an implementation, so I am not sure what Chrilly nor the author is suggesting, since it really doesn't make any sense in the context of the hydra FPGA hardware approach...

Hydra is not only FPGA, but even the FPGA search improved - according to Chrilly, as mentioned by Fritz Reul on page 11 of his thesis. So your paper is probably preliminary and outdated. Don't ask me how and by how much, I only quoted Fritz Reul.

Not sure what you mean by "my paper"? My copy of the thesis? This is a bound copy that was sent to me, printed by "Gildeprint". Last numbered page is 153.

The FPGA part is certainly cloned from Belle. Which means the board representation is fixed there. I can't imagine using a different representation in the software part of the search, then converting to something useful in the FPGA. The basic idea is that the FPGA hardware maintains _the_ board. It has things like Make, Unmake, Evaluate, and of course Search. It is not so easy to stuff a position into one of these things and really doesn't make any sense from a design perspective either.

I could be wrong, of course, but varying from the Belle approach would seem to be _very_ difficult.

[Gerd Isenberg]

Not sure what you mean by "my paper"? My copy of the thesis?

Yes, sorry for being unclear.

This is a bound copy that was sent to me, printed by "Gildeprint". Last numbered page is 153.

Same for me. You can read his statement about Hydra on page 11, which you probably don't believe, if I understand correctly.

[bob]

Not sure what you mean by "my paper"? My copy of the thesis?

Yes, sorry for being unclear.

This is a bound copy that was sent to me, printed by "Gildeprint". Last numbered page is 153.

Same for me. You can read his statement about Hydra on page 11, which you probably don't believe, if I understand correctly.

Sounds like random text produced by a large room full of monkeys, IMHO. Hydra was _clearly_ based on FPGA hardware and used the belle approach, which was discussed at length by CD. Same for deep thought/deep blue hardware. How one would incorporate some odd chess board representation into a program that uses hardware to maintain the chess board is beyond me. All three of those machines (Belle, Deep Thought/Blue and Hydra) were based on a synchronous FSM model. Loops do _not_ transfer to such approaches because, by their very nature, they are variable-length operations. That was one of the places where the Belle design led to high speeds.

I really have no idea what that paragraph means, and more importantly, I really don't care. I know enough of their hardware approach which came from Ken and Hsu. I'm not going to try to parse that paragraph and make any sense of it at all... Unless they departed significantly from the Belle approach, it doesn't make any sense. And it doesn't make sense to depart from the belle approach on a synchronous hardware platform like an FPGA.

[Gian-Carlo Pascutto]

I can't imagine using a different representation in the software part of the search, then converting to something useful in the FPGA.

This would be quite reasonable if the top few plies run in software. You can maintain the board in whatever is convenient there and then blast the position to the FPGA for the last few plies. No requirement to have the same board representation.

It could make sense to use this on the software side, but I agree with you it makes no sense to use it on the FPGA. And the software representation shouldn't have much effect on speed, because why have the FPGA otherwhise.

[Zach Wegner]

Not sure what you mean by "my paper"? My copy of the thesis? This is a bound copy that was sent to me, printed by "Gildeprint". Last numbered page is 153.

The FPGA part is certainly cloned from Belle. Which means the board representation is fixed there. I can't imagine using a different representation in the software part of the search, then converting to something useful in the FPGA. The basic idea is that the FPGA hardware maintains _the_ board. It has things like Make, Unmake, Evaluate, and of course Search. It is not so easy to stuff a position into one of these things and really doesn't make any sense from a design perspective either.

I could be wrong, of course, but varying from the Belle approach would seem to be _very_ difficult.

Belle-style is certainly not the only feasible way to do hardware move generation. Some bitboard approaches work in the same FSM manner, while being a bit more flexible (and perhaps even easier to implement in hardware). Gerd's quad bitboard approach comes to mind, as well as Steffan Westcott's similar ideas.