Scikit-learn: GridSearchCV friert unbegrenzt ein, wenn Multithreading aktiviert ist (dh w / n_jobs! = 1).

Haben Sie ständig Probleme auf dieser Plattform?

In Bezug auf Multithreading: Es gibt einige Schätzer, für die Multithreading wahrscheinlich erhebliche Gewinne bringt, bei denen der größte Teil der Arbeit in Numpy- oder Cython-Operationen ohne GIL ausgeführt wird. Wirklich, ich glaube nicht, dass dies viel bewertet wurde; backend='threading' ist eine ziemlich neue Sache.

Die eigentliche Frage ist: Was können wir noch tun, um das Problem zu identifizieren?

Welche Basisschätzer haben Sie zunächst in Betracht gezogen?

@jnothman Nach Plattform OSX 10.9.5? Wenn ja, dann ist es nicht das erste Mal, dass ich dieses Problem habe.

Ein möglicherweise wichtiges Detail, das ich zuvor ausgelassen habe, war, dass ich immer IPython-Notebooks verwende, wenn ich Probleme habe. Ich habe gerade einen Kernel für ein Notizbuch geladen. Wenn ich mit n_jobs! = 1 ein "Scoring" -Argument hinzufüge, bleibt GridSearchCV für immer hängen, aber wenn ich dieses Argument entferne, ist alles in Ordnung. Selbst wenn die von mir angegebene Bewertungsfunktion nur einen konstanten Gleitkommawert zurückgibt, friert sie immer noch ein (macht aber genau das, was Sie mit n_jobs = 1 erwarten würden).

Betreff: Threading ist gut zu hören, also wäre diese Option für GridSearchCV vielleicht tatsächlich sinnvoll.

Was die Schätzer angeht, mit denen ich Probleme habe, bin ich mir nicht sicher, ob ich sie eingrenzen kann. Normalerweise versuche ich so viele wie möglich, um hier einige nützliche Informationen für Sie zu erhalten. Ich habe jedoch nur überprüft, ob ich die oben genannten Bedingungen mit jedem Schätzer reproduzieren kann, und festgestellt, dass ich dies in allen Fällen tun kann (oder zumindest versucht habe) LogisticRegression, SGDClassifier, GBRT und RF).

Ich würde gerne alles tun, um etwas mehr zu bieten, obwohl ich nicht weiß, welcher Kontext für solche Multithreading-Probleme im Allgemeinen am hilfreichsten ist. Hast du irgendwelche Vorschläge für mich?

Verwenden Sie numpy, das mit dem Accelerate-Framework verknüpft ist?

Nein, es sei denn, ich vermisse etwas. Ich dachte, dass sich die installierte Numpy-Version ändert, wenn Sie das tun, oder zumindest, dass das Accelerate-Paket vorhanden wäre:

(research3.4) eczech $ pip freeze | grep numpy
numpy == 1.9.2
(research3.4) eczech $ conda update beschleunigen
Fehler: Das Paket 'Accelerate' ist nicht in /Users/eczech/anaconda/envs/research3.4 installiert

Verzeihen Sie meine Unwissenheit, dass ich das nicht mit 100% iger Sicherheit beantworten kann, aber ich habe auf keinen Fall absichtlich etwas unternommen, um es zu installieren.

Conda Accelerate ist nicht dasselbe wie Apple Accelerate:
http://docs.continuum.io/accelerate/index
https://developer.apple.com/library/mac/documentation/Accelerate/Reference/AccelerateFWRef/

Conda Accelerate ist eine MKL-beschleunigte Version von Paketen. Apple Accelerate ist die Alternative zu MKL.

Können Sie uns numpy.__config__.show() ?

Multiprocessing funktioniert nicht mit Accelerate IIRC. ping @ogrisel

bestimmt:

