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=


he

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


al pass

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


le to

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


ology

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


zations

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


al world

 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


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 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.
 


DMC supports that as well. Automatic global inlining. That is one of the 
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++.

COM components, and you can get the .NET SDK for the price of 138MB

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




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 Bill Cox <bill viasic.com> writes:
Matthew Wilson wrote:

[Snip]


 Java. Console.WriteLine() rules.)


Nice post.  I couldn't let a debugging tip go by that I didn't 
understand, though.


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

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]


 Java. Console.WriteLine() rules.)


 Nice post.  I couldn't let a debugging tip go by that I didn't
 understand, though.


 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