Hacker News new | ask | show | jobs
by macgyverismo 2233 days ago
Having read through the README, I'm not quite sure what makes this perform better than other systems. I can see that it will perform excellent when iterating over a single type as all entries for this type are next to each other. However, for each meaningfull operation you are likely to combine at least two different types, which means data will have to be read from different locations, defeating the purpose. You could put more data in a single type (for the example from README, you would put velocity and position in a single type) but than you are back to hand-tuning your data types as you would in any other system. It still looks like an interesting library, but if there are any inherent performance benefits I am failing to see, I would love to hear about them.
2 comments
skypjack 2233 days ago
The design is such that you pay for what you need. To do what you're looking for, that is, a linear access on multiple components without jumps nor anything else, there exist groups. They are the fastest thing you can imagine because you iterate literally N arrays for N components in order with no jumps nor branches. They affect performance on creation/destruction though, in order to speed up quite a lot linear accesses. Also, views are such that it doesn't worth it creating a group when one of the components involved in a query is assigned to few entities, since the view internally uses the shortest pool. And so on, there are tons of details and use cases. The documentation (the wiki, not the README) contains all the details but it's pretty big and takes a while to go through all them. The fact is that a real world software isn't made only of linear accesses, so the whole library is meant to allow optimizing the given access pattern when needed.

Feel free to ask if I triggered you and you want more details. ;) Reach me out here, on gitter, discord, by mail, whatever...

link
xashor 2233 days ago
Side note: The vel+pos example is a common one in ECS. It also often follow that you should put them in one type in the real world. However, nowadays thanks to SIMD instructions, it is probably faster to have them separate, as you don't have to unpack/align the various fields:

  // p={(x0,y0),(x1,y1),...} and v={(vx0,vy0),(vx1,vy1),...}
  for(int j=0;j<2*SIZE;j++)p[j]+=v[j];
vs.

  // pv={(x0,y0,vx0,vy0),(x1,y1,vx1,vy1),...}
  for(int j=0;j<4*SIZE;j+=4)
    pv[i+0]+=pv[i+2],pv[i+1]+=pv[i+3];
link