np. config .show ()
atlas_3_10_blas_threads_info:
NICHT VERFÜGBAR
atlas_info:
NICHT VERFÜGBAR
atlas_3_10_info:
NICHT VERFÜGBAR
atlas_threads_info:
NICHT VERFÜGBAR
atlas_3_10_blas_info:
NICHT VERFÜGBAR
blas_opt_info:
extra_compile_args = ['-msse3', '-DAPPLE_ACCELERATE_SGEMV_PATCH', '-I / System / Library / Frameworks / vecLib.framework / Headers']
extra_link_args = ['-Wl, -framework', '-Wl, Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
lapack_mkl_info:
NICHT VERFÜGBAR
atlas_blas_info:
NICHT VERFÜGBAR
mkl_info:
NICHT VERFÜGBAR
lapack_opt_info:
extra_compile_args = ['-msse3', '-DAPPLE_ACCELERATE_SGEMV_PATCH']
extra_link_args = ['-Wl, -framework', '-Wl, Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
blas_mkl_info:
NICHT VERFÜGBAR
atlas_3_10_threads_info:
NICHT VERFÜGBAR
openblas_info:
NICHT VERFÜGBAR
openblas_lapack_info:
NICHT VERFÜGBAR
atlas_blas_threads_info:
NICHT VERFÜGBAR

Ja, das ist ein bekanntes Problem, das ich im Issue-Tracker nicht finden kann. Beschleunigen funktioniert nicht mit Multiprocessing.

Ich bin ein bisschen verwirrt. Das Threading-Backend macht nur etwas, wenn die GIL freigegeben wird, oder?

Gotcha, weißt du, wie ich dann Numpy wieder aufbauen soll? Sollte ich es einfach per Pip installieren, anstatt das Conda-Paket dafür zu verwenden? Oder wäre es besser für mich, aus dem Quellcode zu erstellen und sicherzustellen, dass diese Apple Accelerate-Argumente nicht vorhanden sind?

Klingt so, als wäre dies ein bisschen ein Nichtstarter eines Problems, unabhängig davon. Nah dran, wenn es nur ein totes Pferd schlägt.

Wenn Sie die Conda beschleunigen können, würde es funktionieren;)

Vielleicht könnten wir versuchen, joblib zu retten?

Ah toll, Kontinuum muss Apfel dafür bezahlt haben, haha.

Hast du irgendwelche $ 0 Vorschläge? Und danke für den Einblick so oder so.

Oh, und ich weiß auch, dass dies schon einmal gefragt wurde, aber ist die Tatsache, dass ich dieses Problem nur auf meiner aktuellen Plattform habe, wenn ich eine benutzerdefinierte Bewertungsfunktion verwende, etwas weiter zu tun? Für mein Leben kann ich nicht sehen, was angesichts des Quellcodes grid_search.py ​​möglicherweise problematisch sein könnte, aber könnte es etwas mit dem Beizen der benutzerdefinierten Funktion zu tun haben?

Und etwas unabhängig davon erinnerte ich mich nur daran, dass ich in der Vergangenheit auch versucht habe, dies zu umgehen, indem ich eine modifizierte Version von GridSearchCV erstellt habe, die stattdessen das parallele IPython-Backend verwendet. Diese Lösung funktionierte einwandfrei, war jedoch ein wenig mühsam zu verwenden, da benutzerdefinierte Klassen und Funktionen auf dem Python-Pfad und nicht in den Notizbüchern selbst verfügbar sein mussten. Wenn es jedoch keine anderen besseren Optionen gibt, hat diese möglicherweise einige Beine.

Sie können gegen Atlas verlinken, aber das wird langsamer [Apfel] beschleunigen, denkt.
Vielleicht gibt es eine kostenlose MKL-verknüpfte Nummer für OS X? Es gibt eine für Fenster.

[Wenn Sie ein Akademiker sind, ist die Kontinuumsbeschleunigung übrigens kostenlos]

Ich bin mir ziemlich sicher, dass dies nichts mit der Verwendung einer benutzerdefinierten Bewertungsfunktion zu tun hat.
Können Sie in sich geschlossene Sniplets geben, die mit einer benutzerdefinierten Bewertungsfunktion brechen, aber nicht ohne?

Möglicherweise ist die Tatsache der benutzerdefinierten Bewertungsfunktion relevant (z. B. können Beizprobleme oder verschachtelte Parallelität relevant sein). Könnten wir den Code sehen?

Oder meinst du nur eine Standardmetrik mit make_scorer ?

Natürlich ist hier ein relevanter Teil und es sieht so aus, als ob die Dinge mit make_scorer in Ordnung sind, aber nicht mit einer benutzerdefinierten Funktion:

from sklearn.linear_model import LogisticRegression
from sklearn.grid_search import GridSearchCV
from sklearn.cross_validation import StratifiedKFold
from sklearn.metrics import average_precision_score, make_scorer
import functools

res = []
clfs = []

for response in responses:
    X, y = d_in[features], d_in[response]
    for i, (train, test) in enumerate(StratifiedKFold(y, 5)):
        X_train, y_train, X_test, y_test = X.iloc[train], y.iloc[train], X.iloc[test], y.iloc[test]
        clf = LogisticRegression(penalty='l1')
        grid = {
            'class_weight': [{0: 1, 1: 10}, {0: 1, 1: 100}, {0: 1, 1: 1000}],
            'C': np.logspace(-3, 0, num=4)
        }

        # Using make_scorer doesn't cause any issues
        # clf = GridSearchCV(clf, grid, cv=StratifiedKFold(y_train, 3),  
        #                    scoring=make_scorer(average_precision_score), n_jobs=-1)

        # This however is a problem:
        def avg_prec_score(estimator, X, y):
            return average_precision_score(y, estimator.predict_proba(X)[:, 1])
        clf = GridSearchCV(clf, grid, cv=StratifiedKFold(y_train, 5),  
                           scoring=avg_prec_score, n_jobs=-1)

        clf = clf.fit(X_train, y_train)
        print('Best parameters for response {} inferred in fold {}: {}'.format(response, i, clf.best_params_))

        y_pred = clf.predict(X_test)
        y_proba = clf.predict_proba(X_test)

        clfs.append((response, i, clf))
        res.append(pd.DataFrame({
            'y_pred': y_pred, 
            'y_actual': y_test, 
            'y_proba': y_proba[:,1],
            'response': np.repeat(response, len(y_pred))
        }))

res = functools.reduce(pd.DataFrame.append, res)
res.head()

Ich werde an einer in sich geschlossenen Version arbeiten, die eine Version der Daten enthält, die ich auch verwende (aber es wird länger dauern). In der Zwischenzeit klingt das Beizen dieser benutzerdefinierten Funktionen nach einem guten Hinweis - ich habe es mehrmals wiederholt, um sicherzugehen, und es hängt 100% der Zeit mit einer benutzerdefinierten Funktion und 0% der Zeit mit make_scorer mit Einige bekannte, importierte Metrikfunktionen.

Und ist das in main (dh das Top-Level-Skript wird interpretiert) oder ein
Modul importiert?

Am 15. August 2015 um 23:37 schrieb Eric Czech [email protected] :

Natürlich ist hier ein relevanter Teil und es sieht so aus, als ob die Dinge in Ordnung sind
mit make_scorer aber nicht mit einer benutzerdefinierten Funktion:

aus sklearn.linear_model importieren LogisticRegression von sklearn.grid_search importieren GridSearchCV von sklearn.cross_validation importieren StratifiedKFold von sklearn.metrics importieren durchschnittlicher_Präzisionswert, make_scorerimport functools

res = []
clfs = []
für die Antwort in den Antworten:
X, y = d_in [Merkmale], d_in [Antwort]
für i (Zug, Test) in Aufzählung (StratifiedKFold (y, 5)):
X_train, y_train, X_test, y_test = X.iloc [Zug], y.iloc [Zug], X.iloc [Test], y.iloc [Test]
clf = LogisticRegression (Strafe = 'l1')
Gitter = {
'class_weight': [{0: 1, 1: 10}, {0: 1, 1: 100}, {0: 1, 1: 1000}],
'C': np.logspace (-3, 0, num = 4)
}}

    # Using make_scorer doesn't cause any issues
    # clf = GridSearchCV(clf, grid, cv=StratifiedKFold(y_train, 3),
    #                    scoring=make_scorer(average_precision_score), n_jobs=-1)

    # This however is a problem:
    def avg_prec_score(estimator, X, y):
        return average_precision_score(y, estimator.predict_proba(X)[:, 1])
    clf = GridSearchCV(clf, grid, cv=StratifiedKFold(y_train, 5),
                       scoring=avg_prec_score, n_jobs=-1)

    clf = clf.fit(X_train, y_train)
    print('Best parameters for response {} inferred in fold {}: {}'.format(response, i, clf.best_params_))

    y_pred = clf.predict(X_test)
    y_proba = clf.predict_proba(X_test)

    clfs.append((response, i, clf))
    res.append(pd.DataFrame({
        'y_pred': y_pred,
        'y_actual': y_test,
        'y_proba': y_proba[:,1],
        'response': np.repeat(response, len(y_pred))
    }))

