Numpy: Paquete de rueda de Windows (.whl) en Pypi

Bien dicho, y de hecho hay mucho trabajo de @carlkl detrás de escena para que esto suceda. Creo que ya casi llegamos - @carlkl - ¿cuándo crees que lo harás público?

Por contexto: la razón por la que esto no es trivial es que los archivos binarios que vinculó
depender del tiempo de ejecución y la biblioteca matemática patentados de Intel, que
complica redistribuirlos.

Implementé las recientes ruedas numpy y scipy basadas en OpenBLAS en binstar. Puedes instalarlos con:

pip install -i https://pypi.binstar.org/carlkl/simple numpy
pip install -i https://pypi.binstar.org/carlkl/simple scipy

Esto funciona para python-2.7 y para python-3.4. Las ruedas están marcadas como 'experimentales'. Los comentarios son bienvenidos.

Si desea pruebas generalizadas, debe enviar esto a la lista :-)

El jueves 22 de enero de 2015 a las 8:54 p. m., carlkl [email protected] escribió:

Implementé las recientes ruedas numpy y scipy basadas en OpenBLAS en binstar.
Puedes instalarlos con:

pip install -i https://pypi.binstar.org/carlkl/simple numpy
pip install -i https://pypi.binstar.org/carlkl/simple scipy

Esto funciona para python-2.7 y para python-3.4. Las ruedas están marcadas como
'experimental'. Los comentarios son bienvenidos.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-71096693 .

Nathaniel J Smith
Investigador postdoctoral - Informática - Universidad de Edimburgo
http://vorpus.org

fwiw, personalmente me gustaría cambiar el tamaño del entero predeterminado en win64 antes de que proporcionemos binarios oficiales, aunque también hubo cierta resistencia cuando lo propuse por última vez, también posiblemente con anaconda y otros binarios de terceros, probablemente ya sea demasiado tarde: (

también hablando de openblas, a alguien le apetece algo de depuración, estoy cansado de eso (parece la misma falla que rompe scipy con openblas):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Invalid read of size 16
==31931==    at 0x7B28EB9: ddot_k_NEHALEM (in /usr/lib/libopenblasp-r0.2.10.so)
==31931==    by 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931==    by 0x6E93DEC: cblas_matrixproduct (cblasfuncs.c:528)
==31931==    by 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931==    by 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

La versión de OpenBLAS utilizada es 0.2.12. Todavía no experimenté problemas significativos con esta versión.

Los errores de scipy se copian en https://gist.github.com/carlkl/b05dc6055fd42eba8cc7.

Fallos numpy solo de 32 bits debido a http://sourceforge.net/p/mingw-w64/bugs/367

======================================================================
FAIL: test_nan_outputs2 (test_umath.TestHypotSpecialValues)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath.py", line 411, in test_nan_outputs2
    assert_hypot_isinf(np.nan, np.inf)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath.py", line 402, in assert_hypot_isinf
    "hypot(%s, %s) is %s, not inf" % (x, y, ncu.hypot(x, y)))
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 53, in assert_
    raise AssertionError(smsg)
AssertionError: hypot(nan, inf) is nan, not inf

======================================================================
FAIL: test_umath_complex.TestCabs.test_cabs_inf_nan(<ufunc 'absolute'>, inf, nan, inf)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\nose\case.py", line 197, in runTest
    self.test(*self.arg)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 523, in check_real_value
    assert_equal(f(z1), x)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 275, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 739, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 628, in assert_array_compare
    chk_same_position(x_isnan, y_isnan, hasval='nan')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 608, in chk_same_position
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

x and y nan location mismatch:
 x: array([ nan])
 y: array(inf)

======================================================================
FAIL: test_umath_complex.TestCabs.test_cabs_inf_nan(<ufunc 'absolute'>, -inf, nan, inf)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\nose\case.py", line 197, in runTest
    self.test(*self.arg)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\core\tests\test_umath_complex.py", line 523, in check_real_value
    assert_equal(f(z1), x)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 275, in assert_equal
    return assert_array_equal(actual, desired, err_msg, verbose)
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 739, in assert_array_equal
    verbose=verbose, header='Arrays are not equal')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 628, in assert_array_compare
    chk_same_position(x_isnan, y_isnan, hasval='nan')
  File "D:\tools\wp_279\python-2.7.9rc1\lib\site-packages\numpy\testing\utils.py", line 608, in chk_same_position
    raise AssertionError(msg)
AssertionError: 
Arrays are not equal

x and y nan location mismatch:
 x: array([ nan])
 y: array(inf)

No estoy en desacuerdo con cambiar el tamaño del entero win64, pero creo que eso es
un tema aparte que debe ser desacoplado de las ruedas. Si este fuera el
primera vez que las compilaciones numpy win64 estaban ampliamente disponibles, entonces sería
tiene sentido vincularlos, pero en este punto ya hay toneladas de usuarios
durante años, solo usan cgholke o anaconda o lo que sea. Entonces vamos
tratar eso como una discusión independiente?

(Estrictamente hablando, es una ruptura de la retrocompatibilidad, pero aun así parece razonable
que podamos lograrlo, ya que en realidad reduce
incompatibilidad entre plataformas: todo el código portátil tiene que manejar 64 bits
dtype=int ya).

El jueves 22 de enero de 2015 a las 8:59 p. m., Julian Taylor [email protected]
escribió:

fwiw, personalmente me gustaría cambiar el tamaño del entero predeterminado en
win64 antes de que en realidad proporcionemos binarios oficiales, aunque hubo algunos
resistencia también cuando lo propuse por última vez, también posiblemente con anaconda y
otros binarios de terceros probablemente ya sea demasiado tarde :(

también hablando de openblas, a alguien le apetece algo de depuración, estoy cansado de eso
(parece la misma falla que rompe scipy con openblas):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Lectura no válida de tamaño 16
==31931== en 0x7B28EB9: ddot_k_NEHALEM (en /usr/lib/libopenblasp-r0.2.10.so)
==31931== por 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931== por 0x6E93DEC: cblas_matrixproduct (cblasfuncs.c:528)
==31931== por 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931== por 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-71097408 .

Nathaniel J Smith
Investigador postdoctoral - Informática - Universidad de Edimburgo
http://vorpus.org

También estoy interesado en esto. ¿Hay alguna forma de ayudar con el proceso?

OpenBLAS se puede compilar con INTERFACE64=1 y numpy se puede compilar con -fdefault-integer-8 para un primer intento.

Solo un aviso. Usar enteros de 64 bits en blas es una idea terrible. Deténgase antes de llegar demasiado lejos por ese camino. Matlab, y Julia antes de que fuera y lo arreglara, hizo esto, y rompe cualquier biblioteca de terceros que asuma enteros convencionales de 32 bits en blas.

Lo que hemos estado haciendo en Julia durante los últimos ~5 meses es cambiar el nombre de todos los símbolos en openblas para agregarles un sufijo _64 para la versión de 64 bits, de esa manera puedes hacer álgebra lineal en arreglos realmente grandes si lo desea, pero cargar bibliotecas externas en el mismo proceso no provocará un error de segmentación por sombreado de nombres e intentará llamar a dgemm con la ABI incorrecta.

Hola chicos, ¿hay alguna actualización en los archivos de ruedas disponibles para Numpy?

No que yo sepa ahora mismo.
El 25 de junio de 2015 a las 4:27 a. m., "guyvertres" [email protected] escribió:

Hola chicos, ¿hay alguna actualización sobre los archivos de ruedas disponibles para
entumecido?

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-115215236 .

@guyverthree Christoph Gohlke ha estado lanzando NumPy utilizando MKL de Intel como ruedas desde hace un tiempo.

Además, vea mi publicación de blog sobre ruedas NumPy . Hice algunas ruedas NumPy en mi Dropbox usando la cadena de herramientas mingw-w64 modificada de Carl Kleffner y el puerto OpenBLAS de GotoBLAS de Zhang Xianyi . Olivier Grisel estaba buscando ayuda para modificar el bot de compilación NumPy para repetir los mismos pasos utilizados en el hilo de grupos de Google de OpenBLAS que publico en .

Mi última versión está disponible en binstar.org aunque no estoy seguro si anaconda.org es el nuevo nombre preferido ahora.
Las ruedas para py-2.6 .. 3.4 (32/64bit) tienen unos 2 meses:

• numpy-1.9.2
• scipy-0.15.1
• scikit-imagen-0.11.2

construir con mi https://bitbucket.org/carlkl/mingw-w64-for-python y un OpenBLAS más o menos reciente.
instalación de pip:

• pip install -i https://pypi.binstar.org/carlkl/simple numpy
• pip install -i https://pypi.binstar.org/carlkl/simple scipy

+1 @carlkl y deseo que estos también se puedan agregar a la compilación NumPy en Cheese Factory .

+1 Me encantaría ver que esto suceda también.

En mi humilde opinión: hay al menos tres problemas que deben resolverse antes de que se acepten estas compilaciones:

• los parches mingwpy para el repositorio numpy deben volver a crearse
• no hay un mecanismo de construcción aparte de la construcción manual todavía
• muchos paquetes de Windows de terceros (desplegados por C. Gohlke) dependen explícitamente de numpy-MKL, porque los archivos binarios están vinculados contra DLL de MKL. Esto puede cambiar en el futuro, ya que scipy ahora proporciona un mecanismo para una dependencia implícita en la implementación de scipy BLAS/Lapack. Por lo tanto, instalar (numpy-MKL y scipy-MKL) O (numpy-OpenBLAS y scipy-OpenBLAS) debería ser suficiente para todos los demás paquetes en el futuro.

@carlkl : FWIW, no estoy realmente preocupado por los paquetes de @cgohlke , eso se resolverá solo (al igual que ahora no hay problemas importantes debido a que las personas intentan combinar scipy-MKL con anaconda numpy). Y ni siquiera me preocupa que haya algún mecanismo de compilación elegante: una compilación manual está bien siempre que haya un archivo de texto que documente los pasos.

El problema principal que me preocupa es la sostenibilidad: si no podemos obtener estas cosas en sentido ascendente, tendremos que volver a validar y volver a hacer los parches cada vez que llegue una nueva versión de gcc / mingw-w64 / msvc. fuera, y probablemente no sucederá. No queremos quedar atrapados en la trampa en la que comenzamos a proporcionar compilaciones, pero luego esto se vuelve cada vez más oneroso con el tiempo, ya que tenemos que lidiar con un viejo compilador malhumorado para hacerlo.

Es por eso que he estado tratando de recaudar fondos para respaldar hacer esto aguas arriba ... Los +1 son geniales y todo eso, pero si alguien quiere donar algo de dinero o conoce una empresa que podría estar interesada en hacer que gcc generalmente se pueda usar para python extensiones en Windows, luego envíeme un correo electrónico :-) ([email protected])

Si no tiene $$ pero aún quiere ayudar, una forma de hacerlo sería enviar parches a mingw-w64 para mejorar su compatibilidad con funciones trascendentales como seno y coseno. (Resulta que MSVC ABI no está de acuerdo con todos los demás acerca de cómo se debe configurar la unidad FPU x87, por lo que la mayoría de las funciones matemáticas del software libre no funcionan del todo bien). Afortunadamente, hay buenas implementaciones compatibles con la licencia en Android " bionic" libc , por lo que esto no requiere ninguna magia matemática o una comprensión profunda de los problemas de ABI; es solo una cuestión principalmente mecánica de encontrar y extraer los archivos de origen relevantes y luego colocarlos en el árbol mingw-w64 en el lugar correcto. También podemos proporcionar más detalles sobre esto si alguien está interesado.

¿No es este el tipo de cosas que numfocus debería financiar? Si no es así, tal vez podamos volver atrás y revisar la solicitud para el PSF.

¿De cuánto dinero estamos hablando?

+1 publique ruedas para Windows en PyPI https://pypi.python.org/pypi/numpy

Si prueba pip install numpy en una instalación de Python Windows lista para usar, obtendrá el infame e inútil mensaje de error "No se puede encontrar vcvarsall.bat".

+1 realmente ayudaría a los usuarios de Windows.

No puedo jugar con https://github.com/glumpy/glumpy por esto. ¿Cuáles son los pasos de compilación manual para que Numpy funcione en Windows? Parece que el trabajo de AppVeyor está ahí , por lo que no debería haber ningún problema para cargar artefactos en GitHub .

En este momento, es literalmente imposible crear una versión rápida de numpy con licencia BSD en Windows. Estamos trabajando para solucionarlo, pero es una limitación técnica; Los +1 no tendrán ningún efecto de ninguna manera. (El trabajo de appveyor se basa en Windows, pero utiliza una biblioteca de álgebra lineal no optimizada alternativa que no es realmente adecuada para el trabajo real). Hasta que solucionemos esto, recomendaría descargar ruedas del sitio web de Christoph Gohlke, o usar Anaconda u otra distribución científica de python .

@njsmith ¿puede ser más específico? Preferiblemente con comandos exactos que no funcionan. En este momento, esto no es procesable.

Creo que 'imposible' es demasiado fuerte, pero ciertamente aún no hay un camino general obvio a seguir. Puse una página wiki sobre el estado actual aquí: https://github.com/numpy/numpy/wiki/Whats-with-Windows-builds . Siéntase libre de editar/enmendar a todos los que quieran.

@techtonik : no hay "comandos exactos que no funcionan", el problema es que no hay compiladores que tengan la combinación de características que necesitamos. mingwpy.github.io documenta el estado actual de nuestros esfuerzos para crear dicho compilador.

@ matthew-brett agradable. We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler. Es para scipy, ¿verdad? ¿Por qué es necesario para numpy?

@njsmith http://mingwpy.github.io/issues.html es una iniciativa increíble con un buen análisis. Lástima que upstream (Python) nunca lo admitirá (promueve el uso de MSVS a ciegas). Pero estoy tratando de obtener una imagen clara del estado actual.

1. ¿Es un problema de "tener una cadena de herramientas abierta para el trabajo abierto" o MSVS realmente no puede compilar C parte de numpy?
2. ¿Todavía hay fallas con las extensiones compiladas por mingw?

Para limitar el enfoque por ahora, digamos que es solo Python 2.7 + Win32. No se necesita rendimiento (solo quiero ejecutar la aplicación para probarlo allí), pero se necesitan datos de referencia sobre ese rendimiento.

Entonces, ¿cuál es la siguiente acción que se debe realizar para que esta configuración haga que la rueda de Windows esté disponible desde PyPI?

@techtonik , ahora hay versiones preliminares de ruedas numpy y scipy disponibles en https://anaconda.org/carlkl/numpy y https://anaconda.org/carlkl/scipy. El rendimiento es casi tan bueno como el de las ruedas +MKL de gohlke. No encontré fallas de segmento con mi caja de Windows en casa.

Se han discutido varios problemas con este enfoque y se resumirán en http://mingwpy.github.io (en construcción). La combinación de la cadena de herramientas basada en mingw-w64 llamada _mingwpy_ y OpenBLAS es el camino a seguir para la plataforma Windows.

_mingwpy_ tiene una configuración especial que asegura una mejor compatibilidad y un uso más conveniente en comparación con las cadenas de herramientas basadas en mingw-w64 más conocidas, es decir, _mingw-builds_, _tdm_ ...

Todo esto y más se explica en https://github.com/mingwpy/mingwpy.github.io. Siéntase libre de abrir problemas o relaciones públicas allí.

@techtonik : Creo que es un grave malentendido/tergiversación de la posición de python.org. Diría que se niegan a promover el cisma del soporte de Windows CPython en múltiples ABI incompatibles (y estoy de acuerdo con ellos en esto). Steve Dower, que se encarga del mantenimiento de las versiones preliminares oficiales de Windows, nos ha estado ayudando a descubrir cómo hacer que mingwpy sea compatible con estas versiones.

En mi opinión, el requisito previo para poner ruedas numpy en pypi es que deben ser (a) eficaces, (b) mantenibles, (c) con la licencia adecuada. Si desea que el proyecto aplique un conjunto diferente de criterios (es decir, que debemos esforzarnos en proporcionar ruedas con un rendimiento terrible), el siguiente paso es enviar un correo electrónico a la lista de correo numpy para demostrar que sus criterios son mejores.

MSVS puede compilar numpy por sí mismo, pero no puede compilar ninguna de las implementaciones de BLAS de alta calidad con licencia adecuada. Upstream mingw-w64 puede compilar numpy + BLAS (con parches), pero el resultado fallará si intenta usarlo con CPython upstream. La cadena de herramientas mingwpy de Carl puede compilar numpy + BLAS (con parches), y el resultado funcionará en algunas versiones de python (pero no en la 3.5), pero la cadena de herramientas es frágil e imposible de mantener en su estado actual; literalmente, nadie, excepto Carl, sabe cómo se construyó o podría recrearlo. Nadie en el proyecto numpy está listo para comprometerse a proporcionar "compilaciones oficiales" utilizando una cadena de herramientas con estas limitaciones, por lo que nos estamos enfocando en solucionarlas.

Hay múltiples fuentes disponibles de forma trivial de compilaciones numpy de alta calidad en Windows. Tengo mucha curiosidad: ¿por qué insistes tanto en que deberíamos lanzar algunas compilaciones de baja calidad solo para que estén en PyPI?

@njsmith Solo quería decir que mi caso de uso (que admito que de ninguna manera justificaría una inversión de recursos de desarrollador por sí solo) es distribuir un paquete muy simple en PyPI que depende de matplotlib , que a su vez depende de numpy .

Para mi caso de uso, el rendimiento no es una preocupación, pero poder tener un usuario de Windows simplemente pip install ____ mi paquete que instala recursivamente matplotlib , numpy , etc. es mucho más fácil de explique que apuntarlos a las URL para que también se instalen, especialmente para los usuarios que no entienden el ecosistema de compilación de Python. Por lo tanto, es principalmente para simplificar las instrucciones de instalación.

Nuevamente, no intento usar mi caso como justificación, solo quería compartirlo porque tenía curiosidad.

@johnthagen : Oh, claro, ¡no te preocupes! Entiendo perfectamente por qué esto es deseable en general; si parezco gruñón en estos comentarios es exactamente porque yo y otros hemos pasado mucho tiempo durante el último año tratando de arreglar esto :-). Solo le preguntaba a @techtonik específicamente porque sonaba como si estuvieran diciendo "Solo quiero probar una pequeña aplicación, así que no me importa el rendimiento", pero si solo quieren probar una pequeña aplicación, no lo hago. sé por qué les importa la parte de PyPI :-)

(Es importante tener en cuenta que cualquier rueda que coloquemos en pypi comenzará a ser utilizada de inmediato por decenas de miles de personas, la mayoría de las cuales no están leyendo este hilo. Así que creo que tenemos la obligación de asegurarnos de que lo que sea de hecho, será ampliamente utilizable para una amplia gama de casos de uso).

Creo que sería esencialmente trivial comenzar a enviar ruedas numpy de 32 bits para Python 2.7, usando ATLAS. Es probable que tengan que ser SSE2, por lo que fallan sin las instrucciones de SSE, pero eso solo afectaría a una proporción muy pequeña de usuarios. Podríamos usar nuestra cadena de herramientas de lanzamiento actual para eso. Tenga en cuenta que esto significaría que pip daría una rueda binaria para 32 bits, pero recurriría a la instalación de origen para 64 bits. ¿Sería útil?

@njsmith ¡ Gracias por la información! Aprecio todo su arduo trabajo :)

Creo que sería esencialmente trivial comenzar a enviar ruedas numpy de 32 bits para Python 2.7, usando ATLAS. Es probable que tengan que ser SSE2, por lo que fallan sin las instrucciones de SSE, pero eso solo afectaría a una proporción muy pequeña de usuarios. Podríamos usar nuestra cadena de herramientas de lanzamiento actual para eso. Tenga en cuenta que esto significaría que pip daría una rueda binaria para 32 bits, pero recurriría a la instalación de origen para 64 bits. ¿Sería útil?

@ matthew-brett, la configuración actual de numpy-vendor está rota, hay una falla de segmento en fromfile . El manejo de archivos está de alguna manera desordenado, y no estamos seguros de si eso se debe a un cambio en la versión de Wine, la versión de Ubuntu o (poco probable) un cambio en numpy. Diría que dedicar más tiempo a eso es una pérdida de tiempo; dedicar ese tiempo a mingwpy es mucho más productivo.

Tengo NumPy 1.10.4 compilado con OpenBLAS (Int32 Windows 64, v0.2.15 binario precompilado) y MKL (usando una licencia comunitaria en MKL, es decir, distribución gratuita). Pero... No puedo compilar SciPy; parece que una pequeña parte busca el compilador gfortran "compilador fortan no encontrado" si alguien tiene una idea de cómo solucionar este problema. Estoy usando ifort.exe ya que Ananconda admite estas compilaciones como complementos directos. Compilado para Python 3.5 con Microsoft Visual Studio Community 2015, si alguien puede ayudarme a descubrir cómo empaquetar esto para su distribución... entonces lo subiré al sitio web de github o anaconda. Lo aprecio.

@mrslezak : probablemente lo mejor que puede hacer es publicar en la lista de correo de desarrolladores de scipy, o abrir un nuevo error en scipy, en lugar de publicar errores aleatorios existentes :-)

Tengo mucha curiosidad: ¿por qué insistes tanto en que deberíamos lanzar algunas compilaciones de baja calidad solo para que estén en PyPI?

Solo porque estoy cansado de afeitar yaks. Sé que la gente quiere rendimiento, y es bueno que alguien tenga los recursos para hacerlo, pero para mí, personalmente, la complejidad de realizar esta tarea es enorme, así que solo puedo esperar que lo logre, pero para mí eso Puede que nunca suceda, o puede suceder en dos o tres años, durante los cuales las personas continúan chocando contra las paredes y perdiendo el tiempo en horas proporcionales a las descargas de todos los binarios de Windows de PyPI que requieren la instalación de NumPy como una dependencia directa o indirecta.

¡Uf! Probablemente la oración en inglés más larga que escribí en toda mi vida. =)

@techtonik : comparto su frustración, creo que muchos de nosotros nos sentimos frustrados por esto.

@carlkl - Me encantaría recibir sus comentarios aquí.

Claramente, hay una fuerte presión para que coloquemos una rueda de ventanas numpy. Aquí hay una lista de las ruedas más descargadas para cualquier plataforma desde hace un par de semanas: https://gist.github.com/dstufft/1dda9a9f87ee7121e0ee . matplotlib, scikit-learn y pandas windows wheels vienen en las posiciones 3, 4 y 5. Habría un gran mercado para numpy windows wheels.

Creo que las preguntas sobre la mesa son:

1) ¿Podemos comprometernos a obtener una rueda numpy que funcione y sea casi óptima en pypi a corto o mediano plazo (digamos, 6 meses)? Diría que la respuesta a esto es sí (feliz de escuchar desacuerdo);
2) ¿Vale la pena poner una rueda numpy no óptima mientras tanto para que otros construyan contra ella?

La pregunta 2 es la más difícil. "No óptimo" podría significar lento (sin blas / lapack optimizados) o difícil de soportar (no hay garantía de que podamos repetir la compilación en 6 meses).

Puedo ver argumentos en contra de "lento". Debemos tener cuidado de que, cuando las ruedas empiecen a funcionar para Windows, no activen inmediatamente preguntas de desbordamiento de pila con respuestas "Bajo ningún concepto, descargue las ruedas numpy de pypi". Creo que esas respuestas serían razonables y durarían lo suficiente como para hacernos daño.

Significado no óptimo, difícil de soportar el proceso de construcción, creo que podemos vivir, si estamos realmente comprometidos a encontrar una solución a largo plazo bastante pronto.

Hace un tiempo construí binarios ATLAS para Windows: http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

¿Tengo razón al pensar que ya podemos construir binarios numpy que pasan todas las pruebas usando estos binarios ATLAS?

En cuyo caso, ¿por qué no las subimos?

1) ¿Podemos comprometernos a obtener una rueda numpy que funcione y sea casi óptima en pypi a corto o mediano plazo (digamos, 6 meses)? Diría que la respuesta a esto es sí (feliz de escuchar desacuerdo);

Eso espero, de lo contrario significa que para entonces habremos tenido problemas inesperados con la propuesta de mingwpy o no almacenaremos en caché lo que habilita :)

2) ¿Vale la pena poner una rueda numpy no óptima mientras tanto para que otros construyan contra ella?

¿Sus compilaciones de ATLAS parecen estar hechas con Cygwin? ¿O es solo un nombre de directorio y usaste alguna versión de MingwPy?

Creo que mis compilaciones de ATLAS se realizaron con Cygwin, pero no se vinculan a Cygwin.dll, por lo que creo que serían seguras para compilar con MSVC.

mingwpy no está en problemas pero necesita su tiempo. Construir la cadena de herramientas gcc, OpenBLAS y luego numpy/scipy con diferentes variantes requiere tiempo de construcción y prueba. Y no publicaré archivos binarios sin publicar primero todos los scripts de compilación. Un mingwpy basado en gcc-5.3.0 está casi listo, así como OpenBLAS. El siguiente paso es construir ruedas numpy y scipy basadas en eso.

Esta discusión, así como las últimas contribuciones al subproceso numpy "Ruedas de Linux de distribución múltiple: pruebe", lleva a la pregunta de si OpenBLAS tiene la calidad que permite la implementación de ruedas numpy de Windows basadas en OpenBLAS. Pero no estoy seguro de que usar atlas sea una mejor solución. Tal vez las ruedas numpy deberían construirse con ambas variantes para una fase de prueba primero.

Supongo/espero que de alguna manera lleguemos a la etapa de que OpenBLAS es de calidad aceptable. Pero, hasta ese momento, me parece razonable comenzar con las ruedas numpy de ATLAS, esperando que a su debido tiempo podamos cambiar a las ruedas OpenBLAS. Sin embargo, es posible que tengamos que realizar la verificación SSE2 para las compilaciones de 32 bits: http://mingwpy.github.io/blas_lapack.html#atlas

Colocar un cuadro de progreso en la parte superior de la página de PyPI puede atraer a más personas al problema (incluidos aquellos que pueden donar para apoyar la iniciativa). El cuadro puede enumerar la estrategia actual, los criterios de aceptación (¿enlace a la prueba de rendimiento?), el estado y la acción que se realizará cuando la versión final esté lista (¿aumentar la versión principal?).

@ matthew-brett, todavía no me queda claro si su propuesta para lanzar algo es viable. ¿Qué compilador usarías? Si MingwPy, tenemos un plan claro de en qué orden hacerlo y ahora parece demasiado pronto. Si hay otro gcc, volvemos al problema de la vinculación estática y a la distribución del dolor de DLL.

Mi idea era compilar numpy con ATLAS usando MSVC. Por supuesto, eso no podría funcionar para scipy, pero al menos las personas podrían comenzar a enviar las ruedas de sus ventanas, sin importar cómo estén construidas.

Acabo de intentarlo y obtuve algunos errores de forma unresolved external symbol __gfortran_compare_string así que supongo que los binarios de ATLAS tienen algunas referencias pendientes al tiempo de ejecución de gfortran. @carlkl : ¿alguna sugerencia sobre cómo depurar?

Mezclar archivos de objetos estáticos provenientes de diferentes compiladores es algo que debe evitar como el diablo evita el agua bendita. En algunos casos funciona, pero fallará para un conjunto diferente de combinaciones de compiladores.
Por cierto: MS en sí no admite oficialmente ni recomienda mezclar objetos estáticos de diferentes versiones de su Visual Studio.

Hice algunas pruebas hace algunas semanas, cuando aparece esta pregunta: ¿se puede usar la biblioteca estática npymath.a creada por mingwpy con compiladores de MSVC? En principio , puede funcionar si se agregan a esta biblioteca algunos objetos seleccionados de las bibliotecas de tiempo de ejecución de gcc. Llegué a la conclusión de que tal enfoque es inestable y frágil.

Si atlas es una opción para construir ruedas numpy, intentaría construirlo como DLL, ¿alguna objeción?

Mezclar archivos de objetos estáticos provenientes de diferentes compiladores es algo que debe evitar como el diablo evita el agua bendita.

Siento que https://mingwpy.github.io/motivation.html (página Why) carece de una explicación muy simple y directa del problema para los módulos cargados dinámicamente . Hablé con los muchachos de Far Manager, cuyo administrador de archivos es nativo de Windows, se basa en complementos, que se cargan desde .dlls escritos en diferentes idiomas, y no tienen este problema con "exactamente el mismo compilador". Me pregunto por qué Python lo tiene: también carga módulos desde .dlls.

@techtonik , mi comentario fue sobre vincular archivos de objetos producidos por diferentes compiladores en un solo archivo binario (DLL o EXE). Eso es lo que quise decir con _mezclar archivos de objetos estáticos_. Tal enfoque _puede_ funcionar en algunas situaciones bien probadas si se maneja con cuidado. Pero está lejos de ser una forma robusta de construir binarios.

La interoperabilidad de las DLL de diferentes compiladores en un espacio de proceso común es algo completamente diferente. Por lo general, este enfoque funciona bien como regla general. Uno tiene que asegurarse de que estos archivos binarios estén vinculados a la misma DLL de tiempo de ejecución de MS si, por ejemplo, comparten descriptores de archivos. También hay otros posibles problemas de ABI que deben manejarse. Y, por supuesto, necesita un conjunto diferente de depuradores para la depuración según los compiladores que se utilicen.

minwgpy es un proyecto para admitir la creación de extensiones de python con la ayuda de mingw-w64 para usar dentro de las compilaciones estándar de MSVC CPython.

OK: logré construir numpy con enlaces MSVC contra una compilación de ATLAS.

ATLAS construir aquí:

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/atlas-3.10.1-sse2-32.tgz

Hay algunas instrucciones básicas sobre cómo construir el dll de ATLAS.

Todas las pruebas numpy pasan aparte de la verificación del script f2py , creo que es una falla benigna.

El último paso es enviar la biblioteca dinámica dentro de la rueda. @carlkl : ¿cuál es tu forma favorita actual de hacer eso?

Es bueno saberlo, también me gustaría descubrir cómo crear una rueda con
binarios incluidos: puede publicar una compilación MKL y hacer que otros prueben OpenBlas
una.
El 11 de febrero de 2016 a la 1:28 p. m., "Matthew Brett" [email protected] escribió:

OK: logré construir numpy con enlaces MSVC contra una compilación de ATLAS.

ATLAS construir aquí:

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/atlas-3.10.1-sse2-32.tgz

Hay algunas instrucciones básicas sobre cómo construir el ATLAS
dll

Todas las pruebas numpy pasan aparte de la verificación del script f2py, creo que eso es un
fracaso benigno.

El último paso es enviar la biblioteca dinámica dentro de la rueda. @carlkl
https://github.com/carlkl : ¿cuál es tu forma favorita de hacer actualmente?
¿ese?

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-183021728 .

El último paso es enviar la biblioteca dinámica dentro de la rueda.

¿Y el cheque SSE2 y el elegante rescate?

@mrslezak : la forma más fácil es colocarlo en la carpeta numpy/core, ya que se carga automáticamente en el espacio de proceso durante la importación de multiarray.pyd.

El último paso es enviar la biblioteca dinámica dentro de la rueda.

@matthew-brett: estoy 99% seguro de que la forma "correcta" de hacer esto es a través de ensamblajes SxS, cuya documentación es rigurosamente pobre, pero probablemente factible... Sé que ha pasado tiempo tratando de entenderlos, y yo También he estado leyendo, así que si quieres sentarte en algún momento y tratar de resolver los detalles, házmelo saber :-).

(El problema con todos los demás enfoques es que los procesos de Windows IIUC normalmente mantienen un único espacio de nombres global de todos los archivos DLL importados. Lo que esto significa es que si dos extensiones envían un archivo llamado foo.dll, la extensión que se cargue primero tendrá su versión de foo.dll "win" y la otra extensión terminará usándolo, el clásico problema "dll hell". Y IIUC, la única forma de evitar este comportamiento es a través de la maquinaria SxS, por fea que sea).

