« BackShow HN: Iceoryx2 – Fast IPC Library for Rust, C++, and Cekxide.ioSubmitted by elfenpiff 11 hours ago
  • hardwaresofton an hour ago

    Been doing some IPC experiments recently following the 3tilley post[0], because there just isn't enough definitive information (even if it's a snapshot in time) out there.

    Shared memory is crazy fast, and I'm surprised that there aren't more things that take advantage of it. Super odd that gRPC doesn't do shared memory, and basically never plans to?[1].

    All that said, the constructive criticism I can offer for this post is that in mass-consumption announcements like this one for your project, you should:

    - RPC throughput (with the usual caveats/disclaimers) - Comparison (ideally graphed) to an alternative approach (ex. domain sockets) - Your best/most concise & expressive usage snippet

    100ns is great to know, but I would really like to know how much RPC/s this translates to without doing the math, or seeing it with realistic de-serialization on the other end.

    [0]: https://3tilley.github.io/posts/simple-ipc-ping-pong/

    [1]: https://github.com/grpc/grpc/issues/19959

    • emmanueloga_ 4 hours ago

      Looks great! From a quick glance it seems like it is a cross platform shared memory library. Maybe similar to this? [1].

      Suggestion: would be cool to have a quick description of the system calls involved for each supported platform [2]. I'm guessing mmap on linux/osx and CreateFileMapping on Windows?

      --

      1: https://github.com/LiveAsynchronousVisualizedArchitecture/si...

      2: https://github.com/eclipse-iceoryx/iceoryx2?tab=readme-ov-fi...

      • npalli 6 hours ago

        Congrats on the release.

        What's the difference between iceoryx and iceoryx2? I don't want to use Rust and want to stick to C++ if possible.

        • elBoberido 3 hours ago

          Besides being written in Rust, the big difference is the decentralized approach. With iceoryx1 a central daemon is required but with iceoryx2 this in not the case anymore. Furthermore, more fine grained control over the resources like memory and endpoints like publisher. Overall the architecture is more modular and it should be easier to port iceoryx2 to even more platforms and customize it with 3rd party extension.

          With this release we have initial support for C and C++. Not all features of the Rust version are supported yet, but the plan is to finish the bindings with the next release. Furthermore, with an upcoming release we will make it trivial to communicate between Rust, C and C++ applications and all the other language bindings we are going to provide, with Python being probably the next one.

          • tormeh 3 hours ago

            Looks like it has significantly lower latency.

            > want to stick to C++ if possible

            The answer to that concern is in the title of the submission.

            • tbillington 4 hours ago

              > Language bindings for C and C++ with CMake and Bazel support right out of the box. Python and other languages are coming soon.

            • westurner 3 hours ago

              How does this compare to and/or integrate with OTOH Apache Arrow which had "arrow plasma IPC" and is supported by pandas with dtype_backend="pyarrow", lancedb/lancedb, and Serde.rs? https://serde.rs/#data-formats