res = functools.reduce (pd.DataFrame.append, res)
res.head ()

Ich werde an einer eigenständigen Version arbeiten, die eine Version von enthält
Daten, die ich auch verwende (aber es wird länger dauern). In der Zwischenzeit jedoch
Das Beizen dieser benutzerdefinierten Funktionen klingt nach einem guten Vorsprung - ich habe es versucht
mehrmals nochmal um sicher zu sein und es hängt 100% der zeit mit einem custom
Funktion und 0% der Zeit bei Verwendung von make_scorer mit einigen bekannten,
importierte Metrikfunktion.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/scikit-learn/scikit-learn/issues/5115#issuecomment -131376298
.

Oh, es ist ipynb. Hmmm interessant. Ja, Beizen könnte ein Problem sein ..?

Am 15. August 2015 um 23:51 Uhr tritt Joel Nothman an. [email protected] schrieb:

Und ist das in main (dh das Skript der obersten Ebene wird interpretiert) oder
ein importiertes Modul?

Am 15. August 2015 um 23:37 schrieb Eric Czech [email protected] :

Natürlich ist hier ein relevanter Teil und es sieht so aus, als ob die Dinge in Ordnung sind
mit make_scorer aber nicht mit einer benutzerdefinierten Funktion:

aus sklearn.linear_model importieren LogisticRegression von sklearn.grid_search importieren GridSearchCV von sklearn.cross_validation importieren StratifiedKFold von sklearn.metrics importieren durchschnittlicher_Präzisionswert, make_scorerimport functools

res = []
clfs = []
für die Antwort in den Antworten:
X, y = d_in [Merkmale], d_in [Antwort]
für i (Zug, Test) in Aufzählung (StratifiedKFold (y, 5)):
X_train, y_train, X_test, y_test = X.iloc [Zug], y.iloc [Zug], X.iloc [Test], y.iloc [Test]
clf = LogisticRegression (Strafe = 'l1')
Gitter = {
'class_weight': [{0: 1, 1: 10}, {0: 1, 1: 100}, {0: 1, 1: 1000}],
'C': np.logspace (-3, 0, num = 4)
}}

    # Using make_scorer doesn't cause any issues
    # clf = GridSearchCV(clf, grid, cv=StratifiedKFold(y_train, 3),
    #                    scoring=make_scorer(average_precision_score), n_jobs=-1)

    # This however is a problem:
    def avg_prec_score(estimator, X, y):
        return average_precision_score(y, estimator.predict_proba(X)[:, 1])
    clf = GridSearchCV(clf, grid, cv=StratifiedKFold(y_train, 5),
                       scoring=avg_prec_score, n_jobs=-1)

    clf = clf.fit(X_train, y_train)
    print('Best parameters for response {} inferred in fold {}: {}'.format(response, i, clf.best_params_))

    y_pred = clf.predict(X_test)
    y_proba = clf.predict_proba(X_test)

    clfs.append((response, i, clf))
    res.append(pd.DataFrame({
        'y_pred': y_pred,
        'y_actual': y_test,
        'y_proba': y_proba[:,1],
        'response': np.repeat(response, len(y_pred))
    }))

res = functools.reduce (pd.DataFrame.append, res)
res.head ()

Ich werde an einer eigenständigen Version arbeiten, die eine Version von enthält
Daten, die ich auch verwende (aber es wird länger dauern). In der Zwischenzeit jedoch
Das Beizen dieser benutzerdefinierten Funktionen klingt nach einem guten Vorsprung - ich habe es versucht
mehrmals nochmal um sicher zu sein und es hängt 100% der zeit mit einem custom
Funktion und 0% der Zeit bei Verwendung von make_scorer mit einigen bekannten,
importierte Metrikfunktion.

- -
Antworte direkt auf diese E-Mail oder sieh sie dir auf GitHub an
https://github.com/scikit-learn/scikit-learn/issues/5115#issuecomment -131376298
.

Das steht in einem Notizbuch

Ich werde versuchen, es stattdessen von einem Modul zu importieren und zu sehen, wie das geht

Hmm, was weißt du, funktioniert gut, wenn es außerhalb des Notebooks definiert wird.

Ich habe im Wesentlichen den gleichen Code in Python 2.7 (ich brauchte eine ältere Bibliothek) sowie diesen Code in Python 3.4 und während ich das Problem in 2.7 habe, unabhängig davon, ob es sich um eine benutzerdefinierte Funktion oder etwas handelt, das make_scorer verwendet, habe ich Ich denke, das löst alle meine Probleme in der neueren Version, so dass ich nur mit Problemumgehungen in der alten leben kann.

Kann ich noch etwas tun, um herauszufinden, warum in einem Notizbuch definierte Beizfunktionen ein Problem darstellen könnten?

