Going faster than memcpy • Hacker News Board

Re: Going faster than memcpy

#81

Post by CyberDildonics » Wed, Aug 13, 2025, 1:11 PM UTC

JonChesterfield wrote: post #80

CyberDildonics wrote: post #62

Earlier quoted context omitted.

I thought memcpy would have launched some sort of built-in mechanism Where did you get this impression?

I'd expect memcpy calls to turn into builtin_memcpy and then into raw loads/stores for known small N and a call into compiler-rt for unknown or large N. If it doesn't, patches to do that for your architecture are likely appreciated.

Calling a function with 'builtin' in the name doesn't mean it's embedded in the CPU itself to run concurrently which I think is what they thought might exist.

Re: Going faster than memcpy

#82

Post by elBoberido » Fri, Aug 15, 2025, 3:28 PM UTC

6keZbCECT2uB wrote: post #9

waschl wrote: post #2

Thought 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.

Btw, with the next release iceoryx2 will have Python bindings. They are already on main and we will make it available via PIP. This should make it easier to use with Pytorch.

Re: Going faster than memcpy

#83

Post by penguin_booze » Sun, Aug 24, 2025, 8:20 AM UTC

davrosthedalek wrote: post #34

> Since the loop copies data pointer by pointer, it can handle the case of overlapping data. I don't think this loop does the right thing if destination points somewhere into source. It will start overwriting the non-copied parts of source.

It'll indeed. Copying data pointer-by-pointer has nothing to do with overlaps. One should iterate backwards to deal with overlapping.