[zeromq-dev] Multicore Magic

Naked Short Selling cashox at gmail.com
Thu Apr 29 21:04:58 CEST 2010


On 4/26/10, Martin Sustrik <sustrik at 250bpm.com> wrote:
> Pieter Hintjens wrote:
>> On Mon, Apr 26, 2010 at 10:09 PM, Martin Sustrik <sustrik at 250bpm.com>
>> wrote:
>>
>>>> Wouldn't happen like that, rather allocate fixed shmem buffers that
>>>> are reused for smaller messages.  And use signals to indicate new
>>>> data... no?
>>> Definitely doable. But that's what OS-provided IPC mechanism does under
>>> covers. Once you go that way you find yourself competing with kernel
>>> implementation of the same thing.
>>
>> Are signals as fast as, or slower than inproc?
>
> They are slower.
>
>>> Not that it's not doable. There've been a discussion on the list where
>>> someone proposed busy-looping when waiting for incoming data, thus
>>> by-passing the kernel. Still, my feeling is that such measures are a bit
>>> drastic even for a HPC solution like 0MQ.
>>
>> Busy-looping makes sense (except for energy consumption) when there's
>> one core per task, and that's kind of where things are heading...
>
> If anyone is willing to take a try on that, why not. But be warned: It's
> complex and the reward may be not worth of the effort invested.
>

I heard people are doing this in the trading world as latency is very sensitive.
I think 0mq should at least have this optional implementation available; people
can choose to use it at their own risk.

Is there any open source projects that have such "crazy" implementation?

>> Might be worth collecting this into a design whitepaper.
>
> Sure. I've gave up writing design whitepapers after version 0.6 :)
>
> Martin
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



More information about the zeromq-dev mailing list