Hi friends.
I am wondering if there are any methods for defining the memory allocation for a function level "symbol" (fx pointer or array).
I know the DATA_SECTION pragma can be used on file level. Is there a simular method that can be applied for non-global variables?
Thank you for your time.
Esben.
Can you please post some more details ? The code that you might be working with.
Hoping to see you back soon.
REALNAPSTER
I wouldn't think so, the stack works quite well and it's efficient. Where else do you want to put them? You can align data with the aligned keyword (if that's at all helpful). You could also use static, I think that plops it in bss or data, not sure though.
Last edited by valis; 04-28-2006 at 03:51 PM.
>the stack works quite well and it's efficient. Where else do you want to put them?
Arent variables normally allocated on the heap?
I am tuning some code to run fast on a TI c6416 dsp. I have a problem with thrashing of one of my dynamic arrays, and I want to make sure that this array is read into a different cache-line than the arrays that might be thrashing it.
I am not sure this code will make any sense in regards to the cache problems but here it goes:
My problem is with the 'tmpptr', which points 'buf', whick points to 'splitbuf'. I would like to control the allocation of this 'splitbuf' to avoid thrashing...Code:static void jpc_qmfb1d_split(jpc_fix_t *startptr, int startind, int endind, register int step, jpc_fix_t *lstartptr, int lstartind, int lendind, jpc_fix_t *hstartptr, int hstartind, int hendind) { const int bufsize = JPC_CEILDIVPOW2(endind - startind, 2); #if !defined(HAVE_VLA) #define QMFB_SPLITBUFSIZE 4096 jpc_fix_t *splitbuf=(jpc_fix_t*)malloc(sizeof(jpc_fix_t)*QMFB_SPLITBUFSIZE); #else jpc_fix_t *splitbuf=(jpc_fix_t*)malloc(sizeof(jpc_fix_t)*bufsize); #endif jpc_fix_t *buf; int llen; int hlen; int twostep; jpc_fix_t *tmpptr; register jpc_fix_t *ptr; register jpc_fix_t *hptr; register jpc_fix_t *lptr; register int n; int state; buf = splitbuf; twostep = step << 1; llen = lendind - lstartind; hlen = hendind - hstartind; #if !defined(HAVE_VLA) if (bufsize > QMFB_SPLITBUFSIZE) { //esbn: ..SIZE=4096. if (!(buf = jas_malloc(bufsize * sizeof(jpc_fix_t)))) { abort(); } } #endif state = 0; ptr = startptr; lptr = lstartptr; tmpptr = buf; n = llen; #pragma MUST_ITERATE(2,,); while (n-- > 0) { if (state) { *tmpptr = *lptr; ++tmpptr; } *lptr = *ptr; ptr += twostep; lptr += step; state ^= 1; } ptr = &startptr[((((llen + hlen) >> 1) << 1) - 1) * step]; hptr = &hstartptr[(hlen - 1) * step]; n = hlen - (tmpptr - buf); #pragma MUST_ITERATE(2,,); while (n-- > 0) { *hptr = *ptr; ptr -= twostep; hptr -= step; } n = tmpptr - buf; #pragma MUST_ITERATE(2,,); while (n-- > 0) { --tmpptr; *hptr = *tmpptr; hptr -= step; } #if !defined(HAVE_VLA) /* If the split buffer was allocated on the heap, free this memory. */ if (buf != splitbuf) { jas_free(buf); } #endif }
Hope this made some sense...
Esben.
1. How do you know it is a cache problem?
2. What is the difference between malloc and jas_malloc ?
3. Why don't you free splitbuf - I see massive memory leakage here.
malloc and free calls can be pretty expensive, maybe this is the actual cause of the problem.
For a given input, compare the results with using a static array of a known size with using malloc to allocate the same.
4. Why are you using the register keyword?
Modern compilers are much more efficient at working out which variables are best stored in registers.
At best, the compiler will just ignore your attempts
At worst, the compiler will try and obey your wishes, even if the code is worse as a result.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
>Salem:
>1. How do you know it is a cache problem?
I have runned a profiling analysis on the code, and can see that I have 5% cpu stall cycles caused by cache read and write misses...
>2. What is the difference between malloc and jas_malloc ?
No difference really. jas_malloc() just calls malloc(). Guess it's for portabililty purposes or something. I'm not sure, the original code is open source, not mine.
>3. Why don't you free splitbuf?
ups...and you are right: it just costed me 80,000 cpu cycles to free the splitbuf. I declared it as a static array instead and gained back almost 150,000 cycles.
By the way, the reason I have declared it as a dynamic array is off course for flexability purposes. Is there any way to keep this kind of flexability with a static array?
The original declaration looked like the following. It couldnt build on TI.s CCS developer, and I must say I find it strange that it could in MSVC...
>4. Why are you using the register keyword?Code:const int bufsize = JPC_CEILDIVPOW2(endind - startind, 2); #if !defined(HAVE_VLA) #define QMFB_SPLITBUFSIZE 4096 static jpc_fix_t splitbuf[QMFB_SPLITBUFSIZE]; #else jpc_fix_t splitbuf[bufsize]; #endif
Good question. I removed the register keyword and gained 300 cycles
> and can see that I have 5% cpu stall cycles caused by cache read and write misses
Since you seem to be walking through memory in a linear fashion, this doesn't seem unreasonable.
Are there any #pragma hints for cache prediction?
Is there a cache API, which may for example make it more favourable to linear access rather than random access?
> while (n-- > 0)
> if (state)
If n is always even when you run this loop, I would suggest you unroll it and eliminate the state variable altogether. Even if it isn't, making the last iteration a special case is going to be preferable to testing the flag on each iteration.
> #pragma MUST_ITERATE(2,,)Code:while (n-- > 0) { // these lines done when state == 0 *lptr = *ptr; ptr += twostep; lptr += step; // these lines done when state == 1 *tmpptr = *lptr; ++tmpptr; *lptr = *ptr; ptr += twostep; lptr += step; }
Check your optimisation hints.
http://tii.developerconference.ext.t...n-tutorial.pdf
> My problem is with the 'tmpptr', which points 'buf', whick points to 'splitbuf'.
In particular, does your compiler support the "restrict" qualifier which helps to reduce the pointer aliasing problem.
> Is there any way to keep this kind of flexability with a static array?
Perform some calculation to determine whether your static array is big enough. If it is, use it. If not, malloc.
Or you could just pass the problem back to the caller, and let it supply the working storage buffer as another parameter, since the caller is likely to know more about what is required.
> and I must say I find it strange that it could in MSVC
Variable length arrays are a C99 only feature. It is not in C89 nor C++.
However, this doesn't stop individual compilers from extending the language in various ways, and vla's seem a popular thing to support.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Salem: thanks for you helpful suggestions.
>I would suggest you unroll it and eliminate the state variable altogether.
I dont understand how UNROLL together with your code example corresponds to the original code...?
Esben.
State toggles between false and true
It's simply all the code which executes when state == 0, followed by all the code which executes when state == 1
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Sure! I see it...and I would have to run the loop n/2 itertions, right?
Yes.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