Nun, wir möchten verstehen:

• Ist das Beizen und Entpicken im Allgemeinen ein Problem für lokal definierte Funktionen auf dieser Plattform, oder stoßen wir auf einen bestimmten Haken?
• Warum hängt das Beizen, wenn es ein Problem ist, eher, als dass es eine Ausnahme auslöst? Könnten Sie bitte versuchen, Affen zu patchen oder ähnliches, um zu sehen, ob Sie den pickle.dumps(function) Check https://github.com/scikit-learn/scikit-learn/blob/master/sklearn/externals/joblib/parallel ersetzen pickle.loads(pickle.dumps(function)) führt zu einem Fehler? (Zur Erklärung ist dies eine Sicherheitsüberprüfung, um die Pickbarkeit zu gewährleisten, bevor die Mehrfachverarbeitung ausgeführt wird.)

@ogrisel könnte daran interessiert sein.

Nach dem, was ich unter Windows gesehen habe, haben Notebooks seltsame Wechselwirkungen mit Multiprocessing.

Haben Sie versucht, die im selben Notebook definierte Funktion nur zu beizen und zu entfernen?

Heute habe ich versehentlich diese https://pythonhosted.org/joblib/parallel.html#bad-Interaktion-von-Multiprocessing-und-Drittanbieter-Bibliotheken gesehen, ist es nicht verwandt?
Vielleicht sollten Sie einfach auf Python 3.4 oder neuer aktualisieren?

Entschuldigung, ich habe lange Ferien gemacht. Um Ihre Fragen zu beantworten:

1. re @jnothman : Ich habe pickle.loads(pickle.dumps(function)) in parallel.py und eine print-Anweisung danach eingefügt , um sicherzustellen, dass es sauber ausgeführt wird und es dort keine Probleme gab. Um klar zu sein, blieb GridSearchCV.fit, das vom Notizbuch aufgerufen wurde, wie zuvor unverändert hängen (mit Ausnahme der Druckanweisung, die ich hinzugefügt habe und die 16 Mal mit n_jobs = -1 angezeigt wurde).
2. re @amueller : Wenn ich dich richtig verstehe, habe ich so etwas ohne Probleme im Notizbuch ausgeführt:

def test_function(x):
    return x**2
pickle.loads(pickle.dumps(test_function))(3)
# 9

1. re @olologin : Ich bin am 3.4.3. Oder genauer gesagt: '3.4.3 | Continuum Analytics, Inc. | (Standard, 6. März 2015, 12:07:41) n [GCC 4.2.1 (Apple Inc. Build 5577)] '

Ich habe die obige Konversation nicht gelesen, möchte aber darauf hinweisen, dass dieser minimale Test unter dem Python 2.6-Build von Travis fehlschlägt, aber unter einer ähnlichen Konfiguration auf meinem PC bestanden wurde ... (was darauf hindeutet, dass er fehlschlägt, wenn n_jobs = -1 ist unter einem Single-Core-Rechner für alte Python / Joblib / Scipy-Versionen eingestellt?)

def test_cross_val_score_n_jobs():
    # n_jobs = -1 seems to hang in older versions of joblib/python2.6
    # See issue 5115
    cross_val_score(LinearSVC(), digits.data, digits.target, cv=KFold(3),
                    scoring="precision_macro", n_jobs=-1)

+1 für dieses Problem, gerne geben Sie Details, wenn es helfen würde

@ eric-czech Wenn Sie sich unter Python 3.4 oder 3.5 befinden, versuchen Sie bitte, die folgende Umgebungsvariable festzulegen und starten Sie dann Ihr Python-Programm neu:

export JOBLIB_START_METHOD="forkserver"

wie in den joblib-Dokumenten erläutert. Der Forkserver is-Modus ist standardmäßig nicht aktiviert, da er interaktiv definierte Funktionen unterbricht.

Haben Sie das gleiche Problem unter OS X 10.11.4 und Ubuntu 14.04 mit der neuesten installierten Software.

# Metrics
B_R = 10.0

def raw_TPR(y_true, y_pred):
    return np.sum((y_true == 1) & (y_pred == y_true))

def raw_FPR(y_true, y_pred):
    return np.sum((y_true == 0) & (y_pred != y_true))

def AMS(y_true, y_pred):
    print("Hello")
    tpr = raw_TPR(y_true, y_pred)
    fpr = raw_FPR(y_true, y_pred)
    score = np.sqrt(2 * ((tpr + fpr + B_R) * np.log(1 + tpr / (fpr + B_R))) - tpr)
    return score


# Grid search

param_grid = {
    "max_depth":[6, 10],
    "learning_rate":[0.01, 0.5],
    "subsample":[0, 1],
    "min_child_weight":[0.1, 1],
    "colsample_bytree":[0.1, 1],
    "base_score":[0.1, 1],
    "gamma":[0.5, 3.5]
}

scorer = make_scorer(AMS, greater_is_better=True)


clf = XGBClassifier()
gridclf = GridSearchCV(clf, param_grid, scorer, n_jobs=-1, verbose=2)
gridclf.fit(X_train, y_train)

Tatsächlich friert dieser Code nicht nur ein, wenn n_jobs=1 .

Dies sollte jetzt standardmäßig unter Python 3 funktionieren und unter Python 2 ein Wontfix sein, richtig @ogrisel ? Sollen wir schließen?

Wenn es stillschweigend in Python 2 hängt, ohne eine Warnung oder einen Fehler auszulösen ("n_jobs> 1 wird in Python 2 nicht unterstützt"), ist dies nicht akzeptabel. können wir einen Fehler werfen?

@amueller unter Python 3 können Sie https://github.com/scikit-learn/scikit-learn/issues/5115#issuecomment -187683383 folgen, um das Problem zu umgehen, dh es funktioniert standardmäßig nicht einmal unter Python 3.

