Ich arbeite an etwas Forschungscode, der scipy.optimize.leastsq
verwendet, um eine Funktion zu optimieren. Dies geschieht ungefähr 18 mal pro Iteration, also würde ich gerne lostsq parallel aufrufen, um die Laufzeit zu reduzieren. Dies sollte kein Problem sein, da die Optimierungen fast vollständig getrennt sind, so dass sehr wenig Synchronisation erforderlich ist. Ich habe kürzlich über multiprocessing.pool.ThreadPool
herausgefunden, was mir erlauben würde, dies zu tun, ohne den Shared Memory explizit einzurichten (ein Schmerz, da die meisten meiner Daten in NumPy-Arrays sind). Also habe ich meinen Code etwas neu geschrieben, in der Hoffnung, dass es funktioniert, aber es wirft einen seltsamen Fehler auf: SystemError: null argument to internal routine
. Parallelität mit SciPy.optimize
Das Folgende ist eine Vereinfachung meiner Code:
def optfunc(id):
def errfunc(x):
return somedata[id] - somefunc(x)
lock.acquire()
x0 = numpy.copy(currentx[id])
lock.release()
result = scipy.optimize.leastsq(errfunc, x0)
lock.acquire()
currentx[id] = result
lock.release()
ThreadPool(processes=8).map(optfunc, range(idcount))
Dies sollte funktionieren, es sei denn, scipy.optimize.leastsq
nicht THREAD ist. Also habe ich versucht, eine Sperre um scipy.optimize.leastsq
zu setzen; Und siehe da, es funktioniert. Die Prozessorauslastung bleibt jedoch bei 100% hängen, was für mich nutzlos ist.
Meine Frage ist dann, was kann ich dagegen tun? Ich glaube, meine Optionen sind:
- Finden Sie eine Thread-sichere Implementierung von LM
- Versuchen Prozesse mit nicht-Threads (ich glaube nicht, das würde einen Unterschied machen)
Jede Hilfe oder Vorschläge würden sehr geschätzt werden.
Verwenden Sie Windows? Es gibt ein bekanntes Problem mit Threading in optimize.leastsq unter Windows: http://projects.scipy.org/scipy/ticket/1117. –
Hmm, interessant das ist nicht gekommen, als ich gesucht habe. Ich benutze Ubuntu, aber vielleicht betrifft es beide Betriebssysteme. – Steve