Message passing between threads: Java 4 times faster than D
Graham St Jack
Graham.StJack at internode.on.net
Thu Feb 9 14:29:29 PST 2012
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.
>> Gor Gyolchanyan.
Graham St Jack
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 26993 bytes
Desc: not available
More information about the Digitalmars-d