www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Inline Functions

reply Mason Green (Zzzzrrr) <mason.green gmail.com> writes:
Hello,

I'm looking for ways to optimize Blaze, the D port of Box2D, and running into
some frustrations.  In fact, the same Java port
(http://www.jbox2d.org/v2demos/) is currently running circles around Blaze,
performance wise....

I have a sneaking suspicion that this is the result of the many thousands of
vector math operations that are performed each cycle during my stress test. 

Is there a way to force inline function calls?  I'm compiling my code with
'-release -O -inline', but this seems not to have much of an effect on
performance.  When I remove -inline there doesn't seem to be much of a
difference in execution speed. 

FYI, I'm using DMD v1.035 on Windowd x32.

Thanks,
Mason
Feb 24 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Mason Green:

I'm looking for ways to optimize Blaze, the D port of Box2D, and running into
some frustrations.  In fact, the same Java port
(http://www.jbox2d.org/v2demos/) is currently running circles around Blaze,
performance wise....<

In the beginning the Java code used to run very slowly, but today Java (and C# on dotnet) is getting closer to well compiled C++ code (and it's much simpler to write than C++). A JavaVM like HotSpot is more refined than the backend of DMD, its GC is much more refined and more efficient, it's much better in inlining virtual methods, its data structures are usually better performance-tuned, etc. The D language is newer than Java, and it has enjoyed far less money, developers and users. Have you profiled your D code? What has the profiling told you? Have you seen where you allocate memory, to move such allocations away from inner loops, or just reduce their number? Bye, bearophile
Feb 24 2009
next sibling parent reply Mason Green <mason.green gmail.com> writes:
bearophile:

Thanks for the reply.
 
 A JavaVM like HotSpot is more refined than the backend of DMD, its GC is much
more refined and more efficient, it's much better in inlining virtual methods,
its data structures are usually better performance-tuned, etc. The D language
is newer than Java, and it has enjoyed far less money, developers and users.> 

Very well put! But, do you know if there is a way to force inlining where I want it? Someone mentioned to me that template mixins may work...? I would rather not inline all the code by hand, as I would like to trust the compiler.
 Have you profiled your D code? What has the profiling told you? Have you seen
where you allocate memory, to move such allocations away from inner loops, or
just reduce their number? >

No, I have not profiled the D code other than using an FPS counter... :-) To be honest, I'm fairly light on experience when it comes to profiling. Do you have any suggestions on how to make it happen? Bye, Mason
Feb 24 2009
next sibling parent Lutger <lutger.blijdestijn gmail.com> writes:
Mason Green wrote:

 bearophile:
 
 Thanks for the reply.
  
 A JavaVM like HotSpot is more refined than the backend of DMD, its GC is 


methods, its data structures are usually better performance-tuned, etc. The D language is newer than Java, and it has enjoyed far less money, developers and users.>
 
 Very well put! But, do you know if there is a way to force inlining where 

would rather not inline all the code by hand, as I would like to trust the compiler. You could use mixins, but that won't lead to pretty code. It's useful to know which kinds of code can get inlined by dmd. I don't have much knowledge of this, but the most common things that won't get inlined are loops, delegates and virtual functions iirc.
 Have you profiled your D code? What has the profiling told you? Have you 


loops, or just reduce their number? >
 
 No, I have not profiled the D code other than using an FPS counter... :-) 

you have any suggestions on how to make it happen? dmd's builtin profiler can be useful. Some time ago I have written a small utility to help make it's output more readable: http://www.dsource.org/projects/scrapple/wiki/PtraceUtility
Feb 24 2009
prev sibling next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Bill Baxter (wbaxter gmail.com)'s article
 I seem to remember from a previous discussion about  optimizing a
 ray-tracer that DMD will not inline functions that take reference
 parameters.   Can anyone else confirm this?
 --bb

Here's a test program I wrote and the relevant parts of the disassembly. It was compiled w/ -O -inline -release. I think you're right, strange as it seems. I wonder why ref is never inlined. void main() { uint foo; inc(foo); } void inc(ref uint num) { num++; } __Dmain PROC NEAR ; COMDEF __Dmain push eax lea eax, [esp] mov dword ptr [esp], 0 call _D4test3incFKkZv xor eax, eax pop ecx ret __Dmain ENDP _text$__Dmain ENDS _text$_D4test3incFKkZv SEGMENT DWORD PUBLIC 'CODE' _D4test3incFKkZv PROC NEAR ; COMDEF _D4test3incFKkZv inc dword ptr [eax] ret _D4test3incFKkZv ENDP
Feb 24 2009
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
dsimcha:

I think you're right, strange as it seems.  I wonder why ref is never inlined.<

Do you want something like a forced_inline attribute in D? :-) Bye, bearophile
Feb 24 2009
parent dsimcha <dsimcha yahoo.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article
 dsimcha:
