On Saturday, 24 August 2013 at 04:22:09 UTC, Meta wrote:
> On Saturday, 24 August 2013 at 02:12:41 UTC, Jesse Phillips wrote:
>> It gets second no matter how you read it!
>
> It was also not very idiomatic. It looks like some performance improvements could be made.

I made it idiomatic, D is on place 1 now by a big margin. See the
'ldc2' entry:
http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/

Marco Leise:

> I made it idiomatic, D is on place 1 now by a big margin. See the
> 'ldc2' entry:
> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/

Very nice. I have made a more idiomatic version (in D global constants don't need to be IN_UPPERCASE), I have added few missing immutable annotations, and given the benchmark also counts line numbers, I have made the code a little more compact (particularly the struct definitions, but I have moves the then branch of some if on a new line, increasing the line count to make the code a little more readable, so it's not a unnaturally compact D code):

http://dpaste.dzfl.pl/d37ba995

Bye,
bearophile

> http://dpaste.dzfl.pl/d37ba995

That gives me 83 cloc (http://cloc.sourceforge.net ) lines of code, so if you submit that code to the benchmark site, make sure the line count (currently  	108, despite cloc gives me 101 on it) too gets updated.

Bye,
bearophile

Am Thu, 07 Nov 2013 14:19:00 +0100
schrieb "bearophile" <bearophileHUGS@lycos.com>:

> > http://dpaste.dzfl.pl/d37ba995
> 
> That gives me 83 cloc (http://cloc.sourceforge.net ) lines of
> code, so if you submit that code to the benchmark site, make sure
> the line count (currently  	108, despite cloc gives me 101 on it)
> too gets updated.
> 
> Bye,
> bearophile

foreach (immutable xi; r.x .. r.x + r.w + 1)

What the heck?! I didn't know that even compiles. :)
About the UPPERCASE_CONSTANTS: I know we tend to use camelCase
for them, too. It's just a personal preference to have global
constants in uppercase.
If you want it submitted please go ahead. My objection is that
you condensed the code too much to create a small SLOC in
comparison to e.g. C++ and moved away from the original coding
style of the benchmark that made SLOC somewhat comparable.

Btw. I also wrote a new algorithm for the given problem, that
gives deterministic "full" levels without resorting to trial
and error and runs a lot faster (when compiled for 64-bit at
least):
http://dpaste.dzfl.pl/d37ba995

-- 
Marco

Marco Leise:

> foreach (immutable xi; r.x .. r.x + r.w + 1)
>
> What the heck?! I didn't know that even compiles. :)

It's an enhancement that I requested, and Kenji implemented some time ago.


> About the UPPERCASE_CONSTANTS: I know we tend to use camelCase
> for them, too. It's just a personal preference to have global
> constants in uppercase.

In C (and In Python, that doesn't enforce their immutability) I too write global UPPERCASE_CONSTANTS, but in D module-level constants behave better, so I prefer to use the more camelCase.


> If you want it submitted please go ahead.

OK. (I benchmarked it to make sure it's not slower).


> My objection is that
> you condensed the code too much to create a small SLOC in
> comparison to e.g. C++ and moved away from the original coding
> style of the benchmark that made SLOC somewhat comparable.

The style I have used is very similar to my normal style (I add few more braces, few more comments, and little more), so I think this D code is not unnatural. Most D entries in Rosettacode are written in that style.


> Btw. I also wrote a new algorithm for the given problem, that
> gives deterministic "full" levels without resorting to trial
> and error and runs a lot faster (when compiled for 64-bit at
> least):
> http://dpaste.dzfl.pl/d37ba995

I don't know if the author will use that. Nice code and nice popcounts.

Bye,
bearophile

On Thursday, 7 November 2013 at 13:12:56 UTC, bearophile wrote:
> Marco Leise:
>
>> I made it idiomatic, D is on place 1 now by a big margin. See the
>> 'ldc2' entry:
>> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/
>
> Very nice. I have made a more idiomatic version (in D global constants don't need to be IN_UPPERCASE), I have added few missing immutable annotations, and given the benchmark also counts line numbers, I have made the code a little more compact (particularly the struct definitions, but I have moves the then branch of some if on a new line, increasing the line count to make the code a little more readable, so it's not a unnaturally compact D code):
>
> http://dpaste.dzfl.pl/d37ba995
>
> Bye,
> bearophile


Regarding what is idiomatic D, isn't `immutable x = rnd.next % levelSize;` pedantic.
Why not just go with `const x = rnd.next % levelSize;`

Any time the type is a fundamental type with no aliasing there is no sharing so the differentiation of immutable vs const is unnecessary. Might as well go with const. immutable says I or no-one else will change the value. But since no-one else can change the value it seems overkill, no?

Thanks
Dan

Am Thu, 07 Nov 2013 15:27:57 +0100
schrieb "Daniel Davidson" <nospam@spam.com>:

> Regarding what is idiomatic D, isn't `immutable x = rnd.next %
> levelSize;` pedantic.
> Why not just go with `const x = rnd.next % levelSize;`

Yes it is pedantic and I don't mind if anyone objects. :)

> Any time the type is a fundamental type with no aliasing there is no sharing so the differentiation of immutable vs const is unnecessary. Might as well go with const. immutable says I or no-one else will change the value. But since no-one else can change the value it seems overkill, no?
> 
> Thanks
> Dan

Data is either mutable or immutable. The way I see it, const
is just a bridge to combine both worlds when the context
allows for both mutable and immutable data.
Immutable by default would have made the code look less
pedantic, but I could imagine there are big downsides to that
as well.

-- 
Marco

07-Nov-2013 18:27, Daniel Davidson пишет:
> On Thursday, 7 November 2013 at 13:12:56 UTC, bearophile wrote:
>> Marco Leise:
>>
>>> I made it idiomatic, D is on place 1 now by a big margin. See the
>>> 'ldc2' entry:
>>> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/
>>>
>>
>> Very nice. I have made a more idiomatic version (in D global constants
>> don't need to be IN_UPPERCASE), I have added few missing immutable
>> annotations, and given the benchmark also counts line numbers, I have
>> made the code a little more compact (particularly the struct
>> definitions, but I have moves the then branch of some if on a new
>> line, increasing the line count to make the code a little more
>> readable, so it's not a unnaturally compact D code):
>>
>> http://dpaste.dzfl.pl/d37ba995
>>
>> Bye,
>> bearophile
>
>
> Regarding what is idiomatic D, isn't `immutable x = rnd.next %
> levelSize;` pedantic.
> Why not just go with `const x = rnd.next % levelSize;`

IMHO yes, it's pedantic.

> Any time the type is a fundamental type with no aliasing there is no
> sharing so the differentiation of immutable vs const is unnecessary.
> Might as well go with const. immutable says I or no-one else will change
> the value. But since no-one else can change the value it seems overkill,
> no?

immutable is useful for non-value types. Say strings, then wherever function/module it's passed later on can safely avoid copying it since it's immutable.


-- 
Dmitry Olshansky

On 07/11/13 12:47, Marco Leise wrote:
> I made it idiomatic, D is on place 1 now by a big margin. See the
> 'ldc2' entry:

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

Dmitry Olshansky:

>> Regarding what is idiomatic D, isn't `immutable x = rnd.next %
>> levelSize;` pedantic.
>> Why not just go with `const x = rnd.next % levelSize;`
>
> IMHO yes, it's pedantic.

It's a little pedantic, and it's some characters longer than "const", but I think it's the good standard to use unless something (D implementation bugs, bugs or missing parts in Phobos, code logic, etc) prevents you to use it :-)

Bye,
bearophile