| View previous topic :: View next topic |
| Author |
Message |
plankton
Joined: 10 Jan 2006 Posts: 12 Location: USA
|
Posted: Wed Mar 24, 2010 12:25 am Post subject: alignment of global arrays for best performance/ALIGN pragma |
|
|
Hi, I'm the developer of PSPSeq, a homebrew audio synthesizer and sequencer used for making music. I'm cleaning up my code in preparation for a new release and have run into an old, strange issue that I could use some advice on.
PSPSeq is heavily data-driven and I have defined a large number of global arrays and other data structures to hold information on instruments and overall song composition. The key data structures I have use the ALIGN() pragma to try and place on a reasonable boundary to limit data cache thrashing and misses. Specifically I have used ALIGN(16) in a number of places. This seems to work pretty well; I haven't benchmarked removing them recently but I do believe it made a difference when I added them in.
The strange thing is what happens if I removed an unused array from a file with a number of data declaration. This of course changes the overall alignment/memory map but I would expect the difference in performance to be negligible if I saw anything at all as some alignments would probably be better and others worse. It definitely is -not- negligible. I am seeing about a 30% reduction in performance! This both proves that data alignment is important, but also means that I really don't have a good grasp on what exactly to do to keep performance at a high level.
Has anyone out there seen this before? Are there specific recommendations for data alignment for best performance? Is ALIGN(16) the right data alignment to choose for commonly accessed arrays? Many of them are 128 or 129 element float arrays. I don't think it's a code alignment issue (the array I removed is unused so the code doesn't change at all) but if there are tricks I can play on that side to make things work better I'd be interested in hearing that too.
Thanks! |
|
| Back to top |
|
 |
m0skit0
Joined: 02 Jun 2009 Posts: 226
|
Posted: Wed Mar 24, 2010 2:03 am Post subject: |
|
|
I think ALIGN(32) would be better for float arrays. _________________
| The Incredible Bill Gates wrote: | | The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers. |
|
|
| Back to top |
|
 |
Jim

Joined: 02 Jul 2005 Posts: 487 Location: Sydney
|
Posted: Wed Mar 24, 2010 5:56 am Post subject: |
|
|
It's possible that moving things around has changed your data cache usage pattern and that is what is affecting the performance.
Jim _________________ http://www.dbfinteractive.com |
|
| Back to top |
|
 |
plankton
Joined: 10 Jan 2006 Posts: 12 Location: USA
|
Posted: Wed Mar 24, 2010 11:51 pm Post subject: |
|
|
| Jim wrote: | It's possible that moving things around has changed your data cache usage pattern and that is what is affecting the performance.
Jim |
Yes that's what I assume is happening but I am surprised that it is that extreme of a performance degradation. What I am asking is what rules of thumb I should follow in data layout to reduce these sorts of effects. I thought that applying data alignment to key arrays would be enough to keep things relatively stable but that's not proven to be the case.
Is there any documentation on the exact cache memory configuration of the PSP? Are there any directives for controlling exact placement of data in memory? I work on embedded systems where there's typically a linker description file of some sort where you can force specific arrays to lie at particular places in memory. The fact that a simple change made such a huge change in performance makes me wonder if the "good" layout is even close to optimal or if I could see further improvements if I more carefully controlled how data was placed in memory. |
|
| Back to top |
|
 |
plankton
Joined: 10 Jan 2006 Posts: 12 Location: USA
|
Posted: Thu Mar 25, 2010 9:53 am Post subject: |
|
|
| m0skit0 wrote: | | I think ALIGN(32) would be better for float arrays. |
Actually it didn't make any difference. I tried 32, 64, and 4 (essentially no alignment since I assume 32 bit data needs 4 byte alignment) and removing that unused data declaration makes everything run very slowly.
Interestingly enough, I also checked to see if ALIGN was doing anything at all to slow down or speed up the code and that does not appear to be the case! ALIGN(4) is just as fast as ALIGN(16). So now I'm even more confused as to why things are going wrong in my code.
I'll ask again - does anyone have documentation on how the data caches work on the PSP? |
|
| Back to top |
|
 |
|