Xgboost: ¿Mejor instalación de XGBoost en Mac OSX?

Creado en 17 may. 2019  ·  28Comentarios  ·  Fuente: dmlc/xgboost

Asunto

Actualmente en MacOS, el proceso para instalar el paquete python es el siguiente.

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

Pregunta

Lo que me gustaría aprender de un colaborador más experimentado es si hay algún plan para simplificar este proceso de instalación. Lo anterior no es sostenible para un sistema de instalación automatizado para ningún paquete que dependa de xgboost. Lo que se necesitaría para que xgboost sea compatible con el sonido metálico de Apple.

1.0.0 Blocking

Comentario más útil

La fórmula fue aceptada por Homebrew, por lo que los usuarios de Mac ahora pueden hacer:

brew install xgboost

Todos 28 comentarios

El sonido metálico de Apple no es compatible con OpenMP de fábrica, por lo que se necesita Homebrew GCC. Entonces, no, XGBoost no será compatible con el sonido metálico de Apple.

Creo que podemos simplificar el proceso distribuyendo ruedas binarias para Mac OSX. Las ruedas binarias contendrán libxgboost.dylib preconstruido para que el usuario no necesite tener ningún compilador. (Así es como los usuarios de Windows no necesitan tener instalado Visual Studio para usar XGBoost).

Sin embargo, me temo que los mantenedores (incluyéndome a mí) actualmente no están familiarizados con el empaquetado binario con Mac OSX, es decir, cómo hacer binarios que sean ampliamente compatibles en múltiples versiones de OSX. ¿Tienes alguna sugerencia aquí?

Por ahora, debería considerar usar conda-forge para automatizar la instalación de XGBoost en Mac OSX.

@ hcho3 gracias por su rápida respuesta! Conda ciertamente es una opción, pero sería mucho más simple usar pip. Veré cómo se vería el empaquetado binario en macos. Tampoco estoy familiarizado con el empaquetado binario, por lo que agradecería mucho el aporte de cualquier otra persona que tenga experiencia en esa área.

He tenido algunas dificultades con este problema ya que el dylib producido por el proceso de compilación estándar tiene una gran dependencia de las bibliotecas de homebrew gcc. Si alguien tiene una forma de cambiar esa dependencia después de la compilación (o convertirla en genérica en las versiones de gcc), sería genial, pero no creo que macOS se entregue con libgomp (que brinda soporte para OpenMP), por lo que es posible que necesitemos empaquetar eso como bueno, lo que hace la vida difícil.

@Craigacp @hcho3 ¿Es esto algo que podríamos considerar hasta que se encuentre una solución de cmakelists? https://github.com/netket/netket/issues/225#issuecomment-502714445 . No estoy muy familiarizado con el funcionamiento interno de xgboost, cuán crítico es OpenMP para el rendimiento de la biblioteca.

Esto también parecía prometedor, pero no pude hacerlo funcionar: https://stackoverflow.com/questions/46414660/macos-cmake-and-openmp.

@adithyabsk @Craigacp OpenMP es muy importante para el rendimiento de XGBoost, ya que queremos usar todos los núcleos disponibles de CPU multinúcleo comúnmente disponibles en los sistemas de los usuarios. Sin OpenMP, solo podría usar un núcleo de CPU.

En mi humilde opinión, pip no está diseñado para manejar dependencias externas como libomp. Por otro lado, conda puede manejar dependencias que no son de Python con la misma facilidad. Vea esta publicación: https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions/

Cómo Microsoft/LightGBM resuelve el problema: piden a los usuarios que ejecuten brew install libomp . No estoy seguro de si esto es más fácil que instalar GCC o Conda, ya que primero deberá instalar Homebrew.

@hcho3 la solución brew install libomp podría ser mejor, ya que se puede proporcionar en los scripts de configuración de preinstalación mientras que, actualmente, uno tiene que separar xgboost en las canalizaciones de CI para especificar las versiones gcc y g++ adecuadas. Definitivamente, estoy de acuerdo con usted en lo que respecta a conda y esa podría terminar siendo la única solución, pero solo quería explorar las otras opciones para ver si algo más era posible.

Perdón por la pregunta tonta, pero ¿se requiere OpenMP en tiempo de ejecución? Por ejemplo, ¿podríamos compilar dmlc-core y xgboost con OpenMP instalado y luego agrupar ese archivo en una rueda para que la compilación no sea necesaria en el momento de la instalación usando una herramienta como audit_wheel ?

https://stackoverflow.com/a/42106034

@adithyabsk Acabo de intentar usar brew install libomp y ahora puedo compilar XGBoost con el compilador predeterminado, Apple Clang:

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

Además, el binario resultante libxgboost.dylib depende solo de /usr/local/opt/libomp/lib/libomp.dylib y las bibliotecas del sistema OSX. (¡No más dependencia de una versión específica de GCC! ¡Hurra!) Así que supongo que brew install libomp es la forma menos dolorosa de instalar XGBoost en Mac OSX sin Conda.

Sin embargo, distribuir binarios precompilados sigue siendo complicado. Incluso si incluyéramos libomp.dylib dentro de la rueda, Mac OSX no usará el archivo, ya que la dependencia de la biblioteca compartida se especifica con la ruta completa :

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

Por otro lado, Windows es más flexible a la hora de ubicar bibliotecas compartidas. Me pareció suficiente simplemente incluir vcomp140.dll (tiempo de ejecución de OpenMP) dentro de la rueda.

@ hetong007 Nota relacionada: brew install libomp también debería habilitar subprocesos múltiples para CRAN XGBoost en Mac OSX

@ hcho3 Creo que sí. El paquete XGBoost R llama a la misma API de back-end, por lo que debería comportarse de la misma manera.

@hcho3 ¡Es un avance increíble! Ya me estoy moviendo en las direcciones correctas, ya que puedo atestiguar que en muchos laboratorios de I + D, instalar xgboost es un punto doloroso para aquellos que no están íntimamente familiarizados con sus requisitos internos.

Siguiendo con esta nota:

Mac OSX no usará el archivo, ya que la dependencia de la biblioteca compartida se especifica con la ruta completa

Tal vez podríamos analizar más este problema en particular para ver si hay alguna solución para que libomp.dylib entre en la rueda binaria.

@ hcho3 también podría deberse a la extensión en sí. ¿Deberíamos usar .so en macOS también? Este hilo de problemas y la publicación de stackoverflow parecen indicarlo.
https://stackoverflow.com/questions/2488016/how-to-make-python-load-dylib-on-osx
https://github.com/MoDeNa-EUProject/MoDeNa/issues/1

@adithyabsk Dada la complejidad de enviar la biblioteca de tiempo de ejecución en la rueda (y lograr que se cargue), conformémonos con brew install libomp .

  • Homebrew ya se usa bastante entre los usuarios avanzados (creo).
  • Con libomp , podemos usar Apple Clang para compilar XGBoost, eliminando así la dependencia de una versión específica de Homebrew GCC.
  • Este método ha sido verificado por otros proyectos, como LightGBM.

PD. Estoy mirando https://iscinumpy.gitlab.io/post/omp-on-high-sierra/ para entender el uso de OpenMP en Apple Clang.

@hcho3

PD. Estoy mirando https://iscinumpy.gitlab.io/post/omp-on-high-sierra/ para entender el uso de OpenMP en Apple Clang.

Estos PR pueden ayudarlo a:
https://github.com/microsoft/LightGBM/pull/1501 , https://github.com/microsoft/LightGBM/pull/1923.

@adithyabsk Esta es una de mis prioridades. Me gustaría hacer una corrección antes del lanzamiento de 1.0.0.

@hcho3 ¡ Me alegra escucharlo! Veré si puedo jugar con este problema también.

