Going faster than memcpy
squadrick.dev
Going faster than memcpy
1–10 of 83 posts
Re: Going faster than memcpy
#2Thought about zero-copy IPC recently. In order to avoid memcopy for the complete chain, I guess it would be best if the sender allocates its payload directly on the shared memory when it’s created. Is this a standard thing in such optimized IPC and which libraries offer this?
Re: Going faster than memcpy
#3It's not clear from a skim of this article, but a common problem I've seen in the past with memory copying benchmarks is to not serialise and access the copied data in its destination to ensure that it was actually completed before concluding the timing. A simple REP MOVS should be at or near the top, especially on CPUs with ERMSB.
Re: Going faster than memcpy
#4Thought about zero-copy IPC recently. In order to avoid memcopy for the complete chain, I guess it would be best if the sender allocates its payload directly on the shared memory when it’s created. Is this a standard thing in such optimized IPC and which libraries offer this?
This is one of mmap's designed-for use cases. Look at DPDK maybe.
Re: Going faster than memcpy
#5It's not clear from a skim of this article, but a common problem I've seen in the past with memory copying benchmarks is to not serialise and access the copied data in its destination to ensure that it was actually completed before concluding the timing. A simple REP MOVS should be at or near the top, especially on CPUs with ERMSB.
Yah, these benchmarks are irrelevant since the CPU executes instructions out of order. Majority of the time the cpu will continue executing assembly while a copy operation is ongoing.
Re: Going faster than memcpy
#6Conclusion
Stick to `std::memcpy`. It delivers great performance while also adapting to the hardware architecture, and makes no assumptions about the memory alignment.
----
So that's five minutes I'll never get back.
I'd make an exception for RISC-V machines with "RVV" vectors, where vectorised `memcpy` hasn't yet made it into the standard library and a simple ...
0000000000000000 :
0: 86aa mv a3,a0
0000000000000002 :
2: 00267757 vsetvli a4,a2,e8,m4,tu,mu
6: 02058007 vle8.v v0,(a1)
a: 95ba add a1,a1,a4
c: 8e19 sub a2,a2,a4
e: 02068027 vse8.v v0,(a3)
12: 96ba add a3,a3,a4
14: f67d bnez a2,2
16: 8082 ret
Re: Going faster than memcpy
#7Thought about zero-copy IPC recently. In order to avoid memcopy for the complete chain, I guess it would be best if the sender allocates its payload directly on the shared memory when it’s created. Is this a standard thing in such optimized IPC and which libraries offer this?
> I guess it would be best if the sender allocates its payload directly on the shared memory when it’s created.
On an SMP system yes. On a NUMA system it depends on your access patterns etc.
Re: Going faster than memcpy
#8I thought this was going to be about https://github.com/Blosc/c-blosc
Re: Going faster than memcpy
#9Thought about zero-copy IPC recently. In order to avoid memcopy for the complete chain, I guess it would be best if the sender allocates its payload directly on the shared memory when it’s created. Is this a standard thing in such optimized IPC and which libraries offer this?
I've been meaning to look at Iceoryx as a way to wrap this.
Pytorch multiprocessing queues work this way, but it is hard for the sender to ensure the data is already in shared memory, so it often has a copy. It is also common for buffers to not be reused, so that can end up a bottleneck, but it can, in principle, be limited by the rate of sending fds.
Re: Going faster than memcpy
#10It's not clear how the author controlled for HW caching. Without this, the results are, unfortunately, meaningless, even though some good work has been gone