problem with microsoft speed optimization

[mjbackues at yahoo]

Hello.

I'm having a problem with the Visual Studio .net (2003) C++ speed
optimization, and hope someone can suggest a workaround.

My project includes many C++ files, most of which work fine with speed
optimization turned on. At least one does not however, though it does
work with size optimization turned on. I don't know specifically what
the optimizer is doing wrong, just that the output is incorrect. And I
know within about 10 lines where the problem is. I've tried
rearranging the offending lines (which are straight C code). I've
tried using 'volitle' data types in hopes of avoiding optimization.
I've looked for missing variable initializations, but everything looks
correct and straightforward.

One solution would be to have a precompiler directive which would
enable (or disable) the optimization only on specific files. Of course
I can manually turn the optimization on and off while recompiling
specific files, but I need something automated.

I can't post the code, but will try to follow up with a test case that
exhibits the same behavior.

Presumably the program would compile fine with g++, but unfortunately
that's not an option for this project.

Thanks very much.

Mark

 

[deane_gavin]

Hello.

I'm having a problem with the Visual Studio .net (2003) C++ speed
optimization, and hope someone can suggest a workaround.

My project includes many C++ files, most of which work fine with speed
optimization turned on. At least one does not however, though it does
work with size optimization turned on. I don't know specifically what
the optimizer is doing wrong, just that the output is incorrect. And I
know within about 10 lines where the problem is. I've tried
rearranging the offending lines (which are straight C code). I've
tried using 'volitle' data types in hopes of avoiding optimization.
I've looked for missing variable initializations, but everything looks
correct and straightforward.

One solution would be to have a precompiler directive which would
enable (or disable) the optimization only on specific files. Of course
I can manually turn the optimization on and off while recompiling
specific files, but I need something automated.

I can't post the code, but will try to follow up with a test case that
exhibits the same behavior.

Presumably the program would compile fine with g++, but unfortunately
that's not an option for this project.

It sounds like you're asking about the particular behaviour of your
compiler's optimiser. If so, then you are asking the wrong group. There
is a VC++ .Net group suggested here.

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9

Gavin Deane

 

[mjbackues at yahoo]

OK, thanks.

 

[mlimber]

Hello.

I'm having a problem with the Visual Studio .net (2003) C++ speed
optimization, and hope someone can suggest a workaround.

This subject matter is off-topic in this group, which is solely
concerned with *standard* C++. See the FAQ for what is on-topic and for
some suggestions of better places to post:

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9

My project includes many C++ files, most of which work fine with speed
optimization turned on. At least one does not however, though it does
work with size optimization turned on. I don't know specifically what
the optimizer is doing wrong, just that the output is incorrect. And I
know within about 10 lines where the problem is. I've tried
rearranging the offending lines (which are straight C code). I've
tried using 'volitle' data types in hopes of avoiding optimization.
I've looked for missing variable initializations, but everything looks
correct and straightforward.

People often blame the compiler for strange errors, but it usually
turns out to be user error, perhaps in an apparently unrelated part of
the program. Have you tried looking at the generated assembly code?

One solution would be to have a precompiler directive which would
enable (or disable) the optimization only on specific files. Of course
I can manually turn the optimization on and off while recompiling
specific files, but I need something automated.

Look up #pragma in your compiler documentation. Better yet, turn off
the optimizer altogether (except for inlining and such). See this
article, "Optimization: Your Worst Enemy":

http://www.codeproject.com/tips/optimizationenemy.asp

See also "Surviving the Release Version":

http://www.codeproject.com/debug/survivereleasever.asp

I can't post the code, but will try to follow up with a test case that
exhibits the same behavior.

You should have done this before posting. See the FAQ:

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8

But, of course, if you had read the FAQ in advance, you would have
posted to a different newsgroup to begin with. ;-)

Presumably the program would compile fine with g++, but unfortunately
that's not an option for this project.

Such warantless speculation is entirely unhelpful. If possible, you
should try at least the problem spot in your code on that and any other
compiler you have at your disposal. You could use the same distilled
code that you'll be posting shortly, and that might generate some
helpful results.

Cheers! --M

 

[mjbackues at yahoo]

Wow. Since you fancy yourself clever and obviously have time on your
hands....following is a test program that works with gcc but not with
visual studio (either with or without optimization). The output using
'fprintf' is correct, whereas the output with 'fwrite' is not, and the
resulting file doesn't even have the right size. The 'fwrite' does
work however if the '3.14' in the preceeding calculation is replaced
with another pi approximation with more digits.

Useful responses from other people are also welcome.

#include <stdio.h>
#include <math.h>
#include <malloc.h>
#define PI 3.14159265358979

main(){
float* ph;
int i;
FILE *fid;

ph = (float*)malloc(sizeof(float)*128*1024*2);

for(i=0;i<128*1024*2;i+=2){
ph=(float)cos(3.14*(double)i*0.2);
ph[i+1]=1.0;
}

fid=fopen("out1","w");
for(i=0;i<128*1024*2;i++)
fprintf(fid,"%lf\n",ph);
fclose(fid);

fid = fopen("out2","w");
fwrite(ph,sizeof(float),128*1024*2,fid);
fclose(fid);

free(ph);
}

 

