-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build step is prohibitively expensive #58
Comments
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
<#58>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AADJ5PJXE4FJUBL33OFUD6LTSYPLBANCNFSM46VPSZQQ>
.
|
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
> <#58>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AADJ5PJXE4FJUBL33OFUD6LTSYPLBANCNFSM46VPSZQQ>
> .
>
|
✓. Yeah, I don't disagree
Sorry, do you mean that the compiler isn't smart enough to see the bit boards are just
✓
My biggest gripe with my experience was I slightly tweaked I was under the impression that most of what was being generated were many many In the very least, I could see organizing crates like:
NOTE: I'm still very new to Rust, so I'm not sure whether all my terms or suggestions above make complete sense |
…ed for the crate itself. This should fix jordanbray#58.
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? |
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
inboard.rs
)Perhaps there's room to better separate the table generation from other source files into a
core
ortable
sub-crate?(I was toying with
Board
andBoardBuilder
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 BughouseThe text was updated successfully, but these errors were encountered: