Would be interesting.

Trass3r schrieb:
> Would be interesting.


Yes, this would be very interesting indeed. A list of the rules which dmd uses internally for inlining functions and methods similiar to this (which is for .NET)

http://blogs.msdn.com/ericgu/archive/2004/01/29/64717.aspx

would be really nice. Sure you can figure this out on your own by studying the compiler sources but a simple list of rules (does not have to be exhaustive) on http://www.digitalmars.com/d/1.0/lex.html or on a seperate page regarding optimizations for d would be very appreciated.

The only things i figured out so far is that functions across modules do not seem to get inlined (i don't know if this is the case in general) which would be really bad. Another thing which i believe is that functions / methods which contain ref parameters are never inlined at all (which is again really annoying since it's not a clever way passing huge structs by value).

Scorn:
> The only things i figured out so far is that functions across modules do not seem to get inlined (i don't know if this is the case in general) which would be really bad. Another thing which i believe is that functions / methods which contain ref parameters are never inlined at all (which is again really annoying since it's not a clever way passing huge structs by value).

Use LDC (D1), you will note a significant improvement over DMD.

Bye,
bearophile

> Use LDC (D1), you will note a significant improvement over DMD.
>

I believe that, but... D1.
Also LDC doesn't seem to get much attention (development-wise) recently.

bearophile schrieb:
> Scorn:
>> The only things i figured out so far is that functions across modules do not seem to get inlined (i don't know if this is the case in general) which would be really bad. Another thing which i believe is that functions / methods which contain ref parameters are never inlined at all (which is again really annoying since it's not a clever way passing huge structs by value).
> 
> Use LDC (D1), you will note a significant improvement over DMD.
> 
> Bye,
> bearophile


Hi bearophile. Thanks for your advice (i might try out ldc in the future but now i need phobos and not tango as standard library).

At the moment i am using gdc where i nearly always see a significant improvement regarding the speed of the produced code when comparing to dmd.

But since all three dmd, ldc and gdc use the same frontend, the question from Trass3r still remains:

Under which conditions are functions/methods inlined ?

Do you know if ldc inlines functions/methods across modules ? (dmd doesn't seem to do it and neither does gdc).

And that is bad since for an actual project i have made a separate module with a lot of small utility math functions which should be inlined but don't because of this. When i inline them using mixins or manually i get an overall speed up of about 20%.

"bearophile" <bearophileHUGS@lycos.com> wrote in message news:hkpiai$2kt6$1@digitalmars.com...
> Scorn:
>> The only things i figured out so far is that functions across modules do not seem to get inlined (i don't know if this is the case in general) which would be really bad. Another thing which i believe is that functions / methods which contain ref parameters are never inlined at all (which is again really annoying since it's not a clever way passing huge structs by value).
>
> Use LDC (D1), you will note a significant improvement over DMD.
>

Unless you're on windows.

>> Use LDC (D1), you will note a significant improvement over DMD.
>>
> Unless you're on windows.
>

Yep, second big problem.

>>> Use LDC (D1), you will note a significant improvement over DMD.
>>>
>> Unless you're on windows.
>>
> 
> Yep, second big problem.

And unless you're using CodeBlocks (like me at the moment) for
development ...

Scorn:

> Hi bearophile. Thanks for your advice (i might try out ldc in the future but now i need phobos and not tango as standard library).

I like DMD for some of the D2 features, for its speed, for allowing exceptions to be used on Windows too, for its built-in profiler and code coverage analyser that are not present in LDC, and for other small things, but I like how LDC feels more like a real-world compiler, it has smaller features like force_inline that look like coming out of a more practical compiler.

When I optimize code on LDC, I see predictable improvements of the performance, while with DMD it's like a shoot in the dark, and I usually have to avoid several tweaks of the code, otherwise I get a negative improvement.


> But since all three dmd, ldc and gdc use the same frontend, the question
> from Trass3r still remains:
> Under which conditions are functions/methods inlined ?

I think LDC doesn't use the inliner of the front-end and just uses the much better inliner of the back-end. So the inling rules are probably all different (but in theory the front-end knows more about the D semantics, so LDC has to work even more to regain the lost semantics).

Those inling rules of C# are nice and tidy (despite it doesn't inline virtual methods, as Java HotSpot does. Aren't C# programmers complaining? C# programmers don't look obsessed with performance, this is often positive), but it's not easy to find them on most C/C++ compilers I know of. Have you ever seen the exact inlining rules of C code compiled with GCC 4.4.3?


> Do you know if ldc inlines functions/methods across modules ? (dmd doesn't seem to do it and neither does gdc).

I have just done a test, normally LDC is not able to inline across modules. This is a shitty situation.
But with LDC you can perform Link-Time Optimization too (but you have to ask for it!), that in my test I've just seen is able to inline across modules.


> And that is bad since for an actual project i have made a separate module with a lot of small utility math functions which should be inlined but don't because of this. When i inline them using mixins or manually i get an overall speed up of about 20%.

If you explain this problem to Walter he will surely tell you that such inlining can't be done because mumble mumble separate compilation mumble mumble was done fifteen years ago mumble mumble mumble (even if LDC is currently doing it) :-)

Good luck,
bearophile

Am 08.02.2010, 16:33 Uhr, schrieb Scorn <scorn@trash-mail.com>:

> Trass3r schrieb:
>> Would be interesting.
>
>
> Yes, this would be very interesting indeed. A list of the rules which
> dmd uses internally for inlining functions and methods would be really nice.
>

Well if I read the code correctly the following is not supported:
- nested inline?
- variadic functions (T t, ...)
- synchronized
- imported functions
- functions with closure vars
- virtual functions that aren't final
- functions with out, ref or static array parameters
- functions with more than 250 elementary expressions


Created my own little inline dumping patch:


Index: inline.c
===================================================================
--- inline.c	(revision 363)
+++ inline.c	(working copy)
@@ -1126,6 +1126,7 @@
 	if (fd && fd != iss->fd && fd->canInline(0))
 	{
 	    e = fd->doInline(iss, NULL, arguments);
+		printf("Inlined function %s.\n", fd->toPrettyChars());
 	}
     }
     else if (e1->op == TOKdotvar)
@@ -1145,7 +1146,10 @@
 		;
 	    }
 	    else
-		e = fd->doInline(iss, dve->e1, arguments);
+		{
+			e = fd->doInline(iss, dve->e1, arguments);
+			printf("Inlined method %s.\n", fd->toPrettyChars());
+		}
 	}
     }