search

jordanbray / chess

A rust library to manage chess move generation
https://jordanbray.github.io/chess/
MIT License
231 stars 54 forks source link

Build step is prohibitively expensive #58

Closed jrwats closed 1 year ago

jrwats commented 3 years ago

cargo build takes ~2 minutes to run on my 2019 macbook. rust-analyzer (running in my editor — I believe on any given file-save) also wreaks havoc on my CPU when trying to edit files here. Worse yet, it appears to spin up multiple build-script async processes eagerly...

I'd love to contribute more to this project, but these costly build steps make it hard. (FWIW, I'm specifically interested in improving fn legal in board.rs)

Perhaps there's room to better separate the table generation from other source files into a core or table sub-crate? (I was toying with Board and BoardBuilder at the time)

The experience pushed me to a composition model instead (preferable anyhow) wherein I consume the chess crate and hack up my own stuff (though there's still some code duplication), for Bughouse

jordanbray commented 3 years ago

The build step is expensive. It is much faster than that in release mode. I don't remember if rust analyzer obeys release, though.

I do think about the magic numbers as compiled objects, so I'd like them built at build-time (rather than a static file). Maybe, however, there is a way to speed that up quite a bit.

Things that come to mind are:

  1. In debug mode, a relatively huge quantity of time is spent making bit boards. These are just u64s, but the compiler isn't smart enough to see that in debug.
  2. There may be a large number of optimizations in the initial "sliding piece" implementations.
  3. There may be a implementation for the "guess and check" portion of the algorithm that copies less or something.

On Mon, Jun 14, 2021, 11:41 AM John Watson @.***> wrote:

cargo build takes ~2 minutes to run on my 2019 macbook. rust-analyzer (running in my editor — I believe on any given file-save) also wreaks havoc on my CPU when trying to edit files here. Worse yet, it appears to spin up multiple build-script async processes eagerly...

I'd love to contribute more to this project, but these costly build steps make it hard. (FWIW, I'm specifically interested in improving fn legal in board.rs)

Perhaps there's room to better separate the table generation from other source files into a core or table sub-crate? (I was toying with Board and BoardBuilder at the time)

The experience pushed me to a composition model instead (preferable anyhow) wherein I consume the chess crate and hack up my own stuff (though there's still some code duplication), for Bughouse https://github.com/jrwats/bughouse/blob/main/src/bughouse_board.rs

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jordanbray/chess/issues/58, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJ5PJXE4FJUBL33OFUD6LTSYPLBANCNFSM46VPSZQQ .

jordanbray commented 3 years ago

The easy solution may be to add:

[profile.dev]
opt-level = 3

to your Cargo.toml.

On Mon, Jun 14, 2021, 11:49 AM Jordan Bray @.***> wrote:

The build step is expensive. It is much faster than that in release mode. I don't remember if rust analyzer obeys release, though.

I do think about the magic numbers as compiled objects, so I'd like them built at build-time (rather than a static file). Maybe, however, there is a way to speed that up quite a bit.

Things that come to mind are:

  1. In debug mode, a relatively huge quantity of time is spent making bit boards. These are just u64s, but the compiler isn't smart enough to see that in debug.
  2. There may be a large number of optimizations in the initial "sliding piece" implementations.
  3. There may be a implementation for the "guess and check" portion of the algorithm that copies less or something.

On Mon, Jun 14, 2021, 11:41 AM John Watson @.***> wrote:

cargo build takes ~2 minutes to run on my 2019 macbook. rust-analyzer (running in my editor — I believe on any given file-save) also wreaks havoc on my CPU when trying to edit files here. Worse yet, it appears to spin up multiple build-script async processes eagerly...

I'd love to contribute more to this project, but these costly build steps make it hard. (FWIW, I'm specifically interested in improving fn legal in board.rs)

Perhaps there's room to better separate the table generation from other source files into a core or table sub-crate? (I was toying with Board and BoardBuilder at the time)

The experience pushed me to a composition model instead (preferable anyhow) wherein I consume the chess crate and hack up my own stuff (though there's still some code duplication), for Bughouse https://github.com/jrwats/bughouse/blob/main/src/bughouse_board.rs

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jordanbray/chess/issues/58, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJ5PJXE4FJUBL33OFUD6LTSYPLBANCNFSM46VPSZQQ .

jrwats commented 3 years ago

I do think about the magic numbers as compiled objects, so I'd like them built at build-time (rather than a static file). Maybe, however, there is away to speed that up quite a bit.

✓. Yeah, I don't disagree

  1. In debug mode, a relatively huge quantity of time is spent making bit boards. These are just u64s, but the compiler isn't smart enough to see that in debug.

Sorry, do you mean that the compiler isn't smart enough to see the bit boards are just u64, and is doing somethign sub-optimal when building these or something else?

  1. There may be a large number of optimizations in the initial "sliding piece" implementations.

✓

  1. There may be a implementation for the "guess and check" portion of the algorithm that copies less or something. I'll have to read more code to see what you mean

My biggest gripe with my experience was I slightly tweaked board.rs and board_builder.rs hacking around with various ideas, and every minor tweak was met with a 2 minute long whirring of my CPU (limiting coding while on battery to ~2hours).

I was under the impression that most of what was being generated were many many u64 bitboards, and in my mind, these should just be built "independent" of board.rs and board_builder.rs. There's no reason for a bunch of numbers to depend on board.rs etc, so perhaps there's some dependency refactoring that can be done to spell this out better for the compiler and build.rs?

In the very least, I could see organizing crates like:

chess ➡ chess_tables
     ⬊       ⬇
        chess_core

NOTE: I'm still very new to Rust, so I'm not sure whether all my terms or suggestions above make complete sense

adri326 commented 11 months ago

I still find the build step quite slow, and I'm wondering what's stopping you from baking these numbers once for everyone upon a release?