<div dir="ltr"><span style="font-size:10pt">On Thu, Sep 19, 2013 at 5:58 PM, Antony Lee <<a href="mailto:antony.lee@berkeley.edu">antony.lee@berkeley.edu</a>> wrote:</span><br>><br>> Henry: thanks a lot, that would be very appreciated regardless of whether I end up using it in this specific project or not.<br>

> Other replies below.<br>><br>> Antony<br>><br>> 2013/9/19 Robert Kern <<a href="mailto:robert.kern@gmail.com">robert.kern@gmail.com</a>><br>>><br>>> On Thu, Sep 19, 2013 at 2:40 AM, Antony Lee <<a href="mailto:antony.lee@berkeley.edu">antony.lee@berkeley.edu</a>> wrote:<br>

>> ><br>>> > Thanks, I didn't know that multiprocessing Managers could be used with processes not started by multiprocessing itself...  I will give them a try.<br>>> > I just need to compute FFTs, but speed is a real issue for me (I am using the results for real-time feedback).<br>

>><br>>> I am pretty sure that the overhead of communicating a large array from one process to another will vastly overwhelm any speed gains you get by using pyFFTW over numpy.fft.<br>><br>> I would have hoped that the large arrays are simply written (from the beginning) to shared memory (what multiprocessing.sharedctypes.Array seems to do(?)) and that interprocess communication would be cheap enough (but what do I know about that).<br>

<br><div>It certainly won't be automatic just by passing a numpy array to the manager. You will have to manually create the shared memory, pass its handle to the other process, and copy into it. But even the copy of the array may overwhelm the speed gains between PyFFTW and numpy.fft. If you can set it up such that the subprocess owns the shared memory for both input and output and the GUI process always writes into the input shared array directly and reads out the output shared array, then might work out okay. This works well when the inputs/outputs are always the same size.</div>

<div><br>--<br>Robert Kern<br></div></div>