www.digitalmars.com         C & C++   DMDScript  

D - Visual C++ .NET Optimization

reply Patrick Down <Patrick_member pathlink.com> writes:
Thought this was interesting...

<quote>
Visual C++ .NET delivered a core new optimization called Whole Program
Optimization (WPL). Invoked with a compiler switch (/GL), WPL enables the
compiler a second chance to optimize after the linker has done an initial pass
on all the object files in the project. Normally, compilers are only able to
optimize within the module that they are presently compiling. WPL technology
enables the compiler to see the entire program at once and apply optimizations
on a global scale, resulting in real performance gains (up to 10% in real world
code). Be warnedóWPL eats memory, and in some cases may slow the
compilation/link process.
</quote>

http://www.devx.com/codemag/Article/11519/1954?pf=true
Mar 26 2003
next sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Patrick Down wrote:
 Thought this was interesting...
=20
 <quote>
 Visual C++ .NET delivered a core new optimization called Whole Program
 Optimization (WPL). Invoked with a compiler switch (/GL), WPL enables t=

 compiler a second chance to optimize after the linker has done an initi=

 on all the object files in the project. Normally, compilers are only ab=

 optimize within the module that they are presently compiling. WPL techn=

 enables the compiler to see the entire program at once and apply optimi=

 on a global scale, resulting in real performance gains (up to 10% in re=

 code). Be warned=97WPL eats memory, and in some cases may slow the
 compilation/link process.
 </quote>
=20
 http://www.devx.com/codemag/Article/11519/1954?pf=3Dtrue

An important speed factor factor is the position of code in the=20 executable. And it can be edited in the course of linking, so i think=20 that's what is done here. Some researcher(s) have played around with GCC = linker moving the code around the executable, steered by the callgraphs. = They have yuilded a similar or better order of magnitude on general=20 speed-up. -- i found the description of it, the grope project: http://lwn.net/1998/1029/als/rope.html but all further links lead to nowhere. :( http://www.nat.org/ is the page of the author. At the bottom are the documents describing gro= pe. -i.
Mar 26 2003
next sibling parent reply "Walter" <walter digitalmars.com> writes:
An important speed factor factor is the position of code in the
executable. And it can be edited in the course of linking, so i think
that's what is done here. Some researcher(s) have played around with GCC
linker moving the code around the executable, steered by the callgraphs.
They have yuilded a similar or better order of magnitude on general
speed-up.

Digital Mars C/C++ has had that capability for over 12 years (see the Trace Dynamic Profiler www.digitalmars.com/ctg/trace.html which will generate a linker .def file with the optimal ordering of functions based on the call graph). It's one of the reasons why DMC++ is the fastest compiler - I use it myself ;-)
Mar 26 2003
parent "Matthew Wilson" <dmd synesis.com.au> writes:
LOL.

Much respect to the compiler walter.

And kudos to M$ for catching up to 1991 technology.

(my ribs are hurting)

"Walter" <walter digitalmars.com> wrote in message
news:b5u4ti$nhr$1 digitaldaemon.com...
An important speed factor factor is the position of code in the
executable. And it can be edited in the course of linking, so i think
that's what is done here. Some researcher(s) have played around with GCC
linker moving the code around the executable, steered by the callgraphs.
They have yuilded a similar or better order of magnitude on general
speed-up.

Digital Mars C/C++ has had that capability for over 12 years (see the

 Dynamic Profiler www.digitalmars.com/ctg/trace.html which will generate a
 linker .def file with the optimal ordering of functions based on the call
 graph). It's one of the reasons why DMC++ is the fastest compiler - I use

 myself ;-)

Mar 27 2003
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
Ilya Minkov wrote:
 Patrick Down wrote:
 
 Thought this was interesting...

 <quote>
 Visual C++ .NET delivered a core new optimization called Whole Program
 Optimization (WPL). Invoked with a compiler switch (/GL), WPL enables the
 compiler a second chance to optimize after the linker has done an 
 initial pass
 on all the object files in the project. Normally, compilers are only 
 able to
 optimize within the module that they are presently compiling. WPL 
 technology
 enables the compiler to see the entire program at once and apply 
 optimizations
 on a global scale, resulting in real performance gains (up to 10% in 
 real world
 code). Be warnedóWPL eats memory, and in some cases may slow the
 compilation/link process.
 </quote>

 http://www.devx.com/codemag/Article/11519/1954?pf=true

An important speed factor factor is the position of code in the executable. And it can be edited in the course of linking, so i think that's what is done here. Some researcher(s) have played around with GCC linker moving the code around the executable, steered by the callgraphs. They have yuilded a similar or better order of magnitude on general speed-up. -- i found the description of it, the grope project: http://lwn.net/1998/1029/als/rope.html but all further links lead to nowhere. :( http://www.nat.org/ is the page of the author. At the bottom are the documents describing grope. -i.

