Xgboost: Bessere XGBoost-Installation auf Mac OSX?

Erstellt am 17. Mai 2019  ·  28Kommentare  ·  Quelle: dmlc/xgboost

Problem

Derzeit ist der Prozess zum Installieren des Python-Pakets unter MacOS wie folgt.

$ brew install gcc<strong i="7">@5</strong>
$ export CC=/path/to/gcc-5; export CXX=/path/to/g++-5; pip install xgboost

Frage

Was ich gerne von einem erfahreneren Mitwirkenden erfahren würde, ist, ob es irgendwelche Pläne gibt, diesen Installationsprozess zu vereinfachen? Das Obige ist für ein automatisiertes Installationssystem für Pakete, die von xgboost abhängig sind, nicht haltbar. Was wäre erforderlich, um xgboost mit Apples Clang kompatibel zu machen.

1.0.0 Blocking

Hilfreichster Kommentar

Die Formel wurde von Homebrew akzeptiert, sodass Mac-Benutzer jetzt Folgendes tun können:

brew install xgboost

Alle 28 Kommentare

Apples Clang unterstützt OpenMP nicht standardmäßig, daher wird Homebrew GCC benötigt. Also, nein, XGBoost wird nicht mit Apples Clang kompatibel sein.

Ich denke, wir können den Prozess vereinfachen, indem wir Binärräder für Mac OSX verteilen. Die Binärräder enthalten vorgefertigte libxgboost.dylib, sodass der Benutzer keinen Compiler benötigt. (So ​​müssen Windows-Benutzer Visual Studio nicht installiert haben, um XGBoost zu verwenden.)

Ich befürchte jedoch, dass die Betreuer (mich eingeschlossen) derzeit nicht mit Binärpaketen unter Mac OSX vertraut sind, dh wie man Binärdateien erstellt, die über mehrere Versionen von OSX hinweg weitgehend kompatibel sind. Haben Sie hier Anregungen?

Im Moment sollten Sie die Verwendung von conda-forge in Betracht ziehen, um die XGBoost-Installation unter Mac OSX zu automatisieren.

@hcho3 danke für deine schnelle Antwort! Conda ist sicherlich eine Option, aber es wäre viel einfacher, Pip zu verwenden. Ich werde untersuchen, wie das binäre Paketieren auf Macos aussehen würde. Ich bin auch nicht mit binärer Paketierung vertraut, daher wäre jeder andere Beitrag, der Erfahrung auf diesem Gebiet hat, sehr willkommen.

Ich hatte einige Schwierigkeiten mit diesem Problem, da die vom Standardkompilierungsprozess erzeugte dylib eine starke Abhängigkeit von den Bibliotheken des Homebrew gcc hat. Wenn jemand eine Möglichkeit hätte, diese Abhängigkeit nach der Kompilierung zu ändern (oder sie für gcc-Versionen generisch zu machen), wäre das großartig, aber ich glaube nicht, dass macOS mit libgomp (das die OpenMP-Unterstützung bietet) ausgeliefert wird, also müssen wir das möglicherweise so packen naja, was das Leben schwer macht.

@Craigacp @hcho3 Ist das etwas, was wir in Betracht ziehen könnten, bis eine cmakelists-Problemumgehung gefunden wird. https://github.com/netket/netket/issues/225#issuecomment -502714445. Ich bin nicht sehr vertraut mit den Interna von xgboost, wie wichtig OpenMP für die Leistung der Bibliothek ist.

Dies schien auch vielversprechend zu sein, aber ich konnte es nicht zum Laufen bringen: https://stackoverflow.com/questions/46414660/macos-cmake-and-openmp.

@adithyabsk @Craigacp OpenMP ist sehr wichtig für die Leistung von XGBoost, da wir alle verfügbaren Kerne von Mehrkern-CPUs verwenden möchten, die üblicherweise auf den Systemen der Benutzer verfügbar sind. Ohne OpenMP könnten Sie nur einen CPU-Kern verwenden.

IMHO ist pip nicht für den Umgang mit externen Abhängigkeiten wie libomp ausgelegt. Auf der anderen Seite ist conda in der Lage, Nicht-Python-Abhängigkeiten genauso einfach zu handhaben. Siehe diesen Beitrag: https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/

So löst Microsoft/LightGBM das Problem: Sie fordern Benutzer auf, brew install libomp auszuführen. Ich bin mir nicht sicher, ob dies einfacher ist als die Installation von GCC oder Conda, da Sie zuerst Homebrew installieren müssen.

@hcho3 Die brew install libomp-Lösung ist möglicherweise besser, da diese in Vorinstallations-Setup-Skripten bereitgestellt werden kann, während derzeit xgboost in CI-Pipelines getrennt werden muss, um die entsprechenden gcc- und g++-Versionen anzugeben. Ich stimme Ihnen auf jeden Fall zu, was Conda angeht, und das könnte am Ende die einzige Lösung sein, aber ich wollte nur die anderen Optionen untersuchen, um zu sehen, ob etwas anderes möglich ist.

