The answer is "yes, this is fine." When I worked on big iron simulations where performance was non-negotiable, I was surprised to see everything in one big fat (BIG and F-A-T) global array. Later I worked on an OO system and got to compare the two. Although it was super ugly, the "one array to rule them all" version in single-threaded plain old C was several times faster than the "pretty" multithreaded OO system in C++. I think a bit of it had to do with excellent cache locality (in both space and time) in the big-fat-array version.

If you want performance, one big fat global C array is going to be the upper bound (from experience).

The answer is "yes, this is fine." When I worked on big iron simulations where performance was non-negotiable, I was surprised to see everything in one big fat (BIG and F-A-T) global array. Later I worked on an OO system and got to compare the two. Although it was super ugly, the "one array to rule them all" version in single-threaded plain old C compiled in debug was several times faster than the "pretty" multithreaded OO system compiled -O2 in C++. I think a bit of it had to do with excellent cache locality (in both space and time) in the big-fat-array version.

If you want performance, one big fat global C array is going to be the upper bound (from experience).