March 04, 2013
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
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
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
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
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
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
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
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
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
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
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19