[zeromq-dev] ZeroMQ 4.2 release, planning

[Thomas Rodgers]

>
> Looking forward to seeing the benchmarks on that idea!


The most direct way to do so (and most relevant to libzmq, rather than my
toy implementation over Boost Asio) would be to make the change in the
existing zmq code base and benchmark it with a few sizes. I will make some
time to do that over the next week or so.

On Fri, Oct 7, 2016 at 7:28 AM, Manuel Amador (Rudd-O) <rudd-o at rudd-o.com>
wrote:

> On 10/06/2016 02:03 PM, Thomas Rodgers wrote:
> >
> >     What about 96 bytes? same penalty?
> >
> >
> > If you are going to bump the size to > 64 bytes (x86 cache line size),
> > it likely should be rounded up to to 128 bytes, so as to eliminate any
> > potential for false sharing on architectures with 64 byte cache lines.
> >
> > Having said that, I've been playing with an experimental C++
> > implementation of ZMTP using much larger fixed message struct sizes of
> > ~512 bytes. It's nothing more than a toy implementation at this point
> > and I don't have any real perf numbers, but my reasoning for the
> > larger message size is that ZMTP has explicit optimization for small
> > messages of < 256 bytes. A size > 256 bytes accommodates all small
> > ZMTP messages without an extra allocation and indirection and the
> > reference counting overhead of the large message type (all potentially
> > much more expensive operations than the cost of simply being larger
> > than a cache line), along with message metadata, and likely a decent
> > fraction of "large" ZMTP messages.
>
> Looking forward to seeing the benchmarks on that idea!
>
>
> --
>     Rudd-O
>     http://rudd-o.com/
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20161007/27ccccf6/attachment.htm>