On 9/27/2014 3:59 PM, Brad Roberts via Digitalmars-d wrote:
> Look at Peter's example, it's better for this, I believe.  Why isn't empty being
> inlined?  That's a tiny little function with a lot of impact.

It's the autodecode'ing front(), which is a fairly complex function.

On 9/27/2014 3:52 PM, bearophile wrote:
> There is no char auto decoding in this program, right?

Notice the calls to autodecoding 'front' in the assembler dump.

On Saturday, 27 September 2014 at 23:04:00 UTC, Walter Bright wrote:
> On 9/27/2014 3:52 PM, bearophile wrote:
>> There is no char auto decoding in this program, right?
>
> Notice the calls to autodecoding 'front' in the assembler dump.

I think you're imagining things Walter!

There's no auto-decoding my example, it's just adding up the lengths.

On Saturday, 27 September 2014 at 23:00:20 UTC, Brad Roberts via Digitalmars-d wrote:
> Look at Peter's example, it's better for this, I believe.  Why isn't empty being inlined?  That's a tiny little function with a lot of impact.

This is most likely due to an issue with how the new DMD template emission strategy (needsCodegen() et al.) was integrated into LDC: https://github.com/ldc-developers/ldc/issues/674

The issue in question was fixed recently in LDC Git master, but regressed again when 2.066 was merged.

David

On Sat, Sep 27, 2014 at 11:00:16PM +0000, bearophile via Digitalmars-d wrote:
> H. S. Teoh:
> 
> >If we can get Andrei on board, I'm all for killing off autodecoding.
> 
> Killing auto-decoding for std.algorithm functions will break most of my D2 code... perhaps we can do that in a D3 language.
[...]

Well, obviously it's not going to be done in a careless, drastic way!

There will be a proper migration path and deprecation cycle. We already have byCodeUnit and byCodePoint, and the first step is probably to migrate towards requiring usage of one or the other for iterating over strings, and only once all code is using them, we will get rid of autodecoding (the job now being done by byCodePoint). Then, the final step would be to allow the direct use of strings in iteration constructs again, but this time without autodecoding by default. Of course, .byCodePoint will still be available for code that needs to use it.


T

-- 
Ph.D. = Permanent head Damage

On 9/27/2014 4:06 PM, Peter Alexander wrote:
> On Saturday, 27 September 2014 at 23:04:00 UTC, Walter Bright wrote:
>> On 9/27/2014 3:52 PM, bearophile wrote:
>>> There is no char auto decoding in this program, right?
>>
>> Notice the calls to autodecoding 'front' in the assembler dump.
>
> I think you're imagining things Walter!
>
> There's no auto-decoding my example, it's just adding up the lengths.

oh crap, I misread empty as front!

On 9/27/14, 1:57 PM, Walter Bright wrote:
> To scrape the barnacles off, I've filed:
>
> https://issues.dlang.org/show_bug.cgi?id=13541
> https://issues.dlang.org/show_bug.cgi?id=13542
> https://issues.dlang.org/show_bug.cgi?id=13543
> https://issues.dlang.org/show_bug.cgi?id=13544
>
> I'm sure there's much more in std.file (and elsewhere) that can be done.

Noice. Should be told, though, that reading the actual file will dominate execution time. -- Andrei

On 9/27/14, 3:40 PM, H. S. Teoh via Digitalmars-d wrote:
> If we can get Andrei on board, I'm all for killing off autodecoding.

That's rather vague; it's unclear what would replace it. -- Andrei

On 9/27/14, 3:54 PM, Walter Bright wrote:
> Again, this accumulation of barnacles is not a failure of the optimizer.
> It's a failure of adding gee-gaws to the source code without checking
> their effect.

The Go project has something nice set up - easy-to-run benchmarks that are part of the acceptance testing. That's good prevention against creeping inefficiencies. -- Andrei

On 9/27/14, 4:02 PM, Walter Bright wrote:
> On 9/27/2014 3:59 PM, Brad Roberts via Digitalmars-d wrote:
>> Look at Peter's example, it's better for this, I believe.  Why isn't
>> empty being
>> inlined?  That's a tiny little function with a lot of impact.
>
> It's the autodecode'ing front(), which is a fairly complex function.

front() should follow a simple pattern that's been very successful in HHVM: small inline function that covers most cases with "if (c < 0x80)" followed by an out-of-line function on the multicharacter case. That approach would make the cost of auto-decoding negligible in the overwhelming majority of cases.

Andrei