Ich bin mir nicht sicher, ob wir schließen sollen, da das ursprüngliche OP zu sagen schien, dass das Setzen der Joblib start_method auf forkserver nicht immer funktioniert hat ...

Übrigens ist der xgboost ein bekannter, siehe https://github.com/scikit-learn/scikit-learn/issues/6627#issuecomment -206351138.

Bearbeiten: Die folgende Änderung behebt möglicherweise keine Probleme. Es gab eine nicht verwandte Änderung, die ich auch an der Art und Weise vorgenommen habe, wie ich mit Multiprozessen mit Pathos umgegangen bin, was meine eigentliche Lösung gewesen sein könnte.

Schnelle Lösung:
np.random.seed(0)

Erläuterung:
Ich war auch auf dieses Problem gestoßen , am auto_ml . Das erste (2?) Mal, als ich GridSearchCV ausführte, war es in Ordnung, aber nachfolgende Läufe hingen ohne Fehler.

Ich habe in jedem meiner Tests nur np.random.seed(0) , um die Reproduzierbarkeit zu gewährleisten und mir gleichzeitig die Flexibilität zu geben, die Tests im Laufe der Zeit neu zu ordnen, ohne die Zufälligkeit zu beeinträchtigen. Sobald ich das tat, funktionierten alle Tests, die am GSCV-Fehler hingen, wieder.

def test_name():
    np.random.seed(0)
    test_code_involving_gscv_here

hoffe das hilft beim debuggen!

Entwicklungsumgebung:
Mac OS X (Sierra)
Python 2.7
Aktuelle Versionen von Bibliotheken.

@ClimbsRocks gut, es ist wahrscheinlich ein Fehler in Ihren Schätzern. Lassen Sie uns wissen, wenn Sie ein reproduzierbares Beispiel haben;)

@amueller : guter

Ich denke, es war wahrscheinlich ein Problem bei der Verwendung der Parallelisierung von GSCV, wenn ich auch die Parallelisierung von Pathos in anderen Teilen des Programms verwende. Das ist die einzige andere verwandte Sache, die ich in der letzten Woche oder so geändert habe.

Ich habe seitdem umgestaltet, um ihren Multiprozessor-Pool gründlicher zu schließen und zu öffnen.

Was mich dazu bringt, dass es nicht nur ein Fehler in einem der Schätzer war, ist, dass beim Erstellen der Testsuite jeder der Tests einzeln ausgeführt und bestanden wurde. Erst als ich mehrere Tests im selben Durchgang durchführte, hing alles von GSCV ab, und es begann zu hängen.

Der frühere Kommentar wurde bearbeitet, um diese Unsicherheit festzustellen.

Wenn Sie joblib mit einer anderen Parallelisierung kombinieren, ist es sehr wahrscheinlich, dass es abstürzt, und Sie sollten das nicht versuchen.

Es tut mir leid, diesen Thread zu aktualisieren, aber ich stoße auch auf dieses Problem.
Ich habe einen Python 3.5-Kernel erstellt und die Startmethode für die Jobbibliothek für den Forkserver definiert, aber ich habe immer noch das Problem.

Tatsächlich funktioniert es nicht einmal mit n_jobs = 1. Ich sehe, dass es bis auf den letzten Parameter berechnet wird.

Gibt es Neuigkeiten?

Tatsächlich funktioniert es nicht einmal mit n_jobs = 1. Ich sehe, dass es bis auf den letzten Parameter berechnet wird.

Dies ist seltsam und hängt höchstwahrscheinlich nicht mit diesem Problem zusammen (das ist ungefähr n_jobs != 1 ). Der beste Weg, um ein gutes Feedback zu erhalten, besteht darin, ein separates Problem mit einem eigenständigen Snippet zu eröffnen, das das Problem reproduziert.

Ich bin mir ziemlich sicher, dass ich selbst auf dieses Problem stoße. Nachdem ich viele Kombinationen ausprobiert habe, friert alles, was ich mit n_jobs> 1 mache, nach ein paar Falten einfach ein. Ich bin auf einem Ubuntu Linux-Laptop mit sklearn = 0.19.0, daher ist dies eine andere Konfiguration als bei anderen, die ich gelesen habe. Hier ist der "beleidigende" Code:

import xgboost as xgb
from sklearn.model_selection import GridSearchCV
cv_params = {'max_depth': [3,5,7], 'min_child_weight': [1,3,5]}

ind_params = {'learning_rate': 0.1, 'n_estimators': 1000, 'seed':0, 'subsample': 0.8, 'colsample_bytree': 0.8,  'objective': 'binary:logistic'}
optimized_XGB = GridSearchCV(xgb.XGBClassifier(**ind_params), 
                            cv_params, scoring = 'roc_auc', cv = 5, n_jobs = 1, verbose=2) 
optimized_XGB.fit(xgboost_train, label_train,eval_metric='auc')

Eines der interessanten Dinge ist, dass ich beim Importieren von xgboost eine Verfallswarnung für GridSearchCV erhalte, als würde es nicht aus model_selection importiert. Ich bin jedoch auf xgboost 0.62 und beim Betrachten ihres Repositorys sieht es so aus, als würden sie das richtige GridSearchCV importieren. Um es klar auszudrücken, ist die Abwertungswarnung nicht das Problem, das mich betrifft, sondern das vorliegende: das Einfrieren der Ausführung mit n_jobs> 1. Nur darauf hinweisen, falls es helfen könnte.

Können Sie Daten bereitstellen, um das Problem zu replizieren?

Am 24. August 2017 um 20:29 Uhr, Xavier Amatriain [email protected]
schrieb:

Ich bin mir ziemlich sicher, dass ich selbst auf dieses Problem stoße. Nachdem ich viele ausprobiert hatte
Kombinationen, alles was ich mit n_jobs> 1 mache friert einfach nach ein paar ein
Falten. Ich bin auf einem Ubuntu Linux Laptop mit sklearn = 0.19.0, also ist dies ein
andere Konfiguration als andere, die ich gelesen habe. Hier ist das
"beleidigender" Code:

`importiere xgboost als xgb
aus sklearn.model_selection importieren Sie GridSearchCV
cv_params = {'max_depth': [3,5,7], 'min_child_weight': [1,3,5]}

ind_params = {'learning_rate': 0.1, 'n_estimators': 1000, 'seed': 0,
'subsample': 0.8, 'colsample_bytree': 0.8, 'Objective': ' binary: logistic '}
optimized_XGB = GridSearchCV (xgb.XGBClassifier (** ind_params),
cv_params, Scoring = 'roc_auc', cv = 5, n_jobs = 1, verbose = 2)
optimized_XGB.fit (xgboost_train, label_train, eval_metric = 'auc') `

Eines der interessanten Dinge ist, dass ich beim Importieren von xgboost eine bekomme
Verfallswarnung auf GridSearchCV, als würde es nicht aus importieren
model_selection. Allerdings bin ich auf xgboost 0.62 und schaue mir ihre an
Es sieht so aus, als würden sie das richtige GridSearchCV importieren. Sein
Klar, die Abwertungswarnung ist nicht das Problem, das mich betrifft, sondern
die zur Hand: die Ausführung friert mit n_jobs> 1 ein. Ich weise nur darauf hin
Fall könnte es helfen.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/scikit-learn/scikit-learn/issues/5115#issuecomment-324597686 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAEz66DbfTlnU_-dcxLKa5zkrcZ-0qVOks5sbVCmgaJpZM4FqYlN
.

Natürlich können Sie die genauen Dateien, die ich verwende, herunterladen von:
https://xamat.github.io/xgboost_train.csv
https://xamat.github.io/label_train.csv

HTTP404

Entschuldigung, es gab einen Fehler im ersten Link, der jetzt behoben werden sollte. Der 2. sollte auch ok sein, ich habe gerade nachgesehen.

Bekanntes Problem mit xgboost, siehe https://github.com/scikit-learn/scikit-learn/issues/6627#issuecomment -206351138.

Zu Ihrer Information, das

Ist das noch ein Fehler? Ich habe das gleiche Problem mit den Standardeinstellungen (n_jobs = 1) sowie mit pre_dispatch = 1 unter Verwendung eines RandomForestClassifier mit 80 Parameterkombinationen und ShuffleSplit CV (n = 20).

Es hängt auch für eine Pipeline ( SelectKBest(score_func=mutual_info_classif, k=10) gefolgt von RandomForestClassifier ), sowohl in der neuesten Version als auch in der Entwicklungsversion.

Lassen Sie mich wissen, ob Sie eine Problemumgehung oder andere Methoden zur Modellauswahl gefunden haben, die zuverlässig funktionieren. Denken Sie daran, scikit-optimize auszuprobieren.

Meinst du n_jobs = 1 oder ist es ein Tippfehler? In diesem Problem geht es um n_jobs! = 1.

Der beste Weg, um qualitativ hochwertiges Feedback zu erhalten, besteht darin, das Problem zu reproduzieren. Bitte öffnen Sie in diesem Fall ein separates Problem, wenn das Problem tatsächlich bei n_jobs = 1 liegt.

Ich habe geschrieben, was ich meinte, nämlich "Multithreading aktiviert".
n_jobs! = 1 wie in 'ungleich 1'. Entsprechend ist n_jobs> 1. Zum Beispiel n_jobs = 4

Wollen Sie damit sagen, dass Sie das Einfrieren für n_jobs = 4 nicht wiederholen können?

In diesem Fall werde ich innerhalb eines Monats einen Testfall bereitstellen (ich wechsle zu einer neuen Maschine.)

Am 12. September 2017 um 7:10 Uhr schrieb Loïc Estève < [email protected] [email protected] >:

Meinst du n_jobs = 1 oder ist es ein Tippfehler? In diesem Problem geht es um n_jobs! = 1.

Der beste Weg, um qualitativ hochwertiges Feedback zu erhalten, besteht darin, das Problem zu reproduzieren. Bitte öffnen Sie in diesem Fall ein separates Problem, wenn das Problem tatsächlich bei n_jobs = 1 liegt.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/scikit-learn/scikit-learn/issues/5115#issuecomment-328864498 an oder schalten Sie den Thread https://github.com/notifications/unsubscribe- stumm

@smcinerney bist du @raamana? Ich denke, @lesteve hat @raamana geantwortet, der n_jobs=1 , was mit diesem Problem nichts zu tun zu haben scheint.

Oh sorry, nein ich bin nicht @raamana. Ja, @ raamanas Problem ist anders (aber wahrscheinlich aufgrund des gleichen Codes)

Am 12. September 2017 um 9:23 Uhr schrieb Andreas Mueller < [email protected] [email protected] >:

@smcinerney https://github.com/smcinerney sind Sie @raamana https://github.com/raamana ? Ich denke , @lesteve https://github.com/lesteve hat auf @raamana https://github.com/raamana die n_jobs = 1 geschrieben, die zu dieser Frage zu sein scheint in keinem Zusammenhang.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/scikit-learn/scikit-learn/issues/5115#issuecomment-328905819 an oder schalten Sie den Thread https://github.com/notifications/unsubscribe- stumm

Mein schlechtes, ich wollte nichts durcheinander bringen. Ich werde ein anderes Problem öffnen (mit minimalem Code, um es zu reproduzieren), aber GridSearchCV hängt nicht, selbst wenn der Standardwert n_jobs = 1 ist. Dies ist ein größeres Problem (vorausgesetzt, es ist Standard und soll funktionieren) als n_jobs> 1.

@raamana Ja, es ist ein größeres

@ eric-czech @jnothman
Wenn Sie sich also für Backend = 'Threading' entscheiden. Eine einfache Methode ohne Änderung des sklearn-Codes wäre die Verwendung des Kontextmanagers parallel_backend und keine Änderung der Anpassungsmethode des GSV.

from sklearn.externals.joblib import parallel_backend

clf = GridSearchCV()
with parallel_backend('threading'):
    clf.fit(x_train, y_train)

PS: Ich bin nicht sicher, ob "Threading" für alle Schätzer funktioniert. Aber ich hatte das gleiche Problem mit meinem Schätzer mit GSV njob> 1 und die Verwendung funktioniert wie erwartet für mich, ohne die Bibliothek zu ändern.

System anprobiert:
MAC OS: 10.12.6
Python: 3.6
numpy == 1.13.3
pandas == 0.21.0
scikit-learn == 0.19.1

Hmm ... Es kann einige Parallelitätsprobleme bei der Verwendung des Threading-Backends geben
Gittersuche, zum Beispiel schafft der Fehler in # 10329 Rennbedingungen ...

Am 22. Dezember 2017 um 03:59 schrieb Trideep Rath [email protected] :

@ eric-czech https://github.com/eric-czech @jnothman
https://github.com/jnothman
Wenn Sie sich also für Backend = 'Threading' entscheiden. Eine einfache Methode ohne
Das Ändern des sklearn-Codes würde die Verwendung des Kontextmanagers parallel_backend bedeuten
und nicht an der Anpassungsmethode des GSV ändern.

aus sklearn.externals.joblib parallel_backend importieren

clf = GridSearchCV ()
mit parallel_backend ('threading'):
clf.fit (x_train, y_train)

PS: Ich bin nicht sicher, ob "Threading" für alle Schätzer funktioniert. Aber ich war
Ich habe das gleiche Problem mit meinem Schätzer mit GSV njob> 1 und benutze diesen
funktioniert wie erwartet für mich, ohne die Bibliothek zu ändern.

System anprobiert:
MAC OS: 10.12.6
Python: 3.6
numpy == 1.13.3
pandas == 0.21.0
scikit-learn == 0.19.1

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/scikit-learn/scikit-learn/issues/5115#issuecomment-353402474 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAEz64SfwYpjLU1JK0vukBRXJvWYs3LKks5tCo51gaJpZM4FqYlN
.

Fall: Backend als "Threading" verwenden und Estimator verwenden, der BaseEstimator und ClassifierMixin erweitert. Ich bin mir nicht sicher, wo der Rennzustand verursacht wird. Können Sie bitte näher darauf eingehen?

Nach meinem Verständnis und meinen Experimenten habe ich keine Rennbedingungen beobachtet.

out = Parallel(
    n_jobs=self.n_jobs, verbose=self.verbose,
    pre_dispatch=pre_dispatch
)(delayed(_fit_and_score)(clone(base_estimator), X, y, scorers, train,
                          test, self.verbose, parameters,
                          fit_params=fit_params,
                          return_train_score=self.return_train_score,
                          return_n_test_samples=True,
                          return_times=True, return_parameters=False,
                          error_score=self.error_score)
  for parameters, (train, test) in product(candidate_params,
                                           cv.split(X, y, groups)))

_fit_and_score wird auf dem Klon (base_estimator) aufgerufen. Dies führt eine deep_copy durch und verfügt über eine Kopie der eigenen Daten.

out ist die Ausgabe der Methode _fit_and_score. Danach haben alle Threads die Anpassungsmethode des Schätzers abgeschlossen und die Ergebnisse gemeldet.

Das Ergebnis erhalten Sie von GCV_clf.cv_results_

Können Sie bitte in diesem speziellen Fall erklären, warum dies zu einer Rennbedingung führen würde?

Die Race-Bedingung tritt auf, wenn Sie verschachtelte Parameter festlegen, dh wann
Ein geänderter Parameter ist ein Schätzer und ein anderer ist ein Parameter davon
Schätzer.

Ich habe das gleiche Problem mit make_scorer in Kombination mit GridSearchCv und n_jobs=-1 unter Win 7 mit den neuesten Versionen:

Windows-7-6.1.7601-SP1
Python 3.6.4 |Anaconda, Inc.| (default, Jan 16 2018, 10:22:32) [MSC v.1900 64 bit (AMD64)]
NumPy 1.12.1
SciPy 1.0.0
Scikit-Learn 0.19.1

@mansenfranzen danke für die Veröffentlichung deiner Versionen und Plattform! Die beste Möglichkeit, eine qualitativ hochwertige Rückmeldung zu erhalten, besteht darin, ein eigenständiges Snippet bereitzustellen, um das Problem zu reproduzieren. Bitte lesen Sie https://stackoverflow.com/help/mcve für weitere Details.

Das gleiche Problem tritt unter Win7 bei allen benutzerdefinierten Vorverarbeitungsschritten auf.
Toolchain:

Python 3.6.2
NumPy 1.13.1, 1.14.2 (under both)
SciPy 1.0.0
SkLearn 0.19.1

MCVE:

from sklearn.pipeline import Pipeline, make_pipeline
from sklearn.svm import SVC
from sklearn.model_selection import cross_val_score
import numpy as np

class CustomTransformer:
    def fit(self, X, y):
        return self

    def transform(self, X):
        return X

pipeline = make_pipeline(CustomTransformer(),
                         SVC())

X_train = np.array([[1.0, 2.0], [3.0, 4.0], [5.0, 6.0], [7.0, 8.0]])
y_train = np.array([1.0, 0.0, 0.0, 1.0])

print(cross_val_score(pipeline, X_train, y_train, cv=2, n_jobs=-1))

Ist Ihnen bewusst, dass Python-Multiprocessing in Windows ohne if __name__ == '__main__' nicht funktioniert?

Ja bin ich. Entschuldigung, ich habe vergessen zu sagen, dass ich Jupyter benutze.
Ein eigenständiges Skript mit if __name__ == '__main__' druckt die folgenden Spuren und friert dann immer noch ein:

