On Monday, 29 September 2014 at 14:25:34 UTC, monarch_dodra wrote:
> This just misses the *entire* familly of algorithms that operate on generic types, such as "map". EG: the totality of std.algorithm. Oops.

But if you know the common operations on strings used in many programs, then you want them to perform. So you need a mix of special cased precomputed lookup-tables and/or special cased SIMD instructions that will outperform a generic map() by a significant margin.

I am not arguing against generic apis being desirable, I am questioning of the feasibility of being competitive in the space of utf-8 strings without designing for SIMD.

Obviously, doing bitwise and 0x80808080...80 followed by a simd compare with "           " will beat anything scalar based if you want to test for a space in a utf-8 string.

Intel has made a real effort at making UTF-8 SIMD optimizable with the last few generations of instruction sets.

Figuring out how to tap into that potential is a lot more valuable than defining an api a priori. That means writing SIMD code and comparing it to what you have. If SIMD blows what you have out of the water, then it ain't god enough.

If you can define the string APIs to fit what SIMD is good at, then you are onto something that could be really good. D is in a position where you can do that. C++ aint.

On 09/28/2014 02:12 AM, Andrei Alexandrescu wrote:
> Noice. Should be told, though, that reading the actual file will
> dominate execution time. -- Andrei

Absolutely, and we should have different priorities right now.

It would also help to fix compiler bugs that regularly cause performance regressions.

https://issues.dlang.org/show_bug.cgi?id=7625
https://issues.dlang.org/buglist.cgi?keywords=performance&resolution=---

On Monday, 29 September 2014 at 16:43:17 UTC, Martin Nowak wrote:
> On 09/28/2014 02:12 AM, Andrei Alexandrescu wrote:
>> Noice. Should be told, though, that reading the actual file will
>> dominate execution time. -- Andrei
>
> Absolutely, and we should have different priorities right now.

That is not obvious. Modern parsing techniques that deals with ambiguity are O(N^3) to O(N^4), add to this the desire for lexer-free parsers and you'll start to see that performance matters.

Martin Nowak <code@dawg.eu> wrote:
> On 09/28/2014 02:12 AM, Andrei Alexandrescu wrote:
>> Noice. Should be told, though, that reading the actual file will dominate execution time. -- Andrei
> 
> Absolutely, and we should have different priorities right now.
> 
> It would also help to fix compiler bugs that regularly cause performance regressions.
> 
> https://issues.dlang.org/show_bug.cgi?id=7625 https://issues.dlang.org/buglist.cgi?keywords=performance&resolution=---

Totally, thank you. -- Andrei

29-Sep-2014 16:43, Dicebot пишет:
> I refuse to accept any code gen complaints based on DMD. It's
> optimization facilities are generally crappy compared to gdc / ldc and
> not worth caring about - it is just a reference implementation after
> all. Clean and concise library code is more important.
>
> Now if the same inlining failure happens with other two compilers - that
> is something worth talking about (I don't know if it happens)

+1

-- 
Dmitry Olshansky

On Sunday, 28 September 2014 at 12:09:50 UTC, Andrei Alexandrescu wrote:
> On 9/27/14, 4:31 PM, H. S. Teoh via Digitalmars-d wrote:
>> 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!
>
> Stuff that's missing:
>
> * Reasonable effort to improve performance of auto-decoding;
>
> * A study of the matter revealing either new artifacts and idioms, or the insufficiency of such;
>
> * An assessment of the impact on compilability of existing code
>
> * An assessment of the impact on correctness of existing code (that compiles and runs in both cases)
>
> * An assessment of the improvement in speed of eliminating auto-decoding
>
> I think there's a very strong need for this stuff, because claims that current alternatives to selectively avoid auto-decoding use the throwing of hands (and occasional chairs out windows) without any real investigation into how library artifacts may help. This approach to justifying risky moves is frustratingly unprincipled.

As far as I see, backward compatibility is fairly easy.
Extract autodecoding modules into `autodecoding` dub package and clean up phobos modules into non-decoding behavior. The phobos code will be simplified: it will deal with ranges as is without specialization, the `autodecoding` dub package will be simple: just wraps strings into dchar range and invokes non-decoding function from phobos, preserves current module interface to keep legacy D code working.
Run dfix on your sources, it will replace `import std.algorithm` with `import autodecoding.algorithm` - then the code should work.
What do you think? Worth a DIP?