Fast interprocess communication?

[steve]

Hi all,

I'm working on a client/server hash table implementation and am finding that the majority of the latency is in waiting for interprocess communication
via shared memory (using a memory-mapped file). Is there some very fast way to communicate a small (e.g., 64-bit) value from one process to another?
I'm looking for something in the double-digit nanosecond range, which obviously leaves out anything that requires a context switch or syscall of any
type.

Thanks!
------------
Steve Heller

[Adrian Jackson]

Hi Steve,

Using a shared memory segment, at least on Linux, should be pretty fast, with the limitation that you can only communicate between processes on the same node, and numa issues need considered for best performance.

cheers

adrianj

--
You received this message because you are subscribed to the Google Groups "pmem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pmem+uns...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pmem/7hgopfh2cqnms5p7o5epif4rrulh259lt8%404ax.com.

[wam...@gmail.com]

One approach to this might be to use a delegation mechanism similar to the SOSP 2017 paper (“ ffwd: delegation is (much) faster than you think”).  https://dl.acm.org/doi/10.1145/3132747.3132771

Note that this approach does work in shared memory across nodes.

 

Tony

 

 

 

[steve]

On Fri, 30 Oct 2020 11:46:08 -0700, <wam...@gmail.com> wrote:

>One approach to this might be to use a delegation mechanism similar to the SOSP 2017 paper (“ ffwd: delegation is (much) faster than you think”). https://dl.acm.org/doi/10.1145/3132747.3132771
>
>Note that this approach does work in shared memory across nodes.

Sounds interesting. Is there a public paper about it somewhere?
------------
Steve Heller

[wam...@gmail.com]

The code and a tech report version of the paper are here:
https://github.com/bitslab/ffwd

Colyer wrote this up and his link should provide you with full access (it
did for me when I just tried it in an incognito window).
https://blog.acolyer.org/2017/12/04/ffwd-delegation-is-much-faster-than-you-
think/

Tony

[steve]

On Fri, 30 Oct 2020 11:52:49 -0700, <wam...@gmail.com> wrote:

>The code and a tech report version of the paper are here:
>https://github.com/bitslab/ffwd
>
>Colyer wrote this up and his link should provide you with full access (it
>did for me when I just tried it in an incognito window).
>https://blog.acolyer.org/2017/12/04/ffwd-delegation-is-much-faster-than-you-
>think/

I'll definitely take a serious look at that. It appears that it will be a fairly significant effort to adapt my code to it, but should be worth it in
terms of scalability.

Thanks!

>Tony
>
>-----Original Message-----
>Sounds interesting. Is there a public paper about it somewhere?
>
>

------------
Steve Heller

[steve]

On Fri, 30 Oct 2020 11:52:49 -0700, <wam...@gmail.com> wrote:

>The code and a tech report version of the paper are here:
>https://github.com/bitslab/ffwd
>
>Colyer wrote this up and his link should provide you with full access (it
>did for me when I just tried it in an incognito window).
>https://blog.acolyer.org/2017/12/04/ffwd-delegation-is-much-faster-than-you-
>think/
>
>Tony

Hi Tony,

Although that paper and code don't directly address my situation, I believe I now have a much better understanding of how to minimize bus traffic when
copying data between the client and server.

Namel, all data should be copied in 128-byte blocks which are written to only from one core, to eliminate read for ownership traffic and possibly
other cache coherence overhead. Does that sound right?
------------
Steve Heller

[Eduardo Berrocal]

Interesting paper, thanks for sharing !