[fluffybucktsnek]

> To be clear you think an ECS implementation is 50MB?

No.

> Do you think a spreadsheet the[sic] holds a function pointer is a kernel?

Do you think an entire engine, including its system scheduler, is a spreadsheet? If so, shouldn't be hard to apply the same argument to any kernel. Of course, it all relies on your definitions and sense of reductionism.

[CyberDildonics]

I think you're conflating other big features of a game engine with a way to store data. If you look at other ecs implementations they are data structures, they don't do "system scheduling" (is that different from regular scheduling?)

[fluffybucktsnek]

First of, Bevy isn't just an ECS implementation. It's a game engine designed around ECS. While the ECS part is its core, Bevy also provides rendering, resource management, physics, etc. One of its other tasks, a rather important one too, is system scheduling: once you register systems, Bevy is responsible for dispatching them each frame, at the appropriate time, while also avoid data races over global resources and components.

[CyberDildonics]

First of, Bevy isn't just an ECS implementation.

No one thought that or said that so I don't know what point you're trying to make.

If you go to the comments I replied it was someone saying bevy compiles slow and has excessive bloated binaries. Someone else replied that you get so much, like ecs. Then I said that ecs specifically is just a data structure and has no reason to bloat binaries to be 50MB for an empty program that does nothing.

You're replying about things no one was discussing.

[fluffybucktsnek]

Your whole thread is about nitpicking the phrase "Bevy gives you a nice ECS". You are the one who asserted that "ecs specifically is just a data structure" (it isn't, by most definitions [1] [2], except yours). I supposed you were referring exclusively to a simple and basic component storage implementation (which is a data storage), where as OP was probably referring to the whole ergonomics of writing programs in it, alongside all the other features. It seems to me that you're the one who missed the point.

Then, you used this reductionism to question whether the 50MB binary is worth it. And that's ignoring the fact that there are ways to cut it if you wish, as mentioned in the reddit thread. And then there's the issue of whether it will actually matter for a full game.

[1] https://en.wikipedia.org/wiki/Entity_component_system

[2] https://github.com/SanderMertens/ecs-faq#what-is-ecs

[CyberDildonics]

Your link describes a data structure and then just says "systems that use it" which is implied. Of course it gets used. Seems tautological.

[fluffybucktsnek]

I will need citation on which link, and how it defines ECS as a data structure.

From [1]:

> Entity component system (ECS) is a software architectural pattern. An ECS consists of entities composed of data components, along with systems that operate on those components.

From [2]: > ECS ("Entity Component System") describes a design approach which promotes code reusability by separating data from behavior. Data is often stored in cache-friendly ways which benefits performance.

[fluffybucktsnek]

Other ECS implementations might not, but Bevy does come with a system scheduler. You register systems (functions that operate over the components) and, through their parameters, Bevy's scheduler decides how to parallelize the registered systems while avoid data races.

[CyberDildonics]

Other ECS implementations might not, but Bevy does come with a system scheduler.

That's an ecs data structure and a system scheduler. If I make a vector and a system scheduler, vectors don't suddenly have system schedulers, they are two different things.

You register systems (functions that operate over the components)

That's just adding a function pointer to a field.

[fluffybucktsnek]

> That's an ecs data structure [...]

ECS isn't a data structure tho, it's a pattern. You must be referring to the component storage. That's, at best, half the equation. You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?

> That's just adding a function pointer to field

Just as much as creating a new process, through the IP/PC field in the TCB. Don't know why you focused on that particular point, but sure.

[CyberDildonics]

ECS isn't a data structure tho, it's a pattern.

Every implementation out there is a data structure. You keep talking about things that use it and then lump them together. That's just you.

You do realize the discussion is about the 50MB program, which uses both the component storage, the system scheduler and other features, right?

No, the first person I replied to said that justified a 50MB program. A few other software components don't make any sense either. 50MB is not something you get to with 4 or 5 parts of a game engine. That's the stripped binary too, it was originally 700MB.

Don't know why you focused on that particular point, but sure.

You brought it up, I'm not even sure what point you are trying to make.

[fluffybucktsnek]

> Every implementation out there is a data structure.

Examples?

> 50MB is not something you get to with 4 or 5 parts of a game engine.

Depends on the engine's architecture, runtime, etc. Again, don't know if you are blaming the bloat on those components alone (it seems like you are), but you haven't established a direct link between said components and the bloat, thus, it's hard to properly reason about the tradeoffs given that we don't know how said bloat scales.

> That's the stripped binary too, it was originally 700MB.

Actually, no. Rust doesn't strip binaries on release by default. There's a reason there's a guide about minimizing Rust program sizes.

> You brought it up, I'm not even sure what point you were trying to make.

You are the one who nitpicked over "You register functions", ignoring the rest of the sentence.