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

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.

>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 ;-)

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 ;-)
>
>
>

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.

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

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

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

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

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
>