MadChess 2.0 Development

[Henk]

If I would only get the location of a piece from the chess board then I need to inspect each square during evaluation to see if it occupied by a piece. But inspecting an empty square is redundant. Or inspecting a square but it does not contain the piece you want to select.

Iterating over the bitmaps might be an alternative using modulo and divide
or (faster bit operations) but I think that iterating over a list of pieces is faster.

[Joost Buijs]

If I would only get the location of a piece from the chess board then I need to inspect each square during evaluation to see if it occupied by a piece. But inspecting an empty square is redundant. Or inspecting a square but it does not contain the piece you want to select.

Iterating over the bitmaps might be an alternative using modulo and divide
or (faster bit operations) but I think that iterating over a list of pieces is faster.

Iterating over a list of pieces is faster than iterating over a bitboard, but updating it is a different story.
The speed is not very important anyway because move generation only takes a few percent of the total time spent in a chess engine.
For me bitboard representation is the most elegant.

[Henk]

If I would only get the location of a piece from the chess board then I need to inspect each square during evaluation to see if it occupied by a piece. But inspecting an empty square is redundant. Or inspecting a square but it does not contain the piece you want to select.

Iterating over the bitmaps might be an alternative using modulo and divide
or (faster bit operations) but I think that iterating over a list of pieces is faster.

Iterating over a list of pieces is faster than iterating over a bitboard, but updating it is a different story.
The speed is not very important anyway because move generation only takes a few percent of the total time spent in a chess engine.
For me bitboard representation is the most elegant.

I only update these lists before search is started. Also I need to mark a piece as removed in do/undo moves. But Removed is a property of Piece. So there is a performance penalty in do/undo.

Promotion moves give updates too.

[stegemma]

[...]Also I need to mark a piece as removed in do/undo moves. But Removed is a property of Piece. So there is a performance penalty in do/undo.

Promotion moves give updates too.

You make/unmake only a few of the generated moves, do to alpha-beta pruning, so this "penalty" is not very important. I do something similar in my engine. Promotion and castling are other moves that you don't really play often, compared to the numebr of moves generated. For this ones, i use a flag that say "oh, this a special move, do it differently!" so the penalty for executing other moves is nothing more than an if statement.

C++ classes or structures are equivalent, as i've already wrote.

[Henk]

[...]Also I need to mark a piece as removed in do/undo moves. But Removed is a property of Piece. So there is a performance penalty in do/undo.

Promotion moves give updates too.

You make/unmake only a few of the generated moves, do to alpha-beta pruning, so this "penalty" is not very important. I do something similar in my engine. Promotion and castling are other moves that you don't really play often, compared to the numebr of moves generated. For this ones, i use a flag that say "oh, this a special move, do it differently!" so the penalty for executing other moves is nothing more than an if statement.

C++ classes or structures are equivalent, as i've already wrote.

Actually execution time for iterating over the pieces is not so important if you do relatively expensive operations per piece during evaluation.

[emadsen]

Hey Lucas. I agree and disagree with your comments.

I dont think performance hit has anything to do with OOP. The same C code can be written with classes in C++ with no performance penalty (except a few edge cases), and vice versa. I dont see any reason why it would be differnt in C#.

I agree code can be written using classes with little performance penalty. If it's written with an object-oriented style, using all the idiomatic expressions that's typical of manage languages, it's likely to perform much worse. The design patterns typical in C# or Java code, combined with garbage-collected memory management, will produce slower code. In this, I believe we agree.

Languages are designed to make certain tasks easy at the expense of others. One can write some really clever C# or Java code to avoid the performance penalties of the managed runtime- but why? If the programmer is fighting against the language, is avoiding the idiomatic expressions / constructions typical of the language, then why use the language? Again, I believe we agree on this point because on many occasions you have questioned the choice of C# or Java for a chess engine.

Where I disagree with you is your refusal to see any value provided by managed languages and the typical OO style they encourage. I find not only the C# and Java languages extremely valuable for business programming (websites, workflow, application integration), I find the idiomatic object-oriented style of programming very valuable. Yes, typical C# or Java code ignores the memory management and performance issues that receive special attention in pedal-to-the-metal C/C++ code. But if that level of performance has no value to the business, then I'd argue a programmer who spends time solving these irrelevant problems is wasting the company's time and money. Managed languages are widely adopted in the business world because they provide value. They allow the programmer to focus on what matters to the company (time to market, encapsulation of knowledge, extensibility, domain-specific abstractions) at the expense of what doesn't (extreme performance, small memory footprint).

OK, managed languages and the typical OO style they encourage are not best suited for chess engine programming. But who cares? There's no need to write so stridently and disparagingly ("brainwashed") of the techniques employed by others. We're playing with mind toys. We don't need to be lectured on the right way to play.

Anyhow, I enjoyed writing my engine using the OO techniques typical of C# development. And now I'm enjoying writing a new version using more procedural, performance-conscious techniques. And who knows, for a future version I may employ bitboards and C or C++. It's all done for the intellectual challenge and enjoyment. Not as a means to lecture others about code correctness or establish myself as a superior programmer.

[Henk]

Talking about design patterns (the devil) my Piece class is a Bridge because there are two dimensions: 1) color (black, white) and 2) type (pawn, knight, bishop, etc ) with related operations.

By the way I removed the handlers (CapturesHandler, KillerMovesHandler, etc) from my MoveIterator class and changed it into a simple state machine, but performance did not change at all.

[mar]

But if that level of performance has no value to the business, then I'd argue a programmer who spends time solving these irrelevant problems is wasting the company's time and money.

Wrong, hacking something quickly means it will backfire later as soon as it becomes unmaintainable mess costing actually much more money.
This is very typical for managers (biz people in general) that fail to understand this.
They don't care about performance and quality until at a late stage when the "project" is already so bloated that the only cure is to start again from scratch.
I've seen this "pattern" many times, unfortunately.

[emadsen]

Wrong, hacking something quickly... They don't care about performance and quality

I'm not hacking. And I do care about quality. I care about performance if it matters. I won't design chatty interfaces, make I/O calls inside nested loops, read large files into memory versus operating on streams... because it will kill application scalability. Other performance issues are less important and can be ignored. Quality should be a paramount concern regardless of OO versus procedural design decisions.

Bad code is bad code. It's not the province of managed languages.

[mar]

Bad code is bad code. It's not the province of managed languages.

No need to be catchy. Yes, absolutely, language has nothing to do with it.
But if you write something along the lines that biz people don't care about performance, implying that all they care about is to get something done as quickly as possible,
this naturally implies to me that they don't care about quality either. Which is a paradox because quality will save money in the long run.