I think you're right, strange as it seems.  I wonder why ref is never inlined.<

Bye, bearophile

No, actually, I like the idea of leaving these small micro-optimizations to the compiler. It's just that I can't figure out what's special about functions that take ref parameters. Maybe there is a good reason for this behavior. I don't know. It's just that if there is a good reason, I can't think of it. Also, if you really, really, _really_ want to force a function to be inlined, you can probably simulate this with templates or mixins or something. IMHO wanting to absolutely insist that something be inlined is too much of an edge case to have pretty syntax and special language constructs for.
Feb 24 2009
prev sibling parent grauzone <none example.net> writes:
Both LDC and GDC inline the function. (LDC actually reduces your code to 
nothing, so I had to change it a bit to see if the call was really 
inlined.)
Feb 24 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Tue, 24 Feb 2009 14:08:26 -0500, Mason Green wrote:

 Have you profiled your D code? What has the profiling told you? Have you seen
where you allocate memory, to move such allocations away from inner loops, or
just reduce their number? >

No, I have not profiled the D code other than using an FPS counter... :-) To be honest, I'm fairly light on experience when it comes to profiling. Do you have any suggestions on how to make it happen?

The material seems lacking so I've started a series of posts on profiling. Here's the first one: http://snakecoder.wordpress.com/2009/02/26/profiling-with-dmd-on-windows/ I already have some material for the second one, profiling Blaze. ;-)
Feb 26 2009
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sergey Gromov wrote:
 http://snakecoder.wordpress.com/2009/02/26/profiling-with-dmd-on-windows/
 
 I already have some material for the second one, profiling Blaze.  ;-)

http://www.reddit.com/r/d_language/comments/80lpm/profiling_with_digital_mars_d_compiler_on_windows/
Feb 26 2009
parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Thu, 26 Feb 2009 14:43:11 -0800, Walter Bright wrote:

 Sergey Gromov wrote:
 http://snakecoder.wordpress.com/2009/02/26/profiling-with-dmd-on-windows/
 
 I already have some material for the second one, profiling Blaze.  ;-)

http://www.reddit.com/r/d_language/comments/80lpm/profiling_with_digital_mars_d_compiler_on_windows/

Heh, thanks! I hope my opus really worths mentioning.
Feb 26 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sergey Gromov wrote:
 Thu, 26 Feb 2009 14:43:11 -0800, Walter Bright wrote:
 
 Sergey Gromov wrote:
 http://snakecoder.wordpress.com/2009/02/26/profiling-with-dmd-on-windows/

 I already have some material for the second one, profiling Blaze.  ;-)


Heh, thanks! I hope my opus really worths mentioning.

I think it is.
Feb 26 2009
parent TomD <t_demmer nospam.web.de> writes:
Walter Bright Wrote:

 Sergey Gromov wrote:

 Heh, thanks!  I hope my opus really worths mentioning.

I think it is.

Shouldn't things like these maybe be included under the "Tech Tips" on digitalmars.com or so? Ciao TomD
Feb 27 2009
prev sibling parent reply Sergey Gromov <snake.scaly gmail.com> writes:
Thu, 26 Feb 2009 19:42:20 +0300, Sergey Gromov wrote:

 Tue, 24 Feb 2009 14:08:26 -0500, Mason Green wrote:
 
 Have you profiled your D code? What has the profiling told you? Have you seen
where you allocate memory, to move such allocations away from inner loops, or
just reduce their number? >

No, I have not profiled the D code other than using an FPS counter... :-) To be honest, I'm fairly light on experience when it comes to profiling. Do you have any suggestions on how to make it happen?

The material seems lacking so I've started a series of posts on profiling. Here's the first one: http://snakecoder.wordpress.com/2009/02/26/profiling-with-dmd-on-windows/ I already have some material for the second one, profiling Blaze. ;-)

And the second post: http://snakecoder.wordpress.com/2009/03/02/profiling-with-dmd-on-windows-getting-hands-dirty/ This one is more practical.
Mar 01 2009
parent reply Mason Green <mason.green gmail.com> writes:
Excellent, I've implemented your optimizations and left a more detailed comment
on the blog.  I've also made a number of optimizations to the physics engine
over the weekend, and the performance increase is phenomenal!

