On Fri, 3 Feb 2012 00:39:39 +1100
john skaller <[email protected]> wrote:
> BTW: are you so sure performance will suffer?
Yes.
> The reason I ask is related to existing overheads:
>
> (a) malloc/free is used extensively in real applications,
> it is already thread-safe so it is using at least some combination
> of locks and TLS
libzmq goes to great lengths to optimise memory allocation where
possible. See e.g. the VSM functionality. There is several *years*
tuning work that has been done on this.
> (b) the use of "errno" by 0MQ is a performance overhead already:
> errno is in TLS which has a nasty overhead. If you want to improve performance
> give up on, or at least provide a sane alternative to, errno.
One extra indirection per load, that has nowhere near the overhead of a
lock. Or does TLS do something more than that? If so, why?
> Fast barriers are provided on multi-cores, implemented directly in the
> hardware.
> There are also lock free synchronisation primitives on all modern CPUs.
^^^^^^^^^^
Primitives yes. You still need to implement the full lock
free algorithms, e.g. ypipe_t. Speaking from experience, getting lock
free algorithms right is really hard.
-mato
--
Martin Lucina <[email protected]>
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
