March 02, 2013
On 3/2/2013 11:14 AM, cvk012c wrote:
> That is true, but what prevents D to do the same?

Nothing.

> I will go even further: what prevents D to be faster than C?

Nothing. In fact, 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.

March 02, 2013
On Sat, 02 Mar 2013 12:14:07 -0500, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> On 3/2/13 11:12 AM, Jacob Carlborg wrote:
>> On 2013-03-01 23:31, Steven Schveighoffer wrote:
>>
>>> Phobos kind of refuses to treat strings like arrays of characters, it
>>> insists on decoding.
>>>
>>> With DMD and a hand-written splitter, it takes 6 seconds instead of 10
>>> on my system (64-bit macosx).
>>
>> If you need to write a custom splitter to get acceptable performance
>> then it sounds to me that D or Phobos have failed.
>
> I wrote a custom splitter specialized for arrays. It's as fast.

Why doesn't it get used for strings in this instance?  Maybe there is a bad constraint somewhere.

-Steve
March 02, 2013
On Sat, 2013-03-02 at 11:30 -0800, Walter Bright wrote:
> On 3/2/2013 7:43 AM, Russel Winder wrote:
> > For writing interpreters, RPython spanks C.
> 
> What's RPython doing that makes it faster?

Allowing PyPy to have a good JIT compiler.

-- 
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 02, 2013
On Saturday, 2 March 2013 at 19:42:47 UTC, Russel Winder wrote:
> On Sat, 2013-03-02 at 11:30 -0800, Walter Bright wrote:
>> On 3/2/2013 7:43 AM, Russel Winder wrote:
>> > For writing interpreters, RPython spanks C.
>> 
>> What's RPython doing that makes it faster?
>
> Allowing PyPy to have a good JIT compiler.

And why do you think this wouldn't be possible if it was written in C? There are fast JITs written in C.
March 02, 2013
On 3/2/2013 11:42 AM, Russel Winder wrote:
> On Sat, 2013-03-02 at 11:30 -0800, Walter Bright wrote:
>> On 3/2/2013 7:43 AM, Russel Winder wrote:
>>> For writing interpreters, RPython spanks C.
>>
>> What's RPython doing that makes it faster?
>
> Allowing PyPy to have a good JIT compiler.

I don't understand. Does that JIT generate faster code than a C compiler would generate?

March 02, 2013
On Saturday, 2 March 2013 at 19:19:09 UTC, Russel Winder wrote:
> 100,000+ lines of code is a total irrelevance regarding system
> performance, as anyone who knows anything of profiling and benchmarking
> will tell you.

I don't care about benchmarking, I care about writing large, fast systems. Small toy programs are irrelevant because they are not representative of real programs. Real programs are large (many thousands or millions of lines of code) and you don't have the luxury of being able to hand optimize every line of code.


> If C is the only viable language why has Java got the majority of the
> commercial market. C++ and Fortran have the vast majority of the
> computational world.

Commercial market for what? For high performance applications C++ is still champion.


>> If all this is true, where are the video games written in these languages that rival performance/fidelity of AAA titles? I've never seen that. Ever.
>
> Where is D is this arena. It is either C++ or C++ in the high
> performance graphics arena. If there are no AAA titles written in D why
> does this email list have anyone on it?

D is getting there. Remedy Games are sponsoring DConf, and I predict we'll start to see some high quality indie games over the next few years written in D. Up till now, I imagine language stability has been the main thing holding back D. Tomasz was working on a high quality renderer before he got fed up with D's instability (http://h3.gd/code/nucleus/).
March 02, 2013
On Sat, Mar 02, 2013 at 12:02:08PM -0800, Walter Bright wrote:
> On 3/2/2013 11:42 AM, Russel Winder wrote:
> >On Sat, 2013-03-02 at 11:30 -0800, Walter Bright wrote:
> >>On 3/2/2013 7:43 AM, Russel Winder wrote:
> >>>For writing interpreters, RPython spanks C.
> >>
> >>What's RPython doing that makes it faster?
> >
> >Allowing PyPy to have a good JIT compiler.
> 
> I don't understand. Does that JIT generate faster code than a C compiler would generate?

I don't know, but my wild guess is that a JIT optimizes the *right* hotspots based on real-time performance measurements, whereas a lot of C programmers are obsessed with optimizing what they *think* are the hotspots, but which really aren't.


T

-- 
Everybody talks about it, but nobody does anything about it!  -- Mark Twain
March 02, 2013
On Saturday, 2 March 2013 at 20:02:09 UTC, Walter Bright wrote:
> On 3/2/2013 11:42 AM, Russel Winder wrote:
>> On Sat, 2013-03-02 at 11:30 -0800, Walter Bright wrote:
>>> On 3/2/2013 7:43 AM, Russel Winder wrote:
>>>> For writing interpreters, RPython spanks C.
>>>
>>> What's RPython doing that makes it faster?
>>
>> Allowing PyPy to have a good JIT compiler.
>
> I don't understand. Does that JIT generate faster code than a C compiler would generate?

In some cases yes, it can,  but as you know that has nothing to do with the language the jit is written in. As I've said elsewhere, pypy being fast compared to cpython has nothing to do with the former being written in rpython and the latter in c*

*other than perhaps the higher productivity of writing in rpython allowing more resources to be dedicated to optimisation.
March 02, 2013
On 3/2/2013 12:08 PM, H. S. Teoh wrote:
> On Sat, Mar 02, 2013 at 12:02:08PM -0800, Walter Bright wrote:
>> On 3/2/2013 11:42 AM, Russel Winder wrote:
>>> On Sat, 2013-03-02 at 11:30 -0800, Walter Bright wrote:
>>>> On 3/2/2013 7:43 AM, Russel Winder wrote:
>>>>> For writing interpreters, RPython spanks C.
>>>>
>>>> What's RPython doing that makes it faster?
>>>
>>> Allowing PyPy to have a good JIT compiler.
>>
>> I don't understand. Does that JIT generate faster code than a C
>> compiler would generate?
>
> I don't know, but my wild guess is that a JIT optimizes the *right*
> hotspots based on real-time performance measurements, whereas a lot of C
> programmers are obsessed with optimizing what they *think* are the
> hotspots, but which really aren't.

I meant what the C *compiler* generates.

March 02, 2013
On 3/2/13 2:37 PM, Steven Schveighoffer wrote:
> On Sat, 02 Mar 2013 12:14:07 -0500, Andrei Alexandrescu
> <SeeWebsiteForEmail@erdani.org> wrote:
>
>> On 3/2/13 11:12 AM, Jacob Carlborg wrote:
>>> On 2013-03-01 23:31, Steven Schveighoffer wrote:
>>>
>>>> Phobos kind of refuses to treat strings like arrays of characters, it
>>>> insists on decoding.
>>>>
>>>> With DMD and a hand-written splitter, it takes 6 seconds instead of 10
>>>> on my system (64-bit macosx).
>>>
>>> If you need to write a custom splitter to get acceptable performance
>>> then it sounds to me that D or Phobos have failed.
>>
>> I wrote a custom splitter specialized for arrays. It's as fast.
>
> Why doesn't it get used for strings in this instance? Maybe there is a
> bad constraint somewhere.

I fear there's a misunderstanding somewhere. Splitter and find are already specialized appropriately for strings.

Andrei