MadChess 2.0 Development

[mar]

This is what I meant by typical: https://www.youtube.com/watch?v=rX0ItVEVjHc#t=4637
Sad but true.

[lucasart]

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.

I never said there is no value in managed languages or OOP. What I say is:
- dont equate managed languages and OOP. they are different things.
- OOP, by itself, should not create performance penalty. it's nothing but syntactic sugar that should compild in equivalent code as procedural version.
- Using OOP or procedural is not bad. What is bad is that an entire generation of programmers have been brainwashed to believe that _everything_ should be represented by OOP, and that coding that way makes things easier. This is Java marketing kool-aid, and it is simply wrong.
- Correct design involves a subtle mix of OOP (where it makes sense) and procedural. Only experience can teach you where OOP fits, and where procedural is best.
- Take Python for example. Python programmers use both procedural and OOP.

Managed languages certainly add value. No doubt about that. If I wanted to write something like cutechess-cli, I would do it in Python, certainly not in C. For most real life programming situations, managed languages like C# or Python are the best choice. For performance critical code, you have no other choice than C or C++, unfortunately.

[emadsen]

Correct design involves a subtle mix of OOP (where it makes sense) and procedural. Only experience can teach you where OOP fits, and where procedural is best.

OK Lucas, I think we're on the same page. I have seen some ridiculous model-the-universe OO designs.

[emadsen]

I added tapered evaluation, which for now includes only middlegame and endgame piece square tables. +107 ELO. MadChess is now approximately 1600 ELO.

http://www.madchess.net/post/madchess-2-0-beta-build-21

[Sven]

I added tapered evaluation, which for now includes only middlegame and endgame piece square tables. +107 ELO. MadChess is now approximately 1600 ELO.

Hi Erik,

in a previous post you wrote: "[...] alpha / beta negamax search with aspiration windows and a capture / check evasion quiescence search. Evaluation is limited to material and middlegame piece square tables." Now that is already a lot. Do you have an explanation for the current low rating? Even without null move and hash table I would expect at least a rating of 1800/1900 ELO. According to your other postings speed does not seem to be an issue as well, so what is the problem? Could it be related to move ordering?

[emadsen]

Do you have an explanation for the current low rating? ... Could it be related to move ordering?

Hi Sven,

Yes, I believe it's due to move ordering. I use an int to represent moves, with the higher order bits representing higher priority moves. I noticed the other day I forgot to invert the attacker piece, so MadChess searches Q x Q captures before P x Q. That and I need to write more test code to ensure moves are actually sorted the way I expect them to be sorted.

I also expect to get a good ELO gain from passed / unstoppable pawn knowledge. One item at a time...

[emadsen]

I've added features and fixed bugs. +217 ELO since my last post. MadChess is now approximately 1800 ELO. Still no null move, mobility, king safety, or any reductions or pruning of moves.

Draw By Repetition Bug
Passed Pawns
Time Management
Delay Move Generation
MVV / LVA Move Order

[emadsen]

I've improved the static evaluation and added some simple search reductions (null move and futility pruning). +191 since my last post. MadChess is now approximately 2000 ELO. Still no killer moves, history heuristic, late move reductions, or endgame knowledge.

Futility Pruning
Null Move & Quiescence Recaptures
King Safety
Piece Mobility

[Henk]

I've improved the static evaluation and added some simple search reductions (null move and futility pruning). +191 since my last post. MadChess is now approximately 2000 ELO. Still no killer moves, history heuristic, late move reductions, or endgame knowledge.

Futility Pruning
Null Move & Quiescence Recaptures
King Safety
Piece Mobility

I don't understand why checking KingInCheck for each move in futility pruning is not too expensive. KingInCheck means that you have to generate all or almost all moves and test if it can capture the King. This will certainly never work at depth 1.

[hgm]

I don't understand why checking KingInCheck for each move in futility pruning is not too expensive. KingInCheck means that you have to generate all or almost all moves and test if it can capture the King. This will certainly never work at depth 1.

This is not how it is usually done. When I want to know if a move is checking in my mailbox engines, I calculate the vector from the to-Square to the opponent's King square (from the piece list), and test in a lookup table if that vector matches with one of the possible captures from the moved piece (by bitwise AND between the direction sets). If there is alignment, and the piece is a leaper, it is a check. If it was a slider, you have to scan the ray between to-Square and King.

In addition you have to test for discovered checks by scanning the ray from King in the direction of the from-Square, and test if what you hit is a slider that captures in that direction.

If you are smart, you can combine the latter task for several moves, as usually many moves share the same from-square.

It is still expensive compared to MakeMove(), but far cheaper than a full move generation.