Xgboost: XGBoost 0.90-Roadmap

da wir Breaking Changes wie https://github.com/dmlc/xgboost/pull/4349 und https://github.com/dmlc/xgboost/pull/4377 haben werden

Sollen wir die Version auf 0.9 heben?

@CodingCat Sicher, wir können auf 0,90 stoßen, wenn die Breaking Change signifikant ist. Können Sie mir einen Gefallen tun und in einem Absatz beschreiben, warum #4349 benötigt wurde?

sicher,

* Spark 2.3 is reaching its end-of-life in a few months

Gibt es dazu eine offizielle Stellungnahme? Sie veröffentlichten 2.2.3 im Januar und 2.3.3 im Februar. Unser Anbieter (MapR) liefert noch 2.3.1.

@alexvorobiev https://github.com/dmlc/xgboost/issues/4350 , können Sie mit @srowen von databricks überprüfen

Dies ist keine Frage für Databricks, sondern für das Spark-Projekt. Die Standardrichtlinie sind Wartungsversionen für Zweige für 18 Monate: https://spark.apache.org/versioning-policy.html Das würde 2.3.x ungefähr im Juli zum EOL bringen, also würde ich danach keine weiteren 2.3.x-Versionen erwarten das aus dem OSS-Projekt.

@srowen Danke!

@srowen @CodingCat @alexvorobiev Lassen Sie uns auch die Möglichkeit besprechen, Scala 2.12 / 2.13 zu unterstützen. Im Moment ist XGBoost4J für Scala 2.11 kompiliert:
https://github.com/dmlc/xgboost/blob/2c61f02add72cce8f6dc1ba87e016e3c5f0b7ea6/jvm-packages/pom.xml#L38 -L39

Ein Benutzer berichtete, dass für Scala 2.11 kompilierte XGBoost4J-JARs nicht binärkompatibel mit Scala 2.12 sind.

Ja, 2.11 / 2.12 sind immer noch binär-inkompatibel und Spark hat zwei Distributionen. Beide werden in 2.4.x unterstützt, obwohl 2.12 ab hier die Standardeinstellung in 2.4.x ist. 3.0 wird die Unterstützung von Scala 2.11 einstellen.

Es kann nur darum gehen, zwei Versionen zu kompilieren, anstatt viel oder irgendeine Codeänderung. Wenn Sie in 2.12 auf lustige Fehler stoßen, lassen Sie es mich wissen, da ich viele dieser Probleme beim Aktualisieren von Spark angestarrt habe.

2.13 ist immer noch nicht GA und denke, es wird eine kleinere Änderung von 2.12->2.13 als 2.11->2.12 sein (großer Unterschied hier ist eine völlig unterschiedliche Darstellung von Lambdas).

@hcho3 Ich nehme an, du wolltest @alexvorobiev markieren?

@alexeygrigorev Ups , tut mir leid.

Das einzige Problem ist, dass wir eine grundlegende Änderung am Artefaktnamen von xgboost in Maven vornehmen müssen, xgboost4j-spark => xgboost4j-spark_2.11/xgboost4j-spark_2.12, wie z. B. spark https://mvnrepository.com/artifact/ org.apache.spark/spark-core und wir müssen noch einmal überprüfen, ob wir eine vorübergehende Abhängigkeit von 2.11 haben (ich denke nein)

Hallo, @srowen though 2.12 is the default from here on in 2.4.x , ich habe branch-2.4 pom.xml überprüft. Wenn Sie das Profil scala-2.12 nicht angeben, erhalten Sie immer noch einen 2.11-Build, nicht wahr?

Sie könnten sich dafür entscheiden, nur 2.12 in 0.9x zu unterstützen, und dann müssen Sie den Artefaktnamen nicht anhängen. Wenn Sie beides unterstützen, möchten Sie den Artefaktnamen leider wirklich ändern und die Versionen _2.11 und _2.12 haben.

Ja, die Standardversion von Spark 2.4.x ist für 2.11; -Pscala-2.12 erhält den 2.12-Build.

danke, ich würde bei der Unterstützung von 2.12 zumindest für die kommende Version konservativ bleiben

Soweit ich weiß, verwenden die meisten Spark-Benutzer immer noch 2.11, da sie es gewohnt sind, früheren Versionen von Spark zu folgen

