Progress on Rustic

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

Terje
Posts: 347
Joined: Tue Nov 19, 2019 4:34 am
Location: https://github.com/TerjeKir/weiss
Full name: Terje Kirstihagen

Re: Progress on Rustic

Post by Terje »

mvanthoor wrote: Fri Oct 02, 2020 1:59 am PS: For now, I'm rolling my own PSQT's and piece values. Later I'll add tapered evaluation, and even later I'll optimize/tune this somehow. I dislike PSQT's with A1 on the top left. I make mistakes when changing them. I have the impression that PSQT's with A1 = 0 and a flip table for black are more common, but mine are from white's point of view (E1 is element 60 in the table, so A1 is element 56), so I have a FLIP table for white, instead of black.
I have PSQTs written out for blacks PoV and flip for white too, much easier to parse as a human even if I never manually change them anymore :)

Nice to see you are progressing!
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Progress on Rustic

Post by mvanthoor »

Terje wrote: Fri Oct 02, 2020 2:15 am
mvanthoor wrote: Fri Oct 02, 2020 1:59 am PS: For now, I'm rolling my own PSQT's and piece values. Later I'll add tapered evaluation, and even later I'll optimize/tune this somehow. I dislike PSQT's with A1 on the top left. I make mistakes when changing them. I have the impression that PSQT's with A1 = 0 and a flip table for black are more common, but mine are from white's point of view (E1 is element 60 in the table, so A1 is element 56), so I have a FLIP table for white, instead of black.
I have PSQTs written out for blacks PoV and flip for white too, much easier to parse as a human even if I never manually change them anymore :)

Nice to see you are progressing!
Thanks :)

Rustic's internal threading infrastructure cost me quite some time to get right. Modularization vs. over-engineering, and getting it done the "Rust way". Everything seems to work as intended. The Comm module runs on its own, all the time, and the search wakes up and 'does searchy stuff' when it's given a kick. (It is already capable of initializing and running search workers, for future SMP use...)

With regard to piece tables and POV.. it depends what you mean. POV with regard to the chess board? Or POV with regard to square numbers... my PSQT tables are from white's POV as if you're looking at a diagram, with A1 at the lower left, and thus, H1 at the lower right (elements 56-63). Because internally the engine uses some arrays where A1 is element 0, White needs a flip table.

Preliminary implementation / placeholders are here:
https://github.com/mvanthoor/rustic/blo ... on/psqt.rs


Somewhere in the next week or so I hope to be able to play a rudimentary game in the console. (Material + PSQT + A/B search.) I've decided to at least also implement quiescent search and mvv-lva. If I don't, I can just as well use mini-max in the first version; and if I do, the engine will be stuck at ply 6 or so.
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
Terje
Posts: 347
Joined: Tue Nov 19, 2019 4:34 am
Location: https://github.com/TerjeKir/weiss
Full name: Terje Kirstihagen

Re: Progress on Rustic

Post by Terje »

mvanthoor wrote: Fri Oct 02, 2020 2:33 am
Terje wrote: Fri Oct 02, 2020 2:15 am
mvanthoor wrote: Fri Oct 02, 2020 1:59 am PS: For now, I'm rolling my own PSQT's and piece values. Later I'll add tapered evaluation, and even later I'll optimize/tune this somehow. I dislike PSQT's with A1 on the top left. I make mistakes when changing them. I have the impression that PSQT's with A1 = 0 and a flip table for black are more common, but mine are from white's point of view (E1 is element 60 in the table, so A1 is element 56), so I have a FLIP table for white, instead of black.
I have PSQTs written out for blacks PoV and flip for white too, much easier to parse as a human even if I never manually change them anymore :)

Nice to see you are progressing!
Thanks :)

Rustic's internal threading infrastructure cost me quite some time to get right. Modularization vs. over-engineering, and getting it done the "Rust way". Everything seems to work as intended. The Comm module runs on its own, all the time, and the search wakes up and 'does searchy stuff' when it's given a kick. (It is already capable of initializing and running search workers, for future SMP use...)

With regard to piece tables and POV.. it depends what you mean. POV with regard to the chess board? Or POV with regard to square numbers... my PSQT tables are from white's POV as if you're looking at a diagram, with A1 at the lower left, and thus, H1 at the lower right (elements 56-63). Because internally the engine uses some arrays where A1 is element 0, White needs a flip table.

Preliminary implementation / placeholders are here:
https://github.com/mvanthoor/rustic/blo ... on/psqt.rs


Somewhere in the next week or so I hope to be able to play a rudimentary game in the console. (Material + PSQT + A/B search.) I've decided to at least also implement quiescent search and mvv-lva. If I don't, I can just as well use mini-max in the first version; and if I do, the engine will be stuck at ply 6 or so.
Black's PoV as in the score a black piece would have on the square, so the same as you describe :)
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Progress on Rustic

Post by mvanthoor »

Terje wrote: Fri Oct 02, 2020 2:39 am Black's PoV as in the score a black piece would have on the square, so the same as you describe :)
OK :) I never play chess from black's point of view (so I find it strange that you call my/our setup PSQT's "from black POV"), except when a game myself (over the board, or on screen).

Actually, I find it confusing and somewhat irritating, if people who review/comment games on YouTube, or modern books, view games from black's perspective. In the past, a diagram was ALWAYS printed with white at the bottom. (When playing endgames, it's actually very hard to see which side is what, and what is the direction of play, if the diagram can be either white at the bottom or black at the bottom.)
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
Terje
Posts: 347
Joined: Tue Nov 19, 2019 4:34 am
Location: https://github.com/TerjeKir/weiss
Full name: Terje Kirstihagen

Re: Progress on Rustic

Post by Terje »

mvanthoor wrote: Fri Oct 02, 2020 2:53 am
Terje wrote: Fri Oct 02, 2020 2:39 am Black's PoV as in the score a black piece would have on the square, so the same as you describe :)
OK :) I never play chess from black's point of view (so I find it strange that you call my/our setup PSQT's "from black POV"), except when a game myself (over the board, or on screen).

Actually, I find it confusing and somewhat irritating, if people who review/comment games on YouTube, or modern books, view games from black's perspective. In the past, a diagram was ALWAYS printed with white at the bottom. (When playing endgames, it's actually very hard to see which side is what, and what is the direction of play, if the diagram can be either white at the bottom or black at the bottom.)
The resulting 'diagram' the written array looks like is the board seen from white's PoV, but the array represents black's values, so I suppose it's just a matter of perspective, chess vs programming :)
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Progress on Rustic

Post by mvanthoor »

The engine can now apply its PSQT's to the position. I've played a few openings (both sides myself) in the console, and calculated what each PSQT adjustment should be for black and white in the position, and the final evaluation. It seems to work. Additionally, Rustic now has an ASCII-art logo that fits its banner :P

Final stages to Version 1:
A/B-search
Q-search
MVV-LVA
UCI

Almost done.

As if this is ever gonna be 'ready ' ... There's pruning, and hash tables, and evaluations, oh my! :roll:

Code: Select all

d888888b                      dP   oo
88     88                     88
88oooo88  88    88  d8888b  d8888P dP d88888b
88    88  88    88  8ooooo    88   88 88
88     88 88    88       88   88   88 88
88     88  88888P  888888P    dP   dP 888888P
ooooooooooooooooooooooooooooooooooooooooooooo

Engine: Rustic Alpha 1
Author: Marcel Vanthoor
EMail: mail@marcelvanthoor.nl
Website: https://rustic-chess.org/

Initializing engine...
Starting Comm Reader thread.
Starting Search Control thread.
Starting Comm Control thread.
Setting up 1 workers.
Creating worker 1.
Activating worker 1.
================================================

8   r n b q k b n r
7   i i i i i i i i
6   . . . . . . . .
5   . . . . . . . .
4   . . . . . . . .
3   . . . . . . . .
2   I I I I I I I I
1   R N B Q K B N R

    A B C D E F G H

Zobrist key:        819aa694337673fb
Active Color:       White
Castling:           KQkq
En Passant:         -
Half-move clock:    0
Full-move number:   1

Rustic > e
w_psqt: -50
b_psqt: -50
Evaluation: 0
================================================

8   r n b q k b n r
7   i i i i i i i i
6   . . . . . . . .
5   . . . . . . . .
4   . . . . . . . .
3   . . . . . . . .
2   I I I I I I I I
1   R N B Q K B N R

    A B C D E F G H

Zobrist key:        819aa694337673fb
Active Color:       White
Castling:           KQkq
En Passant:         -
Half-move clock:    0
Full-move number:   1

Rustic > d2d4
w_psqt: -30
b_psqt: -50
Evaluation: 20
================================================

8   r n b q k b n r
7   i i i i i i i i
6   . . . . . . . .
5   . . . . . . . .
4   . . . I . . . .
3   . . . . . . . .
2   I I I . I I I I
1   R N B Q K B N R

    A B C D E F G H

Zobrist key:        c8044c147be13960
Active Color:       Black
Castling:           KQkq
En Passant:         d3
Half-move clock:    0
Full-move number:   1

Rustic >
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Progress on Rustic

Post by mvanthoor »

Even though everything was working fine, I've just nuked about 10 evenings of work. The search module was too much over-engineered. Having 500 lines of code only for arranging communication between threads is too much of a good thing... especially if you're getting into trouble keeping the senders and receivers untangled in your own mind. That's ridiculous.

The Search module will still be active (so I don't have to start and end threads all the time for each new move), but it'll be a lot simpler. The Iterative Deepening thread will be controlled by the engine directly, while ID itself will control its workers; without a Search Control thread between the engine, ID, and the workers.

I also refactored the threads in the comm module, so there's now basically an In and Out thread (incoming and outgoing information). The In thread will quit itself immediately if it receives 'quit' (obviously after sending this to the engine's thread first); the engine will then quit the thread for outgoing information by sending a command instead of an outgoing message. Much simpler that way. (Of course the engine will also quit any other threads, and its own main thread.)

Somewhere this week I'll write a new ID-function/thread.
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
User avatar
maksimKorzh
Posts: 771
Joined: Sat Sep 08, 2018 5:37 pm
Location: Ukraine
Full name: Maksim Korzh

Re: Progress on Rustic

Post by maksimKorzh »

Cool web site for your engine, Marcel! I love the idea of crafting site of MD file, it's really cool.
On the other hand it's a bit strange to me WHY actually people create websites for their engines and even buying domain names.
I can understand if one is selling it... but if not - that seems to me a bit strange.
Anyway, I love it's minimalist design - well done!
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Progress on Rustic

Post by mvanthoor »

maksimKorzh wrote: Wed Oct 07, 2020 12:59 am Cool web site for your engine, Marcel! I love the idea of crafting site of MD file, it's really cool.
On the other hand it's a bit strange to me WHY actually people create websites for their engines and even buying domain names.
I can understand if one is selling it... but if not - that seems to me a bit strange.
Anyway, I love it's minimalist design - well done!
Thanks :) The website was generated using MDBOOK:

https://github.com/rust-lang/mdBook/releases

This tool generates websites from markdown files. The tool itself is written in Rust, and it's also used to generate Rust's manual/book and documentation websites.

Why people create websites for their engines? Just to give it its own identity.

If I write an engine and put it on Github, it's just one of the five billion other engines that are hosted there. Why would I put all this time and effort into an engine and then throw it on Github, where it's just another pile of code? This chess engine is something I wanted to write for a LONG time, and now that I'm actually doing it, I want it to have it's own place somewhere.

You have a Youtube series about your engine's development. I'm going to have a website / book. Same thing, different medium.

Apart from that, I also want it to be the main side project where I can point to if someone in the future asks me AGAIN "if I can write and document software from scratch."
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL
User avatar
mvanthoor
Posts: 1784
Joined: Wed Jul 03, 2019 4:42 pm
Location: Netherlands
Full name: Marcel Vanthoor

Re: Progress on Rustic

Post by mvanthoor »

PS: With regard to the search: I've now implemented a simple struct with one thread, which will can accept Start, Stop, and Quit from the engine's thread. The implementation has been simplified a lot.

The search thread just runs Iterative Deepening and Alpha/Beta as usual.

The difference with (for example) VICE is that I don't have to peek into the keyboard buffer to get incoming input. Because everything is threaded, the main engine thread can receive reports from any module (such as Comm or Search), and send output or commands accordingly.

This won't be multi-threaded (edit: I mean: multi-CPU search) of course, because iterative deepning and alpha/beta are both in the same Search thread for now, but I can split off things later, after the search is complete.

Now I just have to fill in the Id and A/B functions. (And Qsearch obviously.)
Last edited by mvanthoor on Wed Oct 07, 2020 1:51 pm, edited 1 time in total.
Author of Rustic, an engine written in Rust.
Releases | Code | Docs | Progress | CCRL