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?
IPC considerations
-
- KVRist
- 241 posts since 29 Sep, 2007 from Europe
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
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
-
- KVRian
- Topic Starter
- 605 posts since 14 Mar, 2002
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?
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?
-
- KVRist
- 241 posts since 29 Sep, 2007 from Europe
The mapping is usually done at initialization time and not in a critical path. So from what I can see, it should not matter.TabSel wrote: 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?
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.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?
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.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?
Unfortunately it isn't available yet, hope I will get it done by this winter.Where can I find more info on shared resident memory, and/or your SDK?
//Daniel
-
- KVRAF
- 7579 posts since 17 Feb, 2005
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.
-
- KVRian
- Topic Starter
- 605 posts since 14 Mar, 2002
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...
-
- KVRist
- 241 posts since 29 Sep, 2007 from Europe
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.TabSel wrote: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...
Jack has its source code published so you can download that and see what it does.
//Daniel