Case A:
typedef struct {
int x;
int y;
int z;
} v3;
v3 foo = {1,2,3};
/* code using v3 and foo */
Case B:
int foo[3] = {1,2,3};
/* code using arrays and foo */
Can A and B be considered equivalent, performance-wise, in general? What about arrays with statically unknown size, such as int foo[n]? Is there a disadvantage, then?
The answer depends on the usage of your array or struct. If you use your array with compile-time constant expressions as indexes, there would be no difference: the compiler would be able to compute the required offset at compile time. This is the only situation where the comparison is apples-to-apples, because there is no way to "index" a struct to get a particular field. Accesses
foo.y = 123;
and
foo[1] = 123;
would likely translate to an identical set of machine instructions.
When the offset is not a compile-time expression, however, there is an additional step required to compute the address in memory: in order to execute the code below
i = 1; // Assume that i is known only at runtime
foo[i] = 123;
CPU would need to add a variable offset from variable i to the address of foo before storing 123 at that address.
Theoretically, this step introduces an additional overhead. However, modern CPUs compute the offset in hardware, so the overhead is negligible.
There's no performance difference between a struct object and a compile-time sized array object, as long as array access is performed through a compile-time index. v3.x and foo[0] will typically generate the same code, as well as v2.y and foo[1] and so on.
The array has an added benefit of supporting run-time element selection, i.e. access through foo[i] where i is a run-time index. This might be slower, but this is not relevant in the context of the question since struct types do not support run-time member selection at all.
A run-time sized array (VLA) will generally be slower than compile-time sized array, since VLA is internally implemented as a pointer instead of an immediate array object, although the difference will not be detectable in overwhelming majority of cases. However, I don't understand why you are asking about VLAs here. C language does not have run-time sized structs, which is why VLAs have no meaningful relevance to the primary question.
Usually, yes. However, when you're writing very performance-sensitive code, using scalars instead of structs can help the optimizer perform better
For example, if you have:
// atom forces
typedef struct float3 {
float x;
float y;
float z;
} float3;
the code here on Intel's site suggests changing:
// position is an array of float3
float3* position;
for (int k=0; k<dis; k++){
jpos = position[ neighList[j*dis + k + maxNeighbors * i] ];
float delx = ipos.x - jpos.x;
float dely = ipos.y - jpos.y;
float delz = ipos.z - jpos.z;
float r2inv = delx*delx + dely*dely + delz*delz;
to
for (int k=0;k<dis;k++){
jposx = position[ neighList[j*dis + k + maxNeighbors * i] ].x;
jposy = position[ neighList[j*dis + k + maxNeighbors * i] ].y;
jposz = position[ neighList[j*dis + k + maxNeighbors * i] ].z;
float delx = iposx - jposx;
float dely = iposy - jposy;
float delz = iposz - jposz;
float r2inv = delx*delx + dely*dely + delz*delz;
... because it helps the compiler efficiently vectorize the memory accesses:
To help the compiler generate better vector code, sometimes it helps to decompose complex data structures to allow the compiler to understand the available parallelism and vectorize the code.
So yes, scalars can be faster because the optimizer can optimize them better. However, note that you should only worry about this if this is a bottleneck in your code, and you should actually test it to see if it's the case in your situation; this is not meant to be a "rule of thumb" of any sort.
In general, yes, all three ints will end up back-to-back in memory and should result in about the same code generated by compiler when you access them.
You could even have array within the structure and things would still end up being about the same.
typedef struct {
int xyz[3];
} v3;
v3 foo = {{1,2,3}};
int foo[n] is supported in C99 and is a gcc extension in C++ and older modes. It would allocate space on stack. Performance-wise there should be no difference, but you should consider explicitly allocating memory for dynamically sized arrays.
