On 2013-03-02 20:27, Walter Bright wrote:

> In D, you can write custom versions of algorithms to exploit unique
> characteristics of particular data structures. I don't regard that as a
> failure.

If you use the most obvious function/way from the standard library to perform a task in Python and you do the same in D. If the D version is slower that's not good.

As you've seen here people will use what's available in the standard library and if that's not good enough compared to what's available in other languages' standard libraries, they will complain. If a function in Phobos can't match the corresponding function in another std lib, I think we're doing something wrong. Or the they just happened to use a language where the std lib was optimized better for that particular task.

-- 
/Jacob Carlborg

On 2013-03-02 17:48, John Colvin wrote:

> It does.
>
> Failing to beat mature, optimised C is not anything to be ashamed of,
> but being slower than python would be an abject failure of D as a
> compiled, systems programming language.

Then D needs to get faster, or we need to switch to C for some std lib functions. In that case, as Walter said, we have failed.

-- 
/Jacob Carlborg

On Sunday, 3 March 2013 at 15:09:58 UTC, Jacob Carlborg wrote:
> On 2013-03-02 17:48, John Colvin wrote:
>
>> It does.
>>
>> Failing to beat mature, optimised C is not anything to be ashamed of,
>> but being slower than python would be an abject failure of D as a
>> compiled, systems programming language.
>
> Then D needs to get faster, or we need to switch to C for some std lib functions. In that case, as Walter said, we have failed.

I agree that anything that makes us faster is good, but I wouldn't go so far as to say we've failed if we're not as fast as the very fastest.

On 3/3/2013 7:07 AM, Jacob Carlborg wrote:
> If you use the most obvious function/way from the standard library to perform a
> task in Python and you do the same in D. If the D version is slower that's not good.

Sure. But you should be cognizant of exactly what it is you're comparing, or you're apt to draw very wrong conclusions.

On 3/3/2013 7:09 AM, Jacob Carlborg wrote:
> On 2013-03-02 17:48, John Colvin wrote:
>
>> It does.
>>
>> Failing to beat mature, optimised C is not anything to be ashamed of,
>> but being slower than python would be an abject failure of D as a
>> compiled, systems programming language.
>
> Then D needs to get faster, or we need to switch to C for some std lib
> functions. In that case, as Walter said, we have failed.

Nothing in this thread suggests that D needs to switch its library implementations to C.

Interestingly, I tried the indexOf() benchmark using C's memchr() and memcmp() from VC's runtime library. It was not faster than Andrei's optimized D one.

On Sunday, 3 March 2013 at 20:18:58 UTC, Walter Bright wrote:
> On 3/3/2013 7:09 AM, Jacob Carlborg wrote:
>> On 2013-03-02 17:48, John Colvin wrote:
>>
>>> It does.
>>>
>>> Failing to beat mature, optimised C is not anything to be ashamed of,
>>> but being slower than python would be an abject failure of D as a
>>> compiled, systems programming language.
>>
>> Then D needs to get faster, or we need to switch to C for some std lib
>> functions. In that case, as Walter said, we have failed.
>
> Nothing in this thread suggests that D needs to switch its library implementations to C.
>
> Interestingly, I tried the indexOf() benchmark using C's memchr() and memcmp() from VC's runtime library. It was not faster than Andrei's optimized D one.

Maybe it is time to look at the python implementation and see why it is faster.

> Maybe it is time to look at the python implementation and see why it is faster.

It isn't faster:

$ time python3 test.py

real    0m14.217s
user    0m14.209s
sys     0m0.004s
$ gdmd -O -inline -release -noboundscheck test
$ time ./test

real    0m5.323s
user    0m5.312s
sys     0m0.008s

D code here uses the same string as the python code, not the one in cvk012c's D code.

jerro:

> $ time python3 test.py

Are Python3 strings still like wstrings/dstrings, or have they applied the patch that makes them UTF8?

Bye,
bearophile

On Monday, 4 March 2013 at 03:20:57 UTC, jerro wrote:
>> Maybe it is time to look at the python implementation and see why it is faster.
>
> It isn't faster:
>
> $ time python3 test.py
>
> real    0m14.217s
> user    0m14.209s
> sys     0m0.004s
> $ gdmd -O -inline -release -noboundscheck test
> $ time ./test
>
> real    0m5.323s
> user    0m5.312s
> sys     0m0.008s
>
> D code here uses the same string as the python code, not the one in cvk012c's D code.

Using noboundcheck isn't fair as you give up on safety, so you are not equivalent to python either.

On 3/3/13 9:31 PM, deadalnix wrote:
> On Sunday, 3 March 2013 at 20:18:58 UTC, Walter Bright wrote:
>> On 3/3/2013 7:09 AM, Jacob Carlborg wrote:
>>> On 2013-03-02 17:48, John Colvin wrote:
>>>
>>>> It does.
>>>>
>>>> Failing to beat mature, optimised C is not anything to be ashamed of,
>>>> but being slower than python would be an abject failure of D as a
>>>> compiled, systems programming language.
>>>
>>> Then D needs to get faster, or we need to switch to C for some std lib
>>> functions. In that case, as Walter said, we have failed.
>>
>> Nothing in this thread suggests that D needs to switch its library
>> implementations to C.
>>
>> Interestingly, I tried the indexOf() benchmark using C's memchr() and
>> memcmp() from VC's runtime library. It was not faster than Andrei's
>> optimized D one.
>
> Maybe it is time to look at the python implementation and see why it is
> faster.

Was the conclusion that it's faster?

Andrei