Ich habe möglicherweise nicht die Bandbreite, um jeden Test zu durchlaufen, den ich zur Einführung der 2.12-Unterstützung habe

Ich würde mich entscheiden, 2.12 + 2.11 oder 2.12 in Version 1.0 zu unterstützen...

@hcho3 FYI, ich habe gerade die dichte Matrixunterstützung aufgrund der begrenzten Bandbreite aus der Roadmap entfernt

@hcho3 Könnten Sie einen Blick auf https://github.com/dmlc/dmlc-core/pull/514 werfen, wenn es die Zeit erlaubt? Es könnte sich lohnen, vor dem nächsten Release-Hit zu fusionieren.

@trivialfis Werde es

@CodingCat Ich denke, wir sollten das Veröffentlichungsdatum verschieben, da Spark 2.4.1 und 2.4.2 Probleme haben. Was denken Sie?

@srowen Weißt du, wann Spark

Ich denke, es ist in Ordnung, eine kleine Verzögerung zu haben

Okay, warten wir, bis Spark 2.4.3 draußen ist

Würde es die letzte Version 0.83 für Spark 2.3.x geben?

@CodingCat Was ist, wenn wir zwei parallele Releases 0.83 und 0.90

Ein Problem ist jedoch die Benutzererfahrung mit dem Umgang mit fehlenden Werten. Vielleicht wird jeder gezwungen, Spark 2.4.x zu verwenden, um ihn daran zu hindern, fehlende Werte zu vermasseln (das Problem, das #4349) motivierte

@hcho3 Ich bin etwas besorgt über die Inkonsistenz verschiedener Versionen bei der Verfügbarkeit von pkgs.

Ich kann mir Fragen vorstellen wie hey, I find 0.83 in maven so I upgrade our Spark pkg, but I cannot use 0.83 in notebook when attempting to explore my new model setup with a small amount of data with python pkg?

Ich würde vorschlagen, dass wir entweder eine vollständige Wartungsversion für den 0.8x-Zweig haben oder nichts

@CodingCat Verstanden . Wir werden konsistente Releases für alle Pakete erstellen. Was haltet ihr dann von 0.83 Release? Sollen wir es tun?

@CodingCat Eigentlich wird dies anderen Betreuern Arbeit bringen, wir müssen sie zuerst fragen

kurze Antwort aus persönlicher Sicht ist theoretisch ja , aber es könnte mehr sein, als direkt vor einem Commit zu schneiden (wie Sie sagten, es wird auch für andere Arbeit schaffen) (aber ich zögere aufgrund der begrenzten Anzahl, dies zu tun) Ressourcen in der Gemeinde...)

Hier sind meine 2 Cent darüber, wie wir über Wartungsversionen wie 0.8x nachdenken sollten

1. Der Grund für eine Wartungsversion besteht darin, kritische Fehlerkorrekturen wie https://github.com/dmlc/xgboost/commit/2d875ec0197d5a83e7d585daf472b8201aa97c51 und https://github.com/dmlc/xgboost/commit/995698b0cb1da7543066d

2. auf der anderen Seite, um die Community nachhaltig zu machen, anstatt alle Committer auszubrennen, sollten wir die Unterstützung der vorherigen Version regelmäßig einstellen

3. die Neuerungen und Verbesserungen sollen durch ein Feature-Release an die Nutzer gebracht werden (Sprung von 0.8 auf 0.9)

Wenn wir uns für 0,83 entscheiden, müssen wir auch Meinungen von @RAMitchell @trivialfis einholen und ihren Richter verwenden, um zu sehen, ob wir wichtige (mehr zur Korrektheit) Fehlerbehebungen haben, die von ihnen bemerkt werden

und dann einen 0,83-Zweig basierend auf 0,82 erstellen, um Commits herauszupicken...... eigentlich eine Menge Arbeit

Wenn ich das richtig verstehe, wird 0.9 ältere Versionen von Spark nicht unterstützen, daher der Vorschlag, eine 0.83-Version sowie 0.9 zu unterstützen, um die Unterstützung für ältere Spark-Versionen fortzusetzen und gleichzeitig Fehlerkorrekturen einzuschließen?

