On Fri, 10 Feb 2012 15:07:41 +0100, deadalnix <deadalnix@gmail.com> wrote:

> Le 09/02/2012 20:57, Martin Nowak a écrit :
>> On Thu, 09 Feb 2012 16:44:46 +0100, Sean Kelly <sean@invisibleduck.org>
>> wrote:
>>
>>> So a queue per message type? How would ordering be preserved? Also,
>>> how would this work for interprocess messaging? An array-based queue
>>> is an option however (though it would mean memmoves on receive), as
>>> are free-lists for nodes, etc. I guess the easiest thing there would
>>> be a lock-free shared slist for the node free-list, though I couldn't
>>> weigh the chance of cache misses from using old memory blocks vs. just
>>> expecting the allocator to be fast.
>>
>> I didn't yet got around to polish my lock-free SList/DList implementations,
>> but mutexes should only become a problem with high contention when you
>> need to block.
>> You'd also would need some kind of blocking for lock-free lists.
>>
>
> Doesn't this require shared to be working ?

Shared is already very helpful for writing lock-free stuff.
I still need to use atomic load/store to make them portable though.
If shared would add memory fences for full sequential order one would
rather hack around this using weaker ordering.

On Feb 9, 2012, at 2:17 PM, Sean Kelly wrote:

> On Feb 9, 2012, at 11:57 AM, Martin Nowak wrote:
>> 
>> I didn't yet got around to polish my lock-free SList/DList implementations,
>> but mutexes should only become a problem with high contention when you need to block.
>> You'd also would need some kind of blocking for lock-free lists.
> 
> No blocking should be necessary for the lock-free list.  Just try to steal a node with a CAS.  If the result was null (i.e. if the list ended up being empty), allocate a node via malloc/GC.

I just realized that the free-list is actually a stack, so doing this lock-free runs into the ABA problem.  There goes the idea of this being an easy optimization.

On Thursday, 9 February 2012 at 09:09:24 UTC, Nicolae Mihalache wrote:
> Hello,
>
> I'm a complete newbie in D and trying to compare with Java. I implemented  a simple test for measuring the throughput in message passing between threads. I see that Java can pass about 4mil messages/sec while D only achieves 1mil/sec. I thought that D should be faster.
>
> The messages are simply integers (which are converted to Integer in Java).
>
> The two programs are attached. I tried compiling the D version with both dmd and gdc and various optimization flags.

I just tried the attached program, D is still 3~4 times slower than the Java version.

Have we made any improvement on the message passing between threads since 2012?

Or is there any new way to improve the D verson?

Thanks.