Pretty cool. I see publish + subscribe example on GitHub but no request/response. Am I missing something?
Request-response is on our todo list and will be introduced in an upcoming release :)
What are you needing request-response for?
Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
41–50 of 53 posts
Re: Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
#42Been 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 p…
I was looking a bit at the code for the shared memory implementation in https://github.com/3tilley/rust-experiments/tree/master/ipc and the dependency https://github.com/elast0ny/raw_sync-rs.
My last systems programming class was already a few years ago and I am a bit rusty, so I got some questions:
1. Looking at the code in https://github.com/elast0ny/raw_sync-rs/blob/master/src/even...) it looks like we are using a userspace spinlock. Aren't these really bad because the mess with the process scheduler and might unnecessarily trigger the scaling governor to increase the cpu frequency? I think at least on linux one could use a semaphore to inform the consumer that new data has been produced.
2. What kind of memory guarantees do we have on modern computer architectures such as x86-64 and ARM? If the producers does two writes (I imagine first the data and then the release of the lock) - is it guaranteed that when the consumer reads the second value that also the first value has been synchronized?
Re: Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
#43Earlier quoted context omitted.
Thanks for sharing here -- yeah these are definitely huge issues that make shared memory hard -- the when-things-go-wrong case is definitely quite hairy. I wonder if it would work well as a sort of opt-in specialization? Start with TCP/UDS/STDIN/whatever, and then maybe graduate, and if anything goes wrong, report errors via the fallback? I do agree it's rarely worth it (and same-machine UDS is probably good enough),…
The other thing is 10x improvement on basically nothing is quite small. Whatever time it takes for a message to be processed is going to be dominated by actually consuming the message. If you have a great abstraction, cool - use it anyhow, but it's probably not worth developing a shared memory library yourself.
Agree, but it's also a question of where do you start from -- 10x is a lot to give up, and knowing you're giving it up is pretty important.
That said, the people who built iceoryx2 obviously believe it's worth investing in, which is interesting.
Re: Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
#44Earlier quoted context omitted.
The other thing is 10x improvement on basically nothing is quite small. Whatever time it takes for a message to be processed is going to be dominated by actually consuming the message. If you have a great abstraction, cool - use it anyhow, but it's probably not worth developing a shared memory library yourself.
Agree, but it's also a question of where do you start from -- 10x is a lot to give up, and knowing you're giving it up is pretty important. That said, the people who built iceoryx2 obviously believe it's worth investing in, which is interesting.
I'm glad the team is putting in the work to get it working for the rest of us.
Re: Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
#45Earlier quoted context omitted.
At $work we are evaluating different IPC strategies in Rust. My colleague expanded upon 3tilley's work, they have updated benchmarks with iceoryx2 included here[0]. I suppose the current release should perform even better. [0]: https://pranitha.rs/posts/rust-ipc-ping-pong/
Excellent writeup! I performed just about the same test, but I didn't see 13M rps in my testing, shared memory went up to about 1M. That said, I made sure to include serialization/deserialization (and JSON at that) to see what a realistic workload might be like.
Thanks! I am updating the benchmarks to take into account the different payload sizes as we speak, maybe we can discuss the difference in our methodologies and results then? I'll drop you a mail once updated.
Re: Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
#46Earlier quoted context omitted.
At $work we are evaluating different IPC strategies in Rust. My colleague expanded upon 3tilley's work, they have updated benchmarks with iceoryx2 included here[0]. I suppose the current release should perform even better. [0]: https://pranitha.rs/posts/rust-ipc-ping-pong/
Sweet. Can we link to your benchmark from the main iceoryx2 readme?
Alright, I am updating the benchmarks for the newest release, I'll open a PR once done.
Re: Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
#47Earlier quoted context omitted.
Interesting that on Linux Unix Domain Sockets are not faster than TCP. People often say that the TCP stack overhead is high but this benchmark does not confirm that.
i couldn't resist reproducing on bare metal linux (8th gen core i5, ubuntu 22.04): cargo run --release -- -n 1000000 --method unixstream cargo run --release -- -n 1000000 --method tcp ~9μs/op for unixstream, ~14μs/op for TCP. unixstream utilizes two cores at ~78% each core, tcp only utilizes ~58% of each core. so there is also something wrong in the benchmarks where blocking is happening and cores are not being fully…
Our prod env is comprised of cloud VMs so tried to replicate that. Have some benchmarks from prod env, will share those.
Re: Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
#48Earlier quoted context omitted.
> Shared memory works as a transport if you either assume that all parties are trusted (in which case why do IPC in the first place? Just put them in a monolith) There are all sorts of domains where mutually-trusted parties need IPC. Off the top of my head and in no particular order: - Applications that pass validated data to/from captive subprocesses. Not everything is available as a natively-linked library. Not eve…
If you use shared memory with a captive process, that process can probably hack you if it gets taken over by an attacker. I agree with your parallelism counter-argument in principle. However even there it would probably make sense to not trust each other, to limit the blast radius of successful attacks. In your next point the "careful" illustrates exactly my point. Using shared memory for IPC is like using C or C++ a…
> Using shared memory for IPC is like using C or C++ and saying "well I'll be careful then"
Sort of. In the replatforming/codebase conversion case, the amount of care and labor needed to effectively use shared memory for communication is, in my experience, much less than the care and labor needed to make things work in the same address space (and the labor and cost-in-currency of making things work with sufficient performance using traditional IPC is also often preventative). In that regard, I don't think it's equivalent to arguing in favor of C: capable alternatives to C exist that require less care and labor to use; capable alternatives to shared memory IPC in some cases do not.
I'd be curious how much effort and specific shared-memory-IPC-expertise is required on the part of the Postgres maintainers to keep the shared memory layer capable and secure. I hope it's more like iceoryx2 bills itself in that it's relatively well encapsulated such that folks can use it safely without extensive familiarity with the risk domain, but I might be disappointed.
Regardless, I hope we can agree to disagree on specifics; I appreciate the thoughtful response in any case.
Re: Show HN: Iceoryx2 – Fast IPC Library for Rust, C++, and C
#49How 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
Another IPC bus: "Varlink – IPC to replace D-Bus gradually in systemd" https://news.ycombinator.com/item?id=41687413
Serde does serialization and serialization with many formats in Rust