Optimizing with 2003 .NET

[Flashman]

A little confusing with setting up optimizing options with 2003 .NET.
Under the Optimization Tab. if you set to /O1 or /O2 is the program ignoring
the settings for Inline Function expansion, Enabling of Intrinsic?
Would seem these should be greyed out to let you know.

Bigger question is what have people found in setting up the optimizing?
Using /O1 or /O2 ? Any ideas would be greatly appreciated.

[Carl Daniel [VC++ MVP]]

Flashman wrote:

A little confusing with setting up optimizing options with 2003 .NET.
Under the Optimization Tab. if you set to /O1 or /O2 is the program
ignoring the settings for Inline Function expansion, Enabling of
Intrinsic?
Would seem these should be greyed out to let you know.
That would be nice, but it's not so. /O1 and /O2 are just shortcuts anyway.

/O1 = /Og /Os /Oy /Ob2 /Gs /GF /Gy

/O2 = /Og /Oi /Ot /Oy /Ob2 /Gs /GF /Gy

If you also enabled any of those other options they're redundant but not
harmful.
Bigger question is what have people found in setting up the
optimizing? Using /O1 or /O2 ? Any ideas would be greatly appreciated.

The default for a release build is /O2. In the past (VC6) many people found
that /O1 actually generated faster code. I'd go with the default of /O2 but
if you're curious, do some profiling of your app under the workloads that
are important to you to see if /O1 or some other combination is a better
choice for you.

You may also want to try /GL and the related linker setting /LTCG which
enable cross-module inlining.

With VC++ 2005 you'll also get PGO - Profile guided optimization that allows
you to run an instrumented version of your application to gather profile
information which can then be fed back into the compiler to produced an even
more optimized version.

-cd

[Flashman]

Thanks for your answer Daniel! A couple of other questions on this if someone
can answer. What would be the settings for .NET 2003 to match Visual C++ 6.00
optimizing? I find the executable from .NET 2003 alot larger then what was
produced under 6.00?

"Carl Daniel [VC++ MVP]" wrote:

Flashman wrote:

A little confusing with setting up optimizing options with 2003 .NET.
Under the Optimization Tab. if you set to /O1 or /O2 is the program
ignoring the settings for Inline Function expansion, Enabling of
Intrinsic?
Would seem these should be greyed out to let you know.

That would be nice, but it's not so. /O1 and /O2 are just shortcuts anyway.

/O1 = /Og /Os /Oy /Ob2 /Gs /GF /Gy

/O2 = /Og /Oi /Ot /Oy /Ob2 /Gs /GF /Gy

If you also enabled any of those other options they're redundant but not
harmful.

Bigger question is what have people found in setting up the
optimizing? Using /O1 or /O2 ? Any ideas would be greatly appreciated.

The default for a release build is /O2. In the past (VC6) many people found
that /O1 actually generated faster code. I'd go with the default of /O2 but
if you're curious, do some profiling of your app under the workloads that
are important to you to see if /O1 or some other combination is a better
choice for you.

You may also want to try /GL and the related linker setting /LTCG which
enable cross-module inlining.

With VC++ 2005 you'll also get PGO - Profile guided optimization that allows
you to run an instrumented version of your application to gather profile
information which can then be fed back into the compiler to produced an even
more optimized version.

-cd

[Carl Daniel [VC++ MVP]]

Flashman wrote:

Thanks for your answer Daniel! A couple of other questions on this if
someone can answer. What would be the settings for .NET 2003 to match
Visual C++ 6.00 optimizing? I find the executable from .NET 2003 alot
larger then what was produced under 6.00?

The settings are basically equivalent between the two, but there's no
combination of settings that will cause VC7.1 to produce exactly the same
code as VC6.

Some ideas in regard to executable size:

1. Make sure you're looking at a release build, not a debug build. VC7+
debug builds are quite a lot larger due to additional debug code.
2. Make sure you're not compiling with /RTC or /GS. Those options increase
code size, and VC6 had no equivalent options.
3. Use a linker map to determine the actual code size of the modules YOU
wrote. Many library modules are larger in VC7+ due to additional robustness
features, conformance improvements, etc.
4. Use dumpbin to determine the size of the code in your executable instead
of the size of the executable itself. There may be additional initialize
data (etc) in the VC7+ executable.
5. Make sure you're comparing native builds - i.e. that you're not compiling
with /clr in VC7.1. Otherwise you're comparing two different machine
architectures.

When you account for the other things that affect executable size, you'll
generally find that VC7.1 produces smaller/faster code than VC6.

-cd

[Flashman]

Hello Daniel:

Problem that occurs is that I have an application under Visual C++ 6.0 exe
release size around 9.7MBytes. Compiling under .NET 2003 release with some
optimizing on produces code ~11 MBytes. Turn on some optimizing (Specifically
Global Opt)
and the program crashes.

Thanks again, will try to profile the app.
Cheers,
Randy

"Carl Daniel [VC++ MVP]" wrote:

Flashman wrote:

Thanks for your answer Daniel! A couple of other questions on this if
someone can answer. What would be the settings for .NET 2003 to match
Visual C++ 6.00 optimizing? I find the executable from .NET 2003 alot
larger then what was produced under 6.00?

The settings are basically equivalent between the two, but there's no
combination of settings that will cause VC7.1 to produce exactly the same
code as VC6.

Some ideas in regard to executable size:

1. Make sure you're looking at a release build, not a debug build. VC7+
debug builds are quite a lot larger due to additional debug code.
2. Make sure you're not compiling with /RTC or /GS. Those options increase
code size, and VC6 had no equivalent options.
3. Use a linker map to determine the actual code size of the modules YOU
wrote. Many library modules are larger in VC7+ due to additional robustness
features, conformance improvements, etc.
4. Use dumpbin to determine the size of the code in your executable instead
of the size of the executable itself. There may be additional initialize
data (etc) in the VC7+ executable.
5. Make sure you're comparing native builds - i.e. that you're not compiling
with /clr in VC7.1. Otherwise you're comparing two different machine
architectures.

When you account for the other things that affect executable size, you'll
generally find that VC7.1 produces smaller/faster code than VC6.

-cd