Whole Program Optimization is a bit more than that. VC7 can inline things whether or not you declare them in a header, since it's the linker that's doing all the actual code generation. It can also play with calling conventions for functions that aren't exported.
Mar 27 2003
parent Ilya Minkov <midiclub tiscali.de> writes:
Andy Friesen wrote:
 
 Whole Program Optimization is a bit more than that.  VC7 can inline 
 things whether or not you declare them in a header, since it's the 
 linker that's doing all the actual code generation.  It can also play 
 with calling conventions for functions that aren't exported.
 

core features of D. And calling conventions in D are also compiler-dependant and thus can be tuned to actual routines, provided the compiler creates an annotation to each compiled unit. This has not been implemented within current compilers, but certainly is to come. Just as the purity annotation i have proposed. D is much better prepared to such things as all these legacy languages. And the next generation D compilers will also be much faster themselves. :)
Mar 28 2003
prev sibling parent reply Bill Cox <bill viasic.com> writes:
Patrick Down wrote:
 Thought this was interesting...
 
 <quote>
 Visual C++ .NET delivered a core new optimization called Whole Program
 Optimization (WPL). Invoked with a compiler switch (/GL), WPL enables the
 compiler a second chance to optimize after the linker has done an initial pass
 on all the object files in the project. Normally, compilers are only able to
 optimize within the module that they are presently compiling. WPL technology
 enables the compiler to see the entire program at once and apply optimizations
 on a global scale, resulting in real performance gains (up to 10% in real world
 code). Be warned?WPL eats memory, and in some cases may slow the
 compilation/link process.
 </quote>
 
 http://www.devx.com/codemag/Article/11519/1954?pf=true
 
 

Intel's compiler does something similar, although I thought it worked on the intermediate language data structures, rather than after obj files are created. It's much harder to optimize globally after machine code has been generated for each module. I benchmarked the Intel compiler a couple years ago when a college professor I know found it sped up his C++ programs by 10x. It improved the performance of our place and route tools by almost 5% vs Microsoft Visual C++, not quite enough to justify switching compilers. Impressively, there were no bugs found in the Intel compiler when compiling our 300K line program. Apparently the Microsoft compiler was generating total crud from the STL, and Intel's did a good job. Our place and route tools don't use templates, and were not significantly affected by Intel's global optimizations, especially since our inner-most function were declared as static, and were well tuned. Intel also beat Microsoft with global optimizations turned off, although only by 2 or 3 percent. The net gain of global optimization for us is was thus less than 3%. We also tried the optimization Intel can do taking profile data into account. It improved our run time by less than 1%, and basically isn't worth doing for our projects. Bill
Mar 27 2003
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
This roughly fits with my observations on with the numerous compilers I use
for the STLSoft project. I always quote when asked the three top quality
compilers - for performance of generated code, language support, speed of
compilation, features - are Metrowerks CodeWarrior, Intel C++ and Digital
Mars. Working without these three would be a drag indeed.

Also good for language support is Comeau, but it's a bit of pain to work
with. Less good are Borland (middle of the road on most aspects; can be
really dumb with some constructs) and G++ (very slow). Less good again is
Visual C++, although VC7 is a _lot_ better in most respects. Even less good
is Watcom C/C++.

Empirically (good to bad):

  Language support: {Metrowerks, Comeau = equiv}, {Intel, G++, DMC++ =
roughly equiv), Borland C++, Visual C++, Watcom
  Speed of compilation: DMC++ by a country mile, {Borland, Comeau, Intel =
roughly equivalent}, Watcom, Metrowerks, Visual C++, G++
  Speed of code: {DMC++, Intel}, {Visual C++, Borland}, Metrowerks, G++.
(Don't know about Comeau and Watcom)
  Features: {Comeau, DMC++, Intel = equiv, but for different reasons}, then
the rest
  Cost: {DMC++, G++, Watcom = completely free}, Borland C++ (versions prior
to 5.6 are free), Comeau (only US$50), (Intel, Metrowerks = equiv, about
~US5-600}, Visual C++ (very expensive, and not worth it!)

If you've no cash, DMC++ is the one without a doubt, apart from still a
little shaky on namespaces for standard library
If you've a bit of cash, Comeau is good, but you'd still want DMC++, as
Comeau is only a front-end (i.e. C++ => C)
If you _must_ have up-to-date language support, Comeau and Metrowerks are
the ones, although Intel, G++ and DMC++ are none-too-distant runners-up
If you've the cash, get Intel and Metrowerks
If you want nice GUI, get Visual C++, and if you can afford that, you can
afford Intel which is a fully compatible plug-in replacement for Visual C++.
This is the solution I advise M$-addicted clients to go for.
If you want UNIX portability of your projects and what-not, G++ - there's an
opening here, Walter!
If you want Linux portability of your projects and what-not, Intel - there's
an opening here, Walter!
If you want Mac portability of your projects and what-not, Metrowerks -
there's an opening here, Walter!
If you want Palm OS portability of your projects and what-not, Metrowerks -
there's an opening here, Walter!
If you're writing MFC, it has to be Intel, Metrowerks, VC++. Everything else
is such a hassle
If you're writing COM, then DMC++, Intel, Metrowerks, VC++.
If you're writing Marketed C++, then you've got no choice but to buy VC++.
Funny that. In that case I recommend just sticking to interroperating C# and
COM components, and you can get the .NET SDK for the price of 138MB
bandwidth. (IMO you rarely need to debug C#, as it's just like working with
Java. Console.WriteLine() rules.)
If you want portability of your code, write portable code, and use portable
libraries (boost, STLSoft). No easy answers here, folks. ;)
For support of STLSoft, go for Intel, DMC++, Metrowerks, VC++, G++,
Borland++, Comeau. Why, because I made it that way, of course. ;)