Nathaniel: escribí mi comprensión de los ensamblajes SxS aquí: https://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-assemblies

Mi conclusión final fue que no había esperanza y que, en cualquier caso, cambiar el nombre de la DLL de alguna forma única por proceso era una alternativa razonable.

Ralf: sugerencia para formalizar la forma de agregar enlaces SSE2, etc. al proceso de instalación: https://github.com/numpy/numpy/pull/7231

@matthew-brett: He leído esas notas, sí... y ugh suspiro, desesperanzador, ¿por qué? ¿Por los problemas del mismo directorio? ¿Y tienes alguna idea sobre cómo lograr ese cambio de nombre? (Todavía no he encontrado ningún equivalente a patchelf --replace para archivos PE, y la regeneración de archivos .lib no es trivial, aunque supongo que usar mingw-w64 no es tan malo porque puede enlazar contra .dll directamente. Al menos si no necesita cambiar el nombre de libgfortran o similar...)

(Es posible que haya algún PE equivalente a patchelf --replace en algún lugar de esta lista: http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

No veo ningún problema para cargar satlas.dll (o alternativamente libopenblaspy.dll ) junto con multiarray.pyd, ya que se prefiere este directorio durante la búsqueda de DLL. Este enfoque funciona debido al hecho de que esta DLL se carga a través LoadLibraryEx desde python en el espacio de proceso. Se debe usar la carpeta numpy/core , ya que esta es la primera aparición de una extensión de Python dependiente de blas durante la importación. Cualquier otro intento de cargar una DLL con el mismo nombre simplemente se ignora porque esta DLL ya está cargada en el espacio de proceso. Windows solo busca el nombre de la DLL por cierto.

El comienzo del infierno DLL Si dicha biblioteca depende de _más_ DLL, pero este no es el caso ya que tanto satlas.dll como libopenblaspy.dll son independientes y solo dependen de las DLL estándar del sistema Windows. Esto es lo que generalmente se denomina DLL vinculados estáticamente, lo que significa que el código de tiempo de ejecución de gcc está vinculado estáticamente.

_A modo de comparación_: para importar las bibliotecas MKL, el enfoque consiste en extender temporalmente PATH a numpy/core . Desafortunadamente, esto falla si las bibliotecas MKL más antiguas se colocan en las carpetas del sistema de Windows.

@matthew-brett @njsmith : Cambio de nombre de DLL: ¿para qué sirve?

@carlkl : el caso que nos preocupa es si numpy incluye atlas.dll , y también scipy incluye atlas.dll , y en algún momento el usuario actualiza scipy (y obtiene una versión más nueva de atlas.dll ), pero luego scipy termina usando la versión anterior de atlas.dll que viene del paquete numpy. Esto es malo, porque scipy puede depender de tener la versión más nueva, por lo que las cosas se romperán aleatoriamente dependiendo exactamente de qué compilaciones de qué paquetes están involucrados y en qué orden los importa el usuario. Esto sucede porque si numpy incluye una DLL llamada atlas.dll entonces "reclamará" el nombre atlas.dll en el espacio de nombres DLL de todo el proceso, y bloqueará cualquier otro paquete para que no use diferentes DLL con esa nombre.

Dos soluciones posibles son (a) si las cosas de SxS/activation-contexts pueden funcionar, proporciona una forma de deshabilitar el espacio de nombres DLL de todo el proceso, o (b) si numpy contiene numpy-atlas.dll y scipy contiene scipy-atlas.dll , entonces estos pueden compartir el mismo espacio de nombres en todo el proceso sin colisionar.

¿O si ambos dependen de un paquete clib_atlas separado que proporciona el dll? Luego, los requisitos de dependencia de la versión se pueden expresar como de costumbre para los paquetes de python.

@tkelman : creo que debemos descubrir cómo admitir tanto las DLL de proveedores como las DLL distribuidas por separado, ya que ambas opciones son apropiadas en diferentes situaciones. Y el caso vendido es mucho más fácil para empezar :-)

Creo que la solución lado a lado requerirá derechos de administrador para instalarse en Windows system32. Por favor, no hagas esto.

También hay ensamblados 'privados' uno al lado del otro, donde los ensamblados se encuentran en su propio árbol binario, pero hay un límite de dos marcadores de ruta de directorio superior que puede usar para apuntar al ensamblado, es decir, puede apuntar a ..\..\some_assembly pero no ..\..\..\some_assembly .

Entonces, por ejemplo, scipy/first/second/third/something.pyd solo puede apuntar a un ensamblaje en paralelo en los directorios third o second o first pero no en scipy (u otros directorios dentro de ese.

OK, construí algunas ruedas para probar, aquí:

http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

Como siempre:

pip install -f https://nipy.bic.berkeley.edu/scipy_installers/atlas_builds numpy

Automatización de compilación muy cruda aquí: https://github.com/matthew-brett/np-wheel-builder

Las ruedas pasan todas las pruebas excepto una falla falsa al ejecutar el script f2py (creo que es un error en esa prueba).

Ralf - SSE2 verifique aquí: https://github.com/matthew-brett/np-wheel-builder/blob/master/_distributor_init.py

También creé instaladores de 64 bits para Pythons 2.7, 3.4, 3.5, en la misma dirección web.

@matthew-brett, no tengo permiso para acceder a estos archivos.

@matthew-brett, la tecnología de ensamblaje SxS ya no se usa (desde VS2010), consulte https://en.wikipedia.org/wiki/Side-by-side_assembly.

¿Qué tal agregar números de versión a los nombres de los archivos DLL: libopenblaspy_0.15..dll o libatlas_3.10.1.dll o similar. Y luego use un _proxy DLL_ que se usa como reenviador DLL para los DLL versionados. Las extensiones numpy y scipy deben compilarse contra una DLL de proxy llamada, por ejemplo, _libblaslapack.dll_.

Si se utiliza atlas, en principio permitiría cargar una DLL de atlas optimizada en tiempo de ejecución. (no es necesario si se usa openblas)

Todo esto podría manejarse con la ayuda de un paquete clib_openblas y/o clib_atlas. (Ahora tengo que aprender a generar el código para una DLL de reenviador). Numpy en sí podría estar equipado con atlas o openblas. Esto debe cargarse si ni clib_openblas ni clib_atlas están disponibles.

@carlkl : creo que la página de wikipedia es confusa, y trato de decir que VS 2010 no usa SxS _para ciertas bibliotecas_, pero SxS en general ciertamente todavía se usa (por ejemplo, más adelante en esa misma página: "Desde Vista en adelante, el sistema operativo también usa WinSxS para sus componentes principales").

Creo que la forma de crear un dll de reenviador con msvc es escribir un archivo .def especial y luego usarlo al generar su .dll. Pero, ¿cómo ayuda un reenviador dll? (En osx o Linux, creo que puede ser una herramienta útil, pero en Windows todavía tiene ese molesto problema de espacio de nombres dll global).

@njsmith , debemos buscar una solución comprensible. Es cierto que SxS todavía existe. Por lo general, ya no se usa para nada más que el propio sistema operativo.

(1) La solución más fácil en mi humilde opinión es vincular a Blas Lapack estáticamente. Este enfoque crea binarios enormes y, por lo tanto, no se recomienda (al menos por mí).
(2) La segunda solución más sencilla es instalar la DLL en numpy/core y listo.
(3) La tercera solución es _forzar_ una dependencia a un paquete externo de Blas/Lapack, que ha sido versionado y simplemente precarga la DLL de Blas Lapack. El uso de pip garantiza que esté disponible la versión correcta de la DLL.
(3) Si una dependencia tan restringida no es bienvenida, podría aumentarse con una DLL proporcionada por numpy y scipy. Estas DLL deben cargarse _solo en situaciones_ en las que no se haya instalado una DLL externa. Eso significa que se preferiría un paquete Blas/Lapack externo, pero no es estrictamente necesario.
La gran ventaja de esta solución es que las versiones más nuevas de openblas/atlas con corrección de errores se pueden intercambiar sin reinstalar numpy/scipy.
(4) Uso de manifiestos y SxS. @njsmith , ¿puede completar los detalles de este caso?

Lo siento, arreglé los permisos para las ruedas, ¿funcionan ahora?

Lamento no responderle sobre las asambleas SxS. Mi comentario 'desesperado' sobre SxS no fue muy útil, intentaré desempaquetarlo.

La pregunta es si deberíamos usar ensamblajes SxS "privados", que son ensamblajes SxS que alojamos en nuestro propio árbol binario. Los ensamblajes SxS también se pueden "compartir". Los ensamblajes compartidos van a la carpeta del sistema de Windows y deben instalarse mediante un paquete de instalación de MS . Creo que eso significa que los ensamblajes compartidos no se pueden instalar a través de una rueda y, en cualquier caso, necesitarían permisos de administrador, por lo que creo que podemos rechazar los ensamblajes compartidos como una opción.

Entonces, ¿cuáles son los problemas para usar ensamblajes SxS privados?

El primer problema es que estaríamos abriendo un camino bastante nuevo si intentáramos hacer esto. No conozco ningún otro proyecto de código abierto que los esté utilizando. Le pregunté a Steve Dower sobre los ensamblajes SxS. Steve trabaja en MS y actualmente es el mantenedor de Python Windows. Me sugirió que los evitara. Parecía que nadie con quien estaba trabajando estaba familiarizado con ellos. Mis notas vinculadas anteriormente fueron un intento de comprender las pocas instancias en las que conocía a alguien (aparentemente) usándolas con éxito. Hay muy pocos buenos recursos para explicarlos.

Relacionada está la observación que Carl ya ha planteado de que la propia EM parece ser ambivalente sobre su uso. Por ejemplo, para el tiempo de ejecución de MSVC, una aplicación obvia de los ensamblados SxS, usan nombres de DLL únicos en su lugar (MSVCR90.DLL, MSVCR100.DLL, etc.).

Para usar ensamblajes SxS, creo que tendríamos que agregar un código repetitivo de inicialización a cada módulo compilado que necesita cargar otra DLL, para crear un "contexto de activación". EDITAR: Nathaniel me recordó que Windows activará automáticamente un nuevo contexto de activación si ve evidencia de un "manifiesto" de ensamblaje en paralelo asociado con la DLL (que puede estar incrustado en la DLL, pero también ser un archivo XML externo) .

Entonces, no desesperado, pero duro.

Lo siento por esta pregunta tan básica, pero, en Windows, si cargo la biblioteca foo.dll que contiene my_symbol en un módulo de extensión, ¿qué sucede si cargo la biblioteca bar.dll ? también contiene my_symbol , en otro módulo de extensión? Supongo que son accesibles por separado en mi proceso, por lo que la primera extensión obtendría foo: my_symbol y la segunda extensión obtendría bar:my_symbol . ¿Alguien puede señalarme una referencia?

Si eso es correcto, entonces seguramente todo lo que necesitaríamos, para evitar el infierno de DLL, es tener un nombre de DLL que sea muy poco probable que se use por accidente en el mismo proceso (donde el usuario no tenía la intención de usar nuestro DLL exacto).

Durante la vinculación, cada símbolo está vinculado a una DLL específica identificada por su nombre. Durante el tiempo de ejecución, uno debe asegurarse de que se cargue la DLL correcta si se puede encontrar más de una DLL con el mismo nombre. Por lo tanto, el orden de búsqueda es importante.
Ejemplo My anaconda.org numpy wheels usa la biblioteca openblas con el nombre libopenblas_py_.dll para evitar un conflicto de nombres con una libopenblas,dll no estándar utilizada por Julia.

Las versiones recientes de julia ahora usan un nombre diferente libopenblas64_ para reflejar el ABI no estándar con el que construimos. En 32 bits no cambiamos el nombre de ningún símbolo o el nombre de la biblioteca ya que no hay muchas razones para elegir enteros de 64 bits en la interfaz.

El sombreado del nombre de los símbolos dentro de las bibliotecas compartidas fue en realidad un problema mayor en Linux y Osx que en Windows, pero hicimos lo mismo en todas partes para mantener la coherencia.

Aunque eso no descarta la posibilidad de que en 32 bits, donde las ABI son las mismas, no podamos rompernos entre nosotros de otras maneras, como necesitar una versión demasiado antigua o demasiado nueva para la otra.

Pulí un poco el proceso de compilación; consulte https://github.com/matthew-brett/np-wheel-builder

Ahora que el proceso está razonablemente automatizado, creo que es práctico seguir construyendo estas ruedas en los próximos lanzamientos si es necesario. Estoy feliz de hacer esto como administrador de versiones de Windows hasta que mingwpy cumpla con las especificaciones.

He probado estas ruedas en Python 2.7, 3.4, 3.5 de 32 y 64 bits, y algunas otras también lo han hecho, así que creo que están en buen estado.

¿Hay algo más que pueda hacer para asegurarles que vale la pena ponerlos en pypi, como preguntó el OP?

¡Hola a todos! Solo quería participar en esta discusión porque me ha frustrado mi incapacidad para instalar numpy y scipy desde la fuente durante bastante tiempo, por lo que ciertamente es beneficioso para mí leer sobre lo que es pasando en este frente.

@matthew-brett: Este script de automatización es increíble . Incluso si no llega a PyPI, parece una forma muy viable de construir numpy desde la fuente (vea este número que abrí aquí ). También está muy cerca de poder construir scipy en el sentido de que puedo construir todo, pero luego las pruebas parecen causar una falla de segmento en algún lugar de Python.

Además, para cualquier persona que realmente haya estado construyendo ruedas numpy , he estado tratando de reunir una documentación pulida y actualizada sobre la construcción de estas bibliotecas desde la fuente para reemplazar lo que está actualmente en línea, por lo que se lo agradecería mucho. la entrada de la gente en ese frente también!

Gracias por los comentarios, y su trabajo en la documentación de la compilación, que serían muy útiles.

Supongo que vio http://mingwpy.github.io - hay una buena cantidad de cosas allí, por supuesto, específicas del proyecto mingw-w64 y la cadena de herramientas mingwpy.

¡Gracias @matthew-brett! Pasa numpy.test() . La prueba f2py.py fue un problema en test_scripts() con virtualenvs que se solucionó en numpy-SHAd3d2f8e , pero recibo 3 advertencias, 2 obsolescencia y 1 tiempo de ejecución.

Una última solicitud, con suerte menor, ¿es posible mostrar una insignia de compilación en su repositorio np-wheel-builder y/o PyPI? Parece que buildbot 0.8 los tiene, e incluso hay un paquete/repositorio de python para que se vean bien, BuildbotEightStatusShields-0.1 .

Además, tengo curiosidad, me he alejado de la compilación ATLAS Windows de 64 bits debido a la falta de parámetros de ajuste. ¿Realmente "tomó todo el día" o hay un conjunto adecuado de valores predeterminados de arquitectura?

FYI: Continuum acaba de lanzar Anaconda con mkl numpy optimizado. Creo que han estado monitoreando este hilo.

Ahora para compilaciones scipy con las mismas bibliotecas atlas. ¿Requiere gfortran?

Si. De lo contrario, no podrá compilar ninguno de los archivos .f en scipy . ¡Buena suerte con esto! Como dije antes, estuve _muy cerca_, pero si eres capaz de pasar las pruebas, ¡sería genial!

Sí, me temo que la compilación de ATLAS tomó alrededor de 8 horas en una máquina sin hacer nada más. El script de compilación de ATLAS se encuentra en el repositorio np-wheel-builder .

Con respecto a las noticias MKL , eso es genial si eres un usuario conda , aunque creo que usar una distribución de Python con numpy y scipy preinstalados es algo que se ha fomentado durante algún tiempo. Hábleme cuando también pueda obtener las bibliotecas MKL de forma gratuita. :)

Para construir con gfortran, creo que mingwpy es nuestra mejor esperanza.

@matthew-brett: ¡Gracias por tomarse el tiempo para construir ATLAS! Intenté ejecutar su secuencia de comandos antes y seguí teniendo problemas, probablemente debido a incompatibilidades específicas de la máquina.

