Comments (6)
Currently, the slowest part of compilation is the build.rs
which generates the lookup tables for the engine. Most chess (library/engine) developers don't build these at compile time, and just generate them once. That may be a smart thing to. Something about that bothers me, though with the whole "Don't put compiled objects in version control." rule.
It's worth noting it builds much faster in release
as compared to debug
builds.
There are a few options though:
-
Thanks to newer versions of Rust, I believe that structures like
BtBoard
no longer need to be astruct
, but can instead be a simpleu64
. This would drastically improve build-time in debug builds (and performance in debug builds), due to some optimizations that aren't done in debug builds. I don't think it would affect release builds, though. -
It's likely possible to optimize the lookup table generation. One simple trick is to try various seeds for the RNG, and simply pick the fastest one.
-
Compile the lookup tables in like a normal person.
This would likely have to be a 4.x release.
from chess.
You can query features in build.rs
, just like in https://github.com/alexcrichton/curl-rust/blob/master/curl-sys/build.rs
So a good start would be to put lookup table support behind a feature guard. And if the feature is a default one, we could avoid a 4.x release for now.
from chess.
One question that remains un-answered is if you are doing debug
builds (without optimizations) or not.
As for the rest, the lookup tables are really needed for the library in general. They are used for very core functionality (like move generation), and there are really no alternative algorithms that match them.
The question of generating the tables is more interesting. Should they be generated at compile time? If so, can that process be optimized?
The second part is why is building these lookup tables slow? I believe (based on research from years ago) the reason is that the structures (like BitBoard
), are structures, and don't map natively to rust types (like u64
). (BitBoard
is a struct BitBoard(u64)
). This causes rust to need optimizations turned on to optimize the operations on BitBoard
.
The reason this was done is because in prior rust versions, it was not possible to implement a local trait on a built-in type. That's no longer true (IIRC), and the whole thing could be re-evaluated.
I'll take a look at the code this week sometime and see if there is anything that can reasonably be done.
from chess.
If someone doesn't use move generation and only makes moves/parses FEN/just works with the board, then the tables are redundant. (for instance: if someone implements a chess client and delegates all the work to a UCI engine)
from chess.
I'm not 100% sure even that is valid. The FEN-parser still needs to check sanity on the board, which means that it needs to ensure the current player is not in check. This uses the lookup tables as well.
These are used a lot throughout the library. I'm not sure feature-gating them is even possible in general, much less something I want to do. In addition, I think there may be other avenues to resolve this issue.
from chess.
It looks like shakmaty has much shorter build times, (at least in debug mode it's < 12s) therefore if the compilation time is more important than runtime performance, shakmaty is probably preferred over chess.
from chess.
Related Issues (20)
- FEN - Half-move clock and full-move counter Display Trait implementation HOT 6
- Build error for the first example in README.md HOT 1
- Improper use of MaybeUninit in code is undefined behaviour HOT 6
- Use of std::mem::transmute in Rank and File is undefined behaviour HOT 1
- CastleRights::from_index and CastleRights::rook_square_to_castle_rights are unsound HOT 1
- En-passant erroneously rejected as invalid when specified via SAN HOT 3
- Move generation is unsound for non-standard positions HOT 1
- Out of bounds square can cause out of bounds access. HOT 1
- Build step is prohibitively expensive HOT 4
- Board.status unnecessarily calculates all legal moves
- Removing en passant doesn't work
- `remove_move` and `remove_mask` truncate moves in the move generator.
- Update source code HOT 1
- Display Game as PGN
- Suggest: add URL to this repo to rust doc
- Repetition in tests
- panic from trying build "1nbqkbnr/1ppppppp/8/8/2PP4/B4N2/P3PPPP/RN1QKB1R b KQkq -"
- Bug in Board Hash trait implementation HOT 3
- [Question] Why does Square allow above 63? HOT 1
- MoveGen throws an IlleganSanMove for a legal move HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chess.