D - Visual C++ .NET Optimization
- Patrick Down <Patrick_member pathlink.com> Mar 26 2003
- Ilya Minkov <midiclub 8ung.at> Mar 26 2003
- "Walter" <walter digitalmars.com> Mar 26 2003
- "Matthew Wilson" <dmd synesis.com.au> Mar 27 2003
- Andy Friesen <andy ikagames.com> Mar 27 2003
- Ilya Minkov <midiclub tiscali.de> Mar 28 2003
- Bill Cox <bill viasic.com> Mar 27 2003
- "Matthew Wilson" <dmd synesis.com.au> Mar 27 2003
- Bill Cox <bill viasic.com> Mar 28 2003
- "Matthew Wilson" <dmd synesis.com.au> Mar 28 2003
- "Luna Kid" <lunakid neuropolis.org> Mar 29 2003
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
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
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
"Matthew Wilson" <dmd synesis.com.au> 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
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
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
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
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
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
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 withJava. 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
I just also wanted to say the same. Luna KidGlad 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