Lo siento por los problemas. Acabo de crear los archivos binarios de ATLAS en el repositorio np-wheel-builder, estaba en una instalación nueva de Windows Server 2012 y Cygwin de 64 bits, con las versiones exactas de ATLAS y lapack enumeradas. Los archivos fuente que utilicé están en http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/. Si tiene otra versión de ATLAS, podría ponerse peludo fácilmente.

Hmmm... ese es probablemente el caso. Nuevamente, muy apreciado dado el esfuerzo que les tomó hacerlo. Si pueden encontrar una manera de implementar compilaciones de ATLAS compatibles con Windows que no requieran tanto tiempo y recursos como ahora, ¡sería genial!

@gfyoung

Hábleme cuando también pueda obtener las bibliotecas MKL de forma gratuita. :)

Consulte https://software.intel.com/sites/campaigns/nest/ y https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 , ¿o se refería a la fuente?

@tkelman , lo acabo de ver en el nuevo sitio del proyecto mingwpy de @carlk, pero la licencia comunitaria de Intel, Nest, no tiene ifort , y sin eso, ¿qué tan scipy?

@tkelman : Ups, no estoy seguro de por qué me había olvidado de las licencias comunitarias. Sin embargo, @tkelman plantea un punto válido.

@tkelman : Podría intentarlo con MinGW, pero por lo que experimenté, desafortunadamente no funciona. Ni siquiera te permitirá pasar numpy debido a problemas de compatibilidad.

@mikofski correcto, no ayuda a scipy dada la falta de compiladores. Actualmente, las únicas opciones para compilaciones de scipy serán mingwpy, o la compilación MSYS2 all-gcc-all-the-time de Python (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- python-scipy). Este último, por supuesto, no será compatible con los binarios cpython o pypi construidos por msvc, por lo que no abordará todos los módulos más allá de scipy.

@matthew-brett: ¿cuál es el déficit de velocidad de estas ruedas ATLAS en comparación con openblas y/o MKL?

¿Alguien ha mirado en PGI Fortran. No se menciona en el sitio del proyecto @carkl mingwpy. Traté de usarlo una vez, bajé bastante por ese agujero de conejo, pero no puedo recordar cuál fue el tapón del espectáculo. Creo que la licencia es permisiva a pesar de que es de código cerrado. ¿Quizás PGI Fortran jugará mejor con msvc?

@mikofski : No lo tengo frente a mí, pero cuando miré PGI el año pasado, recuerdo que mi conclusión fue que era incluso peor que Intel (en términos de obligarlo a agregar restricciones incompatibles con FOSS a su licencia) .

De acuerdo, ¿quizás algunos fondos de enfoque numérico puedan destinarse a una solución BLIS/FLAME para arquitecturas x86?

Aparentemente, Nvidia/PGI contribuirá con su interfaz de Fortran como fuente abierta a LLVM a finales de este año. https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

De acuerdo, ¿quizás algunos fondos de enfoque numérico puedan destinarse a una solución BLIS/FLAME para arquitecturas x86?

No lo creas. BLIS parece un proyecto muy poco saludable (y libflame aún más); poca actividad en términos de compromisos, tráfico de listas de correo, etc. Además, han tenido una financiación significativa (https://github.com/flame/blis#funding), por lo que no es como si unos pocos miles de dólares hicieran mágicamente esos maduran los proyectos.

No veo muy bien de dónde viene o va esta discusión: tenemos una solución provisional que Matthew casi ha completado (usando ATLAS) y, lo que es más importante, tenemos una solución a largo plazo en la que se está trabajando muy activamente (MingwPy + AbrirBLAS). Además, OpenBLAS se usa mucho más; el uso de ese proyecto tanto en la pila de Scipy como en Julia debería madurarlo más rápido.

@rgommers : La conversación fue a donde fue porque @mikofski y yo intentábamos usar la solución @matthew-brett para construir scipy . Sin embargo, parece que ambos nos enfrentamos al mismo problema: el compilador de Fortran. Yo mismo he intentado usar el gfortran.exe instalado tanto para MinGW32 como para MinGW64 sin mucho éxito debido a toneladas de problemas externos sin resolver por alguna razón u otra.

La compilación de @gfyoung Matthew usa MSVC. No tiene sentido intentar usar gfortran con MSVC, se sabe que no funciona. El resumen de la situación de construcción es:

• No Fortran, entonces puede usar MSVC ahora.
• Con Fortran, puede usar uno de MingwPy, MSVC + ifort o icc + ifort.
• Para la pila de Scipy, queremos una solución gratuita que construya ruedas para numpy, scipy, etc. Para eso, MingwPy es.

@rgommers Lo siento por descarrilar la conversación. Tiene toda la razón, la solución de @matthew-brett para trabajos numpy, y el proyecto mingwpy de @carlk ya está financiado por num focus. Intentaré ver si puedo lograr que mi empresa lo apoye. Ya soy miembro de num focus. Aproximadamente a la mitad de scipy 2829 y creo que he llegado a la misma conclusión. Yo sólo espero que funcione. A corto plazo, continuaremos usando @cgohlke o cambiaremos a anaconda. ¡Gracias de nuevo!

Además de enviar compilaciones a pypi, ¿quizás un último problema para @ matthew-brett es un escudo de buildbot en su repositorio de scripts de compilación np? ¡Gracias! Entonces esto se puede cerrar?

Antes de que esto se cierre, una pregunta rápida: construí @matthew-brett numpy para que apunte a ATLAS. Sin embargo, cuando intento compilar scipy usando ifort , también selecciona mi otro archivo site.cfg que usa MKL ubicado en mi directorio de inicio. De hecho, puedo construir con éxito contra numpy , y las pruebas pasan excepto por un par de errores debido a errores de redondeo de minutos. Sin embargo, tengo curiosidad, ¿qué hizo scipy cuando lo construí? ¿Usó las bibliotecas MKL o intentó usar las bibliotecas ATLAS ya creadas con numpy ?

Hay un resumen de los compiladores de Windows Fortran en https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows

@gfyoung : simplemente siguiendo una combinación de suposiciones y memoria distante, creo que scipy recogerá primero el site.cfg en su propio directorio, y si falta, recogerá la configuración de la compilación numpy. Esto, a su vez, señalará dónde estaban las bibliotecas, cuando construí las ruedas. Por lo tanto, debe volver a escribir site.cfg para que scipy recoja las bibliotecas de atlas de np-wheel-builder: el script build_numpy.py hace eso para la compilación numpy.

BLIS parece un proyecto muy poco saludable (y libflame aún más); poca actividad en términos de compromisos, tráfico de listas de correo, etc.

No estoy seguro si los llamaría poco saludables, porque no están tratando de ser proyectos FOSS administrados por la comunidad; son esencialmente un espectáculo de una sola persona, y les gusta de esa manera (al menos por ahora). He estado en contacto con ellos de vez en cuando durante el último año, y la buena noticia es que el enfoque actual de sus esfuerzos está exactamente en las cosas que necesitamos (selección del kernel en tiempo de ejecución y configuración de subprocesamiento en tiempo de ejecución); la mala noticia es que no hay mucho que hacer excepto esperar a que el arquitecto reorganice las cosas a su gusto. ¿Tal vez 6 meses verán algunos resultados?

Parece que BLIS, etc. son una opción bastante lejana en este momento, y que tendremos que planificar para el caso en que no funcione.

Nathaniel: ¿alguna sugerencia sobre dónde obtener buenos puntos de referencia? No creo que numpy.bench() haga nada más. Intenté ejecutar asv , pero muchas pruebas fallan porque Windows numpy no tiene complex256 .

Supongo que las partes de asv que funcionan son útiles. O incluso %timeit np.dot(big_array, other_big_array) sería útil para tener al menos una idea aproximada de dónde estamos parados :-)

Además, por cierto, aquí hay una solución general para el problema del espacio de nombres global DLL de Windows, que nos permite escribir un delocate Windows: https://github.com/njsmith/redll

Desafortunadamente, la falla de asv complex256 rompe secuencias completas de pruebas en dtypes. Aunque supongo que no sería muy difícil de arreglar.

Prueba simple con esto:

def test_dot():
    """
    Test the dot product
    """
    i = 1000
    a = random((i, i))
    b = numpy.linalg.inv(a)
    result = numpy.dot(a, b) - numpy.eye(i)

sugiere que, como Clint Whaley ha advertido antes , ATLAS de 64 bits no está bien optimizado en Windows. Con MKL de 64 bits a través de las ruedas de Christoph Gohlke:

In [9]: %timeit test_dot()
1 loop, best of 3: 764 ms per loop

Con mis ruedas, construidas con ATLAS de 64 bits:

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

La diferencia es mucho menor con las ruedas de 32 bits (en una máquina diferente de 32 bits). MKL:

In [3]: %timeit test_dot()
1 loop, best of 3: 663 ms per loop

contra ATLAS:

In [4]: %timeit test_dot()
1 loop, best of 3: 1 s per loop

@rcwhaley - Te envío, en caso de que tengas algunas ideas aquí. Esto es ATLAS 3.10.1...

Aquí hay otra máquina con Windows de 64 bits con un procesador más moderno; también muestra una ralentización de ~3x.

MKL:

In [3]: %timeit test_dot()
1 loop, best of 3: 400 ms per loop

ATLAS:

In [3]: %timeit test_dot()
1 loop, best of 3: 1.28 s per loop

Sí, el problema complejo 256 no es difícil de solucionar: https://github.com/numpy/numpy/pull/7251

3x es mucho, pero no tan dramático como con lapack_lite , ¿verdad? Creo que está bien para una solución a corto plazo. Y no es que los antiguos instaladores .exe de 32 bits fueran mejores.

Además, por cierto, aquí hay una solución general para el problema del espacio de nombres global DLL de Windows, que nos permite escribir una ubicación de Windows: https://github.com/njsmith/redll

buena declaración de licencia :)

@gfyoung 'site.cfg' se busca en:

1) Directorio del archivo principal setup.py que se está ejecutando.
2) Directorio de inicio del usuario que ejecuta el archivo setup.py como ~/.numpy-site.cfg
3) Directorio de todo el sistema (ubicación de este archivo...)

@rgommers Lo siento por descarrilar la conversación.

No te preocupes, nada se descarriló.

Tiene toda la razón, la solución de @matthew-brett para trabajos numpy, y el proyecto mingwpy de @carlk ya está financiado por num focus. Intentaré ver si puedo lograr que mi empresa lo apoye. Ya soy miembro de num focus. Aproximadamente a la mitad de scipy 2829 y creo que he llegado a la misma conclusión. Yo sólo espero que funcione. A corto plazo, continuaremos usando @cgohlke o cambiaremos a anaconda. ¡Gracias de nuevo!

Frio. Y es bueno ver que estás interesado en MingwPy. Tenga en cuenta que ahora tiene su propio ML, que puede ser de interés: https://groups.google.com/forum/#!forum/mingwpy

@rgommers , @matthew-brett: Ah, sí, parece que se estaba construyendo con MKL de antemano. Apunté directamente mi site.cfg a la compilación de ATLAS, y las compilaciones de scipy pero fallaron durante las pruebas. ¡Tan cerca!

@rgommers - sí - el rendimiento es mucho peor sin ATLAS (con lapack_lite):

In [2]: %timeit test_dot()
1 loop, best of 3: 17.7 s per loop

Supongo que la pregunta restante aquí es si vale la pena estandarizar a OpenBLAS numpy (con todas las pruebas numpy aprobadas), aceptando el riesgo de que esto sea más probable que cause errores numéricos en proyectos que usan numpy.

Un argumento para hacer esto sería que parece que tendremos que ir en esta dirección a corto/mediano plazo, y podría ser mejor empezar ahora y comprometernos con las miserables búsquedas de errores que eso implicará. Al menos estaremos en buena compañía con los mantenedores de Julia.

Numpy también tiene un conjunto bastante diferente de tolerancia al riesgo frente a compensaciones de rendimiento, y una proporción de usuarios a desarrolladores, que Julia. Por lo tanto, creo que podría tener mucho sentido que numpy adopte un enfoque más conservador e opte por lento pero confiable como predeterminado, trabajando para permitir openblas como una opción de opción no predeterminada. Aunque esos tiempos de construcción de 8 horas no suenan divertidos, no es de extrañar que nadie nos haya preguntado sobre el uso de Atlas con Julia.

trabajando para permitir openblas como opción opcional no predeterminada

El problema es que no estoy muy seguro de cómo podría funcionar este proceso :-/. No tenemos ninguna buena manera de distribuir compilaciones alternativas a los usuarios (a largo plazo, espero que podamos obtener variantes de compilación en pypi como numpy[openblas] y así sucesivamente, pero eso no sucederá pronto) , no tenemos ninguna forma de mejorar las compilaciones de Openblas excepto distribuirlas y esperar los informes de errores, y la principal alternativa a las compilaciones de ATLAS para las personas que están motivadas a buscar una no serán las compilaciones de Openblas, será MKL compila de algún tercero :-/.

Supongo que otra opción para poner sobre la mesa sería distribuir compilaciones de BLIS utilizando su núcleo de referencia/SSE2. Debido a que BLIS todavía solo tiene una configuración de tiempo de compilación, esto no será competitivo con openblas, pero podría ser competitivo con ATLAS, y los beneficios en comparación con ATLAS son que el tiempo de compilación es _mucho_ más rápido y la posibilidad de que sea una buena solución a largo plazo. son difíciles de estimar pero ciertamente mejores que ATLAS siendo una buena solución a largo plazo (que yo pondría en cero). Si vamos a hacer control de calidad de algo de todos modos, al menos estaríamos dirigiendo esa energía a algo que _podría_ tener un futuro.

Algunas preguntas que necesitarían respuesta antes de considerar seriamente esta opción:

(1) No estoy seguro de si la compatibilidad con subprocesos múltiples de BLIS es o no competitiva con la de ATLAS (sé que hay algunas opciones de subprocesos múltiples en la fuente, y sé que el desarrollador principal no considera que esté "terminado" todavía , es decir, competitivo con MKL, pero hay mucho espacio entre ATLAS y MKL).

(2) para el caso, tampoco tengo idea de cómo le va a BLIS en un modo no sintonizado en los puntos de referencia anteriores.

(3) En realidad, no he intentado construir BLIS en Windows, y existe el problema de que es solo un BLAS, no un LAPACK, no estoy seguro de qué tan problemático es esto para numpy.

¿Qué tan receptivo es BLIS a los informes de errores? Openblas parece ser bastante bueno
sobre esto.

El lunes 15 de febrero de 2016 a las 15:48, Nathaniel J. Smith <
[email protected]> escribió:

trabajando para permitir openblas como opción opcional no predeterminada

El problema es que no estoy muy seguro de cómo podría funcionar este proceso :-/.
No tenemos ninguna buena manera de distribuir compilaciones alternativas a los usuarios (en el
a largo plazo, espero que podamos obtener variantes de compilación en pypi como numpy [openblas]
y así sucesivamente, pero eso no sucederá pronto), no tenemos ninguna forma de
mejorar las compilaciones de openblas, excepto distribuirlas y esperar el error
informes, y la principal alternativa a las compilaciones de ATLAS para personas que son
motivados para buscar uno no serán compilaciones openblas, serán compilaciones MKL
de algún tercero :-/.

Supongo que otra opción para poner sobre la mesa sería distribuir BLIS
construye usando su referencia/kernel SSE2. Porque BLIS todavía solo tiene compilación
configuración de tiempo esto no será competitivo con openblas, pero podría ser
competitivo con ATLAS, y los beneficios frente a ATLAS son que la construcción
el tiempo es _mucho_ más rápido, y la posibilidad de que sea un buen largo plazo
son difíciles de estimar pero ciertamente mejores que ATLAS siendo una buena
solución a largo plazo (que yo pondría en cero). Si vamos a hacer control de calidad
algo de todos modos, entonces al menos estaríamos dirigiendo esa energía a algo
que _podría_ tener un futuro.

Algunas preguntas que necesitarían respuesta antes de considerar seriamente esto
opción:

(1) No estoy seguro de si la compatibilidad con subprocesos múltiples de BLIS es o no
competitivo con ATLAS (sé que hay algunas opciones de subprocesos múltiples en
la fuente, y sé que el desarrollador principal no considera que sea
"hecho" todavía, es decir, competitivo con MKL, pero hay mucho espacio entre
ATLAS y MKL.)

(2) para el caso, tampoco tengo idea de cómo le va a BLIS en un modo no sintonizado
en los puntos de referencia anteriores.

(3) En realidad, no he intentado compilar BLIS en Windows, y está el
problema con el que lidiar es solo un BLAS, no un LAPACK, no estoy seguro de cómo
gran parte de un problema esto es para numpy.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-184387401 .

Creo que libflame es el equivalente de lapack en blis. Hay una interfaz de compatibilidad con lapack2flame descrita en los documentos de referencia .

¿Qué tan receptivo es BLIS a los informes de errores?

Aún no lo sabemos.

Sin haber probado BLIS, creo que suena como una locura ir y enviar binarios numpy construidos contra lo que es básicamente un proyecto de un solo hombre de baja actividad que muy pocas personas usan.

Todavía no he visto una buena razón en este hilo para desviarme del plan MingwPy + OpenBLAS. No-scipy-ATLAS-MSVC-binaries es bueno tener un recurso provisional, pero menos importante que la solución MingwPy a mediano/largo plazo y si el recurso provisional se convierte en un gran esfuerzo en sí mismo, entonces diría que no vale la pena el esfuerzo .

Los documentos de BLIS/libflame sugieren que, si intentara construir una biblioteca BLAS/LAPACK completa en Windows, sería un camino solitario.

Estoy feliz de hacerlo una vez que los desarrolladores acuerden que eso debería funcionar y es compatible.

ATLAS ha sido la biblioteca predeterminada en Linux durante mucho tiempo. No parece irrazonable imaginar que ese podría ser el caso de las compilaciones compatibles con Windows BSD por un tiempo.

@tkelman , gracias por su análisis, creo que tiene razón, ese tonto debe concentrarse en la corrección. Pero sería bueno unir fuerzas para apoyarse en algunos de los errores más agotadores de OpenBLAS y desarrollar pruebas más completas. Me viene a la mente este error de OpenBLAS : algo oscuro, muy difícil de depurar.

Creo que para este problema en particular, el de proporcionar ruedas numpy en pypi para que un usuario casual del paquete "x" que depende de "y" (por ejemplo: matplotlib) que depende de numpy se instale usando pip, sin causar que el usuario casual arroje levanten los brazos y digan algo como "Python es demasiado difícil". y regrese a MATLAB. El Zen de Python dice que debería haber una forma obvia de hacerlo. Dicho esto, cualquier cosa en pypi por numpy en particular tiene un cierto peso de que _es_ estable, o más que un proyecto paralelo aleatorio, con la posible excepción de cgohlke. Obviamente, el pensamiento y la anaconda se perciben al menos en la industria como más estables.

Creo que, a corto plazo, la compilación de ATLAS debería subir con el mensaje de advertencia de que no es posible compilar con scipy. Si este buildbot se puede automatizar, entonces está hecho, ¿verdad? Con suerte, las futuras compilaciones de ATLAS de 8 horas deberían ser raras. Quizás algún día se resuelva el problema de Windows de 64 bits. El problema de la excepción SSE2 es un fastidio, así que otro mensaje de advertencia en pypi. Además, ATLAS ya es el estándar en Linux y fue el estándar en los paquetes superpack bdist_winst anteriores, lo que brinda aún más soporte a este camino.

Entonces, para el futuro cercano, ya te has decidido por mingwpy. Aquí hay muchas opciones que no tienen que ser resueltas ahora.

A largo plazo, estoy emocionado de que blis/flame sea el futuro. Da un poco de miedo que muchas de nuestras herramientas matemáticas dependan del código FORTRAN de los años 70. La solución solo de CA es un gran avance y, en mi opinión, es algo para apoyar con entusiasmo.

Pero más siempre es mejor para los desarrolladores experimentados, por lo que mantener viva la documentación para las opciones no estándar también es bueno si dichos desarrolladores experimentados tienen el tiempo y la inclinación para construir y probar en ese momento.

Si no intenta usar uno de los núcleos optimizados en blis, entonces probablemente no encontrará el problema (editar: singular) que he tenido abierto allí desde 2014. Creo que el sistema de compilación solo usa enlaces simbólicos para el optimizado kernels, por lo que no confundirá el git de msys2 si intentara construir solo la configuración de referencia allí. Construir desde cygwin funcionó la última vez que lo intenté, aunque fue hace algún tiempo y no puedo recordar lo que pude haber necesitado para modificar localmente. Vale la pena construir, probar y comparar si la alternativa es Atlas, pero considéralo no probado y, por lo tanto, de alto riesgo a su manera hasta que lo hagas.

@mikofski , para ser justos, Lapack es de los 90, es realmente el elefante de Fortran en la habitación.

@tkelman : para ser claros, los problemas que presentó fueron específicamente con el sistema de compilación nativo de Windows, ¿verdad? Por curiosidad, probé la compilación cruzada de blis para Windows desde Linux (usando el compilador cruzado mingw-w64 instalado desde los paquetes de Debian), y me sorprendió descubrir que solo tomó ~2 minutos. Hice "./configure reference; make -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=" y todo funcionó. ( CPICFLAGS= es solo para suprimir un montón de advertencias sobre "ignorar -fPIC , porque ese es el valor predeterminado", y probablemente ni siquiera necesitaba anular AR , pero oye ¿Por qué no?) Tengo algunas advertencias sobre printfs en bli_pool.c y bli_fprintm.c que usan %ld para imprimir intptr enteros, por lo que probablemente haya algunos problemas con LLP64 hacer ejercicio.

@rgommers :

Sin haber probado BLIS, creo que suena como una locura ir y enviar binarios numpy construidos contra lo que es básicamente un proyecto de un solo hombre de baja actividad que muy pocas personas usan.

