3 ms·

Unless the objects you're working with happen to be contiguously arranged in the arrays then it might be 100 cache lines for those 100 pointers. That's another

by shawnz 8y ago

Unless the objects you're working with happen to be contiguously arranged in the arrays then it might be 100 cache lines for those 100 pointers. That's another reason why the "all the data together" approach would probably win performance wise - you'd get 100 whole objects for those 100 cache lines > Because there is a place that must know them all, bind them all together. [...] True, that could be a problem in some circumstances which might warrant a map-like structure like you describe. But I don't think it's the most obvious pattern otherwise

jstimpfle 8y ago
> it might be 100 cache lines for those 100 pointers No, the usual recommendation is that you should split your structures into smaller structures such that each contains only fields that are likely to be accessed together. In other words, you should err on the side of SOA (parallel arrays) rather than AOS. That's because the unused field apply pressure on the cache.
jstimpfle 8y ago
Oops, yeah, I misread your post, and while my sibling comment is technically correct, it wasn't really a reply to your comment. Yes, the way I write it is absolutely that my global buffers are all allocated sequentially, so it's very cache friendly. And I partly agree that this is kind of "all the data together" in this instance. But note that there is not a struct that binds them together, and so there's no code that depends on them being layed out sequentially in memory. Actually I can achieve the effect without losing modularity at all, by having each module specify its global data categorized as types of data (one category of which would be "global buffer pointers"). I'll then just have the build go over all my modules and put them sequentially in the built image. This is exactly what ECS do, by the way. What you want is aspect-oriented program performance-wise (and maintainability-wise in general), but sometimes you still want to maintain parts as optional "packages". So what ECS do is they weave each aspect of each package into the final product. By the way, one very simple way to achieve this in C is to declare the data like BUFFERDATA int *myIntArray; in the header file of each module. And I define BUFFERDATA as "extern" for all modules except one data module, which "implements" all data declared BUFFERDATA by defining BUFFERDATA to an empty string and including all of the project's header files.

by shawnz 8y ago

jstimpfle 8y ago

> it might be 100 cache lines for those 100 pointers No, the usual recommendation is that you should split your structures into smaller structures such that each contains only fields that are likely to be accessed together. In other words, you should err on the side of SOA (parallel arrays) rather than AOS. That's because the unused field apply pressure on the cache.

jstimpfle 8y ago

Oops, yeah, I misread your post, and while my sibling comment is technically correct, it wasn't really a reply to your comment. Yes, the way I write it is absolutely that my global buffers are all allocated sequentially, so it's very cache friendly. And I partly agree that this is kind of "all the data together" in this instance. But note that there is not a struct that binds them together, and so there's no code that depends on them being layed out sequentially in memory. Actually I can achieve the effect without losing modularity at all, by having each module specify its global data categorized as types of data (one category of which would be "global buffer pointers"). I'll then just have the build go over all my modules and put them sequentially in the built image. This is exactly what ECS do, by the way. What you want is aspect-oriented program performance-wise (and maintainability-wise in general), but sometimes you still want to maintain parts as optional "packages". So what ECS do is they weave each aspect of each package into the final product. By the way, one very simple way to achieve this in C is to declare the data like BUFFERDATA int *myIntArray; in the header file of each module. And I define BUFFERDATA as "extern" for all modules except one data module, which "implements" all data declared BUFFERDATA by defining BUFFERDATA to an empty string and including all of the project's header files.