Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Memory access optimization

Reply
Thread Tools

Memory access optimization

 
 
rodneys@gmx.de
Guest
Posts: n/a
 
      01-11-2006
Hi,

please take a look to this sample code:

class MyClass {
private:
static int length ;
public:
static void setLength(int newLength) ;
void do() ;
}

int MyClass::length ;

void MyClass::setLength(int newLength) {
length=newLength ;
}

void MyClass::do() {
for(int i=0;i<length;i++) {
// some simple floating point additions and multiplications ...
}
}

I expected that the compiler (Microsoft EVC 4 for ARM, full
optimization)
would optimize the for-loop of the method "do" to
register int t=length ;
for(int i=0;i<t;i++) {
...
}
But this does not happen. Instead, the generated machine code
refetches "length" in each iteration of the for-loop. Why?
Does the compiler "fear" that another thread could call "setLength"
while the for-loop runs? "length" is *not* declared volatile.

Is there a formal specification how long a compiler is allowed to cache
non-local variables in registers? For example, can code like
a = length ;
b = length ;
always be expected to be optimized to
register int t=length ;
a=t ;
b=t ;
?

rs

 
Reply With Quote
 
 
 
 
Thomas Maier-Komor
Guest
Posts: n/a
 
      01-11-2006
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> Hi,
>
> please take a look to this sample code:
>
> class MyClass {
> private:
> static int length ;
> public:
> static void setLength(int newLength) ;
> void do() ;
> }
>
> int MyClass::length ;
>
> void MyClass::setLength(int newLength) {
> length=newLength ;
> }
>
> void MyClass::do() {
> for(int i=0;i<length;i++) {
> // some simple floating point additions and multiplications ...
> }
> }
>
> I expected that the compiler (Microsoft EVC 4 for ARM, full
> optimization)
> would optimize the for-loop of the method "do" to
> register int t=length ;
> for(int i=0;i<t;i++) {
> ...
> }
> But this does not happen. Instead, the generated machine code
> refetches "length" in each iteration of the for-loop. Why?
> Does the compiler "fear" that another thread could call "setLength"
> while the for-loop runs? "length" is *not* declared volatile.
>
> Is there a formal specification how long a compiler is allowed to cache
> non-local variables in registers? For example, can code like
> a = length ;
> b = length ;
> always be expected to be optimized to
> register int t=length ;
> a=t ;
> b=t ;
> ?
>
> rs
>


rule of thumb is to cache any global variable in a local variable to
ease optimization for the compiler. If a register is available, it will
be allocated for the local variable. If none is available, the local
varialbe will most likely be allocated on stack and therefore will most
likely have a better cache behaviour than its global counterpart. The
compiler might even be capable of eliminating the local variable.

I cannot say what the reason for missing optimization is your case,
because you omitted the contents of the for loop. But I recomend to
allocate a local variable that is the copy of the object attribute.

HTH,
Tom
 
Reply With Quote
 
 
 
 
mlimber
Guest
Posts: n/a
 
      01-11-2006
(E-Mail Removed) wrote:
> Hi,
>
> please take a look to this sample code:
>
> class MyClass {
> private:
> static int length ;
> public:
> static void setLength(int newLength) ;
> void do() ;
> }
>
> int MyClass::length ;
>
> void MyClass::setLength(int newLength) {
> length=newLength ;
> }
>
> void MyClass::do() {
> for(int i=0;i<length;i++) {
> // some simple floating point additions and multiplications ...
> }
> }
>
> I expected that the compiler (Microsoft EVC 4 for ARM, full
> optimization)
> would optimize the for-loop of the method "do" to
> register int t=length ;
> for(int i=0;i<t;i++) {
> ...
> }
> But this does not happen. Instead, the generated machine code
> refetches "length" in each iteration of the for-loop. Why?
> Does the compiler "fear" that another thread could call "setLength"
> while the for-loop runs? "length" is *not* declared volatile.
>
> Is there a formal specification how long a compiler is allowed to cache
> non-local variables in registers? For example, can code like
> a = length ;
> b = length ;
> always be expected to be optimized to
> register int t=length ;
> a=t ;
> b=t ;
> ?
>
> rs


There is no formal specification for such optimizations in the
Standard. You might be better off posting in Microsoft-specific group
where more of their experts lurk. Several such groups are listed in
this FAQ:

http://www.parashift.com/c++-faq-lit...t.html#faq-5.9

Cheers! --M

 
Reply With Quote
 
rodneys@gmx.de
Guest
Posts: n/a
 
      01-11-2006
> There is no formal specification for such optimizations in the
> Standard. You might be better off posting in Microsoft-specific group
> where more of their experts lurk. Several such groups are listed in
> [...]


I know that it may be a MS-specific thing but I wanted to know what
c.l.c++ thinks about it. Do you agree with me that nothing in the specs
prevents the compiler from doing the optimization unless the variable
is declared volatile?

rs

 
Reply With Quote
 
David Harmon
Guest
Posts: n/a
 
      01-11-2006