Entschuldigung für die dumme Frage, aber wird OpenMP zur Laufzeit benötigt? Könnten wir zum Beispiel dmlc-core und xgboost mit installiertem OpenMP kompilieren und diese Datei dann in einem Rad bündeln, sodass die Kompilierung zur Installationszeit mit einem Tool wie audit_wheel nicht erforderlich wäre?

https://stackoverflow.com/a/42106034

@adithyabsk Ich habe gerade versucht, brew install libomp zu verwenden, und jetzt kann ich XGBoost mit dem Standardcompiler Apple Clang kompilieren:

brew install libomp
mkdir build
cd build
cmake ..
make -j10

Darüber hinaus hängt die resultierende Binärdatei libxgboost.dylib nur von /usr/local/opt/libomp/lib/libomp.dylib und den OSX-Systembibliotheken ab. (Keine Abhängigkeit mehr von einer bestimmten Version von GCC! Hurra!) Also nehme ich an, dass brew install libomp der am wenigsten schmerzhafte Weg ist, XGBoost auf Mac OSX ohne Conda zu installieren.

Das Verteilen vorkompilierter Binärdateien ist jedoch immer noch schwierig. Selbst wenn wir libomp.dylib in das Rad einfügen würden, wird Mac OSX die Datei nicht verwenden, da die Abhängigkeit von gemeinsam genutzten Bibliotheken mit dem vollständigen Pfad angegeben wird:

hcho3<strong i="17">@localhost</strong>: xgboost$ otool -l libxgboost.dylib    # show list of library dependencies

libxgboost.dylib:
Mach header
      magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
 0xfeedfacf 16777223          3  0x00           6    15       2112 0x00918085
