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


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



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
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 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
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 "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 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 parent reply 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.
 :-(


 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


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


 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


 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
 


 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.
 


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


 I think this is unavodable. Just let it run overnight.


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