Hacker News new | ask | show | jobs
by fluffybucktsnek 62 days ago
I know the thread. Your point is about whether Bevy's "data structure" is worth 50MB. I pressing on the fact that you haven't shown what this 50MB actually are.

But, out of curiosity, do you also consider the Linux Kernel also a data structure?

1 comments

I pressing on the fact that you haven't shown what this 50MB actually are.

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

But, out of curiosity, do you also consider the Linux Kernel also a data structure?

Do you think a spreadsheet the holds function pointers is a kernel?

> 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.

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?)
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.
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.

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

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.
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.

> 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.