....
Load command 10
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name /usr/local/opt/libomp/lib/libomp.dylib (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 5.0.0
compatibility version 5.0.0
Load command 11
          cmd LC_LOAD_DYLIB
      cmdsize 48
         name /usr/lib/libc++.1.dylib (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 400.9.0
compatibility version 1.0.0
Load command 12
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name /usr/lib/libSystem.B.dylib (offset 24)
   time stamp 2 Wed Dec 31 16:00:02 1969
      current version 1252.50.4
compatibility version 1.0.0

Andererseits ist Windows flexibler, wenn es darum geht, gemeinsam genutzte Bibliotheken zu finden. Ich fand es ausreichend, einfach vcomp140.dll (OpenMP-Laufzeit) in das Rad aufzunehmen.

@hetong007 Zugehöriger Hinweis: brew install libomp sollte auch Multi-Threading für CRAN XGBoost auf Mac OSX aktivieren

@hcho3 Ich denke schon. Das XGBoost R-Paket ruft die gleiche Backend-API auf und sollte sich daher gleich verhalten.

@hcho3 Das ist eine tolle Entwicklung! Ich bewege mich bereits in die richtige Richtung, da ich bezeugen kann, dass die Installation von xgboost in vielen Forschungs- und Entwicklungslabors ein Schmerzpunkt für diejenigen ist, die mit den internen Anforderungen nicht genau vertraut sind.

Folgen Sie diesem Hinweis:

Mac OSX verwendet die Datei nicht, da die Abhängigkeit der gemeinsam genutzten Bibliothek mit dem vollständigen Pfad angegeben wird

Vielleicht könnten wir uns näher mit diesem speziellen Problem befassen, um zu sehen, ob es irgendwelche Problemumgehungen gibt, um die libomp.dylib in das Binärrad zu bekommen.

@hcho3 könnte auch an der Erweiterung selbst liegen? Sollten wir .so auch unter macOS verwenden. Dieser Problemthread und der Stackoverflow-Beitrag scheinen darauf hinzudeuten.
https://stackoverflow.com/questions/2488016/how-to-make-python-load-dylib-on-osx
https://github.com/MoDeNa-EUProject/MoDeNa/issues/1

@adithyabsk Angesichts der Komplexität, die Laufzeitbibliothek im Rad zu versenden (und zum Laden zu bringen), begnügen wir uns mit brew install libomp .

  • Homebrew ist bereits unter Power-Usern ziemlich weit verbreitet (glaube ich).
  • Mit libomp können wir Apple Clang verwenden, um XGBoost zu kompilieren, wodurch die harte Abhängigkeit von einer bestimmten Version von Homebrew GCC beseitigt wird.
  • Diese Methode wurde von anderen Projekten wie LightGBM verifiziert.

PS. Ich schaue mir https://iscinumpy.gitlab.io/post/omp-on-high-sierra/ an, um die Verwendung von OpenMP in Apple Clang zu verstehen.

@hcho3

PS. Ich schaue mir https://iscinumpy.gitlab.io/post/omp-on-high-sierra/ an, um die Verwendung von OpenMP in Apple Clang zu verstehen.

Diese PRs können Ihnen helfen:
https://github.com/microsoft/LightGBM/pull/1501 , https://github.com/microsoft/LightGBM/pull/1923.

@adithyabsk Das ist eine meiner Prioritäten. Ich möchte vor der Veröffentlichung von 1.0.0 eine Korrektur vornehmen.

@hcho3 Freut mich zu hören! Ich werde mal sehen, ob ich mich auch mit diesem Thema beschäftigen kann.

@adithyabsk Ein subtiles Problem, auf das ich gestoßen bin, brew install libomp ist, dass XGBoost ohne OpenMP kompiliert würde, weil CMakeLists.txt nicht richtig konfiguriert war. (Ich konnte das erkennen, indem ich einen mäßig schweren Job auf meinem Macbook ausführte; ohne OpenMP dauern Jobs 2-3x so lange.) Ich versuche, CMakeLists.txt zu überarbeiten, um OpenMP richtig zu aktivieren.

@StrikerRUS Danke für den Link. Es ist ziemlich schwierig, das Build-System zum Laufen zu bringen, und es hilft mir sehr, einen Bezugspunkt (LightGBM) zu haben.

@adithyabsk Ein subtiles Problem, auf das ich gestoßen bin, brew install libomp ist, dass XGBoost ohne OpenMP kompiliert würde, weil CMakeLists.txt nicht richtig konfiguriert war. (Ich konnte das erkennen, indem ich einen mäßig schweren Job auf meinem Macbook ausführte; ohne OpenMP dauern Jobs 2-3x so lange.) Ich versuche, CMakeLists.txt zu überarbeiten, um OpenMP richtig zu aktivieren.

Etwas Glück? Der Grund, warum ich frage, ist, dass "pip install xgboost -U" auch nach der Installation von libomp über "brew install libomp" fehlschlägt.

@wel51x Wir haben CMakeLists.txt noch nicht geändert, damit die neue Lösung funktioniert. Im Moment sollten Sie den Anweisungen in https://xgboost.readthedocs.io/en/latest/build.html folgen.

@adithyabsk @Craigacp Ich habe https://github.com/matthew-brett/delocate gefunden. Dies kann eine nützliche Lösung sein, um fest codierte Bibliotheksabhängigkeiten zu entfernen.

Falls es jemand hilfreich findet ... Ich verstehe, dass es keineswegs ein Mainstream-Ansatz ist, aber der neueste xgboost mit OpenMP-Unterstützung kann unter MacOS mit Nix (https://nixos.org/nix/) so trivial wie installiert werden

$ nix-shell -p python3Packages.xgboost

Hey @hcho3 , ich habe eine Homebrew-Formel für XGBoost erstellt, um die Installation auf dem Mac zu vereinfachen, damit Benutzer in Zukunft brew install xgboost ausführen können. Es funktioniert großartig, wird aber leider nicht mit einer älteren Version von GCC akzeptiert.

Diskussion: https://github.com/Homebrew/homebrew-core/pull/43246

Eine Möglichkeit besteht darin, OpenMP zu deaktivieren, aber wie Sie bereits erwähnt haben, ist dies nicht gut für die Leistung. Wenn Sie in der Lage sind, die Änderungen zu übernehmen, damit es mit libomp funktioniert, kann ich die Formel aktualisieren und wir können dies vorantreiben.

Danke für die Updates.

fwiw, ich habe die Formel aktualisiert, sodass sie nicht mehr von GCC abhängt, aber OpenMP nicht unterstützt. Wir können es aktualisieren, sobald die Unterstützung für libomp freigegeben wird.

Die Formel wurde von Homebrew akzeptiert, sodass Mac-Benutzer jetzt Folgendes tun können:

brew install xgboost

Ich habe brew install xgboost verwendet, aber ich kann XGBoost immer noch nicht importieren. Es gibt keine __init__.py-Datei oder irgendetwas anderes im tatsächlich neu installierten XGBoost-Verzeichnis, daher kann ich keine der XGBoost-Funktionen verwenden. Gibt es einen weiteren Schritt nach der Verwendung von Brew zur Installation von XGBoost?

@bnicholl Siehe https://github.com/dmlc/xgboost/issues/4949#issuecomment -542333666 für eine temporäre Lösung.

@hcho3

Danke für den Link. Es ist ziemlich schwierig, das Build-System zum Laufen zu bringen, und es hilft mir sehr, einen Bezugspunkt (LightGBM) zu haben.

Mit der kommenden CMake 3.16-Version (jetzt in der RC-Phase) sollte es noch einfacher werden: Es wird keine Notwendigkeit mehr geben, zusätzliche Argumente für >=Mojave-Benutzer zu übergeben. Siehe https://gitlab.kitware.com/cmake/cmake/merge_requests/3916.

@adithyabsk @Craigacp #5146 sollte es Ihnen jetzt ermöglichen, OpenMP zu verwenden, ohne Homebrew GCC zu installieren. Jetzt hängt XGBoost nur noch vom libomp Homebrew-Paket ab.

@ankane Folglich sollten wir in der Lage sein, die nächste Version von XGBoost (1.0) mit aktiviertem OpenMP einzureichen.

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen