www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Profiler Speed

reply dsimcha <dsimcha yahoo.com> writes:
I'm working on optimizing some code now, and a nagging issue that I've been
meaning to bring up is how slow stuff runs when profiling is turned on.  It
seems that, given any code that's slow enough to be worth
profiling/optimizing, the DMD profiler slows it down further, to the point
where it's impractical to profile because it would take forever to get the
results.  Does anyone have any tips for speeding this up?
Jan 15 2009
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"dsimcha" <dsimcha yahoo.com> wrote in message 
news:gkobmc$17r0$1 digitalmars.com...
 I'm working on optimizing some code now, and a nagging issue that I've 
 been
 meaning to bring up is how slow stuff runs when profiling is turned on. 
 It
 seems that, given any code that's slow enough to be worth
 profiling/optimizing, the DMD profiler slows it down further, to the point
 where it's impractical to profile because it would take forever to get the
 results.  Does anyone have any tips for speeding this up?

Isn't that kind of a common thing with profilers in general?
Jan 15 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Nick Sabalausky:
 Isn't that kind of a common thing with profilers in general?

Any physical measure alters the thing to be measured, but with a good enough brain you can generally invent ways to decrease such alteration to tolerable levels. So it's a matter of inventing better solutions. There are many kinds of profilers, some of them work "outside" with a random probing of a program, while it runs. I think such kind of profiler may slow down your code as little as you want (but the less it sample the less precise is the result). The new Intel CPUs also have some hardware to profile programs with a very little overhead. Bye, bearophile
Jan 15 2009
parent reply Christopher Wright <dhasenan gmail.com> writes:
bearophile wrote:
 Nick Sabalausky:
 Isn't that kind of a common thing with profilers in general?

Any physical measure alters the thing to be measured, but with a good enough brain you can generally invent ways to decrease such alteration to tolerable levels. So it's a matter of inventing better solutions. There are many kinds of profilers, some of them work "outside" with a random probing of a program, while it runs. I think such kind of profiler may slow down your code as little as you want (but the less it sample the less precise is the result).