Generell bin ich gegen alles, was Entwicklerzeit verbraucht. Sind wir nicht schon genug beschäftigt? Ich sehe jedoch einen gewissen Wert darin, eine stabile Version zu haben.

@CodingCat Gibt es eine Möglichkeit, Fehlerkorrekturen (2d875ec und 995698b) zu integrieren, ohne auf Spark 2.4.x zu aktualisieren?

Wenn das Erstellen von Wartungsversionen mehr ist als nur das Abschneiden von Zweigen (z. B. Rosinenpickerei), würde ich diese Verpflichtung lieber nicht eingehen.

Generell bin ich gegen alles, was Entwicklerzeit verbraucht. Sind wir nicht schon genug beschäftigt?

Ich stimme zu.

@CodingCat Gibt es eine Möglichkeit, Fehlerkorrekturen (2d875ec und 995698b) zu integrieren, ohne auf Spark 2.4.x zu aktualisieren?

@hcho3 leider nein, aufgrund der Breaking Changes in der von Spark abhängigen Bibliothek können wir xgboost nur mit der konsistenten Version von spark kompilieren und ausführen

wenn wir in Zukunft an einem Wartungsrelease interessiert sind, den Workflow (nach Release 0.9)

1. Zurückportieren erforderlich, Fix auf 0,9-Zweig

2. Release 0.9x alle, sagen wir, 2 Monate oder ausgelöst durch einen wichtigen Bugfix

3. Hauptfunktionen und alle Fixes, die auf 0.9x zurückportiert wurden, sollten in Master verfügbar sein

4. ab Version 1.0 einen Ast vom Master abschneiden......

aber noch einmal, sobald wir einen großen refactor in master haben und danach den Fix auf 0.9 zurückportieren wollen... Tonnen Arbeit

@CodingCat Angesichts der aktuellen Größe der

@tovbinm Entschuldigung, ich glaube nicht, dass wir aufgrund mangelnder Bandbreite eine Veröffentlichung von 0.83 durchführen können. Ist ein Upgrade auf Spark 2.4.3 für Sie machbar?

Das ist bedauerlich. Nein, nicht kurzfristig. Wir sind noch am 2.3.x.

Welches Commit hat Spark von 2.3 auf 2.4 aktualisiert? Vielleicht können wir dort schneiden (wenn es natürlich über 0,82 liegt).

@tovbinm Sie können XGBoost mit Commit 711397d6452d596d7acbb68f1052ffebdee3e3af erstellen, um Spark 2.3.x zu verwenden.

Groß. Warum also nicht eine öffentliche Freigabe von diesem Commit machen?

Wie @CodingCat sagte, geht es bei Wartungsversionen nicht einfach darum, vor einem Commit zu schneiden. Außerdem sind öffentliche Veröffentlichungen implizite Versprechen von Unterstützung. Ich glaube nicht, dass die Betreuer zum jetzigen Zeitpunkt bereit sind, zwei neue Releases zu unterstützen.

Ich überlasse @CodingCat , ob wir eine Veröffentlichung von 711397d6452d596d7acbb68f1052ffebdee3e3af vornehmen sollten

Externer Speicher mit GPU-Prädiktor - dies würde bedeuten, dass der Code mit what(): std::bad_alloc: nicht mehr genügend Speicher abstürzt? (dh vorübergehend in RAM einlagern?)

verwandtes Problem, denke ich, https://github.com/dmlc/xgboost/issues/4184 - dies war hauptsächlich auf zeitliche Speicherausbrüche zurückzuführen, der Prozess der Anpassung selbst erfordert nie so viel Speicher

@hlbkin Sie müssen den externen Speicher gemäß https://xgboost.readthedocs.io/en/latest/tutorials/external_memory.html explizit aktivieren

Ich gehe davon aus, dass es nicht möglich ist, ohne einen größeren Versions-Bump (dh 1.0) anders zu wechseln, aber wenn Sie dies tun, könnten Sie in Betracht ziehen, konforme PEP 440- Versionsnummern (iexyz) und vorzugsweise semantische Versionierung zu unterstützen? Die Standardinterpretation von 0.90 (anstatt 0.9.0) wäre, dass es die 90. Nebenversion der Hauptversion 0.x (dh Pre-Stable-Release)-Reihe ist und nicht signifikanter als 0.83 ist. Darüber hinaus sind Sie dadurch auf maximal 9-Punkte-Releases pro Nebenversion beschränkt und erschweren die Interpretation einiger Tools (und Personen). Vielen Dank!