¡Estás absolutamente en lo correcto! El problema es que todas nuestras opciones son terribles :-(.

Entonces, obviamente, MKL tiene una licencia definitivamente mala.

ATLAS tiene un rendimiento definitivamente malo que nunca mejorará.

Y OpenBLAS, creo que tenemos la evidencia para decir en este punto, simplemente no se puede mantener y no es probable que se vuelva tan pronto :-(. El proyecto tiene cinco años, todavía tiene cosas fundamentalmente rotas como el ejemplo de volatile aleatorio de Julian

Entonces, la razón por la que sigo mencionando BLIS no es porque crea que BLIS es definitivamente la solución, sino como una especie de optimismo calculado: BLIS _podría_ volverse tan rápido como MKL/OpenBLAS, tan confiable como ATLAS/MKL y tan abierto a la comunidad. contribuciones como OpenBLAS; o de nuevo, puede que no. Pero no parece haber ningún otro proyecto que tenga una esperanza real de alcanzar todos esos criterios. [Y esto ni siquiera menciona las otras ventajas, como el hecho de que puede admitir matrices de forma nativa; no es inimaginable que podamos eliminar todo nuestro horrible código de despacho BLAS de casos especiales.]

IIUC, GotoBLAS fue mantenido por un solo desarrollador de tiempo completo (Kazushige Goto) que trabajaba en UT Austin con Robert van de Geijn como PI. BLIS es mantenido por un solo desarrollador de tiempo completo (Field G. Van-Zee) que trabaja en UT Austin con Robert van de Geijn como PI. Así que no es que esto no pueda funcionar :-) Pero sí, no va a suceder mágicamente si esperamos; si alguna vez va a haber una comunidad de desarrolladores a su alrededor, será porque alguna comunidad mostró su jardín delantero con carpas como "hey, aquí estamos, nos estamos mudando y haciendo que esto funcione para nosotros, espero que no te importe". Y lo que realmente necesitamos saber para determinar su viabilidad a largo plazo es, como, "qué tan confiable es realmente" y "qué tan susceptibles a los parches son" y esas cosas, que no podemos saber a menos que comencemos a probarlo y enviarlo. parches y demás.

En conclusión: en serio, no sé cuál es nuestra mejor opción, pero meter los dedos de los pies en el agua de BLIS parece una buena idea; incluso si decidimos que queremos esperar, al menos aprenderemos algo.

Presenté varios temas y uno o dos PR. El hecho de que haya enlaces simbólicos en el repositorio significa que la construcción desde msys2 está rota (o solo funciona si configura las opciones de msys2 de una manera específica). La construcción cruzada desde cygwin o linux (aunque no confiaría en Wine para ejecutar las pruebas) debería funcionar, pero tuvo problemas en 2014 con malloc alineado, y los núcleos del puente arenoso fallaron en una prueba. Acabo de reconstruir los núcleos del puente de arena en el último maestro de blis con una cruz de cygwin (en una computadora portátil skylake más nueva) y es posible que la falla de segmento ya no esté. Quién sabe cuándo o qué lo arregló, tendría que bisecar.

Creo que esto se ha mencionado antes, pero podríamos construir binarios ATLAS para SSE2, SSE3, AVX y ponerlos en una estructura de directorios como:

numpy/.lib/sse2/numpy-atlas.dll
numpy/.lib/sse3/numpy-atlas.dll
numpy/.lib/avx/numpy-atlas.dll

Entonces podríamos usar numpy/_distributor_init.py para verificar la CPU actual y precargar la biblioteca correspondiente.

Sugerí hacer básicamente lo mismo, pero para blis en lugar de atlas, a @njsmith. También vale la pena comparar qué tan bien funciona el subprocesamiento en blis frente a atlas. La configuración de referencia de blis no habilita el subproceso de forma predeterminada, aunque ajustar una definición en un archivo de encabezado debería ser todo lo que se necesita para cambiar eso.

Configuré Appveyor para construir los binarios. La iteración actual de la compilación se está produciendo aquí: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Las ruedas construidas llegan aquí: https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

Cualquier problema adicional en la compilación de Appveyor debería ser fácil de resolver, por lo que creo que estas ruedas están listas para cargarse en pypi cuando esté listo, presumiblemente mañana en algún momento.

@rgommers , @matthew-brett: Con respecto a site.cfg , parece que su respuesta se aplica solo a numpy . Parece que scipy no busca site.cfg en el mismo directorio que setup.py solo comienza a buscar site.cfg primero en su directorio de inicio antes de establecer por defecto el numpy configuración.

OK: el script de compilación se ejecuta sin errores, incluidas las pruebas de la rueda instalada: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Ruedas aquí: http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

Los instalé y probé en otra máquina de 64 bits y en otra máquina de 32 bits.

Entonces, creo que estos están listos para funcionar. ¿Alguna objeción a que los suba a pypi?

Podría ser una buena idea tener una nota en pypi que explique/vincule a una explicación de la diferencia entre estas ruedas y las de gohlke (mkl) para evitar la confusión de las personas que se preguntan por qué las ruedas aparecen ahora en pypi y cuál es la diferencia. entre ellos están.

Una pregunta secundaria, lo siento, pero me preguntaba qué

  # Pin wheel to 0.26 to avoid Windows ABI tag for built wheel
  - pip install wheel==0.26

en el script appveyor significa?

Buena sugerencia sobre la explicación: intentaré averiguar cómo agregar eso para esta versión existente.

Wheel > 0.26 agrega una etiqueta ABI adicional a la rueda de Windows. Wheel==0.26 da un nombre de rueda como este:

numpy-1.10.4-cp27-none-win32.whl

Con Wheel > 0.26, obtienes una etiqueta ABI adicional, como esta:

numpy-1.10.4-cp27-cp27m-win32.whl

(Creo) - que especifica la ABI de Windows. Esto es molesto porque pip anterior no instalará estos tipos, por lo que me parece que el nombre sin ABI es mejor por ahora.

OK - Propongo agregar este texto a la página actual de pypi:

Todas las ruedas numpy distribuidas desde pypi tienen licencia BSD.

Las ruedas de Windows están vinculadas con la biblioteca ATLAS BLAS / LAPACK, restringidas a las instrucciones SSE2, por lo que es posible que no brinden un rendimiento de álgebra lineal óptimo para su máquina. Consulte http://docs.scipy.org/doc/numpy/user/install.html para ver alternativas.

Yo diría de otra manera:

Estas ruedas de Windows tienen un rendimiento de álgebra lineal subóptimo (enlace a punto de referencia como http://speed.python.org), porque están vinculados con la biblioteca ATLAS BLAS / LAPACK, que están restringidas a las instrucciones SSE2 (y cuya instrucción no restringida debería estar ahí?). Si necesita rendimiento, puede apoyar el proyecto mingwpy que tiene como objetivo brindar más rendimiento a las extensiones de Python compiladas en esta plataforma. Ver ??? para más detalles y http://docs.scipy.org/doc/numpy/user/install.html para alternativas.

Bueno, las versiones actuales de numpy/scipy de mingwpy usan openblas, pero creo que eso no está relacionado con mingwpy vs MSVC como compilador. También podríamos enviar openblas con estas ruedas, pero me preocupaba que openblas aún no fuera lo suficientemente confiable para usar en una rueda estándar que admitimos.

OpenBlas parece lo suficientemente estable, sé que Anaconda lo usa para su Linux
construye ahora. No hay compilaciones actualizadas de Windows Python 3.5 x64
allí, los puntos de referencia muestran que es casi igual a MKL. Definitivamente lo intentaría si
alguien podría armar una rueda.
El 16 de febrero de 2016 a las 22:36, "Matthew Brett" [email protected] escribió:

Bueno, las versiones actuales de numpy/scipy de mingwpy usan openblas, pero yo
creo que no está relacionado con mingwpy vs MSVC como compilador. También podríamos enviar
openblas con estas ruedas, pero me preocupaba que openblas aún no estuviera
lo suficientemente confiable para usar en una rueda estándar que admitimos.

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-185017546 .

Está bien. Estoy confundido acerca de la fuente del rendimiento subóptimo: no uso esas bibliotecas BLAS y no sé qué hacen y cuál es la diferencia, por lo que explicar estas opciones para los mortales ayuda a volverse ... erm, más científico, ya sabes . =) Pensé que la ausencia de un compilador abierto con un rendimiento óptimo es el problema.

@mrslezak : con respecto a OpenBLAS, ciertamente puedo estar de acuerdo. El paquete OpenBLAS proporcionado en Cygwin, junto con el paquete Lapack, parece capaz de compilar NumPy y SciPy sin problemas.

@mrslezak : ¿dónde puedo encontrar información sobre los puntos de referencia? Estoy tratando de escribir documentación sobre la fuente de construcción de Windows por scipy.org , y sería una gran referencia para cualquier persona que necesite rendimiento con estas bibliotecas.

¿Quizás el enfoque de escopeta es la idea correcta? Algo como:

• Estable: ATLAS con rendimiento, advertencias sse2
• Desarrollador: OpenBLAS ver mingwpy y binstar
• Alternativas: MKL @cgohlke , MKL @continuum y @enthought
  Advertencia: los binarios no son compatibles.
  Enlaces para obtener más información en scipy y github numpy wiki de Matthew Brett

@techtonik Espero que GCC funcione algo peor que MSVC o ICC en el código equivalente que todos esos compiladores son capaces de construir. El problema es la falta de un compilador gratuito (compatible con python.org-cpython) que pueda crear una versión competitiva de Lapack, que está en Fortran (SciPy también tiene otros componentes de Fortran). La parte BLAS pura de OpenBLAS (y probablemente Atlas también) se puede construir con MSVC, pero MSVC no puede construir ninguna de las piezas que requieren ensamblaje en línea, por lo que tampoco será competitivo.

No tengo un MKL de 64 bits a mano (es posible que tenga uno de 32 bits de Conda en algún lugar si voy a cavar), pero aquí hay algunos puntos de referencia ejecutados en Julia comparando el Atlas dll que @ matthew-brett creó contra la referencia y Sandy- configuraciones de puente de BLIS y la compilación de OpenBLAS que viene con Julia https://gist.github.com/54da587b01b7fb163103

Resumen: openblas (en un skylake, el núcleo openblas más nuevo es haswell) es 23 veces más rápido que atlas, 44 veces más rápido que blis de referencia y 5,5 veces más rápido que blis de sandbridge. Podría probar haswell blis para ver cuánto más cerca está.

Hum - ¿Supongo que no tienes scripts de compilación por ahí para tus compilaciones BLIS?

¿Cree que valdría la pena hacer compilaciones de BLIS para una variedad de procesadores y seleccionar uno en tiempo de ejecución? ¿Hay un pequeño subconjunto de procesadores que capturaría la mayor parte del rendimiento de la mayoría de los procesadores?

Está en los comentarios, pero aquí (ejecutar en cygwin 64)

cd build
for i in reference dunnington sandybridge haswell bulldozer piledriver carrizo; do
  mkdir -p ../build64$i
  cd ../build64$i
  ../configure $i
  cp /usr/x86_64-w64-mingw32/sys-root/mingw/bin/lib* .
  make -j8 all test CC=x86_64-w64-mingw32-gcc CPICFLAGS="" BLIS_ENABLE_DYNAMIC_BUILD=yes
done

Esto es lo que tienen disponible: https://github.com/flame/blis/tree/master/config

En términos de Intel x86, la referencia, dunnington, sandybridge y haswell cubrirían un rango bastante bueno. También bulldozer, piledriver y carrizo para AMD (que recientemente dejó de desarrollar ACML a favor de BLIS, por lo que es un voto a favor al menos).

Hay un código de detección automática en https://github.com/flame/blis/tree/master/build/auto-detect que podría ser reutilizable (actualmente solo se ejecuta en el momento de la configuración en BLIS, pero eso no significa que no se pudo reutilizar para otros fines), dependiendo de si ya existe un código de identificación de la familia de CPU en Python que desea usar.

dependiendo de si ya existe un código de identificación de la familia de CPU en Python por ahí

¿Esto ayuda? http://stackoverflow.com/a/35154827/239247

En su mayoría, desea la familia de procesadores que se deriva de eso, pero https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c no es exactamente largo ni complicado. La fuente numexpr que está vinculada desde SO está haciendo coincidencias de expresiones regulares en la salida de la cadena (al menos en Linux), y no parece que tenga muchas arquitecturas recientes en la lista.

openblas es 3,4 veces más rápido que Haswell blis, y 17 veces más rápido que dunnington (básicamente lo mismo que nehalem penryn, creo) blis. Lo interesante es que no creo que los subprocesos múltiples funcionen correctamente en estas ejecuciones. La configuración predeterminada habilita openmp para sandybridge y haswell, tal vez los pthreads de mingw funcionen mejor. Establecer OMP_NUM_THREADS no pareció hacer mucha diferencia.

Creo que ATLAS 3.11 debería funcionar mucho mejor en 64 bits que en la versión 3.10, pero no puedo construirlo en este momento, espero la ayuda de Clint Whaley.

Tony: Supongo que no tienes tiempo/energía para probar la rueda ATLAS de 32 bits. Debería hacerlo mucho mejor, relativamente.

Mi preferencia es seguir adelante con estas ruedas ATLAS, por lo que otros empacadores pueden confiar en que enviaremos algún tipo de rueda. Si encontramos una buena manera de mejorar el rendimiento, pronto tendremos una nueva versión numpy, e incluso para 1.10.4 siempre podemos hacer una versión de mantenimiento para actualizar las ruedas.

@matthew-brett: pregunta rápida, ¿por qué numpy podría no ser capaz de detectar las compilaciones de ATLAS en Cygwin? Pude detectarlos perfectamente bien en un entorno nativo de Windows, pero cuando intenté ejecutar su secuencia de comandos en Cygwin, numpy no se compiló con ATLAS .

Si está utilizando Python de Cygwin, es probable que necesite una versión de atlas construida con cygwin para que las cosas sean compatibles.

Julia de 32 bits parece estar fallando al descargar el atlas dll de 32 bits. No estoy seguro de por qué, ¿tal vez porque ya tenemos un openblas de 32 bits y los nombres de los símbolos están en conflicto?

Pero la versión de @ matthew-brett está construida con Cygwin, y es por eso que estoy confundido.

Entorno de compilación Cygwin, compilado de forma cruzada en una biblioteca mingw. ¿Ves cómo está vinculado a msvcrt.dll en lugar de cygwin1.dll?

Tan pronto como publiqué el comentario, de repente sospeché que ese podría ser el caso. Por desgracia, parece que tendré que construirlo desde cero. Gracias @tkelman !

Se resolvió el problema de dlopen (ref https://github.com/matthew-brett/np-wheel-builder/pull/1, y https://github.com/JuliaLang/julia/issues/15117 estaba ocultando la versión útil de el mensaje de error).

En 32 bits, atlas es 3,6 veces más lento que openblas. Openblas de 32 bits es 3 veces más lento que Openblas de 64 bits para el mismo problema de tamaño. Las pocas familias de kernel más nuevas no están habilitadas en openblas en sistemas de 32 bits.

...
En conclusión: en serio, no sé cuál es nuestra mejor opción, pero meter los dedos de los pies en el agua de BLIS parece una buena idea; incluso si decidimos que queremos esperar, al menos aprenderemos algo.

Eso probablemente sea útil, al menos algunas pruebas/evaluaciones comparativas. Pero en este punto no tiene nada que ver con nuestros problemas de _Windows_. BLIS es solo para Linux en este momento; hay un PR abierto para el soporte de compilación de OSX, y Windows está muy lejos. Y lo que es peor, lo probé ayer en Linux de 32 bits y ni siquiera funciona. ./configure auto && make falla horriblemente en algún código ensamblador (para sandybridge ). Solo puedo construir reference .

Así que creo que el paso 0 es agregar soporte para BLIS en numpy.distutils (la mayoría ya funciona), el paso 1 para probar en Linux para ver que al menos reference funciona, el paso 2 algunas pruebas comparativas, ..., pasoalgo en Windows.

@ matthew-brett, su texto propuesto para PyPI me parece bien. ¿Qué versiones pip ignoran el nombre con la etiqueta ABI? Pip te regaña mucho para que se actualice solo en estos días, así que espero que mucha gente tenga la última versión. Y las versiones de más de 1 (.5) años ni siquiera instalaron ruedas de manera predeterminada.

@rgommers mis pruebas anteriores fueron en Windows. No MSVC, pero mingwpy o openblas no harán mucha diferencia allí; clang probablemente funcionaría, pero necesita una reorganización del repositorio en blis para evitar los enlaces simbólicos.

No ejecuté las pruebas de Julia o numpy contra blis, pero blis estaba pasando sus propias pruebas unitarias. Las cosas fueron mucho mejor de lo que mi experiencia de 2014 me llevó a pensar que lo harían. Todavía necesito descubrir cómo hacer que el subprocesamiento múltiple funcione correctamente, pero con eso es posible que ya tenga un rendimiento competitivo.

Parece que la configuración de referencia es lo único en blis que funciona para x86 de 32 bits en este momento. Eso requeriría escribir nuevos micronúcleos de ensamblaje. Creo que tal vez no, consulte los comentarios de njsmith a continuación.

@tkelman , sobre los núcleos OpenBLAS para 32 bits https://github.com/numpy/numpy/issues/5479#issuecomment -185096062: según un priv. mensaje que recibí de Werner Saar hace algún tiempo, no hay nadie trabajando en kernels Intel de 32 bits para arquitecturas más nuevas. Así que este es un hecho que es poco probable que cambie en el futuro. La atención se centra en los procesadores Intel de 64 bits y ARM.

@tkelman , con respecto a C-runtime https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: en mi humilde opinión, esto no es crítico ya que ATLAS y OpenBLAS no comparten recursos del C-runtime (descriptores de archivos y montón ). _Ojalá tenga razón_. Puede ser útil para las compilaciones de ATLAS para aumentar el tamaño de la pila. Esto se puede dar como bandera durante la vinculación, es decir:

-Wl,--stack,16777216

con respecto a las discusiones ATLAS vs. OpenBLAS: gracias a @matthew-brett, ahora hay disponibles archivos DLL de ATLAS basados ​​en SSE2. Esta compilación de Atlas debe compararse con la compilación de OpenBLAS contra un objetivo habilitado para SSE2 (o simplemente establezca OPENBLAS_CORETYPE=NORTHWOOD , básicamente PENTIUM4) para deshabilitar la detección del tiempo de ejecución de la CPU. Por supuesto, una compilación genérica de OpenBLAS puede explotar muchas más variantes de CPU gracias a la detección del tiempo de ejecución de la CPU. Esta es una de las razones por las que OpenBLAS tiene más rendimiento en comparación con ATLAS. Otra cuestión es la fiabilidad de OpenBLAS. Tal vez un repositorio con pruebas BLAS, LAPACK reunidas podría ayudar.

con respecto a BLIS/Flame: interesante, pero un fruto al alcance de la mano al menos por hoy.

Sin embargo, la toma de decisiones sobre cómo elegir entre ATLAS y OpenBLAS no está clara para mí.

Ralf: pip 8 instalará las ruedas con las nuevas etiquetas ABI de Windows, pip 7 no. Pip 7 y pip 8 instalarán las ruedas sin las etiquetas ABI, sin previo aviso.

Todavía hay muchos pip 7, se lanzó en agosto de 2015, por lo que preferiría mantener el nombre más compatible, al menos por un tiempo.

+1 en la investigación de BLIS. Parece una buena solución a largo plazo. ¿Hemos considerado Eigen en absoluto? Admiten la creación de una interfaz LAPACK parcial y la licencia es MPL2 para la mayor parte del código. Eso puede ser lo suficientemente bueno para NumPy.

Me di cuenta del código de detección de CPU BLIS que muy a menudo recurre a la implementación de referencia si no encuentra las instrucciones AVX, que aún son bastante recientes.

Ian: este es el estado de Eigen desde hace aproximadamente un año: http://mingwpy.github.io/blas_lapack.html#eigen , por lo que creo que sería un poco de trabajo construir una biblioteca utilizable para numpy.

Y lo que es peor, lo probé ayer en Linux de 32 bits y ni siquiera funciona. ./configure auto && make falla horriblemente en algún código ensamblador (para Sandybridge). Solo puedo construir una referencia.

Si observa el contenido de config/ , las diversas "configuraciones" nombradas (como "sandybridge", "haswell") son en realidad configuraciones "iniciales" preempaquetadas que incluyen un montón de configuraciones preespecificadas (no solo Configuración relacionada con el ajuste de la CPU, pero también configuración del modo de subprocesamiento, configuración del compilador, etc.). Y la configuración llamada "sandybridge" es una configuración x86-64. Suena como un error que la configuración automática lo seleccionó, pero sí, no funcionará en x86-32 :-). BLIS parece enviarse con núcleos x86 de 32 bits (ver kernels/x86 ), aunque parece que en este momento ninguna de las configuraciones preempaquetadas los usa. Hacer nuevas configuraciones es en su mayoría trivial; la única pieza de magia está en el archivo bli_kernel.h que nombra qué núcleo interno + algunos tamaños de búfer. Podríamos preguntarles si tienen alguna sugerencia para x86-32.

También:

BLIS es solo para Linux en este momento; hay una PR abierta para el soporte de compilación de OSX, y Windows está muy lejos

Algunos comentarios anteriores, @tkelman está construyendo y evaluando BLIS en Windows :-)

El punto de referencia crudo anterior test_dot con OpenBLAS 0.2.12:

In [2]: %timeit test_dot()
1 loop, best of 3: 449 ms per loop

Comparado con (resultado anterior de) MKL

In [9]: %timeit test_dot()
1 loop, best of 3: 764 ms per loop

ATLAS de 64 bits:

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

Entonces, cuando comparo openblas y MKL (gracias, conda) en serie con la configuración BLIS de Haswell, todos tienen una diferencia máxima del 10-20% entre sí en dgemm. Aquí hay un archivo docker que se creó con éxito en docker hub para compilar de forma cruzada los dll de Windows de cada configuración (excepto bulldozer que no se vinculó correctamente https://github.com/flame/blis/pull/37#issuecomment-185480513, bueno) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

Es posible que desee intentar conectar algo similar a la configuración services: docker de Travis y jugar con la implementación de artefactos binarios en versiones de github/bintray/lo que sea.

Estaba mirando la detección de CPU BLIS -> código de plantilla: https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

Aquí hay una reescritura de Python, que debería ser un poco más liberal al aceptar una de las plantillas avanzadas (es más probable que crea que el sistema operativo puede usar AVX que el código C): https://gist.github.com/matthew-brett /a53778f99b7062cc332d

En todas las máquinas en las que probé, este algoritmo devuelve "referencia", probablemente porque tengo máquinas viejas que nadie más quería usar, para rescatar para mi granja de buildbots.

Compilando numpy contra la referencia BLIS, sin lapack, da lo siguiente en mi punto de referencia crudo:

In [6]: %timeit test_dot()
1 loop, best of 3: 16.2 s per loop

Solo el producto escalar de dos matrices (1000, 1000) es 12 segundos. Entonces, como Tony también descubrió, la referencia BLIS es la peor de nuestras opciones, en torno a la misma compilación predeterminada sin biblioteca de numpy con lapack_lite.

Por lo tanto, creo que necesitaremos más plantillas que cubran máquinas más antiguas o una detección de CPU más liberal -> mapeo de plantillas para brindar un rendimiento razonable en una amplia gama de máquinas.

@matthew-brett, ¿cuándo podemos esperar que estén listos los nuevos volantes de Windows ATLAS de 64 bits? ¿Cual version? v1.10.2? Estarán solo en pypi o también en source forge? ¿Vas a hacer algún tipo de anuncio? ¡Muchas gracias!

@ matthew-brett, ¿cuál fue la relación entre atlas y blis de referencia para usted en la misma máquina? ¿Comparable al factor de alrededor de 2 que estaba viendo? Obtuve subprocesos múltiples para trabajar en blis, simplemente no hice rtfm correctamente (https://github.com/flame/blis/wiki/Multithreading), no está habilitado automáticamente, y hay 4 env vars diferentes para jugar . Con este parche https://gist.github.com/0fc9497a75411fcc0ec5 para habilitar blis paralelos basados ​​en pthreads para todas las configuraciones y establecer BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 , Haswell blis está básicamente vinculado con mkl y openblas en mi máquina. Si configuro solo BLIS_JR_NT en 2, entonces la referencia paralela blis se ajusta en su mayor parte al atlas, y es más rápido con 3 subprocesos.

@tkelman En mi opinión , sería útil si pudiera documentar su progreso en BLIS en las páginas Wiki de NumPy GitHub. También creo que sería interesante proponer un plan similar a mingwpy para hacer una rueda NumPy-BLIS-FLAME (¿y una rueda SciPy-BLIS-FLAME si es posible?).

@tkelman : para asegurarme de que estoy claro, su atlas está enhebrado, ¿verdad?
otra cosa a considerar es agregar -msse2 o similar a la configuración de compilación reference ; parece que, de forma predeterminada, es compatible al máximo y no permite que el compilador use SSE, pero al menos en numpy-land Sé que estamos subiendo a SSE2 como la configuración mínima admitida de todos modos por otras razones...

No sé si FLAME es relevante o no en este momento en comparación con LAPACK normal; nos gustaría preguntar.

Posiblemente deberíamos abrir un nuevo número para las cosas de BLIS en lugar de seguir abarrotando este :-)

Para este hilo, creo que ya podemos enviar una rueda con varios núcleos BLIS seleccionados en tiempo de ejecución usando las mismas reglas que usa BLIS en tiempo de compilación, pero creo que eso daría como resultado muchas máquinas con BLIS de referencia y, por lo tanto, tendrían peores rendimiento que ATLAS de 64 bits, aunque ATLAS de 64 bits en Windows es particularmente malo (para ATLAS).

Pero, si la compilación de referencia es más rápida que el ATLAS de 64 bits, digamos con -msse2, esa sería una opción real.

SSE2 es la configuración mínima para 64 bits, por lo que es seguro usar algo como -mfpmath=sse -msse2 para la compilación de referencia.

Posiblemente deberíamos abrir un nuevo número para las cosas de BLIS en lugar de seguir abarrotando este :-)

Sería una buena idea (editar: ¿puedo sugerir que se titule "Occupy BLIS", dado el sentimiento de @njsmith sobre el césped en https://github.com/numpy/numpy/issues/5479#issuecomment-184472378?) . Creo que hacer que @matthew-brett continúe con la carga de sus ruedas Atlas existentes sería suficiente para cerrar esta por ahora, dejando el trabajo futuro para nuevos problemas.

para asegurarme de que estoy claro, tu atlas está enhebrado, ¿verdad?

Mi atlas es el dll de https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds , pero todavía tengo que verlo usar con éxito más de 1 subproceso. ¿Me estoy perdiendo una variable de entorno?

otra cosa a considerar es agregar -msse2 o similar a la configuración de compilación reference ; parece que, de forma predeterminada, es compatible al máximo y no permite que el compilador use SSE

SSE2 es parte de la especificación x86_64, por lo que esto solo sería relevante en 32 bits. En Julia agregamos -march=pentium4 para nuestras compilaciones de 32 bits.

No sé si FLAME es relevante o no en este momento en comparación con LAPACK normal; nos gustaría preguntar.

Todavía no he tocado la llama, pero vale la pena jugar con ella. Con el tiempo, es posible que pueda usar WIndows Clang como un plan de copia de seguridad alternativo a mingwpy. (editar: en realidad esto no soluciona el fortran en scipy, así que tal vez no)

@matthew-brett: Creo (podría estar equivocado) que el kernel dunnington solo requiere SSE3, que según la Encuesta de hardware de Steam está presente en el 99,94 % de las máquinas (frente al 99,99 % de SSE2). Por lo tanto, parece incorrecto si descubre que la mayoría de los sistemas no pueden manejar eso; no sé si eso es un error en su código cpuid, si de alguna manera tiene un conjunto de máquinas de prueba realmente poco representativo, o en mi entendimiento de lo que requiere ese núcleo.

Publiqué una reescritura de Python del código de detección de CPU en la esencia anterior. Supongo que la selección de plantillas es conservadora, por defecto hace referencia a dónde podría haber funcionado otra plantilla.

Para recordarme, para vincularme a BLIS, necesitaba un site.cfg como:

[blas]
blas_libs = numpy-blis-reference
library_dirs = c:\code\blis\test\lib
include_dirs = c:\code\blis\test\include

También hice esto, supongo que es necesario (parche relativo a numpy 1.10.4):

diff --git a/numpy/distutils/system_info.py b/numpy/distutils/system_info.py
index d7eb49e..3cb7f95 100644
--- a/numpy/distutils/system_info.py
+++ b/numpy/distutils/system_info.py
@@ -1680,18 +1680,11 @@ class blas_info(system_info):
         info = self.check_libs(lib_dirs, blas_libs, [])
         if info is None:
             return
-        if platform.system() == 'Windows':
-            # The check for windows is needed because has_cblas uses the
-            # same compiler that was used to compile Python and msvc is
-            # often not installed when mingw is being used. This rough
-            # treatment is not desirable, but windows is tricky.
-            info['language'] = 'f77'  # XXX: is it generally true?
-        else:
-            lib = self.has_cblas(info)
-            if lib is not None:
-                info['language'] = 'c'
-                info['libraries'] = [lib]
-                info['define_macros'] = [('HAVE_CBLAS', None)]
+        lib = self.has_cblas(info)
+        if lib is not None:
+            info['language'] = 'c'
+            info['libraries'] = [lib]
+            info['define_macros'] = [('HAVE_CBLAS', None)]
         self.set_info(**info)

     def has_cblas(self, info):

Utilidad para permitir la detección en tiempo de ejecución de la CPU: https://github.com/matthew-brett/x86cpu

Supongo que esto podría ser un candidato para su inclusión en numpy, pero también podemos copiar el único módulo cpuinfo compilado en el árbol numpy para la rueda de Windows.

Hola a todos. Un pensamiento: si quisiera publicar varias ruedas numpy diferentes creadas con varias bibliotecas de vectores, podría usar diferentes nombres de paquetes PyPI

1. https://pypi.python.org/pypi/numpy/1.8.1
2. https://pypi.python.org/pypi/numpy-mkl
3. https://pypi.python.org/pypi/numpy-atlas

Registré 2 para intentar subir las ruedas de Gohlke, pero PyPI las rechazó. De nada a la URL.

gh-7294 agrega compatibilidad con BLIS a numpy.distutils . Sería genial si alguien pudiera verificar que esto funciona como se esperaba.

Todavía hay muchos pip 7, se lanzó en agosto de 2015, por lo que preferiría mantener el nombre más compatible, al menos por un tiempo.

Pip 7.0 aún no es tan antiguo, por lo que tiene sentido.

... BLIS parece enviarse con kernels x86 de 32 bits (consulte kernels/x86), aunque parece que en este momento ninguna de las configuraciones preempaquetadas los usa

Eso lo explica, gracias.

Gracias Ralf - Voy a probar.

Me doy cuenta de que esto puede necesitar un nuevo hilo, pero ahora estamos muy cerca de poder usar las compilaciones de BLIS para un lanzamiento.

Creo que todo lo que necesitamos ahora son plantillas recomendadas para una máquina que tiene SSE2 y una máquina que SSE3, que funcionan un poco más rápido que la compilación de Windows ATLAS de 64 bits.

Me doy cuenta de que esto puede necesitar un nuevo hilo, pero ahora estamos muy cerca de poder usar las compilaciones de BLIS para un lanzamiento.

Eh, técnicamente puede ser posible hacer que funcione, pero aún así no es un buen plan lanzar construcciones sobre la pared de esa manera. Ni siquiera hemos realizado pruebas serias de BLIS en Linux o OS X todavía. Entonces, en Windows, donde las preguntas frecuentes de BLIS dicen :

Support for building in Windows is also a long-term goal of ours. 
The Windows build system exists as a separate entity within the top-level
windows directory. However, this feature is still experimental and should not 
(yet) be expected to work reliably. Please contact the developers on the blis-devel 
mailing list for the latest on the Windows build system.

, definitivamente es demasiado pronto. Además de las pruebas, creo que algunas evaluaciones comparativas también son una buena idea.

Claro, pero como ha demostrado Tony, en realidad no es difícil compilar BLIS para Windows mediante la compilación cruzada. Lo experimental, creo, es su sistema de compilación MSVC, que no estamos usando.

Por ahora, solo sugiero usar BLIS para la rueda de Windows, pero, por supuesto, sería muy bueno hacerlo funcionar también para las compilaciones de manylinux.

Estoy completamente de acuerdo en que, si no obtenemos un aumento significativo en el rendimiento promedio, entonces no deberíamos usar BLIS y, por el momento, no creo que lo estemos, excepto en el caso de los procesadores muy nuevos. Eso podría solucionarse trivialmente con un par de nuevas plantillas, me encantaría saber si ese fuera el caso.

Para la corrección, también estoy de acuerdo. ¿Qué tal si demostramos que

a) Todas las pruebas numpy pasan en todas las versiones de Windows;
b) ¿Todas las pruebas numpy y scipy pasan en el sistema manylinux?

Podemos hacer que la plantilla BLIS se pueda seleccionar en tiempo de ejecución y probar todos los núcleos en una máquina moderna. También puedo probar en algunas máquinas viejas y desagradables.

Por ahora, solo sugiero usar BLIS para la rueda de Windows, pero, por supuesto, sería muy bueno hacerlo funcionar también para las compilaciones de manylinux.

Creo que manylinux es menos importante, ya que tenemos administradores de paquetes allí con una pila completa, así como usuarios que pueden compilar cosas mucho más fácilmente. Primero veamos cómo despega todo el concepto de manylinux antes de preocuparnos por él en este contexto numpy + BLAS/LAPACK :)

Para Windows, creo que nuestros prios son:

1) una solución de pila completa (necesita MingwPy, con uno de OpenBLAS/ATLAS/BLIS)
2) ruedas binarias provisionales (tenemos una a punto de subir con su compilación ATLAS)
3) aumentar el rendimiento de (1). Aquí es donde BLIS podría entrar.

Entonces, en mi humilde opinión, no hay necesidad de tener mucha prisa con BLIS en Windows.

Estoy completamente de acuerdo en que, si no obtenemos un aumento significativo en el rendimiento promedio, entonces no deberíamos usar BLIS y, por el momento, no creo que lo estemos, excepto en el caso de los procesadores muy nuevos. Eso podría solucionarse trivialmente con un par de nuevas plantillas, me encantaría saber si ese fuera el caso.

De acuerdo, debe haber una ganancia significativa para que tenga sentido. De hecho, es un poco difícil supervisar cuánto trabajo se necesita.

Para la corrección, también estoy de acuerdo. ¿Qué tal si demostramos que

a) Todas las pruebas numpy pasan en todas las versiones de Windows;
b) ¿Todas las pruebas numpy y scipy pasan en el sistema manylinux?

Eso suena bien. Tendría sentido incluir scikit-learn también, es un usuario de linalg bastante importante.

No sabía que blis y libflame habían sido parte del código base de ACML, que se ha abierto hace algún tiempo:

http://developer.amd.com/community/blog/2015/08/07/open-source-strikes-again-accelerated-math-libraries-at-amd/
http://developer.amd.com/tools-and-sdks/opencl-zone/acl-amd-compute-libraries/

Sin embargo: ¿cómo resolver el problema para comparar 4 implementaciones BLAS/Lapack aceleradas diferentes para compilación numpy/scipy con MSVC o mingwpy para probarlas en numerosas arquitecturas de CPU: Pentium4 hasta skylake?

Buen hallazgo @carlk , vi que los recordaba anunciando la eliminación de acml y el código abierto de acl, pero no recordaba que adoptaran blis/libflame. ¡La licencia bsd es una muy buena noticia! ¿Hay alguna forma de trabajar con AMD y shpc en ut Austin para apuntar a numpy y Julia?

Pude compilar de forma cruzada libblis.a usando msys2 y la configuración haswell lista para usar y pasar todas las pruebas parcheando los enlaces simbólicos del kernel, pero no pude compilar libflame. Obtuve el mismo error de "lista de argumentos demasiado larga" que en mi publicación de la lista de correo blis-discuss. Además, personalmente no pude averiguar cómo vincular a libblis.a desde lapack, pero no lo intenté mucho.

Con la licencia comunitaria de MKL, ¿no es posible proporcionar una rueda de MKL en pypi? ¿Son realmente incompatibles las licencias? ¿O simplemente no es posible construir scipy sin ifort?

Un problema, y ​​probablemente pertenezca a scipy, que no se ha mencionado son los archivos Fortran restantes en scipy. Perdón por la pregunta de novato, pero ¿por qué debemos usarlos? Para mí, Fortran, y la falta de un compilador multiplataforma gratuito, es el verdadero problema aquí. ¿No es eso, después de todo, lo que mingwpy pretende resolver? Dado MKL gratuito o alguna magia futura acl blis/flame, cualquier persona con un compilador c podría construir la pila de scipy si no fuera por los archivos *.f.

@mikofski , es genial escuchar que blis se puede compilar con msys2. ¿Es esto también cierto para libflame? Supongo que necesitamos libflame para la API de Lapack.
Personalmente, es posible tener un numpy compilado de MSVC y usarlo junto con un scipy compilado de mingwpy. Debe agregar -mlong-double-64 a las banderas gcc para asegurarse de que los dobles largos == doble.

Es complicado hacer que este comportamiento sea el predeterminado en gcc, estoy jugando con este problema desde hace una semana :(

Subiré mañana con ruedas scipy. Estos se basarán en Atlas proporcionados por las ruedas numpy de @matthew-brett.

Sin embargo, estoy a favor de usar OpenBLAS ahora mismo.

Un problema, y ​​probablemente pertenezca a scipy, que no se ha mencionado son los archivos Fortran restantes en scipy. Perdón por la pregunta de novato, pero ¿por qué debemos usarlos?

Porque es un montón de código muy útil y de alto rendimiento. Y no es solo BLAS/LAPACK: una gran cantidad de scipy.sparse.linalg , scipy.linalg , scipy.special y scipy.interpolate por ejemplo, es Fortran. Además, Scipy no es el único proyecto con código Fortran, hay otros paquetes como bvp_solver , así como el propio código Fortran de las personas que envolvieron con f2py.

De hecho, buen hallazgo Carl.

Sin embargo: ¿cómo resolver el problema para comparar 4 implementaciones BLAS/Lapack aceleradas diferentes para compilación numpy/scipy con MSVC o mingwpy para probarlas en numerosas arquitecturas de CPU: Pentium4 hasta skylake?

De hecho, esto requiere un marco de referencia/compilación/prueba/comprobación automatizado decente. No tenemos que molestarnos con arquitecturas de CPU muy antiguas (mientras las cosas funcionen allí, está bien) y tampoco con MSVC, creo. Pero aún así será un poco de trabajo configurar esto correctamente.

@rgommers gracias!

Hola a todos. Un pensamiento: si quisiera publicar varias ruedas numpy diferentes creadas con varias bibliotecas de vectores, podría usar diferentes nombres de paquetes PyPI

https://pypi.python.org/pypi/numpy/1.8.1
https://pypi.python.org/pypi/numpy-mkl
https://pypi.python.org/pypi/numpy-atlas

Registré 2 para intentar subir las ruedas de Gohlke, pero PyPI las rechazó. De nada a la URL.

@hickford , por favor, no hagas eso. Redistribuir archivos binarios así (a menos que tenga una licencia personal) es infringir la licencia MKL, y no es la forma correcta de hacerlo. Sin embargo, es posible que en el futuro queramos distribuir algunos sabores a través de extras ( numpy[atlas] , numpy[openblas] etc.).

Además, redistribuir las ruedas de otra persona en PyPi sin preguntar probablemente no sea lo que se debe hacer...

Mingwpy y cualquier problema de fortran que dependa de la vinculación al mismo tiempo de ejecución de c que cpython tienen una tasa limitada en @carlkl , experimentar con BLIS resuelve menos problemas, pero cualquiera puede hacerlo de forma independiente. Desafortunadamente, he agotado mi suministro personal de tiempo para mirar BLIS en este momento, pero vea #7294.

Tony, muchas gracias por toda tu ayuda, ha sido invaluable.

Agregué una compilación de ATLAS posterior (3.11.38) en 64 bits

https://github.com/matthew-brett/np-wheel-builder

Esta es una compilación en serie (sin subprocesos), debido a problemas al compilar 3.11.38 en Windows, pero debería ser un poco más rápido que 3.10.1, y está en mi punto de referencia simple:

In [2]: %timeit test_dot()
1 loop, best of 3: 1.65 s per loop

en comparación con la compilación anterior 3.10.1 (ver arriba):

In [10]: %timeit test_dot()
1 loop, best of 3: 2.41 s per loop

@tkelman : ¿puede comparar esta compilación con Julia?

Perdón por saltar aquí con una nota previa sobre los binarios MKL: Intel ofrece el
versión comunitaria que debería permitir la redistribución ya que es gratuita para todos...
El 2 de marzo de 2016 a las 15:08, "Matthew Brett" [email protected] escribió:

Agregué una compilación de ATLAS posterior (3.11.38) en 64 bits

https://github.com/matthew-brett/np-wheel-builder

Esta es una compilación en serie (sin subprocesos), debido a problemas al compilar 3.11.38
en Windows, pero debería ser un poco más rápido que 3.10.1, y está en mi simple
punto de referencia:

En [2]: %timeit test_dot()
1 bucle, lo mejor de 3: 1,65 s por bucle

en comparación con la compilación anterior 3.10.1 (ver arriba):

En [10]: %timeit test_dot()
1 bucle, lo mejor de 3: 2,41 s por bucle

@tkelman https://github.com/tkelman : ¿puede comparar esta compilación?
Julia?

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-191431331 .

@mrslezak : la licencia permite la redistribución, pero hace que el redistribuidor sea responsable de los honorarios legales si se demanda a Intel como resultado del uso del software. Además, el binario resultante no puede tener licencia BSD. Consulte: http://mingwpy.github.io/blas_lapack.html#intel-math-kernel-library

¿Podría evitarse añadiendo 'siempre y cuando tal cual, sin responsabilidad por ningún
pérdidas monetarias que pueden resultar de su uso' o algo por el estilo?
El 2 de marzo de 2016 a las 6:22 p. m., "Matthew Brett" [email protected] escribió:

@mrslezak https://github.com/mrslezak - la licencia permite
redistribución, pero hace que el redistribuidor sea responsable de los honorarios legales si
Intel es demandado como resultado del uso del software. Asimismo, la resultante
el binario no puede tener licencia BSD. Ver:
http://mingwpy.github.io/blas_lapack.html#intel-math-kernel-library

—
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-191505500 .

No creo que eso funcione, porque tenemos que estar de acuerdo con la licencia de Intel, y la licencia de Intel dice que somos responsables de sus honorarios legales si los demandan. Supongo que podríamos exigir a los usuarios que no demanden a Intel en nuestro acuerdo de licencia, y tal vez, si demandan a Intel, e Intel nos pide el dinero, podemos intentar demandar al usuario por esas tarifas, pero aun así, poner eso en nuestro La licencia nos alejaría aún más de BSD y requeriría que el usuario esté de acuerdo explícitamente, lo cual no es práctico en el caso de las ruedas instaladas por pip.

La compilación de ATLAS para SSE3 solo brinda un beneficio de rendimiento del 5 % en comparación con SSE2 ATLAS, pero la compilación fue complicada y tuve que deshabilitar los indicadores de habilitación más obvios para SSE3 y solo usar -msse3 .

Escribí un correo a la lista de correo numpy proponiendo implementar estas ruedas: https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@matthew-brett Como alguien que admite Windows con aplicaciones Python, gracias.

@matthew-brett, agregué 2 problemas a su repositorio atlas-build-scripts.
Consulte https://github.com/matthew-brett/atlas-build-scripts/issues

El primero https://github.com/matthew-brett/atlas-build-scripts/issues/1 es importante, ya que numpy-atlas.dll exporta a muchos símbolos y, por lo tanto, evita su uso posterior con mingwpy sin piratear la importación. Biblioteca.

@ matthew-brett, lo siento, he estado un poco ocupado para hacer más evaluaciones comparativas. ¿Alguna de las compilaciones anteriores de atlas era multiproceso? No pude hacer que la primera compilación se ejecutara en varios núcleos. La esencia debería ser bastante sencilla de ejecutar, incluso si no está muy familiarizado con julia. ¿O estaba más interesado en hardware más nuevo al que tiene acceso?

No se preocupe, no esperaba que dejara todo y ejecutara puntos de referencia.

En realidad, mi última compilación de atlas no tenía subprocesos múltiples: aparentemente, ATLAS 3.11 necesita más trabajo para que los subprocesos funcionen en Windows.

Para los puntos de referencia, estaba pensando que sería más fácil compararlos con los otros puntos de referencia que ha ejecutado, y solo tengo hardware antiguo con Windows activado; supongo que el éxito es mucho mayor en su máquina que en la mía.

Las ruedas de Windows ahora están en pypi: https://pypi.python.org/pypi/numpy/1.10.4

Lo siento, Tony: sí, las compilaciones anteriores de 3.10 ATLAS eran (o parecían ser) de subprocesos múltiples.

Supongo que podemos cerrar este tema ahora. Tal vez @matthew-brett debería transferir su https://github.com/matthew-brett/np-wheel-builder bajo la organización numpy o tal vez contribuir como relaciones públicas al repositorio numpy bajo la carpeta de herramientas .

Ralf: ¿alguna sugerencia sobre dónde debería ir np-wheel-builder ? numpy/proveedor tal vez?

Preferiría un nuevo repositorio separado ( numpy-wheel-builder ?) bajo la organización numpy, creo. Hay superposición con numpy-vendor en propósito, pero no mucho en código. Ese repositorio es bastante grande, realmente está diseñado para ejecutarse bajo Wine, y la cadena de herramientas gcc en él está obsoleta.

Bien por mí. ¿Están de acuerdo con ustedes para seguir adelante y crear eso?

Por mí está bien, aunque si es específico de Windows (¿ahora mismo es AFAICT?), Entonces el nombre del repositorio debería tener "ventanas" :-). O también podría ser donde ponemos la infraestructura análoga para otras ruedas. También estaría bien si lo pusiera directamente en el repositorio numpy en algún lugar si es lo suficientemente pequeño como para que tenga sentido. Lo que sea que funcione :-)