Ok, enough rant. [In the words of Wheezy:] "I think I feel an article coming
on ... "

Matthew

"Bill Cox" <bill viasic.com> wrote in message
news:3E831F3C.3030602 viasic.com...
 Patrick Down wrote:
 Thought this was interesting...

 <quote>
 Visual C++ .NET delivered a core new optimization called Whole Program
 Optimization (WPL). Invoked with a compiler switch (/GL), WPL enables


 compiler a second chance to optimize after the linker has done an


 on all the object files in the project. Normally, compilers are only


 optimize within the module that they are presently compiling. WPL


 enables the compiler to see the entire program at once and apply


 on a global scale, resulting in real performance gains (up to 10% in


 code). Be warned?WPL eats memory, and in some cases may slow the
 compilation/link process.
 </quote>

 http://www.devx.com/codemag/Article/11519/1954?pf=true

Intel's compiler does something similar, although I thought it worked on the intermediate language data structures, rather than after obj files are created. It's much harder to optimize globally after machine code has been generated for each module. I benchmarked the Intel compiler a couple years ago when a college professor I know found it sped up his C++ programs by 10x. It improved the performance of our place and route tools by almost 5% vs Microsoft Visual C++, not quite enough to justify switching compilers. Impressively, there were no bugs found in the Intel compiler when compiling our 300K line program. Apparently the Microsoft compiler was generating total crud from the STL, and Intel's did a good job. Our place and route tools don't use templates, and were not significantly affected by Intel's global optimizations, especially since our inner-most function were declared as static, and were well tuned. Intel also beat Microsoft with global optimizations turned off, although only by 2 or 3 percent. The net gain of global optimization for us is was thus less than 3%. We also tried the optimization Intel can do taking profile data into account. It improved our run time by less than 1%, and basically isn't worth doing for our projects. Bill

Mar 27 2003
parent reply Bill Cox <bill viasic.com> writes:
Matthew Wilson wrote:

[Snip]
 (IMO you rarely need to debug C#, as it's just like working with
 Java. Console.WriteLine() rules.)

Nice post. I couldn't let a debugging tip go by that I didn't understand, though. Are you saying C# and Java are easier to debug? Is it just the safety of the languages, or is there something more? Bill
Mar 28 2003
parent reply "Matthew Wilson" <dmd synesis.com.au> writes:
It is a potentially ludicrous and thoroughly unqualified prejudice of mine.
I haven't even done any "Marketed C++", but find the notion of having C++
fall within the strictures of the CLR axiomatically preposterous. From what
I've read it seems so bizarrely complex and messy, and I find C# does almost
anything I want it to. I also am staggered by how many of the C++ "high-ups"
let go unchallenged the oft vaunted notion that Managed C++ is the future of
C++. Talk about M$ hubris!

On safer ground, I consider C++ to be the best (for most things at least)
implementation language, but I almost never use it as the language of
linkage. I always interoperate modules via C-interfaces, either free
functions, or C-compatible C++ interfaces, in the same way as COM (and have
done this quite successfully on UNIX, VMS, Linux systems as well as Win32).
I just can't bear all the mangling crud.

So I guess I'd better retract the advice against using Marketed C++, and
stick to what I know. Perhaps I'll try doing some this week, so I know of
what I speak.

Glad you like the post otherwise. :)

Matthew

"Bill Cox" <bill viasic.com> wrote in message
news:3E844C83.8090909 viasic.com...
 Matthew Wilson wrote:

 [Snip]
  > (IMO you rarely need to debug C#, as it's just like working with
 Java. Console.WriteLine() rules.)

Nice post. I couldn't let a debugging tip go by that I didn't understand, though. Are you saying C# and Java are easier to debug? Is it just the safety of the languages, or is there something more? Bill

Mar 28 2003
parent "Luna Kid" <lunakid neuropolis.org> writes:
I just also wanted to say the same.

Luna Kid


 Glad you like the post otherwise. :)

 Matthew

 "Bill Cox" <bill viasic.com> wrote in message
 news:3E844C83.8090909 viasic.com...
 Matthew Wilson wrote:

 [Snip]

 Nice post.


Mar 29 2003