+1

@CAM-Gerlach Wir werden es berücksichtigen, wenn wir 1.0 veröffentlichen. Auf der anderen Seite wollen wir nicht auf 1.0 überstürzen. Wir möchten, dass 1.0 ein Meilenstein in Bezug auf Funktionen, Stabilität und Leistung ist.

Danke für die Erklärung, @hcho3 .

Sie wollen wahrscheinlich sicherstellen, dass Sie den Set python_requires Argument '>=3.5' in setup() Benutzer 2 mit Python , um sicherzustellen , nicht versehentlich zu einer inkompatiblen Version aufgerüstet.

@hcho3 Externer Speicher ist mit GPU-Algorithmen nicht verfügbar

@hlbkin Du hast recht. Externer Speicher ist nur für den GPU-Prädiktor verfügbar, nicht für das Training.

@rongou @sriramch Liege ich richtig, dass GPU-Training mit externem Speicher nicht verfügbar ist?

@hcho3 ja du hast hier, wenn Sie interessiert sind. Ich muss diese Änderung mit dem Master synchronisieren und einige Tests schreiben.

@sriramch Super ! Sollten wir versuchen, externes Gedächtnistraining in die 0.90-Version aufzunehmen, oder sollten wir nach 0.90 darauf zurückkommen?

nur meine zwei Cent, lassen Sie uns etwas zurückhalten, viele neue Funktionen in 0.x zu komprimieren (in Eile) und überlegen wir, was in 1.0 als Meilenstein-Version eingebaut werden soll

@CodingCat Ich stimme zu. Zu Ihrer Information, ich habe verteilte benutzerdefinierte Ziele aus der 0.90-Roadmap entfernt, da es in #4280 erhebliche Meinungsverschiedenheiten gab. Wir werden es nach 0,90 noch einmal in Betracht ziehen.

@sriramch Betrachten wir das externe Gedächtnistraining nach der Veröffentlichung von 0.90. Vielen Dank für Ihre Mühe.

Dies könnte ein guter Zeitpunkt sein, um die cuda 9.0-Binärdateien anstelle von 8.0 zu veröffentlichen. Ich denke, 9.0 wird jetzt von der Treiberversion des Benutzers ausreichend unterstützt. Außerdem müssen die 9.0-Binärdateien für die neueren Volta-Architekturen nicht JIT-kompiliert werden.

@hcho3 sind wir bereit zu gehen?

Schon fast. Ich denke, #4438 sollte zusammengeführt werden.

Alles gut jetzt. Ich werde weitermachen und mit der Arbeit an der nächsten Version beginnen. ETA: 16. Mai 2019

• [x] Erfordert Python 3 in setup.py
• [x] CI ändern, um CUDA 9.0-Räder zu bauen (#4459)
• [x] Windows-Kompilierung korrigieren (#4463)
• [x] Richten Sie ein minimal praktikables CI für Windows mit GPU ein (#4463)

@RAMitchell Sollten wir CUDA 9.0 oder 9.2 für

Lassen Sie uns 9.2 verwenden, da dies bereits auf CI eingerichtet ist. Die Gefahr besteht darin, dass wir zu neue Nvidia-Treiber benötigen. Als Referenz hier die Tabelle, die die Entsprechung zwischen cuda-Version und Treibern zeigt: https://docs.nvidia.com/deploy/cuda-compatibility/index.html#binary -compatibility__table-toolkit-driver

Soweit ich weiß, sollte dies sowieso keine Auswirkungen auf die CPU-Algorithmen haben. Wenn Benutzer beginnen, Probleme zu melden, können wir dies in Zukunft mit besseren Fehlermeldungen zur Treiberkompatibilität angehen.

Hmm, in diesem Fall kann ich versuchen, einen der CI-Worker auf CUDA 9.0 herunterzustufen. Da wir Docker-Container ausgiebig nutzen, sollte es nicht allzu schwierig sein.

Ich werde jetzt 0.90 Release vorbereiten. Mein Ziel ist es, die Release Note bis Ende dieser Woche fertig zu haben.

Geschlossen von #4475