Everything I touch gets simplified...

[maksimKorzh]

Now finally I can share the perft results that IMO are really worth of butchering SF the way I did it:


3x faster than Fairy Stockfish
5x faster than Chameleon (SF derivative that plays xiangqi)
Both use magic bitboards.
Mine is array based (11*14)

[JohnWoe]

Hi guys

Quite surprisingly my work on integrating a custom array based move generator (to play Chienese chess Xiangqi) into Stockfish
goes well - currently I already have a pseudo legal move generator generating moves, encoding them into integers and populating
move list. I've disabled bitboards, changed the internal board array's size (11*14), altered functions to parse FEN and print board.
(I'm working within files position.cpp, position.h, movegen.cpp, search.cpp, types.h, uci.cpp)
https://github.com/maksimKorzh/xiangqi-stockfish

To test above you can build it via:

Code: Select all

make build make build ARCH=x86-64 comp=gcc

And then try commands:
d // SF specific to print board, works within UCI loop => would print xiangqi board
position startpos moves dddd // would invoke move generator or move validation (doesn't validate yet) and prints the generated moves
Next step is to alter sf's pos.do_move() and pos.undo.move() and run perft test.

And now regarding the title of this post.
Probably it happens due to my dumb nature (see avatar). By fact I'm just disabling the most sf's native functionality and replacing it
with the patterns I've worked out within my own engines. I can already see that what I wanted initially to achieve - combine
a custom movegen generating moves for xiangqi with powerful sf's search is possible, however in order to do it I'll need to strip
lot's of stuff from search as well, just a few tech examples to show what I mean:
1. SF scores moves for move ordering using A specific structure RootMoves which is getting populated by c++'s emplace_back() method
2. Obviously the search itself is invoked within the main thread context (assuming 1 thread by default)

What I'm gonna do is to score moves during move generation and get rid of threads because it's extremely hard to debug when
the position instance within the thread might not always be the same as the one initialized globally - I first encountered that when
tried to run perft depth 1 - it generated moves but definitely for somewhat another position that I've set up but if do the same directly
it works perfectly well.

So it's really hard to say whether what I came up with eventually would still be possible to call stockfish or not...
Things that would remain from sf:
1. C++ (it's the biggest pain for me for C++ is just too complicated for me with tons of seemingly unnecessary features complicating the development)
2. Sources spitted into files (you know I love one source file engines regardless of programming language)
3. Position class and it's interface (would get significantly reduced later I hope)
4. Search routine

Now A natural question is arising why not to just right an angine from scratch and reuse sf's search?
well, I wanted to go that way, but in that case I wouldn't learn about how sf works itself and I need to say
that having a pain with C++ and world class project implementation is a really nice source of inspiration.
The more I understand how the original code was working (before I've burnt the bridges) the more amazed I get.
So probably the main reason of doing this is is to learn new things from top engine.
However it's a "learning by breaking" approach - just like when I was a kid I could break a radio to see "what is inside"...
Obviously radio stopped working forever after that and I was hated by my dad for that...
This time I'm turning palace into a barn but you just imagine how much fun that brings)

Hello!
Nice project!
I'm actually surprised Fairy-Stockfish is so damn slow!
Well it's super complex so it makes sense!

I like C++ much more than C. To create something little in C you have to write billions of lines.

Pulling SF search out is next to impossible.
However if you create a SF search ( +QSearch ) module I'll happily grab another +500 ( 3000 -> 3500 ) Elo to Mayhem!
So my idea was to clone the whole SF and strip out stuff while keeping it stable.

[maksimKorzh]

Hi guys

Quite surprisingly my work on integrating a custom array based move generator (to play Chienese chess Xiangqi) into Stockfish
goes well - currently I already have a pseudo legal move generator generating moves, encoding them into integers and populating
move list. I've disabled bitboards, changed the internal board array's size (11*14), altered functions to parse FEN and print board.
(I'm working within files position.cpp, position.h, movegen.cpp, search.cpp, types.h, uci.cpp)
https://github.com/maksimKorzh/xiangqi-stockfish

To test above you can build it via:

Code: Select all

make build make build ARCH=x86-64 comp=gcc

And then try commands:
d // SF specific to print board, works within UCI loop => would print xiangqi board
position startpos moves dddd // would invoke move generator or move validation (doesn't validate yet) and prints the generated moves
Next step is to alter sf's pos.do_move() and pos.undo.move() and run perft test.

And now regarding the title of this post.
Probably it happens due to my dumb nature (see avatar). By fact I'm just disabling the most sf's native functionality and replacing it
with the patterns I've worked out within my own engines. I can already see that what I wanted initially to achieve - combine
a custom movegen generating moves for xiangqi with powerful sf's search is possible, however in order to do it I'll need to strip
lot's of stuff from search as well, just a few tech examples to show what I mean:
1. SF scores moves for move ordering using A specific structure RootMoves which is getting populated by c++'s emplace_back() method
2. Obviously the search itself is invoked within the main thread context (assuming 1 thread by default)

What I'm gonna do is to score moves during move generation and get rid of threads because it's extremely hard to debug when
the position instance within the thread might not always be the same as the one initialized globally - I first encountered that when
tried to run perft depth 1 - it generated moves but definitely for somewhat another position that I've set up but if do the same directly
it works perfectly well.

So it's really hard to say whether what I came up with eventually would still be possible to call stockfish or not...
Things that would remain from sf:
1. C++ (it's the biggest pain for me for C++ is just too complicated for me with tons of seemingly unnecessary features complicating the development)
2. Sources spitted into files (you know I love one source file engines regardless of programming language)
3. Position class and it's interface (would get significantly reduced later I hope)
4. Search routine

Now A natural question is arising why not to just right an angine from scratch and reuse sf's search?
well, I wanted to go that way, but in that case I wouldn't learn about how sf works itself and I need to say
that having a pain with C++ and world class project implementation is a really nice source of inspiration.
The more I understand how the original code was working (before I've burnt the bridges) the more amazed I get.
So probably the main reason of doing this is is to learn new things from top engine.
However it's a "learning by breaking" approach - just like when I was a kid I could break a radio to see "what is inside"...
Obviously radio stopped working forever after that and I was hated by my dad for that...
This time I'm turning palace into a barn but you just imagine how much fun that brings)

Hello!
Nice project!
I'm actually surprised Fairy-Stockfish is so damn slow!
Well it's super complex so it makes sense!

I like C++ much more than C. To create something little in C you have to write billions of lines.

Pulling SF search out is next to impossible.
However if you create a SF search ( +QSearch ) module I'll happily grab another +500 ( 3000 -> 3500 ) Elo to Mayhem!
So my idea was to clone the whole SF and strip out stuff while keeping it stable.

Hi John

re: Pulling SF search out is next to impossible.
- Agreed. That's why at most I've removed... I don't know... 90% of original sf's code)
But from now on it's actually already possible to reuse search as a module like I wanted initially,
However the blind copypasting still wouldn't work because anyway it would rely on position class.

Currently, here's the stuff left from original stockfish:
1. C++ project structure (something I couldn't make on my own from scratch)
2. Position class (heavily butchered though, removed bitboards and all unused stuff)
3. State info class (heavily butchered as well)
4. UCI module

Movegen is now completely rewritten (to fit xiangqi)
Search is now a blank placeholder, I'm gonna reuse this function: https://github.com/official-stockfish/S ... h.cpp#L148
(literally all I wanted from stockfish)
Evaluation is replaced by xiangqi PST placeholder

You might wonder why didn't I write an engine from scratch and simply grab alpha-beta search and considered butchering SF instead.
Well, it was really exciting at very least, now I got familiar with SF's code base, ideas and concepts being involved there.
It provides almost never-ending field for the future improvements.
I wouldn't learn that much in case of just grabbing sf's search.