March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Monday, 4 March 2013 at 04:36:30 UTC, Andrei Alexandrescu wrote:
> 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
It seems that I was wrong, and missed the point that both benchmark weren't using the same string. Sorry for that.
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to John Colvin | On 2013-03-03 16:41, John Colvin wrote: > 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. No, but if we need to drop down to C to get fast enough. -- /Jacob Carlborg |
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On 2013-03-03 21:18, Walter Bright wrote: > Nothing in this thread suggests that D needs to switch its library > implementations to C. Then that's good. > 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. > -- /Jacob Carlborg |
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On 3/3/2013 11:38 PM, Jacob Carlborg wrote:
> On 2013-03-03 16:41, John Colvin wrote:
>
>> 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.
>
> No, but if we need to drop down to C to get fast enough.
I can't think of a reason to need to do that.
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, March 03, 2013 23:40:18 Walter Bright wrote:
> On 3/3/2013 11:38 PM, Jacob Carlborg wrote:
> > On 2013-03-03 16:41, John Colvin wrote:
> >> 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.
> >
> > No, but if we need to drop down to C to get fast enough.
>
> I can't think of a reason to need to do that.
Given how D works, there is something _very_ wrong if we have to drop to C, if nothing else, because it's trivial to write code in D which is equivalent to what it would be in C. If our implementation of something is worse than a C implementation, that merely means that it needs to be refactored and optimized. It's possible that some of our abstractions will hamper efficiency in some cases (e.g. depending on how ranges are used - particularly with strings - you risk a performance hit in comparison to pure C), but that should generally be fixable via specializations and whatnot.
If we have an efficiency problem, it's merely an implementation issue which needs to be sorted out. There should be nothing inherent to D which makes it so that you can't write code as fast as C or C++.
- Jonathan M Davis
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jonathan M Davis | On 2013-03-04 09:18, Jonathan M Davis wrote: > Given how D works, there is something _very_ wrong if we have to drop to C, if > nothing else, because it's trivial to write code in D which is equivalent to > what it would be in C. If our implementation of something is worse than a C > implementation, that merely means that it needs to be refactored and > optimized. It's possible that some of our abstractions will hamper efficiency in > some cases (e.g. depending on how ranges are used - particularly with strings > - you risk a performance hit in comparison to pure C), but that should > generally be fixable via specializations and whatnot. > > If we have an efficiency problem, it's merely an implementation issue which > needs to be sorted out. There should be nothing inherent to D which makes it > so that you can't write code as fast as C or C++. That's what I'm saying. -- /Jacob Carlborg |
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile Attachments:
| On Mon, 2013-03-04 at 04:31 +0100, bearophile wrote: […] > Are Python3 strings still like wstrings/dstrings, or have they applied the patch that makes them UTF8? Python3 is Unicode by default, with UTF-8 the default encoding. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder |
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to deadalnix | On Monday, 4 March 2013 at 03:58:20 UTC, deadalnix wrote:
> 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.
But that does suggest that the main problem is that DMD has very little optimization aimed at reducing the number of bounds checks required.
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | Walter Bright:
> there are semantics in D that allow faster code to be generated than can be for C. They are unexploited at the moment, but they are there.
This is interesting. Maybe you should write a small article on this.
Bye,
bearophile
|
March 04, 2013 Re: Slower than Python | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | Russel Winder:
> Allowing PyPy to have a good JIT compiler.
PyPy is not just a JIT, it's a more complex beast. It's more like a meta-JIT. The only one I know of.
Bye,
bearophile
|
Copyright © 1999-2021 by the D Language Foundation