[zeromq-dev] P/Invoke-based CLR access to zeroMQ

Martin Sustrik sustrik at fastmq.com
Wed Feb 25 09:16:12 CET 2009


Dirk,

Thanks! As I see, the limit where pinning starts to make sense is 128kB. 
Nice.

We'll test whether there's any performance difference between C++/CLI 
and P/Invoke implementations and if there is not, we'll replace the 
existing code with this stuff. If there's significant perf advantage for 
C++/CLI we should consider maintaining both version.

Martin

Dirk O. Siebnich wrote:
> Please find attached an updated P/invoke-based CLR implementation. I
> have implemented switching between copying and pinning in the Send
> function based on some quick measurements.
> 
> -Dirk
> 
> On Mon, 2009-02-23 at 11:03 +0100, Martin Sustrik wrote:
>> Dirk,
>>
>>> Well, the CLR is an amazing piece of technology. Please check the
>>> attached dnzmq.cs, I think I made the Send function work without
>>> modifications to the C-API. So all that's needed now would be a receive
>>> with a allocator callback.
>> It looks pretty elegant.
>>
>>> There is just one minor problem: with messages of 512 bytes size, the
>>> original copy-based implementation is twice as fast as the new one...
>> :)
>>
>> This is why I've proposed to use zero-copy only for large messages. On 
>> low layers (like OS kernel) the low limit for messages to be more 
>> effective with zero-copy is somewhere at several kilobytes of size. With 
>> the functionality on higher level of stack, this limit may be even higher.
>>
>> Once we have a little time we'll give your implementation a try testing 
>> it for different message sizes. Testing it for both zero-copy and copy 
>> algorithms should yield 2 linear graphs. The intersection of the two 
>> lines should be a located at the message size where zero-copy starts to 
>> be more efficient than copy algorithm.
>>
>> Btw, we've fixed the bugs you've reported and merged the fixes into the 
>> trunk. The only exception is the SCTP-related problem which will take a 
>> some time to fix as we are having problems with SCTP API not being fully 
>> standardised at the moment.
>>
>> Martin




More information about the zeromq-dev mailing list