How much is the performance impact difference on

Running multiple processes, each with its own named shared memory mapped file read/write and one process which maps all of these named smm files

Versus

Running one process, creating multiple threads, with only one memory mapped file shared by the threads and another process which which maps the one named smm file.

I'm talking about multiple server processes which each host a different ASIO device, sharing buffers with one client process versus a single server process which hosts multiple asio devices (which is quite tricky to achieve) and one client process.

I'm just interested in the performance difference of the two different process/thread/memory mapping approaches... Has anybody experience to share?

Assuming this is on Windows..

You need to synchronize access to the MMF for all the threads (or processes) that want to access it. As more threads need to access the resouce, this will introduce latency.

If the question is, does executing multiple processes vs multiple threads generally give you a performance gain, the answer is no.

Although MMF are known to be the best IPC mechanism performance wise, they are not necessarily suitable for audio software especially because the memory can be paged out, causing a hard pagefault when the memory is touched. Latency which can result in an audio dropout.

The best way to do IPC latency wise is to have shared resident memory. This is not easy to achieve and requires the backing of a kernel driver. I am working on a SDK which exposes this functionality to application level programmers.


//Daniel

Windows, yes.

Assuming that the kernel needs some time to map shared memory mapped files into the process space, I think mapping multiple shared memory mapped files into one process space takes longer? So it would be faster to have ONE process sharing ONE SMMF with another, than having multiple processes sharing multiple individual SMMF with one other process?

Take for example steinbergs asio multi server / asio client. These two processes communicate via a SMMF, I assum? Or Rewire? How does Rewire IPC work then, when SMMF is not suitable for Realtime applications?

Where can I find more info on shared resident memory, and/or your SDK?

The mapping is usually done at initialization time and not in a critical path. So from what I can see, it should not matter.



I cannot answer that question because I have no insight in your design or even know what purpose your solution serves. In general terms, as more threads need to access your shared data, the more the locking will put weight in.



I don't know what they use. I did not say that MMF are unsuitable for real-time applications per se, but there is the problem of hard pagefaults that needs to be taken care of as the memory is backed by a file on disk.



Unfortunately it isn't available yet, hope I will get it done by this winter.

//Daniel

Thanks anyway! Useful information!

Whatever you decide, it should be small, data-wise. This will minimize the chances of a hard fault. With today's CPUs, the cache size has increased very well, but audio data is still large in comparison. Also, the system using IPC should be optimized for the DAW only, to give it more paging priority.

Thanks. Just a question: how do "others" share data between processes? I mean, a multiclient asio driver for example, or rewire, VEPro local, jackaudio server etc...? These aren't necessarily kernel drivers...

I opened the Rewire DLL with Dependency Walker and see it imports CreateFileMapping, MapViewOfFile among few other functions so I would assume it uses MMF.

Jack has its source code published so you can download that and see what it does.

//Daniel

Another consideration is how to 'address' the processes. They need to be able to find each other and recall state through a shutdown.