Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Add core and alloc over std Lints #15281

Merged
merged 36 commits into from
Sep 27, 2024
Merged

Add core and alloc over std Lints #15281

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
36 commits
Select commit Hold shift + click to select a range
a939e93
Add `core` and `alloc` over `std` Lints
bushrat011899 Sep 18, 2024
120e9e0
Fixing issues raised by CI
bushrat011899 Sep 18, 2024
abb01eb
Bump MSRV
bushrat011899 Sep 18, 2024
864631f
Responding to CI issues
bushrat011899 Sep 18, 2024
145ab01
Switch `define_label` macro to `std` instead of `alloc`
bushrat011899 Sep 18, 2024
8a99654
Re-export `Box` to satisfy lint
bushrat011899 Sep 18, 2024
9e4c516
Fixed doctests
bushrat011899 Sep 18, 2024
273cd3a
Fixed compile check CI
bushrat011899 Sep 18, 2024
6960fd1
Fixed audio patch and formatting
bushrat011899 Sep 18, 2024
389310a
Remove `std` uses that `clippy` missed
bushrat011899 Sep 18, 2024
46aa899
Fixed typo in find-and-replace
bushrat011899 Sep 18, 2024
f3c95da
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 18, 2024
ecc8d33
Respond to lint in CI
bushrat011899 Sep 18, 2024
5c7fa79
One more `std::f32` crushed
bushrat011899 Sep 18, 2024
270a49f
Forgot to check `examples` for those pesky `std::f32`'s
bushrat011899 Sep 18, 2024
50e34bd
Allow examples to use the `std` crate
bushrat011899 Sep 18, 2024
a6780ba
Remove workspace lints from root crate
bushrat011899 Sep 18, 2024
e28ff2a
Added comment to `Cargo.toml`
bushrat011899 Sep 19, 2024
f62b660
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 19, 2024
6bbca4e
CI issues from merge
bushrat011899 Sep 19, 2024
cdbc80a
Fixed instances of redundant braces in `use` statements
bushrat011899 Sep 20, 2024
fff160e
Re-merge `std` imports
bushrat011899 Sep 20, 2024
4704134
Revert change in `tests` as it is not required
bushrat011899 Sep 20, 2024
a9e1664
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 20, 2024
12b5c66
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 20, 2024
e7efe08
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 21, 2024
b89e0d1
Remove double `std`'s
bushrat011899 Sep 21, 2024
7a2b7a5
Reverted to `std` for documentation
bushrat011899 Sep 21, 2024
de8b0d6
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 21, 2024
8e453c7
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 22, 2024
a377ecb
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 22, 2024
6534168
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 23, 2024
546abdc
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 23, 2024
5418ce2
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 26, 2024
5d9b12f
Merge remote-tracking branch 'upstream/main' into UseCoreOrAlloc
bushrat011899 Sep 26, 2024
99bb6f7
Fixed Android-Specific Import Problem
bushrat011899 Sep 27, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
44 changes: 42 additions & 2 deletions Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,15 +48,55 @@ ref_as_ptr = "warn"
# see: https://github.com/bevyengine/bevy/pull/15375#issuecomment-2366966219
too_long_first_doc_paragraph = "allow"

std_instead_of_core = "warn"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The downsides I can see are:

  1. This is a large / sweeping change that permanently changes how we all write Bevy code.
  2. This introduces slightly more boilerplate (we need extern crate alloc in most crates now).
  3. This takes us further from the "internal Bevy code looks like user-facing Bevy code" principle, because the majority of users / plugins can (and should) continue to use std.

As such, before making such a change, it would be good to qualify exactly what it wins us. For example, getting closer to some potential no_std Bevy future doesn't do us much if there are true blockers that prevent us from finishing that journey. Same goes for console support (which is currently phrased like "this might help").

