[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