The author of the serial language comparison has now created a simple parallel comparison:

http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/

From the blog post:

>but for the D and Rust implementations only the single-threaded portion was written idiomatically; the parallelisation of that code was done naively by myself.<

The single-threaded D version of the code is not idiomatic, it's very C-like code.

This was the idiomatic serial D version:
https://github.com/logicchains/levgen-benchmarks/blob/master/D-XorShift.d


Also the author keeps changing the way he measures languages, and in the meantime he has added the line count metric too, so now the D version should be modified so code like this takes 2 lines instead of 12:

struct Tile {
    int X = void;
    int Y = void;
    int T = void;
}

struct Room {
    int X = void;
    int Y = void;
    int W = void;
    int H = void;
    int N = void;
}


More from the blog post:

>The D implementation also surprised me, although I think this was largely because I was unfamiliar with D’s memory model. I originally tried having each thread write to part of a global array, like in the C implementation, but, after they had completed their task and the time came to read the data, the array was empty, possibly having been garbage collected. The solution was to mark the array as shared, which required propagating the chain of ‘shared’ typing to the objects being written to the array in order to ensure safety. This was an interesting difference from Rust’s memory safety model, where the type of pointers rather than objects determines how they can be shared, but I’m not familiar enough with D’s memory model to comment on their relative effectiveness.<

>I parallelised the D and Rust programs myself, hence the code is probably not idiomatic, and still has plenty of room for improvement. D for instance has a parallel for loop; I couldn’t get it working, but if someone got it working then it would significantly reduce the size of the code.<

Bye,
bearophile

The missing link to the Reddit thread:

http://www.reddit.com/r/programming/comments/1kxt7w/parallel_roguelike_levgen_benchmarks_rust_go_d/

Bye,
bearophile

On Fri, Aug 23, 2013 at 03:48:38PM +0200, bearophile wrote:
> The author of the serial language comparison has now created a simple parallel comparison:
> 
> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/
[...]
> Also the author keeps changing the way he measures languages, and in the meantime he has added the line count metric too, so now the D version should be modified so code like this takes 2 lines instead of 12:
> 
> struct Tile {
>     int X = void;
>     int Y = void;
>     int T = void;
> }
> 
> struct Room {
>     int X = void;
>     int Y = void;
>     int W = void;
>     int H = void;
>     int N = void;
> }
[...]

Seriously, I don't understand what's with this obsession with line count metrics. Here's a 2-line version of the above code:

struct Tile { int X = void; int Y = void; int T = void; }
struct Room { int X = void; int Y = void; int W = void; int H = void; int N = void; }

which, as you can tell, says *nothing* whatsoever about the expressiveness of the language. I mean, how would you account for the possibility that perhaps the D community adopted this 2-line style of coding as the "preferred" D style? Since we adopted a style that uses up more lines, why should the *language* be penalized for having a higher line count, when the 2-line version is equally acceptable to the compiler and has exactly the same semantics?

Or, put another way, suppose I rename "void" to "nada", and then call the resulting language E, and I postulate that in E, the preferred coding style in my 2-line format above. Does this then mean that E is more expressive than D? Certainly not! But according to the line count metric, it does.

Frankly, the fact that line counts are used at all has already decremented the author's credibility for me.


T

-- 
English is useful because it is a mess. Since English is a mess, it maps well onto the problem space, which is also a mess, which we call reality. Similarly, Perl was designed to be a mess, though in the nicests of all possible ways. -- Larry Wall

On Fri, 23 Aug 2013 09:48:54 -0700, H. S. Teoh wrote:

> Seriously, I don't understand what's with this obsession with line count metrics. Here's a 2-line version of the above code:
> 
> struct Tile { int X = void; int Y = void; int T = void; }
> struct Room { int X = void; int Y = void; int W = void; int H = void;
> int N = void; }
> 
> Frankly, the fact that line counts are used at all has already decremented the author's credibility for me.
> 
> 
> T

Let's get that character count down :)

struct Tile { int X=void, Y=void, T=void; }
struct Room { int X=void, Y=void, W=void, H=void, N=void; }

I like it and see an interesting mix of concepts in Nimrod.