http://svn.dsource.org/projects/blaze/downloads/blazeDemos.zip

Much appreciated!!!!

Sergey Gromov Wrote:

 And the second post:
 
 http://snakecoder.wordpress.com/2009/03/02/profiling-with-dmd-on-windows-getting-hands-dirty/
 
 This one is more practical.

Mar 02 2009
parent Sergey Gromov <snake.scaly gmail.com> writes:
Mon, 02 Mar 2009 07:12:41 -0500, Mason Green wrote:

 Excellent, I've implemented your optimizations and left a more
 detailed comment on the blog.  I've also made a number of
 optimizations to the physics engine over the weekend, and the
 performance increase is phenomenal! 
 
 http://svn.dsource.org/projects/blaze/downloads/blazeDemos.zip 
 
 Much appreciated!!!!

You're welcome! I've checked out the trunk rev. 423--it's much faster now. Good job!
Mar 02 2009
prev sibling next sibling parent "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 24 Feb 2009 22:08:26 +0300, Mason Green <mason.green gmail.com>  
wrote:

 bearophile:

 Thanks for the reply.

 A JavaVM like HotSpot is more refined than the backend of DMD, its GC  
 is much more refined and more efficient, it's much better in inlining  
 virtual methods, its data structures are usually better  
 performance-tuned, etc. The D language is newer than Java, and it has  
 enjoyed far less money, developers and users.>

Very well put! But, do you know if there is a way to force inlining where I want it? Someone mentioned to me that template mixins may work...? I would rather not inline all the code by hand, as I would like to trust the compiler.
 Have you profiled your D code? What has the profiling told you? Have  
 you seen where you allocate memory, to move such allocations away from  
 inner loops, or just reduce their number? >

No, I have not profiled the D code other than using an FPS counter... :-) To be honest, I'm fairly light on experience when it comes to profiling. Do you have any suggestions on how to make it happen? Bye, Mason

DMD has profiling built-in. Just recompile your code with -profile flag, run once and analyze output.
Feb 24 2009
prev sibling parent Bill Baxter <wbaxter gmail.com> writes:
I seem to remember from a previous discussion about  optimizing a
ray-tracer that DMD will not inline functions that take reference
parameters.   Can anyone else confirm this?

--bb
Feb 24 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Mason Green (Zzzzrrr) wrote:
 When I remove -inline there doesn't seem to
 be much of a difference in execution speed.

Try running obj2asm to see if the functions you want inlined are actually inlined or not.
Feb 24 2009
next sibling parent reply Tomas Lindquist Olsen <tomas.l.olsen gmail.com> writes:
On Wed, Feb 25, 2009 at 8:42 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Mason Green (Zzzzrrr) wrote:
 When I remove -inline there doesn't seem to
 be much of a difference in execution speed.

Try running obj2asm to see if the functions you want inlined are actually inlined or not.

perhaps a verbose mode could be added in dmd that prints the pretty printed declaration when a function is inlined. then it would be a simple grep to make sure. dmd -vi foo.d | grep 'foo\.inc' telling people to inspect the obj2asm output seems to be popular, but it's hardly user friendly.
Feb 25 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tomas Lindquist Olsen wrote:
 perhaps a verbose mode could be added in dmd that prints the pretty
 printed declaration when a function is inlined. then it would be a
 simple grep to make sure.
 
 dmd -vi foo.d | grep 'foo\.inc'
 
 telling people to inspect the obj2asm output seems to be popular, but
 it's hardly user friendly.

I know, but it isn't that hard, either, even if you don't know assembler. If the "call" isn't there, it likely got inlined. Also, if you are trying to optimize the code by trying various tweaks at the statement level, it's much like shooting skeet blindfolded if you don't look at the asm output. It's time consuming and unlikely to be successful.
Feb 25 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 In this case it's not entirely helpful that DMD's inlining rules are
 completely opaque.  Do you have a list of what DMD will and won't
 inline, and their justifications?  If not, could you make one?

In the immortal words of Oggie-Ben-Doggie, "use the source, Luke". In this case, the source is FuncDeclaration::canInline() in /dmd/src/dmd/inline.c. Yes, I know, but it's all there is at the moment.
Feb 25 2009
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 Also, looking at the DMD frontend source is *not* an acceptable option.

