March 03, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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 |
March 03, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | 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 |
March 03, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
|
March 03, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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.
|
March 03, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | 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.
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | > 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.
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to jerro | jerro:
> $ time python3 test.py
Are Python3 strings still like wstrings/dstrings, or have they applied the patch that makes them UTF8?
Bye,
bearophile
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to jerro | 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.
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | 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
|
Copyright © 1999-2021 by the D Language Foundation