lithander wrote: ↑Sat Jan 30, 2021 12:34 am
mvanthoor wrote: ↑Fri Jan 29, 2021 1:33 am
I look forward to playing Rustic against it some day.
I guess with the self imposed constraint of making my first engine intentionally a minimal one that will never be a fair fight!
It depends... my engine is also minimal, but in a different sort of way. I want to try and create an engine as strong as possible, with the least amount of features. That means that I'll add new features only when I think the current ones are maxed out.
At this point in the development, there are only two things I can do:
- Add new features
- Start looking into Texel tuning for the material+PST evaluation.
I'll probably add a transposition table first, because it greatly boosts endgame performance (and increases search depth in the middle game) without actually adding any new knowledge or capabilities to the engine. Then I think I'll start looking into tuning the PST's before I do other things.
I've run a test against your engine (the BigExecutables version). At this point it is indeed not a fair fight. Some observations:
- Rustic is 4-7x faster, depending on the position. You'd need to look into the code with a profiler to improve this.
- Your engine doesn't seem to have quiescence search (or it doesn't work correctly), as it sometimes just gives away a piece for no reason.
- The UCI commands on the command line have to come in a very particular order. The engine works in CuteChess, but I have been able to crash the engine or make it quit in numerous ways when typing valid UCI commands on the command line.
That's a problem future-me will have to solve in whatever more ambitious engine I'll attempt after minimal chess.
It might sound crazy to some of you that I limit myself intentionally like that but I've experienced burning out on too ambitious projects time and time again and learned my lesson. And so I'm not trying to maximize the ELO of my first engine but rather it's price-performance ratio where price may be defined as the confusion and despair a chess programming noob is experiencing while trying to understand, debug and maintain it's source code.
Doesn't sound strange at all. For me, Rustic is a very long term project. I started it in August 2019, when I finally (FINALLY after 20 years) bit the bullet and decided to write an engine. I set the following goals:
- Clear, readable code that I can understand myself in another 10 years
- It has to be well commented and documented
- Every function I add has to be extensively tested. I DON'T want to go back and fix bugs; only go back and improve or optimize. (In the entire development of the engine up until now, I only had to fix ONE bug: at some point I forgot to remove a castling permission on rook capture.)
- Speed. I'm running this engine through a profiler more often than is healthy for a sane person, and I try to improve/replace any line of code that is slower than other lines.
- Strength per feature. There are many engines that have lots and lots of features, but still are weak due to bugs. I don't want that, because these kinds of bugs are VERY hard to fix long after the fact.
- It can't be written in C or C++.
The one thing you're not seeing is: "I want to achieve X ELO within Y months, or be on spot A of CCRL before..." Not in your life. I'll write code for the engine when I have the time and motivation... I had two huge development sprints to get to the point where the engine is now (because I had the time and motivation). Now I have less time due to several factors, so development is slower. That isn't a problem, because the engine is basically done: I "only" "need" to add features to make it stronger.
Nope. So far I only used the testing approach to compare minmax vs alpha beta. I'm going to add move ordering and some kind of iterative deepening next. I can post the results here if anyone else is curious!
I'm certainly curious. I'm always curious to see how far new engines can go, especially in the beginning: how strong can they become with the features they have?