Additionally, you can turn profiling on and off with most profilers, so you only get a 3-4x slowdown until you start profiling (at which point it's more like 20x, judging by ANTS profiler for C#). I don't see any profiling stuff in the runtime. I suppose incrementing a global variable is just a lot faster than calling a method in the runtime, except for cache issues.
Jan 15 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Right, that would probably do the trick, except I don't think there's
 anyway to programatically turn D's profiler on or off.  So if you've
 got a program with a big startup cost and you want to profile
 something that happens after startup, it means you could be waiting a
 long time to get to the thing you actually care about, and by that
 time the profile logs are filled up with a bunch of unrelated junk.
 
 So I think your only hope with the D profile is to try to extract out
 the chunk you want to profile into a separate program.  Not always
 possible, and often when possible only painfully so.

You can do profiling for specific modules only by compiling just those modules with profiling on.
Jan 15 2009
parent reply bearophile <bearophileHUGS lycos.com> writes:
Bill Baxter:
 That's a good point.  I never think of stuff like that because I use
 dsss most of the time.
 You want per-file flags?  Ha!  Dsss laughs at you.  Unfortunately. :-(

I usually compile programs with bud, that applies the same thing to all modules. I presume as dsss. As soon as Walter realizes that's a quite natural way to use D (that is, to let something (possibly the compiler) find the modules it needs by itself. LDC may eventually grow this essential feature), he may think about ways to influence the compiler from the code itself, creating compiler directives that can be embedded in the code (as in Pascal). I am not sure this is the best good solution, maybe there are better solutions, like improving those tools (or the compiler) to allow a finer specification of the compilation flags. Bye, bearophile
Jan 16 2009
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
bearophile wrote:
 Bill Baxter:
 That's a good point.  I never think of stuff like that because I use
 dsss most of the time.
 You want per-file flags?  Ha!  Dsss laughs at you.  Unfortunately. :-(

I usually compile programs with bud, that applies the same thing to all modules. I presume as dsss. As soon as Walter realizes that's a quite natural way to use D (that is, to let something (possibly the compiler) find the modules it needs by itself. LDC may eventually grow this essential feature), he may think about ways to influence the compiler from the code itself, creating compiler directives that can be embedded in the code (as in Pascal). I am not sure this is the best good solution, maybe there are better solutions, like improving those tools (or the compiler) to allow a finer specification of the compilation flags. Bye, bearophile

Back when I was working, someone had put a pragma somewhere in the source tree that turned on link-time code generation for the whole project. Every build (i.e. a developer build on my machine) took ~26 minutes. This is especially damning when you've spent your entire programming career being taught to recompile at every code change (or using IDEs that compile stuff in the background). (I eventually hunted down the flag and got the build time down to manageable levels)
Jan 16 2009
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:
 Bill Baxter:
 That's a good point.  I never think of stuff like that because I
 use dsss most of the time. You want per-file flags?  Ha!  Dsss
 laughs at you.  Unfortunately. :-(

I usually compile programs with bud, that applies the same thing to all modules. I presume as dsss. As soon as Walter realizes that's a quite natural way to use D (that is, to let something (possibly the compiler) find the modules it needs by itself. LDC may eventually grow this essential feature), he may think about ways to influence the compiler from the code itself, creating compiler directives that can be embedded in the code (as in Pascal). I am not sure this is the best good solution, maybe there are better solutions, like improving those tools (or the compiler) to allow a finer specification of the compilation flags.

It's a careful decision about whether to embed a switch in the source code or not. One can really make a mess making the wrong choice. For profiling, though, it clearly should not go in the source code.
Jan 16 2009
prev sibling next sibling parent BCS <ao pathlink.com> writes:
Reply to bearophile,

 Bill Baxter:
 
 That's a good point.  I never think of stuff like that because I use
 dsss most of the time.
 You want per-file flags?  Ha!  Dsss laughs at you.  Unfortunately.
 :-(

all modules. I presume as dsss. As soon as Walter realizes that's a quite natural way to use D (that is, to let something (possibly the compiler) find the modules it needs by itself. LDC may eventually grow this essential feature), he may think about ways to influence the compiler from the code itself, creating compiler directives that can be embedded in the code (as in Pascal). I am not sure this is the best good solution, maybe there are better solutions, like improving those tools (or the compiler) to allow a finer specification of the compilation flags. Bye, bearophile

A better way to go could be to have a config file passed to DMD that has a long list of "codefile.d: -flags" and let DMD pick the correct flags to append to the command line
Jan 16 2009
prev sibling parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Fri, 16 Jan 2009 22:47:26 +0300, BCS <ao pathlink.com> wrote:

 Reply to bearophile,

 Bill Baxter:

 That's a good point.  I never think of stuff like that because I use
 dsss most of the time.
 You want per-file flags?  Ha!  Dsss laughs at you.  Unfortunately.
 :-(

all modules. I presume as dsss. As soon as Walter realizes that's a quite natural way to use D (that is, to let something (possibly the compiler) find the modules it needs by itself. LDC may eventually grow this essential feature), he may think about ways to influence the compiler from the code itself, creating compiler directives that can be embedded in the code (as in Pascal). I am not sure this is the best good solution, maybe there are better solutions, like improving those tools (or the compiler) to allow a finer specification of the compilation flags. Bye, bearophile

A better way to go could be to have a config file passed to DMD that has a long list of "codefile.d: -flags" and let DMD pick the correct flags to append to the command line

You can't set version (and some other options) on per-file basis. Your best bet would be having two (or more) passes with different files and compilation options.
Jan 16 2009
parent BCS <ao pathlink.com> writes:
Reply to Denis,

 On Fri, 16 Jan 2009 22:47:26 +0300, BCS <ao pathlink.com> wrote:
 
 A better way to go could be to have a config file passed to DMD that
 has  a long list of "codefile.d: -flags" and let DMD pick the correct
 flags  to append to the command line
 

best bet would be having two (or more) passes with different files and compilation options.

That's not the point: I'm thinking you would run dsss with file-at-a-time and dmd would add in one line of the file depending on what file is being compiled. It would be up to the user to make sure that doesn't foobar stuff.
Jan 16 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jan 16, 2009 at 9:44 AM, Christopher Wright <dhasenan gmail.com> wrote:
 bearophile wrote:
 Nick Sabalausky:
 Isn't that kind of a common thing with profilers in general?

Any physical measure alters the thing to be measured, but with a good enough brain you can generally invent ways to decrease such alteration to tolerable levels. So it's a matter of inventing better solutions. There are many kinds of profilers, some of them work "outside" with a random probing of a program, while it runs. I think such kind of profiler may slow down your code as little as you want (but the less it sample the less precise is the result).

Additionally, you can turn profiling on and off with most profilers, so you only get a 3-4x slowdown until you start profiling (at which point it's more like 20x, judging by ANTS profiler for C#).

Right, that would probably do the trick, except I don't think there's anyway to programatically turn D's profiler on or off. So if you've got a program with a big startup cost and you want to profile something that happens after startup, it means you could be waiting a long time to get to the thing you actually care about, and by that time the profile logs are filled up with a bunch of unrelated junk. So I think your only hope with the D profile is to try to extract out the chunk you want to profile into a separate program. Not always possible, and often when possible only painfully so. --bb
Jan 15 2009
prev sibling next sibling parent Bill Baxter <wbaxter gmail.com> writes:
On Fri, Jan 16, 2009 at 2:24 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Bill Baxter wrote:
 Right, that would probably do the trick, except I don't think there's
 anyway to programatically turn D's profiler on or off.  So if you've
 got a program with a big startup cost and you want to profile
 something that happens after startup, it means you could be waiting a
 long time to get to the thing you actually care about, and by that
 time the profile logs are filled up with a bunch of unrelated junk.

 So I think your only hope with the D profile is to try to extract out
 the chunk you want to profile into a separate program.  Not always
 possible, and often when possible only painfully so.

You can do profiling for specific modules only by compiling just those modules with profiling on.

That's a good point. I never think of stuff like that because I use dsss most of the time. You want per-file flags? Ha! Dsss laughs at you. Unfortunately. :-( --bb
Jan 15 2009
prev sibling parent "Tim M" <a b.com> writes:
On Fri, 16 Jan 2009 21:18:46 +1300, bearophile <bearophileHUGS lycos.com>  
wrote:

 Bill Baxter:
 That's a good point.  I never think of stuff like that because I use
 dsss most of the time.
 You want per-file flags?  Ha!  Dsss laughs at you.  Unfortunately. :-(

I usually compile programs with bud, that applies the same thing to all modules. I presume as dsss. As soon as Walter realizes that's a quite natural way to use D (that is, to let something (possibly the compiler) find the modules it needs by itself. LDC may eventually grow this essential feature), he may think about ways to influence the compiler from the code itself, creating compiler directives that can be embedded in the code (as in Pascal). I am not sure this is the best good solution, maybe there are better solutions, like improving those tools (or the compiler) to allow a finer specification of the compilation flags. Bye, bearophile

Is bud still maintained or is 11 month gaps between changes in /trunk normal?
Jan 16 2009
prev sibling next sibling parent reply BCS <none anon.com> writes:
Hello dsimcha,

 I'm working on optimizing some code now, and a nagging issue that I've
 been meaning to bring up is how slow stuff runs when profiling is
 turned on.  It seems that, given any code that's slow enough to be
 worth profiling/optimizing, the DMD profiler slows it down further, to
 the point where it's impractical to profile because it would take
 forever to get the results.  Does anyone have any tips for speeding
 this up?
 

I think this is unavodable. Just let it run overnight.
Jan 16 2009
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from BCS (none anon.com)'s article
 Hello dsimcha,
 I'm working on optimizing some code now, and a nagging issue that I've
 been meaning to bring up is how slow stuff runs when profiling is
 turned on.  It seems that, given any code that's slow enough to be
 worth profiling/optimizing, the DMD profiler slows it down further, to
 the point where it's impractical to profile because it would take
 forever to get the results.  Does anyone have any tips for speeding
 this up?


One other thing I've noticed about the DMD profiler (I don't have any experience w/ any other profilers): After the program appears done, it sits there at high CPU usage for a long time if it's been profiling for a while, long enough that I often end up killing it. Is the profiler supposed to take a while after the program is done running to output the results?
Jan 16 2009
parent BCS <ao pathlink.com> writes:
Reply to dsimcha,

 Is the profiler supposed to take a while after the program is done
 running to output the results?
 

I think that would be DMD running some stats (fan-in/fan-out, sums, sorts, etc.) just lest it run for a while.
Jan 16 2009
prev sibling next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
dsimcha wrote:
 I'm working on optimizing some code now, and a nagging issue that I've been
 meaning to bring up is how slow stuff runs when profiling is turned on.  It
 seems that, given any code that's slow enough to be worth
 profiling/optimizing, the DMD profiler slows it down further, to the point
 where it's impractical to profile because it would take forever to get the
 results.  Does anyone have any tips for speeding this up?

You could try using an external non-intrusive profiler. If you compile your stuff with GCC on *nix, I've been hearing that kcachegrind is pretty awesome: http://kcachegrind.sourceforge.net/html/Home.html If you'd like to profile a DMD-Win-compiled executable, I've written a simple tool to do it which is similar to the Sleepy profiler: http://sleepy.sourceforge.net/ ( Sleepy doesn't work with DMD-made executables ): http://team0xf.com:1024/dprof/ ; if you compile Main.d and run it, passing the name of your executable as a parameter, it will attach to it (your app must be compiled with -g and without -O). Then it pauses the target thread a few thousand times a second, checking its register states and finding the currently executed function. The stats are gathered and when you hit Enter, you're provided with some info. The program is a pretty simple one and may not do what you'd like, however the actual profiler is a separate lib (dprof.Profiler) which could be used in a more sophisticated way. So far, I've used it to successfully optimize some ray-tracing code and remove a few bottlenecks from Hybrid. -- Tomasz Stachowiak http://h3.team0xf.com/ h3/h3r3tic on #D freenode
Jan 16 2009
next sibling parent BCS <ao pathlink.com> writes:
Reply to Tom,

 Then it
 pauses the target thread a few thousand times a second, checking its
 register states and finding the currently executed function. The stats
 are gathered and when you hit Enter, you're provided with some info.

A neat trick. I've done the same thing by hand with the VS debugger.
Jan 16 2009
prev sibling parent KlausO <kobi goppertsweiler.de> writes:
Tom S schrieb:
 You could try using an external non-intrusive profiler. If you compile 
 your stuff with GCC on *nix, I've been hearing that kcachegrind is 
 pretty awesome: http://kcachegrind.sourceforge.net/html/Home.html
 If you'd like to profile a DMD-Win-compiled executable, I've written a 
 simple tool to do it which is similar to the Sleepy profiler: 
 http://sleepy.sourceforge.net/ ( Sleepy doesn't work with DMD-made 
 executables ): http://team0xf.com:1024/dprof/ ; if you compile Main.d 
 and run it, passing the name of your executable as a parameter, it 
 will attach to it (your app must be compiled with -g and without -O). 
 Then it pauses the target thread a few thousand times a second, 
 checking its register states and finding the currently executed 
 function. The stats are gathered and when you hit Enter, you're 
 provided with some info. The program is a pretty simple one and may 
 not do what you'd like, however the actual profiler is a separate lib 
 (dprof.Profiler) which could be used in a more sophisticated way. So 
 far, I've used it to successfully optimize some ray-tracing code and 
 remove a few bottlenecks from Hybrid.

There is also an advanced version of sleepy called verysleepy :-) (http://www.codersnotes.com/sleepy) and a commercial profiler called LTProf (http://www.lw-tech.com) using the same technique. KlausO
Jan 16 2009
prev sibling parent J Duncan <jtd514_ ameritech.net> writes:
dsimcha wrote:
 I'm working on optimizing some code now, and a nagging issue that I've been
 meaning to bring up is how slow stuff runs when profiling is turned on.  It
 seems that, given any code that's slow enough to be worth
 profiling/optimizing, the DMD profiler slows it down further, to the point
 where it's impractical to profile because it would take forever to get the
 results.  Does anyone have any tips for speeding this up?

If you are on windows, you should check out GlowCode. Its pretty simple but its extremely fast http://www.glowcode.com/
Jan 16 2009