Repo tiene binarios ATLAS bastante grandes, creo que haría que el repositorio numpy fuera grande para no tener un buen propósito.

¿Qué tal win-wheel-builder ?

¿Qué tal windows-wheel-builder ? No soy fan de win ;)

¿Qué hay de no hacerlo específico de Windows y tener la configuración de compilación de ruedas de macosx y manylinux1 en un solo lugar?

De lo contrario, +1 para "ventanas" sobre "ganar".

¿Qué hay de no hacerlo específico de Windows y tener la configuración de compilación de ruedas de macosx y manylinux1 en un solo lugar?

Sería más fácil cambiar las cosas en todas las plataformas. Pero espero que OS X y Linux solo necesiten compilar scripts, mientras que para Windows tenemos los enormes binarios de ATLAS. Si todo va a un repositorio, ¿se pueden separar los binarios de ATLAS de alguna manera (tal vez con git-lfs)?

Use almacenamiento de archivos grandes (LFS) en github para binarios

@rgommers : creo que pronto también llevaremos binarios atlas-o-algún-otro-blas para Linux, y posiblemente también osx (por ejemplo, si decidimos que estamos cansados ​​de acelerar el multiprocesamiento).

podría comenzar a usar lanzamientos de github o bintray o algo así en lugar de registrarlos ... aunque no es que sean tan grandes hasta que comience a ingresar a DYNAMIC_ARCH habilitadas compilaciones de openblas o las combinaciones equivalentes de múltiples configuraciones de blis

¿Qué tal poner el repositorio como windows-wheel-builder por ahora, y refactorizar/renombrar cuando esté más claro lo que vamos a hacer con Linux/OSX?

Suena bien para mí.

bien conmigo también

Creo que necesito derechos de administrador para la organización numpy, o puedo dar
alguien administra los derechos del repositorio, y puede hacerlo, supongo.

@matthew-brett: Estoy muy confundido con la página de permisos de github (y la de numpy en particular es un desastre), pero si quieres convertirme en administrador del repositorio o transferirme el repositorio, entonces puedo moverlo a numpy/

Transferí el repositorio a @njsmith ...

https://github.com/numpy/windows-wheel-builder

¿Hay una cuenta de appveyor numpy? ¿Alguien puede habilitar las compilaciones de Appveyor para este repositorio?

Creo que estamos usando la cuenta Appveyor de @charris...

Sí, consulte aquí https://ci.appveyor.com/project/charris/numpy/history

El miércoles 16 de marzo de 2016 a las 00:15, Nathaniel J. Smith <
[email protected]> escribió:

Creo que estamos usando @charris https://github.com/charris 's Appveyor
cuenta...

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-197064930

En realidad, acabo de crear una nueva cuenta de grupo para numpy en appveyor (tenía la intención de hacer esto de todos modos, y esto me impulsó a hacerlo :-)), y lo habilité allí:
https://ci.appveyor.com/project/numpy/windows-wheel-builder

@njsmith ¿Cómo lograste eso? La última vez que miré, alguien necesitaba pedirles a los administradores que crearan cuentas de proyecto y la forma de agregar a otros no era completamente transparente.

Si la cuenta funciona, me gustaría transferir la responsabilidad de las pruebas numpy.

@charris : revisa tu correo electrónico :-). Acabo de crear una cuenta individual con numpy-steering-council @googlegroups.com como individuo. No sabía que las cuentas de proyecto eran algo que existía... ¿Queremos una?

por el bien de la cola, probablemente desee distribuir diferentes proyectos en diferentes cuentas

La desventaja de usar el correo de numpy-steering-council es que appveyor envía notificaciones cuando falla una prueba de combinación. Si la gente de appveyor tiene algo mejor en estos días, sería bueno usarlo, pero dado el desorden que ha sido su interfaz en el pasado, no apostaría por eso.

@tkelman Buen punto. Además, si vamos a gastar dinero para conseguir una cola más rápida, probablemente queramos algo más oficial.

@charris : Acabo de intentar habilitar la prueba de numpy/numpy en la nueva cuenta de appveyor, y también deshabilitar todas las notificaciones, y también agregar todos los equipos de github relevantes como administradores en la cuenta. Veamos qué sucede. adivinar...

@matthew-brett: Se me ocurre que el enfoque más elegante podría ser esconder las compilaciones de BLAS en algún lugar como numpy/windows-build-tools , pero ejecutar las herramientas de creación de ruedas reales desde el repositorio real numpy/numpy como parte de la compilación de appveyor: podrían bajar los binarios BLAS a pedido.

¡Gracias por todo el gran trabajo! ¿Se agregarán numpy 1.11.0 Window wheels a pypi pronto? https://pypi.python.org/pypi/numpy

oh sí, posiblemente necesitemos descubrir cómo actualizar nuestros procedimientos de lanzamiento aquí... IIUC la experiencia del usuario en este momento es que tan pronto como se cargó el lanzamiento de la fuente 1.11, todas las máquinas de Windows de repente dejaron de descargar ruedas (¡sí! ) para intentar descargar y construir la fuente (boo). Supongo que la forma "correcta" de hacer esto es que una vez que se etiqueta el lanzamiento final, construimos y cargamos todas las ruedas binarias _antes_ de cargar el sdist. Por muy molesto que sea...

@njsmith eso sería bueno, pero un retraso de unos minutos (o incluso unas horas) estaría bien para mí.

Solo para aclarar, ¿son los archivos whl actuales de Windows en PyPI para la versión 1.11.0 compilados contra ATLAS? ¿Hay un script de compilación que se pueda compartir?

Sí, las ruedas se construyen contra ATLAS, pero estamos pensando en pasar a OpenBLAS cuando estemos seguros de los resultados.

La compilación se automatiza a través de Appveyor: https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day . =)

Podría ser posible crear un lanzamiento hidden ; al menos hay una opción en el formulario PyPI https://pypi.python.org/pypi?%3Aaction=submit_form y mostrarlo cuando todos los archivos estén listos.

Lamentablemente, la función de lanzamiento oculto impide que las personas obtengan ese lanzamiento a través de la línea de comando, solo les impide ver el lanzamiento a través de la GUI de pypi:

https://sourceforge.net/p/pypi/support-requests/428/

Probé la instalación de Windows de 64 bits de numpy y funciona muy bien, así que gracias a todos los que han trabajado en esto.

Lo que me pregunto es si todavía hay un plan para hacer lo mismo con Scipy Wheels. ¿Es esto esperar la decisión de pasar a OpenBLAS?

En https://bitbucket.org/carlkl/mingw-w64-for-python/downloads hay algunas ruedas de prueba de scipy-0.17.0. Estas ruedas se han construido con mingwpy contra las compilaciones de numpy de @matthew-brett https://pypi.python.org/pypi/numpy/1.10.4

El jueves 28 de abril de 2016 a las 12:48 p. m., carlkl [email protected] escribió:

En https://bitbucket.org/carlkl/mingw-w64-for-python/downloads hay
algunas ruedas de prueba de scipy-0.17.0. Estas ruedas han sido construidas con
mingwpy contra @matthew-brett https://github.com/matthew-brett's
compilaciones de numpy https://pypi.python.org/pypi/numpy/1.10.4

Lo siento si ya lo dijiste, y me lo perdí, pero ¿te hacen alguna prueba?
fallas para estas ruedas?

¿Está enlazando con el ATLAS enviado dentro de las ruedas numpy?

@ matthew-brett, anuncié estas compilaciones hace un mes, pero no recuerdo dónde. De todos modos, estas compilaciones se vinculan con el atlas numpy proporcionado por sus ruedas numpy.

scipy-0.17.0-cp35-cp35m-win##.whl están vinculados contra _wrong_ C-runtime msvcrt.dll. Para scipy esto parece estar bien. Los registros de prueba están aquí: https://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

¿Es ese el registro correcto? Tiene NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy al final.

Me preguntaba si estamos cerca de poder proporcionar una rueda scipy, incluso si se vincula peligrosamente con el tiempo de ejecución de MSVC incorrecto, pero parece que hay demasiados errores para esta compilación.

¿Obtiene menos errores para la compilación de 64 bits? ¿Para la mejor compilación actual contra openblas 0.2.18?

64 bits tiene solo 6 fallas, todas con:

FAIL: test_continuous_basic.test_cont_basic(<scipy.stats._continuous_distns.nct_gen object ...

Lo sé: esto llora por la comparación con OpenBLAS. Sin embargo, estoy atascado desde las últimas 4 semanas por varias razones, como habrás notado. Esperemos que la situación siga mejorando.

@ matthew-brett, agradecería usar compilaciones numpy MSVC con OpenBLAS. Mis últimas construcciones están aquí:

• https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/OpenBLAS-0.2.17_win32.7z
• https://bitbucket.org/carlkl/mingw-w64-for-python/downloads/OpenBLAS-0.2.17_amd64.7z

Como si mingwpy, conda-forge, Anaconda y Canopy no fueran suficientes, aquí viene Intel Distribution para Python y se puede descargar gratis . Incluye solo las herramientas numéricas (SciPy, NumPy, Numba, Scikit-Learn) más algunos extras (mpi4py Intel mp interface y pyDAAL data analytics) y utiliza conda.

No se preocupe, la licencia vence el 29/10/16, por lo que estas compilaciones de Intel son solo una
prueba beta seguida probablemente de una tarifa de licencia MKL+, etc. Construcciones OpenBLAS
seguirá siendo la solución de código abierto, así que gracias por proporcionar estos
construye
El 28 de abril de 2016 a las 7:21 p. m., "Mark Mikofski" [email protected] escribió:

Como si mingwpy, conda-forge, Anaconda y Canopy no fueran suficientes aquí viene
la distribución de Intel para Python
https://software.intel.com/en-us/python-distribution y es gratis
descargar
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation.
Incluye solo las herramientas numéricas (SciPy, NumPy, Numba, Scikit-Learn)
más algunos extras (interfaz mpi4py Intel mp y análisis de datos pyDAAL) y
utiliza conda.

—
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-215600103

Para 1.11.1, parece que falta una rueda de Windows en PyPi para Python 3.5 amd64.

¿Hay alguna razón en particular para eso? Si voy a 1.11.0 (https://pypi.python.org/pypi/numpy/1.11.0), la rueda está ahí.

Gracias por el informe. Creo que debemos haberlo subido demasiado pronto y, por lo tanto, antes de que se construyeran todas las ruedas. He subido la rueda que falta. Parece que necesitamos una prueba para asegurarnos de que esto no vuelva a suceder.

He subido la rueda que falta.

Lo acabo de probar y funciona muy bien!

Muchas gracias por todo el trabajo realizado para que las ruedas de Windows estén disponibles.

Cerrando el problema: las ruedas han estado disponibles para los últimos lanzamientos.

Entiendo que este problema está cerrado, pero creo que deberíamos considerar reabrirlo.

Esto sigue siendo un problema para los usuarios de Windows que intentan hacer funcionar su stack científico sin tener que recurrir a conda. Todavía necesito usar las compilaciones @cgohlke 'MKL' para ver este problema de scipy relacionado que permanece abierto. Aunque se están creando ruedas, sin ser compatibles con scipy, no son usables para muchos.

@waynenilsen , tiene las instrucciones para instalar las nuevas ruedas en el hilo de la lista de correo que está vinculado en el problema que acaba de mencionar:

https://github.com/scipy/scipy/issues/5461#issuecomment-326744515

entonces si lo haces

pip install -f https://7933911d6844c6c53a7d-47bd50c35cd79bd838daf386af554a83.ssl.cf2.rackcdn.com/ --pre scipy

debería funcionar para ti.

No queda nada por hacer para Numpy, por lo que el problema está cerrado. El
El problema de Scipy aún está abierto y probablemente se resolverá en el próximo
liberar.

Esto funciona muy bien para mí, @Juanlu001 . ¡Espero con ansias cuando esto esté en pypi!