On Monday, 9 September 2013 at 17:42:04 UTC, Johannes Pfau wrote:
> But compile times will explode.

Are you sure?

time dmd hello.d # import std.stdio; void main() { writeln("hello"); }
real    0m0.665s

$ time dmd hello.d d/dmd2/src/phobos/std/*.d
std.md5 is scheduled for deprecation. Please use std.digest.md instead

real    0m2.367s


That's slow for hello world, but not a dealbreaker to me since larger projects can easily exceed that anyway (especially with optimizations turned on). And that's making no attempt to only compile the files actually imported.

If we try to be smarter about it:

time dmd hello.d d/dmd2/src/phobos/std/{stdio,conv,format,string,traits,typetuple,typecons,bitmanip,system,functional,utf,uni,container,random,numeric,complex,regex,stdiobase}.d

real    0m1.119s


It's adding about 1/2 second to the compile time - note, not really doubling it since more complex user code would take a bigger fraction of the total than phobos as the app grows - ....which really isn't awful.


At least when specifically asking for -inline, I think this is worth the extra compile time.

On Monday, September 09, 2013 18:58:47 Dmitry Olshansky wrote:
> 09-Sep-2013 18:39, Joseph Rushton Wakeling пишет:
> > On 09/09/13 16:34, Dmitry Olshansky wrote:
> >> On the bright side of things std.regex is real fast on LDC *when
> >> hacked* to
> >> inline the critical bits :)
> > 
> > Do you mean when manually inlined, or when the design is tweaked to facilitate inlining?
> 
> When I put extra () to indicate that said functions are templates.
> Then compiler gets its grip on them and finally inlines.
> Otherwise it generates calls and links in object code from libphobos.
> 
> Which is the whole reason for the topic - is THAT is the way to go? Shouldn't compiler look into source for inlinable stuff (when source is available)?

The compiler should definitely be able to look at non-templated functions and inline them where appropriate. I expect that it will really hurt performance in general if it doesn't - especially with stuff like getters or setters. I don't know what the best way would be for the compiler to go about doing that and have no idea how the inliner currently works, but I don't think that there's any question that it needs to.

- Jonathan M Davis

On 2013-09-10 06:02, Jonathan M Davis wrote:

> The compiler should definitely be able to look at non-templated functions and
> inline them where appropriate. I expect that it will really hurt performance
> in general if it doesn't - especially with stuff like getters or setters. I
> don't know what the best way would be for the compiler to go about doing that
> and have no idea how the inliner currently works, but I don't think that
> there's any question that it needs to.

I agree.

-- 
/Jacob Carlborg

On 09/09/13 16:34, Dmitry Olshansky wrote:
> 09-Sep-2013 18:26, Joseph Rushton Wakeling пишет:
>> On 09/09/13 15:01, Dmitry Olshansky wrote:
>>> While investigating std.regex performance in Phobos I've found that a
>>> lot of
>>> stuff never gets inlined (contrary to my expectations).
>>
>> Is that just with dmd, or with gdc and ldc as well?
> 
> For DMD and LDC confirmed. Would be interesting to test GDC but I bet it's the same (does LTO work here btw?).

It used to, back in the gcc4.6 days. Right now gdc LTO is broken (unless
things changed in the last couple of months).
So you have the choice of using an old frontend with LTO or a reasonably
recent one without (with no cross-module inlining). The fact that it is
effectively impossible to use both gdc versions (ie the old LTO-enabled
one just for release builds) makes the situation even worse (the language
accepted by gdc was changed in a backward incompatible way; pragma-gcc-
-attributes became errors).

artur

On 10/09/13 11:57, Artur Skawina wrote:
> It used to, back in the gcc4.6 days. Right now gdc LTO is broken (unless
> things changed in the last couple of months).

What happened to break it?

On 09/10/13 12:12, Joseph Rushton Wakeling wrote:
> On 10/09/13 11:57, Artur Skawina wrote:
>> It used to, back in the gcc4.6 days. Right now gdc LTO is broken (unless things changed in the last couple of months).
> 
> What happened to break it?

The changes to gcc lto post-4.6.

http://forum.dlang.org/thread/5139CF92.4070408@gmail.com

http://bugzilla.gdcproject.org/show_bug.cgi?id=61

artur

On Monday, 9 September 2013 at 13:01:51 UTC, Dmitry Olshansky wrote:
> [...]

I'm "resurrecting" this thread, because I also noticed that "std.ascii" is "victim" to this. Almost all of the function in there are trivially inline-able, but because they are not templates, aren't.

By simply making them templates, I can improve the performance of functions such as "split on ascii white" by 2 to 3 (!).

This is a damn shame.

On 9/15/13, monarch_dodra <monarchdodra@gmail.com> wrote:
> By simply making them templates, I can improve the performance of functions such as "split on ascii white" by 2 to 3 (!).

Speaking of which, I think the following special case should be allowed:

-----
void foo()() { }

void main()
{
    auto x = &foo;  // NG
}
-----

Then maybe we won't even break anyone's code.

15-Sep-2013 23:05, Andrej Mitrovic пишет:
> On 9/15/13, monarch_dodra <monarchdodra@gmail.com> wrote:
>> By simply making them templates, I can improve the performance of
>> functions such as "split on ascii white" by 2 to 3 (!).
>
Yes, yes and yes. I think many of the performance issues of Phobos are rooted there.

I'm of the opinion that the user must not suffer because of a undecided situation with inlining in the toolchain (all of them).

> Speaking of which, I think the following special case should be allowed:
>
> -----
> void foo()() { }
>
> void main()
> {
>      auto x = &foo;  // NG
> }
> -----
>
> Then maybe we won't even break anyone's code.
>

Providing either this special case for empty argument templates seems to be a small price to help this ugly situation.

That is unless compiler devs agree with the following observation and see a way to get there in short-term:

> I *thought* that the intended behavior is:
> a) Have source - compile from source
> b) Don't have source (*.di files) - link in objects

Which is something nobody clarified yet.
Well Johannes spoke for GDC by noting that there is no notion to support that in the current frontend-backend dialog.

-- 
Dmitry Olshansky

16-Sep-2013 01:51, Dmitry Olshansky пишет:
> 15-Sep-2013 23:05, Andrej Mitrovic пишет:
>> On 9/15/13, monarch_dodra <monarchdodra@gmail.com> wrote:
>>> By simply making them templates, I can improve the performance of
>>> functions such as "split on ascii white" by 2 to 3 (!).
>>
> Yes, yes and yes. I think many of the performance issues of Phobos are
> rooted there.
>

For the benefit of these who have followed this thread...
All is not lost - we have Kenji!

Relevant Pull:
https://github.com/D-Programming-Language/dmd/pull/2561


-- 
Dmitry Olshansky