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
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
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
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[i]=(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[i]);
fclose(fid);
fid = fopen("out2","w");
fwrite(ph,sizeof(float),128*1024*2,fid);
fclose(fid);
free(ph);
}
When you're writing binary data you must open the file with "wb" rather
than "w".
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
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[i]=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;
}
oops, intended as reply to 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.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
IIRC there are #pragmas that can do this; consult your documentation.
--
Mike Smith
> In article <t5SdnbmlSeM7kSne...@giganews.com>,
> Pete Becker <peteb...@acm.org> wrote:
> >mjbackues at yahoo wrote:
> >> 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".
>
> 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.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
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.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
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
Ah, that would explain it. Thanks for setting me straight. It was a
port from Linux to Win32.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
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.
--
Mark Ping
ema...@soda.CSUA.Berkeley.EDU
Yes, some systems hide the difference. <g>
Being curious: If your problem was indeed related to
opening files in text vs. binary mode, why changing
the optimization settings caused the problem to go
away?