>> but the ability of engines like Bevy to analyze system dependencies and automatically scale to multiple CPUs is a big deal
>> Is it? The article addresses that, and basically calls it a pointless feature
> You can see that all the CPUs are being maxed out.
You're missing the forest for the trees - the poster above basically said "seeing all the CPUs being maxed out is a pointless feature" and you reply with "but see, all the CPUs are being maxed out".
You're literally ignoring the complaint and replying with marketing.
No, the original article said that you don't get parallelism from Bevy in practice:
> Unfortunately, after all the work that one has to put into ordering their systems it's not like there is going to be much left to parallelize. And in practice, what little one might gain from this will amount to parallelizing a purely data driven system that could've been done trivially with data parallelism using rayon.
It's not saying "yes, you get parallelism, but I don't need the performance"; it's claiming that in practice you don't get (system-level) parallelism at all. That's at odds with my experience.
The article is not saying that Bevy does not parallelize but that the impredictability of parallelism (both in ordering and in timing) forces the developer to add enough dependency constraints that there is not much left to parallelize.
To be fair, you've posted a toy example. Real games are often chains of dependent systems, and as complexity increases, clean threading opportunities decrease.
So, while yes it's nice in theory, in practice it often doesn't add as much performance as you'd expect.
>> Is it? The article addresses that, and basically calls it a pointless feature
> You can see that all the CPUs are being maxed out.
You're missing the forest for the trees - the poster above basically said "seeing all the CPUs being maxed out is a pointless feature" and you reply with "but see, all the CPUs are being maxed out".
You're literally ignoring the complaint and replying with marketing.