On 11 Jan 2006 06:00:59 -0800 in comp.lang.c++, (E-Mail Removed)
wrote,
>I know that it may be a MS-specific thing but I wanted to know what
>c.l.c++ thinks about it. Do you agree with me that nothing in the specs
>prevents the compiler from doing the optimization unless the variable
>is declared volatile?


I think you are right.


 
Reply With Quote
 
Dave Townsend
Guest
Posts: n/a
 
      01-11-2006

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> > There is no formal specification for such optimizations in the
> > Standard. You might be better off posting in Microsoft-specific group
> > where more of their experts lurk. Several such groups are listed in
> > [...]

>
> I know that it may be a MS-specific thing but I wanted to know what
> c.l.c++ thinks about it. Do you agree with me that nothing in the specs
> prevents the compiler from doing the optimization unless the variable
> is declared volatile?
>
> rs
>


Why don't you make the length variable a local and see what MSVC does ?
Although "length" is not declared as voltaile, in typical MS manner, they
might
have tried to anticipate that you might be modifying "length" in another
thread
and so get the value each iteration of the loop.


 
Reply With Quote
 
Bo Persson
Guest
Posts: n/a
 
      01-12-2006

"Dave Townsend" <(E-Mail Removed)> skrev i meddelandet
news:(E-Mail Removed). ..
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ups.com...
>> > There is no formal specification for such optimizations in the
>> > Standard. You might be better off posting in Microsoft-specific
>> > group
>> > where more of their experts lurk. Several such groups are listed
>> > in
>> > [...]

>>
>> I know that it may be a MS-specific thing but I wanted to know what
>> c.l.c++ thinks about it. Do you agree with me that nothing in the
>> specs
>> prevents the compiler from doing the optimization unless the
>> variable
>> is declared volatile?
>>
>> rs
>>

>
> Why don't you make the length variable a local and see what MSVC
> does ?
> Although "length" is not declared as voltaile, in typical MS manner,
> they
> might
> have tried to anticipate that you might be modifying "length" in
> another
> thread
> and so get the value each iteration of the loop.


Yes. The length is globally accessible through the public static
function setLength. To be able to cache the length, the compiler must
first prove that no one is ever calling setLenght while the loop runs.

That's hard to do in the general case, so they have obviously not
bothered.


Bo Persson


 
Reply With Quote
 
rodneys@gmx.de
Guest
Posts: n/a
 
      01-12-2006
> Yes. The length is globally accessible through the public static
> function setLength. To be able to cache the length, the compiler must
> first prove that no one is ever calling setLenght while the loop runs.


As already discussed above, the specs don't force the compiler
to prove anything, do they?

Ramin

 
Reply With Quote
 
rodneys@gmx.de
Guest
Posts: n/a
 
      01-12-2006
> Why don't you make the length variable a local and see what MSVC does ?

First thing I tried. As expected, the local variable is kept in a
register
(plenty of free registers in the ARM processor).

> Although "length" is not declared as voltaile, in typical MS manner, they
> might have tried to anticipate that you might be modifying "length" in
> another thread and so get the value each iteration of the loop.


As an experiment, I removed the setter-method and initialized the
variable
via
static MyClass::length=10 ;
so that the variable is never write-accessed in the code. No difference


I suppose that optimization on global data is generally very difficult
in languages like C/C++ where the compiler has to assume that you can
modify any variable indirectly with some pointer arithmetic+type casts.

Ramin

 
Reply With Quote
 
Bo Persson
Guest
Posts: n/a
 
      01-12-2006

<(E-Mail Removed)> skrev i meddelandet
news:(E-Mail Removed) ups.com...
>> Yes. The length is globally accessible through the public static
>> function setLength. To be able to cache the length, the compiler
>> must
>> first prove that no one is ever calling setLenght while the loop
>> runs.

>
> As already discussed above, the specs don't force the compiler
> to prove anything, do they?


Yes, they do. Using volatile prevents the compiler from keeping the
value in a register. Not using volatile doesn't automatically allow
caching. The compiler must first make sure that the value is not
updated any other way. If the variable is global, or accessible
through a public function, that is hard.

Consider this code:

int i;

void f(int& j)
{
for (i = 0; i < 10; i++)
j = i;
}

int main()
{
int k;

f(k);
f(i);

}

What happens for f(k) ?
What happens for f(i) ?

Does that affect the optimizations possible for the function f()? It
sure does!


Bo Persson






 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Any optimization technique regarding efficient use of memory spacefor class/Union types? Good Guy C++ 4 10-19-2010 01:32 PM
Zero Optimization and Sign Optimization??? Ravikiran C Programming 22 11-24-2008 03:19 AM
combinations script - out of memory - optimization? Andrew Perl Misc 13 03-20-2006 08:57 AM
memory optimization Evangelista Sami C Programming 4 06-15-2004 02:16 PM
c++ memory optimization BCC C++ 11 11-06-2003 04:26 PM



Advertisments