March 02, 2013
On Saturday, 2 March 2013 at 15:43:57 UTC, Russel Winder wrote:
> On Sat, 2013-03-02 at 10:33 -0500, Andrei Alexandrescu wrote:
> […]
>> 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. Performance tuning in these languages becomes more difficult in larger applications where data layout, allocation, and indirect function calls start to dominate.
> […]
>
> Interestingly, there isn't only one Python implementation. There is only
> one language but there is CPython, PyPy, Jython, IronPython, to mention
> but 4.
>
> On computationally intensive code, PyPy (Python execution environment in
> RPython) is generally 10 to 30 times faster than CPython (Python
> execution environment written in C).
>
> C is a (reasonably) well known and used language thought to create fast
> code. RPython is Python but with some restrictions that is statically
> compiled.  For writing interpreters, RPython spanks C. PyPy is not the
> only language using RPython to implement the interpreter. C's days in
> this game are seriously numbered.

I'm not sure that's entirely fair. PyPy is fast because it implements a JIT, not because it's written in RPython.
March 02, 2013
On Saturday, 2 March 2013 at 15:43:57 UTC, Russel Winder wrote:
> C is a (reasonably) well known and used language thought to create fast
> code. RPython is Python but with some restrictions that is statically
> compiled.  For writing interpreters, RPython spanks C. PyPy is not the
> only language using RPython to implement the interpreter. C's days in
> this game are seriously numbered.

Source? (Googling "rpython interpreter speed" didn't show anything)

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.

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.
March 02, 2013
On 2013-03-02 02:10, Walter Bright wrote:

> Python's splitter, which you are measuring, isn't written in Python. It
> is written in C. You're actually comparing a bit of C code with a bit of
> D code.

Does that really matter. He's using Python, if the function is part of the standard library and if it's implement in Python or C doesn't really matter.

-- 
/Jacob Carlborg
March 02, 2013
On 2013-03-01 23:01, Andrei Alexandrescu wrote:

> I doubt that.
>
> 1. Microbenchmarks are a crapshoot, they exercise a tiny portion of the
> language and library.

If that tiny portion is what's only used, then the rest doesn't matter.

> 2. With Python, after comparing 2-3 idioms - well, this is pretty much
> it. We doubled the speed in no time by just tuning options. D being a
> systems language allows you take your code to a million places if you
> want to optimize.

Perhaps we should look over the default configuration.

-- 
/Jacob Carlborg
March 02, 2013
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.

-- 
/Jacob Carlborg
March 02, 2013
On Saturday, 2 March 2013 at 16:06:57 UTC, Peter Alexander wrote:
> On Saturday, 2 March 2013 at 15:43:57 UTC, Russel Winder wrote:
>> C is a (reasonably) well known and used language thought to create fast
>> code. RPython is Python but with some restrictions that is statically
>> compiled.  For writing interpreters, RPython spanks C. PyPy is not the
>> only language using RPython to implement the interpreter. C's days in
>> this game are seriously numbered.
>
> Source? (Googling "rpython interpreter speed" didn't show anything)
>
> 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.
>
> 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.

Rpython has been used to write a very fast jit (pypy) which is not the same as an interpreter. The interpreter is what you fall back to when you can't use the jit.

I don't know how fast pypys interpreter is specifically, but it's not it's main selling point.
March 02, 2013
On Saturday, 2 March 2013 at 16:09:02 UTC, Jacob Carlborg wrote:
> On 2013-03-02 02:10, Walter Bright wrote:
>
>> Python's splitter, which you are measuring, isn't written in Python. It
>> is written in C. You're actually comparing a bit of C code with a bit of
>> D code.
>
> Does that really matter. He's using Python, if the function is part of the standard library and if it's implement in Python or C doesn't really matter.

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.
March 02, 2013
> Does that really matter. He's using Python, if the function is part of the standard library and if it's implement in Python or C doesn't really matter.

You can look at it that way, but still, the fact that most of the work in the Python version is done by C code makes the timings less surprising. If split() was implemented in pure python and it would be only three times slower (when run with CPython) than std.algorithm.splitter, that would be very surprising and a sign that std.algorithm.splitter is doing something horribly wrong.
March 02, 2013
On 3/2/13 11:09 AM, Jacob Carlborg wrote:
> On 2013-03-02 02:10, Walter Bright wrote:
>
>> Python's splitter, which you are measuring, isn't written in Python. It
>> is written in C. You're actually comparing a bit of C code with a bit of
>> D code.
>
> Does that really matter. He's using Python, if the function is part of
> the standard library and if it's implement in Python or C doesn't really
> matter.

The point here is that often one needs to write code that's more than gluing library calls together. I've seen that many, many times.

Andrei


March 02, 2013
On 3/2/13 11:11 AM, Jacob Carlborg wrote:
> On 2013-03-01 23:01, Andrei Alexandrescu wrote:
>
>> I doubt that.
>>
>> 1. Microbenchmarks are a crapshoot, they exercise a tiny portion of the
>> language and library.
>
> If that tiny portion is what's only used, then the rest doesn't matter.

Agreed. But I doubt that's the case in nontrivial applications.

Andrei