Schnelleres Sampling der Kernel-Schätzung

8

Hier ist ein MWE eines viel größeren Codes, den ich verwende. Im Grunde führt es eine Monte-Carlo-Integration über eine KDE-Kernel-Dichte-Schätzung durch ( ) für alle Werte unterhalb einer bestimmten Schwelle (die Integrationsmethode wurde bei dieser Frage vorgeschlagen. BTW: Integriere 2D-Kerndichte-Schätzung ).

%Vor%

Die Ausgabe sieht ungefähr so ​​aus:

%Vor%

was eindeutig bedeutet, dass der Aufruf filter / sample fast die ganze Zeit in Anspruch nimmt, die der Code zum Ausführen benötigt. Ich muss diesen Codeblock mehrere tausend Mal iterativ ausführen, so dass es ziemlich zeitaufwändig werden kann.

Gibt es eine Möglichkeit, den Filter- / Sampling-Prozess zu beschleunigen?

Hinzufügen

Hier ist ein etwas realistischerer MWE meines tatsächlichen Codes mit Ophions Multi-Threading-Lösung geschrieben:

%Vor%

Die von Ophion vorgestellte Lösung funktioniert großartig mit dem ursprünglichen Code, den ich vorgestellt habe, aber sie schlägt mit dem folgenden Fehler in dieser Version fehl:

%Vor%

Ich habe versucht, die Funktion calc_kernel zu verschieben, da eine der Antworten in dieser Frage Multiprocessing: Wie wird Pool.map für eine in einer Klasse definierte Funktion verwendet? gibt an, dass " die Funktion, die Sie map () geben, über ein zugreifbar sein muss Import Ihres Moduls "; aber ich kann immer noch nicht, dass dieser Code funktioniert.

Jede Hilfe wird sehr geschätzt.

Add 2

Implementierung von Ophions Vorschlag, um die Funktion calc_kernel zu entfernen und einfach:

zu verwenden %Vor%

funktioniert, um die PicklingError loszuwerden, aber jetzt sehe ich, dass wenn ich ein initiales m_list von etwas mehr als etwa 62-63 Elementen erstelle, bekomme ich diesen Fehler:

%Vor%

Da meine tatsächliche Liste in meiner tatsächlichen Implementierung dieses Codes bis zu 2000 Elemente enthalten kann, macht dieses Problem den Code unbrauchbar. Zeile 38 ist diese:

%Vor%

Offensichtlich hat es etwas mit der Anzahl der Kerne zu tun, die ich benutze?

Diese Frage "Kann einen neuen Thread-Fehler nicht starten" in Python schlägt vor:

%Vor%

um die Anzahl der Threads zu prüfen, die ich bei diesem Fehler führe. Ich habe überprüft, und es stürzt immer ab, wenn es 374 threads erreicht. Wie kann ich dieses Problem umgehen?

Hier ist die neue Frage, die sich mit dieser letzten Ausgabe beschäftigt: Threadfehler: kann nicht gestartet werden neuer Thread

    
Gabriel 30.08.2013, 17:52
quelle

2 Antworten

4

Der einfachste Weg, dies zu beschleunigen, ist die Parallelisierung von kernel(sample) :

Nehmen Sie dieses Codefragment:

%Vor%

Ändern Sie dies, um multiprocessing :

zu verwenden %Vor%

Überprüfen Sie, dass sie dieselbe Antwort zurückgeben:

%Vor%

Eine 3,9fache Verbesserung bei 4 Kernen. Ich bin mir nicht sicher, auf was Sie das anwenden, aber nach etwa 6 Prozessoren ist die Größe Ihres Input-Arrays nicht groß genug, um beträchtliche Gewinne zu erzielen. Zum Beispiel mit 20 Prozessoren ist es nur etwa 5,8x schneller.

    
Daniel 02.09.2013, 14:10
quelle
2

Der Anspruch in den Kommentaren dieses Artikels (Link unten) ist

  

"SciPy's gaussian_kde verwendet keine FFT, während es eine statsmodels-Implementierung gibt, die"

... was eine mögliche Ursache für die beobachtete schlechte Leistung ist. Es wird berichtet, Größenordnungen Verbesserung mit FFT. Siehe @ jseabolds Antwort.

Ссылка

Haftungsausschluss: Ich habe keine Erfahrung mit statsmodels oder scipy.

    
Glenn 02.09.2013 14:27
quelle