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.

Andrei

On 3/1/13 8:29 PM, Steven Schveighoffer wrote:
> On Fri, 01 Mar 2013 20:05:34 -0500, cvk012c
> <cvk012c@motorolasolutions.com> wrote:
>
>> In my latest version of D script I didn't use splitter at all. I used
>> string specific indexOf function. Still result is very bad. For text
>> based protocols, such as SIP, performance of string manipulating
>> functions is very important. Unfortunately, looks like it is not D
>> strongest point at this time.
>
> indexOf uses the same mechanism as splitter to find the separators. If
> it doesn't improve anything, I'd say that is where the problem lies
> (std.algorithm.find).

find and indexOf on arrays are on par with handwritten loops.

Andrei

On 3/1/13 6:26 PM, Steven Schveighoffer wrote:
> On Fri, 01 Mar 2013 18:22:54 -0500, Steven Schveighoffer
> <schveiguy@yahoo.com> wrote:
>
>> So it's just pure heuristics. Not hard to see how that would affect a
>> 10 million cycle program.
>>
>> We may be able to create a string-specific version of splitter that
>> would take advantage of the representation.
>
> Just found a disturbing artifact: splitter(message, '\n') is more than
> twice as slow as splitter(message, "\n")
>
> -Steve

That is a problem. Could you please file a but report?

Thanks,

Andrei

On 3/2/13 12:20 PM, Andrei Alexandrescu wrote:
> On 3/1/13 6:26 PM, Steven Schveighoffer wrote:
>> On Fri, 01 Mar 2013 18:22:54 -0500, Steven Schveighoffer
>> <schveiguy@yahoo.com> wrote:
>>
>>> So it's just pure heuristics. Not hard to see how that would affect a
>>> 10 million cycle program.
>>>
>>> We may be able to create a string-specific version of splitter that
>>> would take advantage of the representation.
>>
>> Just found a disturbing artifact: splitter(message, '\n') is more than
>> twice as slow as splitter(message, "\n")
>>
>> -Steve
>
> That is a problem. Could you please file a but report?

s/but/bug/

:o)

Andrei

On Sat, 2013-03-02 at 16:55 +0100, John Colvin wrote:
[…]
> I'm not sure that's entirely fair. PyPy is fast because it implements a JIT, not because it's written in RPython.

The second sentence is almost entirely true, the first I am not so sure. Armin Rigo used to manage Psycho which was an amendment to the CPython code base to include a JIT. He quit trying to keep that going and so CPython doesn't have a JIT of any real importance. Unladen Swallow dissapeared. The JIT framework is an integral part of RPython rather than being specific only to PyPy.

The point is that for I/O bound systems all languages are more or less equivalent, for computational intensive code, JITs are needed for virtual machine based systems or they will not compete.

-- 
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

On Saturday, 2 March 2013 at 15:33:42 UTC, Andrei Alexandrescu wrote:
> On 3/1/13 8:05 PM, cvk012c wrote:
>> In my latest version of D script I didn't use splitter at all. I used
>> string specific indexOf function. Still result is very bad. For text
>> based protocols, such as SIP, performance of string manipulating
>> functions is very important. Unfortunately, looks like it is not D
>> strongest point at this time.
>
> That conclusion would be hasty if not missing the whole point. You essentially measured the speed of one loop in various translators implementing various languages. Java code doing straight computation is on a par with C speed, no two ways about that. Python code using library primitives ain't no slouch either.

That is true, but what prevents D to do the same? Why Java code can be on par with C speed and D cannot? If Java and Python folks can do it, why D creators cannot? If performance optimizations is always number one priority in Java and Python community, why it is not a case for D?
I will go even further: what prevents D to be faster than C? That's where D will really shine and people will start talking about.
But that is probably a distant future of D and for now, my personal opinion is that ANY part of D code should not be slower than at least Java.
If it is, it should be reported as an issues and fixed.
Being more than twice slower than Java is a failure.

On Sat, 2013-03-02 at 17:06 +0100, Peter Alexander wrote: […]
> Source? (Googling "rpython interpreter speed" didn't show anything)

For me, my source is my microbenchmarks, which are testing just loop with computation, i.e compute intensive data parallel. There is plenty of other stuff.

> There's always claims that systems like RPython, or Haskell, or LuaJIT, or Java HotSpot are able to rival or beat C, yet all I ever see are small toy programs. Show me something big. Something with 100's of thousands of lines of code.

100,000+ lines of code is a total irrelevance regarding system performance, as anyone who knows anything of profiling and benchmarking will tell you.

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.

> 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?

Clearly I think your response is just trolling, I will stop feeding the troll.

-- 
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

On 3/2/2013 8:12 AM, Jacob Carlborg wrote:
> If you need to write a custom splitter to get acceptable performance then it
> sounds to me that D or Phobos have failed.


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.

But if, to write a custom version, you had to switch to another language, then I would agree that is a failure of a "systems" programming language.

On 3/2/2013 7:43 AM, Russel Winder wrote:
> For writing interpreters, RPython spanks C.

What's RPython doing that makes it faster?

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

> On 3/1/13 8:29 PM, Steven Schveighoffer wrote:
>> On Fri, 01 Mar 2013 20:05:34 -0500, cvk012c
>> <cvk012c@motorolasolutions.com> wrote:
>>
>>> In my latest version of D script I didn't use splitter at all. I used
>>> string specific indexOf function. Still result is very bad. For text
>>> based protocols, such as SIP, performance of string manipulating
>>> functions is very important. Unfortunately, looks like it is not D
>>> strongest point at this time.
>>
>> indexOf uses the same mechanism as splitter to find the separators. If
>> it doesn't improve anything, I'd say that is where the problem lies
>> (std.algorithm.find).
>
> find and indexOf on arrays are on par with handwritten loops.

This is not a personal attack, please don't take it that way.  My anecdotal tests with hand writing a custom splitter range to handle the OP's program gave me a 40% savings.  Whether it's find or not, I'm not sure, but there definitely is room for improvement.  Using indexOf instead of splitter seems to result in the same time usage, so something that is common between the two would be a logical choice to target.

It would be interesting to examine the assembly differences, but I haven't got the time right now.

-Steve