[Pete Becker]

fid = fopen("out2","w");
fwrite(ph,sizeof(float),128*1024*2,fid);

When you're writing binary data you must open the file with "wb" rather
than "w".

 

[mlimber]

Wow. Since you fancy yourself clever and obviously have time on your
hands....following is a test program that works with gcc but not with
visual studio (either with or without optimization). The output using
'fprintf' is correct, whereas the output with 'fwrite' is not, and the
resulting file doesn't even have the right size. The 'fwrite' does
work however if the '3.14' in the preceeding calculation is replaced
with another pi approximation with more digits.

Useful responses from other people are also welcome.

#include <stdio.h>
#include <math.h>
#include <malloc.h>
#define PI 3.14159265358979

main(){
float* ph;
int i;
FILE *fid;

ph = (float*)malloc(sizeof(float)*128*1024*2);

for(i=0;i<128*1024*2;i+=2){
ph=(float)cos(3.14*(double)i*0.2);
ph[i+1]=1.0;
}

fid=fopen("out1","w");
for(i=0;i<128*1024*2;i++)
fprintf(fid,"%lf\n",ph);
fclose(fid);

fid = fopen("out2","w");
fwrite(ph,sizeof(float),128*1024*2,fid);
fclose(fid);

free(ph);
}

In what way is the output incorrect?

BTW, a more C++-style way to do it might look something like:

#include <vector>
#include <cmath>
#include <fstream>
#include <iostream>
#include <iterator>
#include <algorithm>

using namespace std;

#define PI 3.14159265358979

int main()
{
vector<double> v( 128*1024*2 );

for(unsigned int i=0; i < v.size(); i+=2 )
{
v=cos(PI*i*0.2);
v[i+1]=1.0;
}

ofstream f1("out1");
if( !f1 )
{
cerr << "error!" << endl;
return -1;
}
copy( v.begin(), v.end(),
ostream_iterator<double>( f1, "\n" ) );

ofstream f2( "out2", ios_base::binary );
if( !f2
|| !f2.write( reinterpret_cast<const char*>( &v[0] ),
v.size()*sizeof(double) ) )
{
cerr << "error!" << endl;
return -1;
}

return 0;
}

 

[mjbackues at yahoo]

yeah, that's it, thanks very much.

 

[mjbackues at yahoo]

Thanks. This was a problem a coworker had, and he wound up using
ofstream and write to get around it.

 

[mjbackues at yahoo]

yeah, that's it, thanks very much.

oops, intended as reply to Pete Becker

 

[E. Mark Ping]

When you're writing binary data you must open the file with "wb" rather
than "w".

And IIRC the default mode is text in VC, but binary in GCC. Which
caused some interesting issues when I was porting some code a while
back.

 

[Mike Smith]

One solution would be to have a precompiler directive which would
enable (or disable) the optimization only on specific files. Of course
I can manually turn the optimization on and off while recompiling
specific files, but I need something automated.

IIRC there are #pragmas that can do this; consult your documentation.

 

[Jack Klein]

On Thu, 29 Dec 2005 17:53:06 +0000 (UTC),

And IIRC the default mode is text in VC, but binary in GCC. Which
caused some interesting issues when I was porting some code a while
back.

The default mode is text in any conforming C or C++ compiler. It just
so happens that on *X operating systems, there is no translation or
substitution of characters in text mode, so the effect of using text
or binary mode is the same.

 

[mjbackues at yahoo]

Thanks. #pragmas didn't work, but someone pointed out some file
specific settings that did.

 

[Pete Becker]

And IIRC the default mode is text in VC, but binary in GCC. Which
caused some interesting issues when I was porting some code a while
back.

When passed to fopen, "w" says to open for writing in text mode. "wb"
says to open for writing in binary mode. VC and GCC both implement that
correctly.

 

[E. Mark Ping]

When passed to fopen, "w" says to open for writing in text mode. "wb"
says to open for writing in binary mode. VC and GCC both implement that
correctly.

That may be the case now, but for GCC it wasn't on the version I was
porting from in 2002. Now that I think about it, it was on a read,
not a write.

 

[mlimber]

That may be the case now, but for GCC it wasn't on the version I was
porting from in 2002.

[snip]

It may well have been just an OS dependency, not a non-conformancy in
the compiler. See Jack Klein's post:

http://groups.google.com/group/comp.lang.c++/msg/6d4f7b0a262826b6

Cheers! --M

 

[E. Mark Ping]

It may well have been just an OS dependency, not a non-conformancy in
the compiler. See Jack Klein's post:

http://groups.google.com/group/comp.lang.c++/msg/6d4f7b0a262826b6

Ah, that would explain it. Thanks for setting me straight. It was a
port from Linux to Win32.

 

[Pete Becker]

That may be the case now, but for GCC it wasn't on the version I was
porting from in 2002.

If so, the library had a serious bug. That's been the rule since time
immemorial. Or, at least, since the original C standard.

 

[E. Mark Ping]

If so, the library had a serious bug. That's been the rule since time
immemorial. Or, at least, since the original C standard.

I think Jack Klein corrected me in that on the Linux OS binary is the
same as text mode.