I implemented a D2 version of an open Rosetta problem.
Problem: http://rosettacode.org/wiki/Atomic_updates
Code: http://dpaste.dzfl.pl/e6615a53
Any comments or improvements?
I actually implemented a more scalable version than most of the
other languages used, by using a lock per item instead
qznc:
Code: http://dpaste.dzfl.pl/e6615a53
Any comments or improvements?
I have reformatted your code a little, according to the style
used in all other D entries of RosettaCode:
http://codepad.org/ceDyQ8lE
The usage of a sink for toString() isn't common, but it's OK.
I suggest to add so
On Monday, 21 January 2013 at 20:35:16 UTC, bearophile wrote:
qznc:
Code: http://dpaste.dzfl.pl/e6615a53
Any comments or improvements?
I have reformatted your code a little, according to the style
used in all other D entries of RosettaCode:
http://codepad.org/ceDyQ8lE
The usage of a sink
On Monday, 21 January 2013 at 21:16:58 UTC, bearophile wrote:
Some more little changes, I have added counters, and I have
used the faster Xorshift:
http://codepad.org/hIFPgSTd
Bye,
bearophile
I wouldn't mind seeing some "scope" in there. Keeps things safe.
After all, those locks can throw e
qznc:
I made another iteration on your changes.
http://codepad.org/9xB58cbE
I suggest to put your code on Rosettacode now, and then we'll do
the changes there... As you see in other answers, both me and
monarch_dodra have other ideas for improvements.
Bye,
bearophile
On Tuesday, 22 January 2013 at 00:10:22 UTC, bearophile wrote:
I suggest to put your code on Rosettacode now, and then we'll
do the changes there... As you see in other answers, both me
and monarch_dodra have other ideas for improvements.
Ok, posted it.
http://rosettacode.org/wiki/Atomic_upda
On Tuesday, 22 January 2013 at 08:12:03 UTC, qznc wrote:
On Tuesday, 22 January 2013 at 00:10:22 UTC, bearophile wrote:
I suggest to put your code on Rosettacode now, and then we'll
do the changes there... As you see in other answers, both me
and monarch_dodra have other ideas for improvements.
On Tuesday, 22 January 2013 at 09:26:25 UTC, cal wrote:
On Tuesday, 22 January 2013 at 08:12:03 UTC, qznc wrote:
On Tuesday, 22 January 2013 at 00:10:22 UTC, bearophile wrote:
I suggest to put your code on Rosettacode now, and then we'll
do the changes there... As you see in other answers, both
I have modified a little the code on RosettaCode (no changes in
the logic).
monarch_dodra:
Avoids deadlock.
imagine 2 threads:
a: from 2 to 5.
b: from 5 to 2.
If both threads acquire their first lock, then you have a dead
lock, and your program is basically dead.
By always locking low fir
On Tuesday, 22 January 2013 at 10:27:58 UTC, bearophile wrote:
I have modified a little the code on RosettaCode (no changes in
the logic).
monarch_dodra:
Avoids deadlock.
imagine 2 threads:
a: from 2 to 5.
b: from 5 to 2.
If both threads acquire their first lock, then you have a dead
lock,
monarch_dodra:
That's a good point, and I'm sure we could also have a version
of D that could also do it that way.
Someone is willing to create that second version for RosettaCode?
I have modified a bit the second and third Go versions on
Rosettacode, now there are 20 buckets and it shows th
I have modified a bit the second and third Go versions on
Rosettacode,
The changes on the Go versions are only on my local copies of the
code.
Bye,
bearophile
I have tried to scope the Mutex, but the D code gets a little
slower, I don't know why:
5,6d5
< import std.typecons: scoped;
< import std.traits: ReturnType;
19,22c17,19
< ReturnType!(scoped!Mutex) mtx;
< alias this = value;
< }
< // pragma(msg, Bucket.sizeof); // 52 byt
On Tuesday, 22 January 2013 at 10:27:58 UTC, bearophile wrote:
The Go language has four different solutions, one of them is:
http://rosettacode.org/wiki/Atomic_updates#Lock-free
From the site:
This version uses no locking for the phase where the
two clients are updating the buckets. Instead i
On Tuesday, 22 January 2013 at 14:10:14 UTC, qznc wrote:
On Tuesday, 22 January 2013 at 10:27:58 UTC, bearophile wrote:
The Go language has four different solutions, one of them is:
http://rosettacode.org/wiki/Atomic_updates#Lock-free
From the site:
This version uses no locking for the phase
monarch_dodra:
D has attomic swap operations too, AFAIK.
In core.atomic I think there is what's needed, cas and atomicOp:
https://github.com/D-Programming-Language/druntime/blob/master/src/core/atomic.d
Do you know why the site doesn't show the ddocs here?
http://dlang.org/phobos/core_atomic.
On 22.1.2013 16:00, bearophile wrote:
> Do you know why the site doesn't show the ddocs here?
> http://dlang.org/phobos/core_atomic.html
Wild guess, but couldn't it be because the ddoc documentation is inside
version(CoreDdoc) and not processed?
Martin
Martin Drasar:
Wild guess, but couldn't it be because the ddoc documentation
is inside
version(CoreDdoc) and not processed?
The question then becomes why is that version(CoreDdoc) used :-)
Bye,
bearophile
In core.atomic I think there is what's needed, cas and atomicOp:
I know what a cas is, but I don't have experience on this kind of
coding. First try at a translation (doesn't work yet, and the
global lock on buckets is missing still):
import core.atomic: atomicLoad, atomicOp, cas;
...
Second try at a translation of the third Go version. It seems to
work correctly (comments welcome), but it seems slower:
http://codepad.org/y1LnjLl0
Bye,
bearophile
On Tuesday, 22 January 2013 at 09:47:25 UTC, monarch_dodra wrote:
Avoids deadlock.
imagine 2 threads:
a: from 2 to 5.
b: from 5 to 2.
If both threads acquire their first lock, then you have a dead
lock, and your program is basically dead.
By always locking low first, you avoid the deadlock i
On Monday, 21 January 2013 at 20:35:16 UTC, bearophile wrote:
qznc:
Code: http://dpaste.dzfl.pl/e6615a53
Any comments or improvements?
I have reformatted your code a little, according to the style
used in all other D entries of RosettaCode:
http://codepad.org/ceDyQ8lE
The usage of a sink
On Tuesday, 22 January 2013 at 18:10:27 UTC, cal wrote:
On Tuesday, 22 January 2013 at 09:47:25 UTC, monarch_dodra
wrote:
Avoids deadlock.
imagine 2 threads:
a: from 2 to 5.
b: from 5 to 2.
If both threads acquire their first lock, then you have a dead
lock, and your program is basically dead
ixid:
I note you always seem to use "in" in your functions and on
reddit seemed to imply that this was the idiomatic way of using
D yet I recall Jonathan M Davies posting that using "in" was a
bad idea.
I think "in" is supposed to be(come) idiomatic, because it's
short, and it's supposed to
24 matches
Mail list logo