Process SpawnPoolWorker-1:
Traceback (most recent call last):
  File "C:\Python\Python36\lib\multiprocessing\process.py", line 249, in _bootstrap
    self.run()
  File "C:\Python\Python36\lib\multiprocessing\process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Python\Python36\lib\multiprocessing\pool.py", line 108, in worker
    task = get()
  File "C:\Python\Python36\lib\site-packages\sklearn\externals\joblib\pool.py", line 362, in get
    return recv()
  File "C:\Python\Python36\lib\multiprocessing\connection.py", line 251, in recv
    return _ForkingPickler.loads(buf.getbuffer())
AttributeError: Can't get attribute 'CustomTransformer' on <module '__mp_main__' from 'C:\\projects\\Python\\Sandbox\\test.py'>
< same for SpawnPoolWorker-3 here >

Oh, interessant. Aus Faulheit habe ich das gesamte Skript unter if __name__ == '__main__' und die Ergebnisse aus dem vorherigen Kommentar erhalten.

Jetzt habe ich nur pipeline = make_pipeline... und es wurde erfolgreich ausgeführt. Vielleicht ist es die Ursache in Jupyter?

Wie auch immer, ich weiß nicht, ob das Verhalten im vorherigen Kommentar gültig ist und durch die missbräuchliche Verwendung von if __name__ == '__main__' wurde oder ob es SkLearns Schuld ist.

Es klingt so, als wäre es kein Problem mit unserer Bibliothek, sondern mit der Ausführung
Kontext für die Mehrfachverarbeitung in Windows ...

Das ist ekelhaft. Und tatsächlich konnte ich keines der Probleme unter Ubuntu mit den gleichen Versionen von allem reproduzieren. Danke für die Hilfe!

Kann bestätigen, dass dieser Fehler lebendig und gut ist.

Laufen unter Windows 10 in einem Jupyter-Notebook, Python3, Sklearn 0.19.1

Gleiches Problem unter Linux Mint (Ubuntu 16.10) Python 3.5

Alles bleibt in der ersten Epoche auf jedem Kern hängen, und die CPUs sind im Leerlauf, sodass keine Arbeit geleistet wird.

@ MrLobs , das klingt nach einem

@ Chrisjw42 @avatsaev ohne mehr Kontext können wir nicht wirklich viel tun.
@avatsaev klingt wie Sie möglicherweise Tensorflow verwenden?

@ Müller ja es ist Tensorflow

@avatsaev das sind immer noch nicht genug Informationen. Haben Sie ein Mindestbeispiel zum Reproduzieren? Welche Blas verwenden Sie, verwenden Sie die GPU, welche Version von Scikit-Learn verwenden Sie?

Ok, es stellt sich heraus, dass ich eine TF-GPU verwende, sodass das Setzen von n_jobs auf> 1 nicht wirklich funktioniert. Dies ist normal, da ich nur eine GPU habe

Ja, du solltest n_jobs nicht so oder so mit TF verwenden.

warum nicht?

@amueller , ja, das Problem

Wäre es für n_jobs! = 1 möglich, in den Umgebungen, in denen es hängen bleibt, einen Fehler (oder zumindest eine Warnung) auszulösen? Ich bin gerade auf dieses Problem in Jupyter-Notizbüchern gestoßen, und wenn ich ein Anfänger wäre (wie der Rest meiner Klasse), hätte ich nie herausgefunden, warum gridsearchcv weiter hängt. Unser Lehrer hat uns sogar geraten, n_jobs = - zu verwenden 1. Wenn das Problem hier bekannt ist, könnte das Paket (Keras oder Sklearn, je nachdem) warnen, dass es auftreten wird, und das Hängen verhindern?

Ich glaube nicht, dass jemand weiß, in welcher Umgebung dies hängen wird ... Ich glaube nicht, dass es jemandem gelungen ist, diesen Fehler zuverlässig zu reproduzieren.

Wir arbeiten jedoch daran, unsere Multiprozessor-Infrastruktur zu verbessern.
Es ist mir unklar, ob dies all diese Probleme lösen wird.

@jnothman 👍

Das ist schön zu hören!

Ich bin nicht sicher, warum dies mit 0,21 markiert ist. Dies wird in den meisten Fällen in 0,20 gelöst. Ich denke, wir sollten dies schließen und die Leute dazu bringen, neue Themen zu eröffnen. Dieser ist zu lang und unspezifisch.

Ich habe gerade das gleiche auf AWS Ubuntu mit Jupyter angetroffen ...

Die Verwendung von parallel_backend scheint zu funktionieren ...

from sklearn.externals.joblib import parallel_backend

clf = GridSearchCV(...)
with parallel_backend('threading'):
    clf.fit(x_train, y_train)

@morienor Wenn Sie dieses Problem mit scikit-learn 0.20.1 reproduzieren können, öffnen Sie bitte ein neues Problem mit allen erforderlichen Details, damit jemand anderes das Problem reproduzieren kann (das vollständige Skript mit Importanweisungen für einen gefälschten zufälligen Datensatz) mit allen Versionsnummern für Python, Scikit-Learn, Numpy, Scipy und das Betriebssystem.

Ich habe gerade das gleiche auf AWS Ubuntu mit Jupyter angetroffen ...

Die Verwendung von parallel_backend scheint zu funktionieren ...

from sklearn.externals.joblib import parallel_backend

clf = GridSearchCV(...)
with parallel_backend('threading'):
    clf.fit(x_train, y_train)

Das funktioniert bei mir! Vielen Dank!

@ jmq19950824 @morienor Ja, aber es macht keinen Sinn, threading Backend aufgrund von GIL zu verwenden.

Ich habe gerade das gleiche auf AWS Ubuntu mit Jupyter angetroffen ...

Die Verwendung von parallel_backend scheint zu funktionieren ...

from sklearn.externals.joblib import parallel_backend

clf = GridSearchCV(...)
with parallel_backend('threading'):
    clf.fit(x_train, y_train)

Genie arbeitet für mich zu