On 8/5/2016 7:02 AM, qznc wrote:
> Ultimately, my opinion is that the benchmark is outdated and not useful today. I
> ignore it, if anybody cites the benchmark game for performance measurements.

Yeah, I wouldn't bother with it, either.

On Sat, 2016-08-06 at 22:04 -0700, Walter Bright via Digitalmars-d wrote:
> On 8/5/2016 7:02 AM, qznc wrote:
> > 
> > Ultimately, my opinion is that the benchmark is outdated and not
> > useful today. I
> > ignore it, if anybody cites the benchmark game for performance
> > measurements.
> 
> Yeah, I wouldn't bother with it, either.

Since so much effort has gone into constructing wierd and wonderful implementations just to gain speed on the one platform, yes the game itself is long past it real usefulness. If it reverted to programmer friendly algorithmic expression with a view to performance, then the problems and the game would become relevant again. I cannot see this happening, sadly.

In the end a bit of X10 or Chapel code running on a Blue Gene ro Cray is going to annihilate any code written in Fortran, FORTRAN, C++, C, or any other language for performance.

-- 
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 Sunday, 7 August 2016 at 13:30:27 UTC, Russel Winder wrote:

> In the end a bit of X10 or Chapel code running on a Blue Gene ro Cray is going to annihilate any code written in Fortran, FORTRAN, C++, C, or any other language for performance.


http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=chapel&lang2=gpp

On Sunday, 7 August 2016 at 05:04:29 UTC, Walter Bright wrote:

>> Ultimately, my opinion is that the benchmark is outdated and not useful today. I
>> ignore it, if anybody cites the benchmark game for performance measurements.
>
> Yeah, I wouldn't bother with it, either.



Rather than only being dismissive, wouldn't it be more effective to say what you would bother with.

https://github.com/kostya/crystal-benchmarks-game

https://github.com/def-/nim-benchmarksgame

Where are the D comparison programs that people should bother with?

On Sunday, 7 August 2016 at 17:53:12 UTC, Isaac Gouy wrote:
> On Sunday, 7 August 2016 at 05:04:29 UTC, Walter Bright wrote:
>
>>> Ultimately, my opinion is that the benchmark is outdated and not useful today. I
>>> ignore it, if anybody cites the benchmark game for performance measurements.
>>
>> Yeah, I wouldn't bother with it, either.
>
>
>
> Rather than only being dismissive, wouldn't it be more effective to say what you would bother with.
>
> https://github.com/kostya/crystal-benchmarks-game
>
> https://github.com/def-/nim-benchmarksgame
>
> Where are the D comparison programs that people should bother with?

Comparing so many languages is too broad. We need more specific benchmarks which must be looked at in more detail.

For example, it makes sense to have a benchmark for regular expressions. It is interesting to compare Rust and D, because they both use compile-time tricks, which C cannot do. It makes no sense to compare them to an equivalent Python/Ruby/etc program, because they all use the same C library internally. More details: Regular expressions are used in very different scenarios, so one program might not be enough. Simple expression or complex expression? Find first or find all? ASCII or Unicode? Large haystack or small?

If you want to answer the big question of "how fast is D compared to C", the best answer is "roughly the same if you compare clang to LDC, because they use the same optimizer and code generator". Getting some numbers from a bunch of benchmark programs does not improve the answer. You can only get a better answer in the sense that it becomes more specific to your specific use case, but that requires you to build your own benchmark.

On Sunday, 7 August 2016 at 21:19:54 UTC, qznc wrote:

> Comparing so many languages is too broad. We need more specific benchmarks which must be looked at in more detail.

"Chapel programs versus C++ g++" just compares 2.

Where are those "more specific benchmarks" ?


> If you want to answer the big question of "how fast is D compared to C", the best answer is "roughly the same if you compare clang to LDC, because they use the same optimizer and code generator".

So does -fllvm Haskell.

Is your "roughly the same" within 10% or is it 2x slower or is it 3x slower?

Doesn't "getting some numbers from a bunch of benchmark programs" improve that answer.

On Sunday, 7 August 2016 at 22:43:35 UTC, Isaac Gouy wrote:
>
> "Chapel programs versus C++ g++" just compares 2.
>
> Where are those "more specific benchmarks" ?
>

I think he's referring to a HPC cluster running chapel vs. C++ versions of programs.

However, I would argue Chapel would only win those comparisons when you're comparing Chapel taking advantage of all the different computers in the cluster vs. C++ code that is not taking advantage of everything it could. For instance, Chapel does not have good support for graphics cards as of yet. Anyway, Chapel does their own benchmarks against things like C+MPI. In some cases it's good, but it's not consistently better. The advantage to Chapel is its simplicity and expressiveness.

On 8/7/2016 10:53 AM, Isaac Gouy wrote:
> Rather than only being dismissive,

http://www.digitalmars.com/d/archives/digitalmars/D/No_D_in_Great_Computer_Language_Shootout_103371.html#N103383

https://www.reddit.com/r/programming/comments/ckxjv/d_an_up_and_coming_embedded_software_language/c0u7uv8

If you've changed your mind about putting D back on the site, we'd be happy to help.

On Monday, 8 August 2016 at 00:15:09 UTC, jmh530 wrote:

> I think he's referring to a HPC cluster running chapel vs. C++ versions of programs.

Let's not speculate about Russel Winder's comment.


> The advantage to Chapel is its simplicity and expressiveness.

That does seem to be the selling point -- even with tiny tiny benchmarks game programs.

On Monday, 8 August 2016 at 00:44:46 UTC, Walter Bright wrote:
> On 8/7/2016 10:53 AM, Isaac Gouy wrote:
>> Rather than only being dismissive,

How did you get from

>> Yeah, I wouldn't bother with it, either.

to

> If you've changed your mind about putting D back on the site, we'd be happy to help.

?