09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
> On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
>> 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
>>> On Mon, Dec 08, 2014 at 08:33:16AM +0000, Russel Winder via Digitalmars-d wrote:
>>> [...]
>>>> As with any of these situation the convoluted hardcoded for a
>>>> specific processor code, especially assembly language will always
>>>> win. I don't care about that, I care about the fastest
>>>> comprehensible code that is portable simply by compilation or
>>>> execution. Based on this, Java does well, so does some Groovy
>>>> perhaps surprisingly, also Scala.  C++ does well especially with TBB
>>>> (though as an API it leaves a lot to be desired). D is OK but only
>>>> using ldc2 or gdc, dmd sucks.
>>> [...]
>>>
>>> Yeah, I find in my own experience that gdc -O3 tends to produce code
>>> that's consistently ~20% faster than dmd -O, especially in
>>> compute-intensive code.
>>
>> And that's not nearly enough. Also both LDC & GDC often can't inline
>> many functions from phobos due to separate compilation.
> [...]
>
> Really? Most of the Phobos function I use are templates, so inlining
> shouldn't be a problem, should it? Besides, gdc is far better at
> inlining that dmd ever was, though of course there are some constructs
> that the front-end doesn't inline, and the backend doesn't have enough
> info to do so. This is an area that should be improved.
>

std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates.

Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining.


-- 
Dmitry Olshansky

On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
> 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
> >On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
> >>08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
[...]
> >>>Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code.
> >>
> >>And that's not nearly enough. Also both LDC & GDC often can't inline many functions from phobos due to separate compilation.
> >[...]
> >
> >Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved.
> >
> 
> std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates.
> 
> Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining.
[...]

Hmm. Would it help to change isWhite into a template function?


T

-- 
It only takes one twig to burn down a forest.

On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
>> 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
>> >On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
>> >>08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
> [...]
>> >>>Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code.
>> >>
>> >>And that's not nearly enough. Also both LDC & GDC often can't inline many functions from phobos due to separate compilation.
>> >[...]
>> >
>> >Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved.
>> >
>>
>> std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates.
>>
>> Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining.
> [...]
>
> Hmm. Would it help to change isWhite into a template function?
>

That can't be the answer for everything.

Iain

09-Dec-2014 22:18, Iain Buclaw via Digitalmars-d пишет:
> On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d
> <digitalmars-d@puremagic.com> wrote:
>> On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
>>> 09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
>>>> On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
>>>>> 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
>> [...]
>>>>>> Yeah, I find in my own experience that gdc -O3 tends to produce
>>>>>> code that's consistently ~20% faster than dmd -O, especially in
>>>>>> compute-intensive code.
>>>>>
>>>>> And that's not nearly enough. Also both LDC & GDC often can't inline
>>>>> many functions from phobos due to separate compilation.
>>>> [...]
>>>>
>>>> Really? Most of the Phobos function I use are templates, so inlining
>>>> shouldn't be a problem, should it? Besides, gdc is far better at
>>>> inlining that dmd ever was, though of course there are some
>>>> constructs that the front-end doesn't inline, and the backend doesn't
>>>> have enough info to do so. This is an area that should be improved.
>>>>
>>>
>>> std.ascii.isWhite ... and there are plenty of things our templates
>>> inevitably unfold to. I mean come on phobos library is big pile of
>>> object code, it can't be all templates.
>>>
>>> Last time I checked if you copy-paste isWhite it to your source code
>>> it gets much faster then std one because of inlining.
>> [...]
>>
>> Hmm. Would it help to change isWhite into a template function?
>>
>
> That can't be the answer for everything.
>

As someone (ab)using empty template "idiom", I agree, we need a better solution.

-- 
Dmitry Olshansky

On Tue, Dec 09, 2014 at 10:22:13PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
> 09-Dec-2014 22:18, Iain Buclaw via Digitalmars-d пишет:
> >On 9 December 2014 at 19:15, H. S. Teoh via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> >>On Tue, Dec 09, 2014 at 10:08:35PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
> >>>09-Dec-2014 20:54, H. S. Teoh via Digitalmars-d пишет:
> >>>>On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
[...]
> >>>>>And that's not nearly enough. Also both LDC & GDC often can't inline many functions from phobos due to separate compilation.
> >>>>[...]
> >>>>
> >>>>Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved.
> >>>>
> >>>
> >>>std.ascii.isWhite ... and there are plenty of things our templates inevitably unfold to. I mean come on phobos library is big pile of object code, it can't be all templates.
> >>>
> >>>Last time I checked if you copy-paste isWhite it to your source code it gets much faster then std one because of inlining.
> >>[...]
> >>
> >>Hmm. Would it help to change isWhite into a template function?
> >>
> >
> >That can't be the answer for everything.
> >
> 
> As someone (ab)using empty template "idiom", I agree, we need a better
> solution.
[...]

I don't see what's the problem with making it an "empty" template. It eliminates dead code in your executable if you never call that function, it enables attribute inference, and it allows inlining. The only major incompatibility I can see is the ability to ship closed-source libraries, but in that case, inlining is already out of the question anyway, so it's a non-issue.

Or am I missing something obvious?


T

-- 
IBM = I Blame Microsoft

On Tuesday, 9 December 2014 at 20:19:59 UTC, H. S. Teoh via
Digitalmars-d wrote:
>> As someone (ab)using empty template "idiom", I agree, we need a better
>> solution.
> [...]
>
> I don't see what's the problem with making it an "empty" template. It
> eliminates dead code in your executable if you never call that function,
> it enables attribute inference, and it allows inlining. The only major
> incompatibility I can see is the ability to ship closed-source
> libraries, but in that case, inlining is already out of the question
> anyway, so it's a non-issue.
>
> Or am I missing something obvious?
>

Considering the optimizer don't know what a template is, and do
the inlining, I'm not sure why everybody think the 2 are that
linked.

On Tuesday, 9 December 2014 at 20:19:59 UTC, H. S. Teoh via Digitalmars-d wrote:
> I don't see what's the problem with making it an "empty" template. It
> eliminates dead code in your executable if you never call that function,
> it enables attribute inference, and it allows inlining. The only major
> incompatibility I can see is the ability to ship closed-source
> libraries, but in that case, inlining is already out of the question
> anyway, so it's a non-issue.
>
> Or am I missing something obvious?

Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution.

On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
> Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution.

You can compile against phobos sources instead of interface files.

On Wednesday, 10 December 2014 at 08:43:49 UTC, Kagamin wrote:
> On Tuesday, 9 December 2014 at 20:55:51 UTC, Dicebot wrote:
>> Because you don't really create a template that way but workaround broken function behavior. It is not the usage of empty templates that is bad but the fact that plain functions remain broken => not really a solution.
>
> You can compile against phobos sources instead of interface files.

This cannot be the solution if D aspires to be used in contexts where binary libraries are used.

C++ is excused to have template code in headers given the primitive tooling, but languages like Ada and Modula-3 support proper information hiding for generic code.

--
Paulo

On Wednesday, 10 December 2014 at 10:24:53 UTC, Paulo  Pinto wrote:
> This cannot be the solution if D aspires to be used in contexts where binary libraries are used.

For completely opaque libraries one can compile against interface files.