I knew you'd say that <g>. On the other hand, inlining or not is, like register allocation and any other optimizations, highly implementation dependent. If you're going to micro-optimize at that level, it really is worthwhile to get familiar with obj2asm and the relevant compiler source code. It'll save you much time in the long run, and will pay off in being able to write consistently faster code. Or, you could sign up for http://www.astoriaseminar.com/compiler-construction.html <g>.
Feb 25 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:
 True.  However defining what the compiler does in these optimizations
 is not just in the interest of performance, but also in the interest
 of correctness and other implementations.

Optimization should have nothing to do with correctness.
 If everyone can see what
 DMD is and isn't inlining, they can ask "why" or "why not"; they can
 correct you if you make a mistake; they can suggest optimizations you
 might not have thought of; and they can see optimizations that fall
 out as a consequence of the language that they might not have
 considered when making their own compiler.

If they're working at that level, why avoid looking at the compiler source? Optimization suggestions from someone who knows how compilers work are much more likely to be viable.
 Furthermore things like NRVO either need to be specified in the
 language or specified in the ABI.  You told me before that static
 opCall for structs is just as efficient as constructors because of
 NRVO; I didn't and still don't buy it for exactly the reasons you just
 now gave: optimizations are highly implementation-dependent.  It's
 this kind of stuff that needs to be specified: is NRVO required, or
 just _really really nice to have_?  Insert many other optimizations
 here.

If an optimization is required, then yes, it needs to go in the spec. But inlining is not required. Let me put it another way. There are *thousands* of optimizations the compiler does, and they often have some very complex interactions. Even enumerating them all would be an enormous time sink. There's nothing particularly special about inlining as opposed to constant folding, dead code elimination, register allocation, instruction scheduling, strength reduction, etc., etc. Even if I wrote such a tome, it would be a waste of time to read it. The easiest, quickest way to see if an optimization happened is to look at the obj2asm output. Remember the thread a while back about how dmd did a terrible job generating arithmetic code? A quick check with obj2asm showed that the speed problem had nothing to do with the code generation, it was all sucked up by a library module (since fixed).
Feb 25 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Feb 25, 2009 at 3:26 AM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Also, if you are trying to optimize the code by trying various tweaks at the
 statement level, it's much like shooting skeet blindfolded if you don't look
 at the asm output. It's time consuming and unlikely to be successful.

In this case it's not entirely helpful that DMD's inlining rules are completely opaque. Do you have a list of what DMD will and won't inline, and their justifications? If not, could you make one?
Feb 25 2009
prev sibling next sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Feb 25, 2009 at 9:09 AM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:
 On Wed, Feb 25, 2009 at 3:26 AM, Walter Bright
 <newshound1 digitalmars.com> wrote:
 Also, if you are trying to optimize the code by trying various tweaks at=


 statement level, it's much like shooting skeet blindfolded if you don't =


 at the asm output. It's time consuming and unlikely to be successful.

In this case it's not entirely helpful that DMD's inlining rules are completely opaque. =A0Do you have a list of what DMD will and won't inline, and their justifications? =A0If not, could you make one?

Also, looking at the DMD frontend source is *not* an acceptable option.
Feb 25 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Wed, Feb 25, 2009 at 8:59 PM, Walter Bright
<newshound1 digitalmars.com> wrote:
 Jarrett Billingsley wrote:
 Also, looking at the DMD frontend source is *not* an acceptable option.

I knew you'd say that <g>.

I knew you'd suggest it ;)
 On the other hand, inlining or not is, like register allocation and any
 other optimizations, highly implementation dependent. If you're going to
 micro-optimize at that level, it really is worthwhile to get familiar with
 obj2asm and the relevant compiler source code.

True. However defining what the compiler does in these optimizations is not just in the interest of performance, but also in the interest of correctness and other implementations. If everyone can see what DMD is and isn't inlining, they can ask "why" or "why not"; they can correct you if you make a mistake; they can suggest optimizations you might not have thought of; and they can see optimizations that fall out as a consequence of the language that they might not have considered when making their own compiler. Furthermore things like NRVO either need to be specified in the language or specified in the ABI. You told me before that static opCall for structs is just as efficient as constructors because of NRVO; I didn't and still don't buy it for exactly the reasons you just now gave: optimizations are highly implementation-dependent. It's this kind of stuff that needs to be specified: is NRVO required, or just _really really nice to have_? Insert many other optimizations here.
Feb 25 2009