@adithyabsk Un problema sutil que encontré con brew install libomp es que XGBoost se compilaría sin OpenMP, porque CMakeLists.txt no estaba configurado correctamente. (Me di cuenta al ejecutar un trabajo moderadamente pesado en mi Macbook; sin OpenMP, los trabajos tardarán de 2 a 3 veces más). Estoy tratando de revisar CMakeLists.txt para habilitar correctamente OpenMP.

@StrikerRUS Gracias por el enlace. Hacer que el sistema de compilación funcione es bastante difícil y me ayuda mucho tener un punto de referencia (LightGBM).

@adithyabsk Un problema sutil con el que me encontré brew install libomp es que XGBoost se compilaría sin OpenMP, porque CMakeLists.txt no estaba configurado correctamente. (Me di cuenta al ejecutar un trabajo moderadamente pesado en mi Macbook; sin OpenMP, los trabajos tardarán de 2 a 3 veces más). Estoy tratando de revisar CMakeLists.txt para habilitar correctamente OpenMP.

¿Alguna suerte? La razón por la que pregunto es que "pip install xgboost -U" falla incluso después de instalar libomp a través de "brew install libomp".

@wel51x Todavía no modificamos CMakeLists.txt para que la nueva solución funcione. Por ahora, debe seguir las instrucciones en https://xgboost.readthedocs.io/en/latest/build.html.

@adithyabsk @Craigacp Encontré https://github.com/matthew-brett/delocate. Esta puede ser una solución útil para eliminar dependencias de biblioteca codificadas de forma rígida.

En caso de que alguien lo encuentre útil... Entiendo que de ninguna manera es un enfoque convencional, pero el último xgboost con soporte OpenMP se puede instalar en MacOS usando Nix (https://nixos.org/nix/) tan trivialmente como

$ nix-shell -p python3Packages.xgboost

Hola @hcho3 , creé una fórmula Homebrew para XGBoost para ayudar a simplificar la instalación en Mac, para que los usuarios puedan ejecutar brew install xgboost en el futuro. Funciona muy bien, pero lamentablemente no se aceptará con una versión anterior de GCC.

Discusión: https://github.com/Homebrew/homebrew-core/pull/43246

Una opción es deshabilitar OpenMP, pero como mencionaste, no es excelente para el rendimiento. Si puede confirmar los cambios para que funcione con libomp , puedo actualizar la fórmula y podemos impulsar esto.

Gracias por las actualizaciones.

Fwiw, actualicé la fórmula para que ya no dependa de GCC pero no tenga soporte para OpenMP. Podemos actualizarlo una vez que se publique el soporte para libomp .

La fórmula fue aceptada por Homebrew, por lo que los usuarios de Mac ahora pueden hacer:

brew install xgboost

Usé brew install xgboost pero todavía no puedo importar XGBoost. No hay ningún archivo __init__.py ni nada dentro del directorio XGBoost recién instalado, por lo que no puedo usar ninguna de las funciones de XGBoost. ¿Hay otro paso después de usar brew para instalar XGBoost?

@bnicholl Consulte https://github.com/dmlc/xgboost/issues/4949#issuecomment -542333666 para obtener una solución temporal.

@hcho3

Gracias por el enlace. Hacer que el sistema de compilación funcione es bastante difícil y me ayuda mucho tener un punto de referencia (LightGBM).

Con el próximo lanzamiento de CMake 3.16 (ahora en fase RC) debería ser aún más fácil: no habrá necesidad de pasar argumentos adicionales para >=usuarios de Mojave. Consulte https://gitlab.kitware.com/cmake/cmake/merge_requests/3916.

@adithyabsk @Craigacp #5146 ahora debería permitirle usar OpenMP sin instalar Homebrew GCC. Ahora XGBoost solo dependerá del paquete libomp Homebrew.

@ankane En consecuencia, deberíamos poder enviar la próxima versión de XGBoost (1.0) con OpenMP habilitado.

¿Fue útil esta página
0 / 5 - 0 calificaciones