Before merging, I'd want satisfying answers to:

  1. With this change, what are the remaining blockers to "no_std Bevy"
  2. With just this change, what scenarios are we unlocking?
  3. For (2), can we unlock those scenarios with targeted ports of specific crates? (ex: doing this for bevy_ecs)

I also question the viability of this effort for things like consoles when the majority of plugins and user code will still target std. Seems like an std console port (even if it starts as a partial / shimmed port) would be preferable from an ecosystem perspective.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking the time to look at this! As an immediate response, here's what I personally think in regards to those listed downsides:

  1. This is a large / sweeping change that permanently changes how we all write Bevy code.

Agreed, this will affect all contributors for Bevy going forward. However, I believe this is a relatively minor impact, as clippy can suggest the exact changes required to pass these lints. In effect, contributors can continue to write std-reliant code, but on completion they'll fix this lint the same way we already do for things like fmt and taplo.

  1. This introduces slightly more boilerplate (we need extern crate alloc in most crates now).

This is true, effectively every crate root (lib.rs) will include extern crate alloc. However, it is only a single line of code per crate, so I think, while annoying, its real impact is negligible. Especially considering this PR adds the lines already, so contributors will only encounter this boilerplate when creating a new Bevy crate.

  1. This takes us further from the "internal Bevy code looks like user-facing Bevy code" principle, because the majority of users / plugins can (and should) continue to use std.

This is true and I don't have a meaningful rebuttal; this will add one layer of indirection between user and contributor code. What I would say is that we already have that for things like bevy_reflect being feature-gated. The majority of users write code for Bevy assuming bevy_reflect is available, but contributors can't make that same assumption.

As such, before making such a change, it would be good to qualify exactly what it wins us. For example, getting closer to some potential no_std Bevy future doesn't do us much if there are true blockers that prevent us from finishing that journey. Same goes for console support (which is currently phrased like "this might help").

I personally don't have access to any modern console SDKs so I can't comment on the necessity for a no_std Bevy for platforms like the Nintendo Switch, Xbox Series, PS5, etc. However, I can say that for the homebrew and retro community, no_std is an absolute must. For some context on my personal motivations here, I'm wanting to use the agb crate with Bevy to create some games for the GameBoy Advance. To do this, I need the following crates to be no_std at a minimum:

  • bevy_ptr
  • bevy_utils
  • bevy_tasks
  • bevy_ecs
  • bevy_app

Out of the above 5 crates, bevy_ptr and bevy_utils are already no_std, and I have a draft no_std for bevy_tasks already published. bevy_app is trivial to make no_std, as it only uses the standard library for thiserror, Mutex, and panic capturing, all of which have suitable no_std replacements (or just not-applicable in the case of panic capturing). This leaves bevy_ecs as the only core crate remaining, and I'm already about half-way through a port of that too, with the biggest issues being non-Send resources (requires access to std::thread) and the schedule graph using a single type and algorithm from petgraph (GraphMap).

Once the above changes are made, I will be able to use Bevy on any platform, including the GameBoy Advance. What's more, I'd be able to use the high level abstractions like systems, queries, and the App and plugin infrastructure too, making Bevy the single best engine for retro-consoles.

With the above context, here are my answers to your three questions:

  1. With this change, what are the remaining blockers to "no_std Bevy"
  1. thiserror
  2. petgraph's GraphMap data structure
  3. non-Send resources
  4. Refactoring bevy_ecs and bevy_app to include a std feature

Obviously this excludes other aspects of Bevy, (bevy_time, etc.) which I want to be no_std, but everything else is optional, bevy_app and bevy_ecs are the minimum to provide an end-user appropriate no_std experience.

  1. With just this change, what scenarios are we unlocking?

To make a crate like bevy_ecs no_std, the first step will be this very refactor, and then it'll be meaningful work (e.g., petgraph, etc.). The problem is that any PR which attempts to make bevy_ecs no_std will be made vastly more controversial by mixing this PR's work and their actual changes to Bevy's code, making review substantially harder and more likely to fail. By applying this lint in its own PR and across the workspace, we remove that controversy and noise from future discussions around no_std Bevy, and we keep all of Bevy consistent ("Oh you can't write that code here, we have the std lint on").

  1. For (2), can we unlock those scenarios with targeted ports of specific crates? (ex: doing this for bevy_ecs)

Yes, but I believe this introduces the very inconsistency in Bevy that we'd like to avoid. These lints make no restrictions around what code we write, or even how they're written, only the names of core and alloc types. These lints provide a consistent experience for all Bevy contributions, regardless of whether you're in a no_std crate or not. Since Bevy already has two no_std crates, these lints will make working on those crates consistent with the rest of the library.

I also question the viability of this effort for things like consoles when the majority of plugins and user code will still target std.

I see this as a chicken-and-egg problem; Bevy's plugins are std because Bevy is std. You actually can't write a no_std Bevy plugin right now because the required traits are "stuck" inside an std-only crate. I can personally attest to my intention to make a bevy_agb plugin to allow working on the GameBoy Advance, and I'm certain that other community members would have similar excitement around a new area of Bevy to explore. Bare-metal games on the Raspberry Pi, Playdate support, embedded projects using bevy_ecs as a database, etc. are projects I have seen discussed in the Bevy Discord as fantastical, but I genuinely believe are achingly close to realisation.

Seems like an std console port (even if it starts as a partial / shimmed port) would be preferable from an ecosystem perspective.

For the modern consoles, definitely, but this would not be viable for anything retro. Additionally, with Bevy relying on the whole std (right now), knowing how much of the std library you need to port is difficult. If Bevy's reliance on the standard library was reduced to what it needs, then that work also becomes more actionable.

I apologise for the long response, especially considering just how large this PR itself is, and I thank you for taking the time to read it!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thiserror

I'd like to keep this if possible, I think with core::Error stabilizing we can actually fix this upstream.

petgraph's GraphMap data structure

Not long for this world frankly, the ECS folks kinda hate petgraph

non-Send resources

Feature-flagging this is fine

Refactoring bevy_ecs and bevy_app to include a std feature

Very doable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, to provide some hard evidence for how close no_std Bevy is, I have made some rough ports of bevy_ecs and bevy_app on this branch. All that really had to change was adding an Instant type appropriate for no_std environments, and porting petgraph's required parts to a custom solution. That in of itself was actually just an almost straight copy-paste of petgraph's implementation (simplified), since it was already almost no_std, just needed to disable a couple features we weren't using.

These changes allow this application to compile on x86_64-unknown-none, bare-metal x86:

`Cargo.toml` 
[package]
name = "bevy_no_std_test"
version = "0.1.0"
edition = "2021"

[dependencies]
bevy_app = { path = "../bevy_app", version = "0.15.0-dev", default-features = false }
bevy_ecs = { path = "../bevy_ecs", version = "0.15.0-dev", default-features = false }

[profile.dev]
opt-level = 3
debug = true
panic = "abort"
`main.rs` 
//! Demonstrates a [`no_std`] Bevy application.

#![allow(unsafe_code)]
#![no_std]
#![no_main]

// Since we don't have access to `std`, and the `core` library can't assume there's
// a global allocator, we have to explicitly include it using `extern crate`.
extern crate alloc;

// Explicitly importing bevy sub-crates because I haven't threaded the `std` feature
// through bevy_internal and then bevy proper.
use bevy_app::prelude::*;
use bevy_ecs::prelude::*;

#[derive(Resource, Default)]
struct MyResource {
    hello_world: bool,
}

#[derive(Component)]
struct Player;

fn main() {
    App::empty()
        .init_resource::<MyResource>()
        .add_systems(Update, |my_resource: Res<MyResource>| {
            assert_eq!(my_resource.hello_world, false);
        })
        .add_systems(Startup, |mut commands: Commands| {
            commands.spawn(Player);
        })
        .add_systems(Update, |query: Query<&Player>| {
            assert_eq!(query.iter().count(), 1);
        })
        .run();
}

/// You cannot rely on [`main`] being called for you in a `no_std` environment.
/// The exact name of your start function will depend on the platform you're developing for.
/// It's convention to name this function `_start`, and we use `#[no_mangle]` to ensure
/// the Rust compiler doesn't change this name.
#[no_mangle]
pub extern "C" fn _start() -> ! {
    // Our start function is just going to call main, and if main exits we'll
    // just loop forever. Quitting in a `no_std` context isn't defined, since
    // you might be running on bare-metal hardware without power management!
    main();
    loop {}
}

/// Bevy requires access to a global allocator, another item which is platform specific
/// and so must be setup manually.
#[global_allocator]
static ALLOCATOR: allocator::Dummy = allocator::Dummy;

/// Obviously _your_ code will never panic. But, Rust still requires setting up
/// a panic handler _just in case_.
#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

/// Custom allocator for our no_std environment
mod allocator {
    use alloc::alloc::{GlobalAlloc, Layout};
    use core::ptr::null_mut;

    /// This is a demonstration allocator and is _intentionally_ broken.
    pub struct Dummy;

    unsafe impl GlobalAlloc for Dummy {
        unsafe fn alloc(&self, _layout: Layout) -> *mut u8 {
            null_mut()
        }

        unsafe fn dealloc(&self, _ptr: *mut u8, _layout: Layout) {
            panic!("dealloc should be never called")
        }
    }
}

After applying the lints in this PR, it's about another 3000 diff-lines to make bevy usable in no_std applications with all the high-level functionality people rely on Bevy for.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a big win for bevy as the core 😉 of the ecosystem for a very small price.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok I'm convinced. Lets do this!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Brilliant! I'm going to resolve the merge conflicts now so hopefully this could be merged soon!

std_instead_of_alloc = "warn"
alloc_instead_of_core = "warn"
Comment on lines +51 to +53
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These lints direct Bevy contributors to use core where possible, then alloc, and then finally std. The status quo is to just import everything from std. Enabling these lints makes investigation into a no_std Bevy feasible. Additionally, items in alloc and std but not in core can indicate blocking or allocating types, which could impact performance.


[workspace.lints.rust]
missing_docs = "warn"
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(docsrs_dep)'] }
unsafe_code = "deny"
unsafe_op_in_unsafe_fn = "warn"
unused_qualifications = "warn"

[lints]
workspace = true
Comment on lines -58 to -59
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We explicitly don't want examples to be subject to the same linting requirements as the rest of Bevy, since it is encouraged that users rely on the Rust std library when possible. Unfortunately, there is no way to override just those lints, so a copy of the workspace lints is needed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add a comment to this effect here and in the workspace lints to reduce the risk of desync.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done!

# Unfortunately, cargo does not currently support overriding workspace lints
# inside a particular crate. See https://github.com/rust-lang/cargo/issues/13157
#
# We require an override for cases like `std_instead_of_core`, which are intended
# for the library contributors and not for how users should consume Bevy.
# To ensure examples aren't subject to these lints, below is a duplication of the
# workspace lints, with the "overrides" applied.
#
# [lints]
# workspace = true

[lints.clippy]
doc_markdown = "warn"
manual_let_else = "warn"
match_same_arms = "warn"
redundant_closure_for_method_calls = "warn"
redundant_else = "warn"
semicolon_if_nothing_returned = "warn"
type_complexity = "allow"
undocumented_unsafe_blocks = "warn"
unwrap_or_default = "warn"

ptr_as_ptr = "warn"
ptr_cast_constness = "warn"
ref_as_ptr = "warn"

too_long_first_doc_paragraph = "allow"

std_instead_of_core = "allow"
std_instead_of_alloc = "allow"
alloc_instead_of_core = "allow"

[lints.rust]
missing_docs = "warn"
unexpected_cfgs = { level = "warn", check-cfg = ['cfg(docsrs_dep)'] }
unsafe_code = "deny"
unsafe_op_in_unsafe_fn = "warn"
unused_qualifications = "warn"

[features]
default = [
Expand Down
30 changes: 15 additions & 15 deletions benches/benches/bevy_ecs/change_detection.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -86,7 +86,7 @@ fn generic_bench<P: Copy>(

fn all_added_detection_generic<T: Component + Default>(group: &mut BenchGroup, entity_count: u32) {
group.bench_function(
format!("{}_entities_{}", entity_count, std::any::type_name::<T>()),
format!("{}_entities_{}", entity_count, core::any::type_name::<T>()),
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most changes look like this, where some inline call to a std item needs to be replaced with the core/alloc alternative. As std re-exports alloc and core, this is a non-breaking change even in public facing signatures.

|bencher| {
bencher.iter_batched_ref(
|| {
Expand All @@ -110,8 +110,8 @@ fn all_added_detection_generic<T: Component + Default>(group: &mut BenchGroup, e

fn all_added_detection(criterion: &mut Criterion) {
let mut group = criterion.benchmark_group("all_added_detection");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
for &entity_count in ENTITIES_TO_BENCH_COUNT {
generic_bench(
&mut group,
Expand All @@ -129,7 +129,7 @@ fn all_changed_detection_generic<T: Component + Default + BenchModify>(
entity_count: u32,
) {
group.bench_function(
format!("{}_entities_{}", entity_count, std::any::type_name::<T>()),
format!("{}_entities_{}", entity_count, core::any::type_name::<T>()),
|bencher| {
bencher.iter_batched_ref(
|| {
Expand Down Expand Up @@ -158,8 +158,8 @@ fn all_changed_detection_generic<T: Component + Default + BenchModify>(

fn all_changed_detection(criterion: &mut Criterion) {
let mut group = criterion.benchmark_group("all_changed_detection");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
for &entity_count in ENTITIES_TO_BENCH_COUNT {
generic_bench(
&mut group,
Expand All @@ -179,7 +179,7 @@ fn few_changed_detection_generic<T: Component + Default + BenchModify>(
let ratio_to_modify = 0.1;
let amount_to_modify = (entity_count as f32 * ratio_to_modify) as usize;
group.bench_function(
format!("{}_entities_{}", entity_count, std::any::type_name::<T>()),
format!("{}_entities_{}", entity_count, core::any::type_name::<T>()),
|bencher| {
bencher.iter_batched_ref(
|| {
Expand Down Expand Up @@ -208,8 +208,8 @@ fn few_changed_detection_generic<T: Component + Default + BenchModify>(

fn few_changed_detection(criterion: &mut Criterion) {
let mut group = criterion.benchmark_group("few_changed_detection");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
for &entity_count in ENTITIES_TO_BENCH_COUNT {
generic_bench(
&mut group,
Expand All @@ -227,7 +227,7 @@ fn none_changed_detection_generic<T: Component + Default>(
entity_count: u32,
) {
group.bench_function(
format!("{}_entities_{}", entity_count, std::any::type_name::<T>()),
format!("{}_entities_{}", entity_count, core::any::type_name::<T>()),
|bencher| {
bencher.iter_batched_ref(
|| {
Expand All @@ -252,8 +252,8 @@ fn none_changed_detection_generic<T: Component + Default>(

fn none_changed_detection(criterion: &mut Criterion) {
let mut group = criterion.benchmark_group("none_changed_detection");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
for &entity_count in ENTITIES_TO_BENCH_COUNT {
generic_bench(
&mut group,
Expand Down Expand Up @@ -308,7 +308,7 @@ fn multiple_archetype_none_changed_detection_generic<T: Component + Default + Be
"{}_archetypes_{}_entities_{}",
archetype_count,
entity_count,
std::any::type_name::<T>()
core::any::type_name::<T>()
),
|bencher| {
bencher.iter_batched_ref(
Expand Down Expand Up @@ -356,8 +356,8 @@ fn multiple_archetype_none_changed_detection_generic<T: Component + Default + Be

fn multiple_archetype_none_changed_detection(criterion: &mut Criterion) {
let mut group = criterion.benchmark_group("multiple_archetypes_none_changed_detection");
group.warm_up_time(std::time::Duration::from_millis(800));
group.measurement_time(std::time::Duration::from_secs(8));
group.warm_up_time(core::time::Duration::from_millis(800));
group.measurement_time(core::time::Duration::from_secs(8));
for archetype_count in [5, 20, 100] {
for entity_count in [10, 100, 1000, 10000] {
multiple_archetype_none_changed_detection_generic::<Table>(
Expand Down
16 changes: 8 additions & 8 deletions benches/benches/bevy_ecs/components/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,8 +23,8 @@ criterion_group!(

fn add_remove(c: &mut Criterion) {
let mut group = c.benchmark_group("add_remove");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
group.bench_function("table", |b| {
let mut bench = add_remove_table::Benchmark::new();
b.iter(move || bench.run());
Expand All @@ -38,8 +38,8 @@ fn add_remove(c: &mut Criterion) {

fn add_remove_big(c: &mut Criterion) {
let mut group = c.benchmark_group("add_remove_big");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
group.bench_function("table", |b| {
let mut bench = add_remove_big_table::Benchmark::new();
b.iter(move || bench.run());
Expand All @@ -53,8 +53,8 @@ fn add_remove_big(c: &mut Criterion) {

fn add_remove_very_big(c: &mut Criterion) {
let mut group = c.benchmark_group("add_remove_very_big");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
group.bench_function("table", |b| {
let mut bench = add_remove_very_big_table::Benchmark::new();
b.iter(move || bench.run());
Expand All @@ -64,8 +64,8 @@ fn add_remove_very_big(c: &mut Criterion) {

fn insert_simple(c: &mut Criterion) {
let mut group = c.benchmark_group("insert_simple");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
group.bench_function("base", |b| {
let mut bench = insert_simple::Benchmark::new();
b.iter(move || bench.run());
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/events/iter.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,7 @@ impl<const SIZE: usize> Benchmark<SIZE> {
pub fn run(&mut self) {
let mut reader = self.0.get_cursor();
for evt in reader.read(&self.0) {
std::hint::black_box(evt);
core::hint::black_box(evt);
}
}
}
8 changes: 4 additions & 4 deletions benches/benches/bevy_ecs/events/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,8 +7,8 @@ criterion_group!(event_benches, send, iter);

fn send(c: &mut Criterion) {
let mut group = c.benchmark_group("events_send");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
for count in [100, 1000, 10000, 50000] {
group.bench_function(format!("size_4_events_{}", count), |b| {
let mut bench = send::Benchmark::<4>::new(count);
Expand All @@ -32,8 +32,8 @@ fn send(c: &mut Criterion) {

fn iter(c: &mut Criterion) {
let mut group = c.benchmark_group("events_iter");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
for count in [100, 1000, 10000, 50000] {
group.bench_function(format!("size_4_events_{}", count), |b| {
let mut bench = iter::Benchmark::<4>::new(count);
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/events/send.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ impl<const SIZE: usize> Benchmark<SIZE> {
pub fn run(&mut self) {
for _ in 0..self.count {
self.events
.send(std::hint::black_box(BenchEvent([0u8; SIZE])));
.send(core::hint::black_box(BenchEvent([0u8; SIZE])));
}
self.events.update();
}
Expand Down
6 changes: 3 additions & 3 deletions benches/benches/bevy_ecs/fragmentation/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@ use bevy_ecs::prelude::*;
use bevy_ecs::system::SystemState;
use criterion::*;
use glam::*;
use std::hint::black_box;
use core::hint::black_box;

criterion_group!(fragmentation_benches, iter_frag_empty);

Expand All @@ -17,8 +17,8 @@ fn flip_coin() -> bool {
}
fn iter_frag_empty(c: &mut Criterion) {
let mut group = c.benchmark_group("iter_fragmented(4096)_empty");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));

group.bench_function("foreach_table", |b| {
let mut world = World::new();
Expand Down
4 changes: 2 additions & 2 deletions benches/benches/bevy_ecs/iteration/heavy_compute.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,8 @@ pub fn heavy_compute(c: &mut Criterion) {
struct Transform(Mat4);

let mut group = c.benchmark_group("heavy_compute");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
group.bench_function("base", |b| {
ComputeTaskPool::get_or_init(TaskPool::default);

Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ impl<'w> Benchmark<'w> {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Position(Vec3::X),
Rotation(Vec3::X),
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple_foreach.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ impl<'w> Benchmark<'w> {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Position(Vec3::X),
Rotation(Vec3::X),
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple_foreach_sparse_set.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ impl<'w> Benchmark<'w> {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Position(Vec3::X),
Rotation(Vec3::X),
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple_foreach_wide.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ impl<'w> Benchmark<'w> {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Rotation(Vec3::X),
Position::<0>(Vec3::X),
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple_foreach_wide_sparse_set.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ impl<'w> Benchmark<'w> {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Rotation(Vec3::X),
Position::<0>(Vec3::X),
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple_sparse_set.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ impl<'w> Benchmark<'w> {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Position(Vec3::X),
Rotation(Vec3::X),
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple_system.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,7 +20,7 @@ impl Benchmark {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Position(Vec3::X),
Rotation(Vec3::X),
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple_wide.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ impl<'w> Benchmark<'w> {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Rotation(Vec3::X),
Position::<0>(Vec3::X),
Expand Down
2 changes: 1 addition & 1 deletion benches/benches/bevy_ecs/iteration/iter_simple_wide_sparse_set.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ impl<'w> Benchmark<'w> {
let mut world = World::new();

world.spawn_batch(
std::iter::repeat((
core::iter::repeat((
Transform(Mat4::from_scale(Vec3::ONE)),
Rotation(Vec3::X),
Position::<0>(Vec3::X),
Expand Down
16 changes: 8 additions & 8 deletions benches/benches/bevy_ecs/iteration/mod.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -35,8 +35,8 @@ criterion_group!(

fn iter_simple(c: &mut Criterion) {
let mut group = c.benchmark_group("iter_simple");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
group.bench_function("base", |b| {
let mut bench = iter_simple::Benchmark::new();
b.iter(move || bench.run());
Expand Down Expand Up @@ -82,8 +82,8 @@ fn iter_simple(c: &mut Criterion) {

fn iter_frag(c: &mut Criterion) {
let mut group = c.benchmark_group("iter_fragmented");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
group.bench_function("base", |b| {
let mut bench = iter_frag::Benchmark::new();
b.iter(move || bench.run());
Expand All @@ -105,8 +105,8 @@ fn iter_frag(c: &mut Criterion) {

fn iter_frag_sparse(c: &mut Criterion) {
let mut group = c.benchmark_group("iter_fragmented_sparse");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
group.bench_function("base", |b| {
let mut bench = iter_frag_sparse::Benchmark::new();
b.iter(move || bench.run());
Expand All @@ -128,8 +128,8 @@ fn iter_frag_sparse(c: &mut Criterion) {

fn par_iter_simple(c: &mut Criterion) {
let mut group = c.benchmark_group("par_iter_simple");
group.warm_up_time(std::time::Duration::from_millis(500));
group.measurement_time(std::time::Duration::from_secs(4));
group.warm_up_time(core::time::Duration::from_millis(500));
group.measurement_time(core::time::Duration::from_secs(4));
for f in [0, 10, 100, 1000] {
group.bench_function(format!("with_{}_fragment", f), |b| {
let mut bench = par_iter_simple::Benchmark::new(f);
Expand Down
Loading