Performance Penalty - On accessing a Array in a structure vs a simple array

[hariprasad]

Posted on October 12, 2015 at 18:59

Hi

I want to know whether there is penalty on accessing an array from a structure vs accessing by a simple array. Here is my snippet which i used when I faced the problem

unsigned 
char
array_1[10240];
typedef
struct
{
int
header;
unsgined 
char
array_2[10240]
}simple_queue;
typedef
struct
{
int
top;
simple_queue simple_arr[3]
}simple_stack;
simple_stack struct_var1;
....some file open ....
f_write
(&fp, &struct_var1.simple_arr.array_2[0], 10240);
f_write
(&fp, &array_1[0], 10240);
....

So this is a file operation function which works perfectly and I could see that the performance was varying in the both steps. What I could Observe in the benchmark test was the first f_write took 50ms time to complete , while the second f_write took only 2ms So all that differs while comparing the two f_write are , one uses array in a structure and other uses a simple array.. Please explain me about this behavior. #memory-organization #stm32f429

[waclawek.jan]

Posted on October 12, 2015 at 19:29

> So all that differs while comparing the two f_write are , one uses array in a structure and other uses a simple array..

... and the state of the file metadata (e.g. FAT table), and the state of the medium where you are writing (e.g. cache in a SD card full from previous write)...

The two arrays may be aligned differently in the mcu memory, but it's unlikely that would make such a difference.

JW

[jpeacock]

Posted on October 12, 2015 at 19:37

You are measuring the sum of two variables in your benchmark, array access and file write time.  Use a generated test pattern instead of file I/O to reduce your benchmark to a single variable. 

Your time difference could easily be from the file I/O.  If it's flash you may be seeing a sector erase taking place.

  Jack Peacock

[hariprasad]

Posted on October 13, 2015 at 08:55

Did some debugging today removing the f_write. So I used a simple memcpy() operation

unsigned char array_1[10240];

unsigned char array_2[10240];

typedef struct

{

unsgined char array_2[10240]

}simple_queue;

typedef struct

{

simple_queue simple_arr[3]

}simple_stack;

simple_stack struct_var1;

... ....

memcpy(char array_2, char array_1, 10240 );

memcpy(&struct_var1.simple_arr.array_2[0], char array_1, 10240 );

....

So I could see that first memcpy() took 90microsec, while the second mempy() took 310microsec.

I changed the

unsigned char

to

int and I could see that each memcpy() took 40microsec.    So I assume this is related to compiler optimization..    Can someone please explain to me how compiler optimization can lead to this behaviour? 

[waclawek.jan]

Posted on October 13, 2015 at 09:04

Is this a Cortex-M0/M0+ device? Those don't allow unaligned accesses at all, and the compiler might be aware of the alignment of the source/target.

Also, are both arrays in the same memory?

JW

[stm322399]

Posted on October 13, 2015 at 09:31

you got it ! this is something that happens with memcpy. As f_write also uses memcpy, you can observe the same penalties.

The memcpy routine is provided by the C library, and depending on your library provider, this memcpy migth uses some optimisations based on source and target alignements. In other word, when it is possible, bytes are moved by 4 or even 8 for most of loads and stores. Otherwise bytes are moved one by one. Of course both cases ends up in very different performance.

How it is connected to your data ? Alignment. Yes try the following to understand how it works:

memcpy (dst, src+0, count)

memcpy (dst, src+1, count)

memcpy (dst, src+2, count)

memcpy (dst, src+3, count)

memcpy (dst, src+4, count)

Normally there should be a difference.

When +0 and +4 cases exhibit a significative difference, try to run until +8.

[waclawek.jan]

Posted on October 13, 2015 at 19:46

Laurent,

> you got it !

Memory access alone would explain a (310-40)us difference, not the (50-2)ms difference.

JW

[stm322399]

Posted on October 13, 2015 at 20:17

Oh, you are certainly right. Who knows what's between f_write and memcpy that explains a 50-2 ms difference !