Message passing between threads: Java 4 times faster than D

[Graham St Jack]

I suggest using a template-generated type that can contain any of the 
messages to be sent over a channel. It is reasonably straightforward to 
generate all the boilerplate code necessary to make this happen. My 
prototype (attached) still needs work to remove linux dependencies and 
tighten it up, but it works ok. Another advantage of this approach 
(well, I see it as an advantage) is that you declare in a single 
location all the messages that can be sent over the channel, and of 
course the messages are type-safe.

The file of interest is concurrency.d.

On 10/02/12 02:14, Sean Kelly 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.
>
> On Feb 9, 2012, at 6:10 AM, Gor Gyolchanyan<gor.f.gyolchanyan at gmail.com>  wrote:
>
>> Generally, D's message passing is implemented in quite easy-to-use
>> way, but far from being fast.
>> I dislike the Variant structure, because it adds a huge overhead. I'd
>> rather have a templated message passing system with type-safe message
>> queue, so no Variant is necessary.
>> In specific cases Messages can be polymorphic objects. This will be
>> way faster, then Variant.
>>
>> On Thu, Feb 9, 2012 at 3:12 PM, Alex_Dovhal<alex_dovhal at yahoo.com>  wrote:
>>> Sorry, my mistake. It's strange to have different 'n', but you measure speed
>>> as 1000*n/time, so it's doesn't matter if n is 10 times bigger.
>>>
>>>
>>
>>
>> -- 
>> Bye,
>> Gor Gyolchanyan.


-- 
Graham St Jack

-------------- next part --------------
A non-text attachment was scrubbed...
Name: delve.tar.gz
Type: application/x-gzip
Size: 26993 bytes
Desc: not available
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120210/84f18cc8/attachment-0001.bin>