That said, I didn't and still don't see the major breakthrough or
value of {} vs. begin/end vs. Python style. While I agree that
Python enforces some visual style I also see that this question
always comes down to personal philosophy and discipline. You can
write clean looking code in D as well as in Python. If someone
really really feels, say, begin/end to be earthshakingly,
strategically better than {}, he is free to edit the language
spec and to create his private D (or whatever) with begin/end
rather than {}.

More importantly, I feel that whole sloc thingy misses the major
point. Code is written for 2 situations, once for the compiler
(which doesn't care too much about human readability) and, imo
way more important, maintenance. *That*, maintenance, is what
readability is or should be mostly all about.

I'll keep an occasional eye on Nimrod but I fail to spot anything
major or strategic enough to warrant even considering leaving D
for Nimrod.

R

H. S. Teoh:

> Seriously, I don't understand what's with this obsession with line count metrics.
> ...
> Frankly, the fact that line counts are used at all has already
> decremented the author's credibility for me.

I agree with you. When you show a table to people, and such table is ranked according to run-time and cloc counts, some readers will judge better languages the ones that have lower run-time and lower line count.

In my D code I like to add unittests, contracts, asserts for loop invariants, and so on. All such things increase the line count. A person could say that in theory a better language should offer safety even without all those extra tests, so those extra lines of code should be counted for the length of the D entry, and removing them is not fair to improve the D line count metric.

But in most languages (including D, C, Python, etc) you can write code that has various degrees of safety. This means that a D entry without those compile-time and run-time tests is just as valid as D code with those tests.

This means using just the line count metric is not enough, you somehow have to produce entries that show similar level of safety (and doing this across different languages is not easy), only now the metric count is meaningful.

In the meantime in Rosettacode and other places where D code is shown and compared to code written in other languages I put all the run-time and compile-time tests I feel necessary, because for a professional programmer that's the right thing to do, from an engineering point of view.

Said that, in such comparisons wasting space is not a good idea.

Bye,
bearophile

On 8/23/2013 6:48 AM, bearophile wrote:
> The author of the serial language comparison has now created a simple parallel
> comparison:
>
> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/

And note how well D did in the speed tests!

Not really intrinsic to the language(syntactically), but there is
the "soft realtime GC", meaning you can control when and for how
long the gc can do the collecting. Sounds like a lovely feature
for games.

http://nimrod-code.org/gc.html

On Friday, 23 August 2013 at 17:33:12 UTC, Ramon wrote:
> I like it and see an interesting mix of concepts in Nimrod.
>
> That said, I didn't and still don't see the major breakthrough or
> value of {} vs. begin/end vs. Python style. While I agree that
> Python enforces some visual style I also see that this question
> always comes down to personal philosophy and discipline. You can
> write clean looking code in D as well as in Python. If someone
> really really feels, say, begin/end to be earthshakingly,
> strategically better than {}, he is free to edit the language
> spec and to create his private D (or whatever) with begin/end
> rather than {}.
>
> More importantly, I feel that whole sloc thingy misses the major
> point. Code is written for 2 situations, once for the compiler
> (which doesn't care too much about human readability) and, imo
> way more important, maintenance. *That*, maintenance, is what
> readability is or should be mostly all about.
>
> I'll keep an occasional eye on Nimrod but I fail to spot anything
> major or strategic enough to warrant even considering leaving D
> for Nimrod.
>
> R

On 8/23/13 9:29 AM, bearophile wrote:
> The missing link to the Reddit thread:
>
> http://www.reddit.com/r/programming/comments/1kxt7w/parallel_roguelike_levgen_benchmarks_rust_go_d/

Awesome, upboat!

I am mostly speculating, but in the past few months I subjectively perceive we've turned a corner of sorts in terms outlook and adoption by the larger community. Complaints about quality have dwindled and more people report trying D and finding it impressive. Seems we're doing something right. Congratulations for the hard work for everyone involved!


Andrei

On Friday, 23 August 2013 at 13:48:39 UTC, bearophile wrote:
> The author of the serial language comparison has now created a simple parallel comparison:
>
>...

Off-topic:
First time hearing of Nimrod, it has a neat GC implementation for
games and similar soft-realtime applications. Being able to step
your GC by small amounts each frame instead of just getting
freezes every few hundred-ish would be handy.