Joseph Rushton Wakeling:

> Slightly baffled to see "ldc2" and "ldmd2" listed as two separate entries.  Your code will surely achieve similar speed when compiled with ldmd2 and appropriate optimization choices .... ?

Yes, I think the ldmd2 "entry" should be removed...

Bye,
bearophile

On Thursday, 7 November 2013 at 14:27:59 UTC, Daniel Davidson wrote:
> Regarding what is idiomatic D, isn't `immutable x = rnd.next % levelSize;` pedantic.
> Why not just go with `const x = rnd.next % levelSize;`

I actually prefer usage of `immutable` by default for value types because it is likely to cause a compilation error if later code changes to stop conforming value semantics. `const` version is likely to still compile with wrong assumption.

Benchmark author here. I left the ldmd2 entry there to represent the performance of the D implementation from the time of the benchmark, to highlight that the current D implementation is much newer than the others, and that there have been no attempts to optimise the C and C++ versions similarly to how the latest D version was optimised. If you feel it creates needless confusion I can remove it, however, or put a note next to it stating the above.

I'm currently working on an OpenGL benchmark, and if anybody wants to improve the D implementation they're most welcome: https://github.com/logicchains/ParticleBench/blob/master/D.d. Currently it's just a straight port of the C version. Conciseness will be measured by the compressed source file size this time, rather than by the Github SLOC number. Note however that there seems to be little scope for improving the speed, as waiting for the GPU to render the scene is a significant bottleneck (for reference, the unoptimised racket implementation currently runs at around 50% of the speed of the -O3 C implementation, which obviously wouldn't be possible for something more cpu-bound).

On Thursday, 7 November 2013 at 15:28:13 UTC, bearophile wrote:
> Joseph Rushton Wakeling:
>
>> Slightly baffled to see "ldc2" and "ldmd2" listed as two separate entries.  Your code will surely achieve similar speed when compiled with ldmd2 and appropriate optimization choices .... ?
>
> Yes, I think the ldmd2 "entry" should be removed...
>
> Bye,
> bearophile

logicchains:

> Benchmark author here. I left the ldmd2 entry there to represent the performance of the D implementation from the time of the benchmark, to highlight that the current D implementation is much newer than the others, and that there have been no attempts to optimise the C and C++ versions similarly to how the latest D version was optimised. If you feel it creates needless confusion I can remove it, however, or put a note next to it stating the above.

ldmd2 is not a compiler, it's just a thin wrapper that helps use the ldc2 compiler with the same command line options of dmd. So I think putting two entries for ldc2 and ldmd2 is a little confusing for D newbies, it looks like they are two different compilers (also because their performance appears different in the table).

I have just written an answer in your good blog to solve the small problem you have found in my code. Here is a better explanation. If you have code like:

uint[10] data;
foreach (i, ref x; data)
    x = i;

This code works on 32 bit systems, because the index i of an array is deduced as a size_t. So it fits inside the array of uints. On a 64 system i is still size_t, but it's now 64 bit long, and it can't fit. Most integral values (like int and uint) in D have a fixed size. While size_t is not fixed in size.

This causes some problems when you want to move 32 bit code to a 64 bit system.

Some times ago I opened an enhancement request on this topic, but perhaps better solutions are needed:
https://d.puremagic.com/issues/show_bug.cgi?id=5063

And the solution suggested by Walter here is not enough:
> auto i = array.length;

It's not a big problem, such mistakes usually don't cause significant problems, and sometimes the attempt to avoid the problem is worse than the the problem itself.

Bye,
bearophile

That's interesting. Is there a particular reason for using size_t for array indexing rather than int?

> uint[10] data;
> foreach (i, ref x; data)
>     x = i;
>
> This code works on 32 bit systems, because the index i of an array is deduced as a size_t. So it fits inside the array of uints. On a 64 system i is still size_t, but it's now 64 bit long, and it can't fit. Most integral values (like int and uint) in D have a fixed size. While size_t is not fixed in size.
>
> This causes some problems when you want to move 32 bit code to a 64 bit system.
>
> Some times ago I opened an enhancement request on this topic, but perhaps better solutions are needed:
> https://d.puremagic.com/issues/show_bug.cgi?id=5063

Am Fri, 08 Nov 2013 09:58:38 +0100
schrieb "logicchains" <jonathan.t.barnard@gmail.com>:

> That's interesting. Is there a particular reason for using size_t for array indexing rather than int?

It is the natural representation of an array index. It is
unsigned and spans the whole addressable memory area.
The _t indicates that its size depends on the target
architecture.

-- 
Marco

On Friday, 8 November 2013 at 09:37:56 UTC, Marco Leise wrote:
> The _t indicates that its size depends on the target
> architecture.

Erm? I am pretty sure "_t" is just a short form for "type", common naming notation from C.

Ah, right. I'll bear it in mind if I'm ever writing cross-architectural code in D.

On Friday, 8 November 2013 at 09:37:56 UTC, Marco Leise wrote:
> Am Fri, 08 Nov 2013 09:58:38 +0100
> schrieb "logicchains" <jonathan.t.barnard@gmail.com>:
>
>> That's interesting. Is there a particular reason for using size_t for array indexing rather than int?
>
> It is the natural representation of an array index. It is
> unsigned and spans the whole addressable memory area.
> The _t indicates that its size depends on the target
> architecture.

Your site counts 90 SLOC for the D entry, that comes from 83 lines of code plus 7 comment lines. I think you shouldn't count the lines of comments, from all the entries.

If you want to count the comments too, then if you want I'll submit a 83 lines long D version without comments for your site, as in the Scala entry, for a little more fair comparison.

The Scala entry has lines of code like:

case (numLvls, threadNum) => {val rnd = new Xorshift32(rand.nextInt); if(!silent) println(s"Thread number $threadNum has seed " +  rnd.seed); numLvls -> rnd}

Bye,
bearophile

On Friday, 8 November 2013 at 11:47:02 UTC, logicchains wrote:
> Ah, right. I'll bear it in mind if I'm ever writing cross-architectural code in D.

Using size_t as array indices is a c/c++ convention that is also relevant to D, it's definitely not a D specific thing. Perhaps it is more common here due to it's use in .length for arrays and the index in foreach amongst other places in the language.