Numpy: Package de roue Windows (.whl) sur Pypi

Bien dit - et en effet, @carlkl travaille en coulisses pour que cela se produise. Je crois que nous y sommes presque maintenant - @carlkl - quand allez-vous devenir public, pensez-vous ?

Pour le contexte : la raison pour laquelle ce n'est pas trivial est que les binaires que vous avez liés
dépendre de l'environnement d'exécution et de la bibliothèque mathématique propriétaires d'Intel, qui
complique leur redistribution.

J'ai déployé les récentes roues numpy et scipy basées sur OpenBLAS sur bistar. Vous pouvez les installer avec :

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

Cela fonctionne pour python-2.7 et pour python-3.4. Les roues sont marquées comme « expérimentales ». Les commentaires sont les bienvenus.

Si vous voulez des tests généralisés, vous devez l'envoyer à la liste :-)

Le jeu. 22 janvier 2015 à 20 h 54, carlkl [email protected] a écrit :

J'ai déployé les récentes roues numpy et scipy basées sur OpenBLAS sur bistar.
Vous pouvez les installer avec :

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

Cela fonctionne pour python-2.7 et pour python-3.4. Les roues sont marquées comme
'expérimental'. Les commentaires sont les bienvenus.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-71096693 .

Nathaniel J. Smith
Chercheur postdoctoral - Informatique - Université d'Edimbourg
http://vorpus.org

fwiw Personnellement, j'aimerais changer la taille de l'entier par défaut dans win64 avant de fournir des binaires officiels, bien qu'il y ait eu une certaine résistance quand je l'ai proposé pour la dernière fois, peut-être aussi avec anaconda et d'autres binaires tiers, c'est probablement déjà trop tard : (

en parlant aussi d'openblas, quelqu'un a envie de déboguer, j'en ai marre (ça ressemble au même échec qui casse scipy avec 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 version OpenBLAS utilisée est la 0.2.12. Je n'ai pas encore rencontré de problèmes importants avec cette version.

Les échecs scipy sont copiés sur https://gist.github.com/carlkl/b05dc6055fd42eba8cc7.

Échecs numpy 32 bits uniquement dus à 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)

Je ne suis pas en désaccord sur la modification de la taille entière de win64, mais je pense que c'est
une question distincte qui devrait être découplée des roues. Si c'était le
la première fois que les builds win64 numpy devenaient largement disponibles, alors il
il est logique de les lier, mais à ce stade, il y a déjà des tonnes d'utilisateurs
pendant des années, ils n'utilisent que cgholke ou anaconda ou autre. Alors allons-y
traiter cela comme une discussion indépendante?

(À proprement parler, c'est une rupture de backcompat, mais même ainsi, cela semble raisonnable
que nous pourrions être en mesure de le retirer, car cela réduit en fait
incompatibilité entre les plates-formes - tout le code portable doit gérer 64 bits
dtype=int déjà.)

Le jeu. 22 janvier 2015 à 20h59, Julian Taylor [email protected]
a écrit:

fwiw Personnellement, je voudrais changer la taille de l'entier par défaut dans
win64 avant de fournir des binaires officiels, bien qu'il y ait eu quelques
résistance aussi quand je l'ai proposé pour la dernière fois, peut-être aussi avec anaconda et
d'autres binaires tiers, c'est probablement déjà trop tard :(

en parlant aussi d'openblas, quelqu'un a envie de déboguer, j'en ai marre
(ressemble au même échec qui casse scipy avec openblas):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Lecture invalide de la taille 16
==31931== à 0x7B28EB9 : ddot_k_NEHALEM (dans /usr/lib/libopenblasp-r0.2.10.so)
==31931== par 0x6DBDA90 : DOUBLE_dot (arraytypes.c.src:3127)
==31931== par 0x6E93DEC : cblas_matrixproduct (cblasfuncs.c:528)
==31931== par 0x6E6B7B3 : PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931== par 0x6E6E29B : array_matrixproduct (multiarraymodule.c:2276)

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-71097408 .

Nathaniel J. Smith
Chercheur postdoctoral - Informatique - Université d'Edimbourg
http://vorpus.org

Cela m'intéresse aussi. Existe-t-il un moyen d'aider au processus?

OpenBLAS peut être compilé avec INTERFACE64=1 et numpy peut être compilé avec -fdefault-integer-8 pour un premier essai.

Juste un avertissement. Utiliser des entiers 64 bits dans blas est une idée terrible. Arrêtez-vous avant d'aller trop loin sur cette route. Matlab et Julia avant que je ne le répare, l'ont fait, et cela casse toute bibliothèque tierce qui suppose des entiers 32 bits conventionnels dans blas.

Ce que nous avons fait dans Julia au cours des 5 derniers mois, c'est en fait renommer tous les symboles dans openblas pour leur ajouter un suffixe _64 pour la version 64 bits-int, de cette façon vous pouvez faire de l'algèbre linéaire sur des tableaux vraiment énormes si vous le souhaitez, mais le chargement de bibliothèques externes dans le même processus ne provoquera pas d'erreur de segmentation en raison de l'ombrage des noms et en essayant d'appeler dgemm avec la mauvaise ABI.

Hé les gars, y a-t-il une mise à jour sur les fichiers de roues disponibles pour Numpy ?

Pas que je sache en ce moment.
Le 25 juin 2015 à 04h27, "guyverthree" [email protected] a écrit :

Hé les gars, y a-t-il une mise à jour sur les fichiers de roues disponibles pour
Numpy ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-115215236 .

@guyverthree Christoph Gohlke a publié NumPy en utilisant le MKL d'Intel comme roues depuis un certain temps maintenant.

Voir aussi mon article de blog sur les roues NumPy . J'ai créé des roues NumPy dans ma Dropbox à l'aide de la chaîne d'outils mingw-w64 modifiée de Carl Kleffner et du port OpenBLAS de Zhang Xianyi de GotoBLAS . Olivier Grisel cherchait de l'aide pour modifier le buildbot NumPy afin de répéter les mêmes étapes que celles utilisées dans le fil de discussion des groupes Google OpenBLAS sur lequel je poste .

Ma dernière version est disponible sur binstar.org même si je ne sais pas si anaconda.org est le nouveau nom préféré maintenant.
Les roues pour py-2.6 .. 3.4 (32/64bit) ont environ 2 mois :

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

build avec mon https://bitbucket.org/carlkl/mingw-w64-for-python et un OpenBLAS plus ou moins récent.
pip installer:

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

+1 @carlkl et je souhaite que ceux-ci puissent également être ajoutés à la construction NumPy à la Cheese Factory .

+1 J'aimerais que cela se produise aussi.

IMHO : il y a au moins trois problèmes à résoudre avant que ces versions ne soient acceptées :

• les correctifs mingwpy pour le référentiel numpy doivent être recréés
• il n'y a pas encore de mécanisme de construction à part la construction manuelle
• de nombreux packages Windows tiers (dépolyés par C. Gohlke) dépendent explicitement de numpy-MKL, car les binaires sont liés en dur aux DLL MKL. Cela pourrait changer à l'avenir, car scipy fournit désormais un mécanisme pour une dépendance implicite à l'implémentation scipy BLAS/Lapack. Ainsi, l'installation de (numpy-MKL & scipy-MKL) OU (numpy-OpenBLAS & scipy-OpenBLAS) devrait être suffisante pour tous les autres packages à l'avenir.

@carlkl : FWIW, je ne suis pas vraiment inquiet pour les packages de @cgohlke -- cela va s'arranger (tout comme il n'y a pas de problèmes majeurs maintenant en raison de personnes essayant de combiner scipy-MKL avec anaconda numpy). Et je ne suis même pas vraiment inquiet qu'il y ait un mécanisme de construction sophistiqué -- une construction manuelle est bien tant qu'il y a un fichier texte documentant les étapes.

Le principal problème qui m'inquiète est la durabilité : si nous ne pouvons pas obtenir ces éléments en amont, nous devrons alors re-valider et refaire des correctifs à chaque fois qu'une nouvelle version de gcc / mingw-w64 / msvc arrive dehors, et cela n'arrivera probablement pas. Nous ne voulons pas être pris au piège où nous commençons à fournir des versions, mais cela devient de plus en plus onéreux avec le temps car nous devons faire face à un vieux compilateur grincheux pour le faire.

C'est pourquoi j'ai essayé de réunir des fonds pour soutenir le faire en amont... Les +1 sont super et tout, mais si quelqu'un veut faire un don d'argent ou connaît une entreprise qui pourrait être intéressée à rendre gcc généralement utilisable pour python extensions sur windows, puis envoyez moi un email :-) ([email protected])

Si vous n'avez pas $$ mais que vous voulez quand même aider, alors une façon de le faire serait d'envoyer des correctifs à mingw-w64 améliorant leur prise en charge des fonctions transcendantales comme sin et cos. (Il s'avère que l'ABI MSVC n'est pas d'accord avec tout le monde sur la façon dont l'unité FPU x87 doit être configurée, donc la plupart des fonctions mathématiques du logiciel libre ne fonctionnent pas tout à fait correctement.) Heureusement, il existe de bonnes implémentations compatibles avec les licences dans Android " bionic" libc , donc cela ne nécessite aucune magie mathématique ou une connaissance approfondie des problèmes d'ABI - c'est juste une question principalement mécanique de trouver et d'extraire les fichiers source pertinents, puis de les déposer dans l'arborescence mingw-w64 au bon endroit. Nous pouvons également fournir plus de détails à ce sujet si quelqu'un est intéressé.

N'est-ce pas le genre de chose que numfocus devrait financer ? Si ce n'est pas le cas, alors peut-être pouvons-nous revenir en arrière et revoir notre candidature à la PSF.

De combien d'argent parlons-nous?

+1 veuillez publier des roues pour Windows sur PyPI https://pypi.python.org/pypi/numpy

Si vous essayez pip install numpy sur une installation Windows Python prête à l'emploi, vous obtenez le message d'erreur tristement célèbre "Impossible de trouver vcvarsall.bat".

+1 aiderait vraiment les utilisateurs de Windows.

Impossible de jouer avec https://github.com/glumpy/glumpy à cause de cela. Quelles sont les étapes de construction manuelles pour que Numpy fonctionne sous Windows ? On dirait que le travail AppVeyor est là , donc ne devrait pas poser de problème pour télécharger des artefacts sur GitHub .

À l'heure actuelle, il est littéralement impossible de créer une version rapide de numpy sous licence BSD sur Windows. Nous travaillons à résoudre ce problème, mais c'est une limitation technique ; Les +1 n'auront aucun effet de toute façon. (Le travail appveyor s'appuie sur Windows, mais il utilise une bibliothèque d'algèbre linéaire non optimisée de secours qui n'est pas vraiment adaptée au travail réel.) ou une autre distribution python scientifique .

@njsmith peux-tu être plus précis ? De préférence avec des commandes exactes qui ne fonctionnent pas. Pour le moment, ce truc n'est pas exploitable.

Je pense que « impossible » est trop fort - mais il n'y a certainement pas encore de voie générale évidente à suivre. J'ai mis en place une page wiki sur l'état actuel ici : https://github.com/numpy/numpy/wiki/Whats-with-Windows-builds . N'hésitez pas à éditer / amender tous ceux qui vous en soucient.

@techtonik : il n'y a pas de "commandes exactes qui ne fonctionnent pas", le problème est qu'il n'y a pas de compilateurs qui ont la combinaison de fonctionnalités dont nous avons besoin. mingwpy.github.io documente l'état actuel de nos efforts pour créer un tel compilateur.

@matthew-brett sympa. We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler. C'est pour scipy, non ? Pourquoi est-ce nécessaire pour numpy?

@njsmith http://mingwpy.github.io/issues.html est une initiative géniale avec une bonne analyse. Dommage qu'en amont (Python) ne le supporte jamais (favorise l'utilisation aveugle de MSVS). Mais j'essaie d'avoir une image claire de l'état actuel.

1. est-ce un problème "d'avoir une chaîne d'outils ouverte pour un travail ouvert" ou MSVS ne peut vraiment pas compiler la partie C de numpy?
2. y a-t-il encore des plantages avec les extensions compilées par mingw ?

Pour restreindre le focus pour l'instant, disons qu'il ne s'agit que de Python 2.7 + Win32. Aucune performance n'est nécessaire (je veux juste exécuter l'application pour la tester là-bas), mais des données de référence sur ces performances sont nécessaires.

Alors, quelle est la prochaine action à effectuer pour que cette configuration rende la roue Windows disponible à partir de PyPI ?

@techtonik , il existe maintenant des versions préliminaires des roues numpy et scipy disponibles sur https://anaconda.org/carlkl/numpy et https://anaconda.org/carlkl/scipy. Les performances sont presque aussi bonnes que les roues +MKL du gohlke. Je n'ai pas rencontré de défauts de segmentation avec ma boîte de fenêtre à la maison.

Plusieurs problèmes liés à cette approche ont été discutés et seront résumés sur http://mingwpy.github.io (en construction). La combinaison de la chaîne d'outils basée sur mingw-w64 appelée _mingwpy_ et OpenBLAS est la voie à suivre pour la plate-forme Windows.

_mingwpy_ a une configuration spéciale qui assure une meilleure compatibilité et une utilisation plus pratique par rapport aux chaînes d'outils basées sur mingw-w64 les plus connues, à savoir _mingw-builds_, _tdm_ ...

Tout cela et bien plus est expliqué sur https://github.com/mingwpy/mingwpy.github.io. N'hésitez pas à y ouvrir des problèmes ou des relations publiques.

@techtonik : Je pense que c'est un grave malentendu/une fausse représentation de la position de python.org en amont. Je dirais qu'ils refusent de promouvoir le schisme de la prise en charge de Windows CPython en plusieurs ABI incompatibles (et je suis d'accord avec eux sur ce point). Steve Dower, qui maintient les versions officielles de Windows en amont, nous a aidés à comprendre comment rendre mingwpy compatible avec ces versions.

OMI, la condition préalable pour mettre des roues numpy sur pypi est qu'elles doivent être (a) performantes, (b) maintenables, (c) sous licence appropriée. Si vous souhaitez que le projet applique un ensemble de critères différent (c'est-à-dire que nous devrions faire des efforts pour fournir des roues aux performances épouvantables), la prochaine étape consiste à envoyer un e-mail à la liste de diffusion numpy en faisant valoir que vos critères sont meilleurs.

MSVS peut créer numpy lui-même, mais il ne peut créer aucune des implémentations BLAS de haute qualité sous licence appropriée. En amont, mingw-w64 peut créer numpy + BLAS (avec des correctifs), mais le résultat se bloquera si vous essayez de l'utiliser avec CPython en amont. La chaîne d'outils mingwpy de Carl peut créer numpy + BLAS (avec des correctifs), et le résultat fonctionnera sur certaines versions de python (mais pas 3.5), mais la chaîne d'outils est fragile et impossible à maintenir dans son état actuel ; littéralement personne à part Carl ne sait comment il a été construit ou pourrait le recréer. Personne dans le projet numpy n'est prêt à s'engager à fournir des "versions officielles" en utilisant une chaîne d'outils avec ces limitations, nous nous concentrons donc sur les corriger.

Il existe plusieurs sources trivialement disponibles de builds numpy de haute qualité sur Windows. Je suis vraiment curieux : pourquoi insistez-vous autant pour que nous lancions des builds de mauvaise qualité juste pour qu'ils soient sur PyPI ?

@njsmith Je voulais juste préciser que mon cas d'utilisation (qui, je l'admets, ne justifierait en aucun cas un investissement en ressources de développement à lui seul) consiste à distribuer un package très simple sur PyPI qui dépend de matplotlib , qui à son tour dépend de numpy .

Pour mon cas d'utilisation, les performances ne sont pas un problème, mais pouvoir avoir un utilisateur Windows simplement pip install ____ mon package qui installe récursivement matplotlib , numpy , etc est beaucoup plus facile à expliquer que de les pointer vers des URL à installer également, en particulier pour les utilisateurs qui ne comprennent pas l'écosystème de construction Python. C'est donc surtout pour une simplification des instructions d'installation.

Encore une fois, je n'essayais pas d'utiliser mon cas comme justification, mais je voulais juste partager car vous étiez curieux.

@johnthagen : Oh, bien sûr, pas de soucis ! Je comprends tout à fait pourquoi cela est souhaitable en général ; si je parais grincheux dans ces commentaires, c'est exactement parce que moi et d'autres avons passé énormément de temps au cours de la dernière année à essayer de résoudre ce problème :-). Je demandais juste à @techtonik parce qu'il semblait en quelque sorte qu'ils disaient "Je veux juste essayer une petite application, donc je ne me soucie pas des performances", mais s'ils veulent juste essayer une petite application, je ne le fais pas savoir pourquoi ils se soucient de la partie PyPI :-)

(Il est important de garder à l'esprit que toute roue que nous installons sur pypi commencera immédiatement à être utilisée par des dizaines de milliers de personnes, dont la plupart ne lisent pas ce fil. Je pense donc que nous avons l'obligation de nous assurer que quoi que ce soit nous mettons en place sera en fait largement utilisable pour un large éventail de cas d'utilisation.)

Je pense qu'il serait essentiellement trivial de commencer à expédier des roues numpy 32 bits pour Python 2.7, en utilisant ATLAS. Ils devraient probablement être SSE2, donc crash sans instructions SSE, mais cela n'affecterait qu'une très petite proportion d'utilisateurs. Nous pourrions utiliser notre chaîne d'outils de version actuelle pour cela. Gardez à l'esprit que cela signifierait que pip donnerait une roue binaire pour 32 bits, mais reviendrait à l'installation source pour 64 bits. Serait-ce utile?

@njsmith Merci pour l'info ! Appréciez tout votre travail acharné :)

Je pense qu'il serait essentiellement trivial de commencer à expédier des roues numpy 32 bits pour Python 2.7, en utilisant ATLAS. Ils devraient probablement être SSE2, donc crash sans instructions SSE, mais cela n'affecterait qu'une très petite proportion d'utilisateurs. Nous pourrions utiliser notre chaîne d'outils de version actuelle pour cela. Gardez à l'esprit que cela signifierait que pip donnerait une roue binaire pour 32 bits, mais reviendrait à l'installation source pour 64 bits. Serait-ce utile?

@matthew-brett la configuration actuelle de numpy-vendor est cassée, il y a une erreur de segmentation dans fromfile . La gestion des descripteurs de fichiers est en quelque sorte faussée, et nous ne savons pas si cela est dû à un changement dans la version de Wine, la version Ubuntu ou (peu probable) un changement dans numpy lui-même. Je dirais que passer plus de temps là-dessus est une perte de temps - mettre ce temps dans mingwpy est bien plus productif.

J'ai NumPy 1.10.4 compilé avec OpenBLAS (Int32 Windows 64, binaire précompilé v0.2.15) et MKL (en utilisant une licence communautaire sur MKL, c'est-à-dire une distribution gratuite). Mais... Je ne peux pas compiler SciPy - il semble qu'une petite partie recherche le compilateur gfortran "compilateur fortan introuvable" si quelqu'un a une idée de la façon de résoudre ce problème. J'utilise iffort.exe car Anaconda prend en charge ces versions en tant que plug-ins directs. Compilé pour Python 3.5 avec Microsoft Visual Studio Community 2015, si quelqu'un peut m'aider à comprendre comment l'emballer pour la distribution... alors je téléchargerai sur github ou sur le site Web d'anaconda. Appréciez-le.

@mrslezak : probablement la meilleure chose à faire est de poster sur la liste de diffusion des développeurs scipy, ou d'ouvrir un nouveau bogue sur scipy, plutôt que de poster sur des bogues existants aléatoires :-)

Je suis vraiment curieux : pourquoi insistez-vous autant pour que nous lancions des builds de mauvaise qualité juste pour qu'ils soient sur PyPI ?

Juste parce que j'en ai marre de raser les yaks. Je sais que les gens veulent de la performance, et c'est bien que quelqu'un ait les ressources nécessaires, mais pour moi personnellement, la complexité de faire cette tâche est énorme, donc je ne peux qu'espérer que vous y parviendrez, mais pour moi cela peut ne jamais arriver, ou cela peut arriver dans deux ou trois ans, au cours desquels les gens continuent de se heurter aux murs et de perdre du temps en heures proportionnellement aux téléchargements de tous les binaires Windows de PyPI qui nécessitent l'installation de NumPy en tant que dépendance directe ou indirecte.

Ouf. Probablement la plus longue phrase en anglais que j'ai écrite de toute ma vie. =)

@techtonik - Je partage votre frustration, je pense que beaucoup d'entre nous se sentent frustrés à ce sujet.

@carlkl - J'aimerais vos commentaires ici.

Il y a clairement une forte pression pour que nous mettions en place une roue Windows numpy. Voici une liste des roues les plus téléchargées pour n'importe quelle plate-forme il y a quelques semaines : https://gist.github.com/dstufft/1dda9a9f87ee7121e0ee . Les roues Windows matplotlib, scikit-learn et pandas se trouvent aux positions 3, 4 et 5. Il y aurait un grand marché pour les roues Windows numpy.

Je pense que les questions sur la table sont :

1) Pouvons-nous nous engager à obtenir une roue numpy fonctionnelle et presque optimale sur pypi à court ou moyen terme (disons 6 mois). Je dirais que la réponse est oui (heureux d'entendre un désaccord) ;
2) Cela vaut-il la peine de mettre en place une roue numpy non optimale en attendant pour que les autres puissent s'appuyer dessus ?

La question 2 est la plus difficile. "Pas optimal" pourrait signifier lent (pas de blas / lapack optimisé) ou difficile à prendre en charge (aucune garantie que nous puissions répéter la construction dans 6 mois).

Je peux voir des arguments contre "lent". Nous devons faire attention à ce que, lorsque les roues commencent à fonctionner pour Windows, elles ne déclenchent pas immédiatement des questions de débordement de pile avec les réponses "Ne téléchargez en aucun cas les roues numpy de pypi". Je pense que ces réponses seraient raisonnables et elles dureraient assez longtemps pour nous blesser.

Sens non optimal, difficile de soutenir le processus de construction, je pense que nous pouvons vivre avec, si nous nous engageons vraiment à trouver une solution à long terme assez rapidement.

Il y a quelque temps, j'ai construit des binaires ATLAS pour Windows : http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

Ai-je raison de penser que nous pouvons déjà créer des binaires numpy qui passent tous les tests en utilisant ces binaires ATLAS ?

Dans ce cas, pourquoi ne les mettons-nous pas en place ?

1) Pouvons-nous nous engager à obtenir une roue numpy fonctionnelle et presque optimale sur pypi à court ou moyen terme (disons 6 mois). Je dirais que la réponse est oui (heureux d'entendre un désaccord) ;

Je l'espère, sinon cela signifie que d'ici là, nous aurons soit rencontré des problèmes inattendus avec la proposition mingwpy, soit nous n'aurons pas mis en cache ce qu'elle permet :)

2) Cela vaut-il la peine de mettre en place une roue numpy non optimale en attendant pour que les autres puissent s'appuyer dessus ?

Vos builds ATLAS semblent être terminés avec Cygwin ? Ou s'agit-il simplement d'un nom de répertoire et vous avez utilisé une version de MingwPy ?

Je pense que mes versions d'ATLAS ont été faites avec Cygwin, mais elles ne sont pas liées à Cygwin.dll, donc je pense qu'elles seraient sans danger pour la construction avec MSVC.

mingwpy n'est pas en difficulté mais a besoin de son temps. Construire la chaîne d'outils gcc, OpenBLAS puis numpy/scipy avec différentes variantes prend du temps de construction et de test. Et je ne publierai pas de binaires sans publier d'abord tous les scripts de build. Un mingwpy basé sur gcc-5.3.0 est presque prêt, ainsi qu'OpenBLAS. La prochaine étape consiste à créer des roues numpy et scipy basées sur cela.

Cette discussion ainsi que les dernières contributions au fil numpy "Roues Linux multi-distribution - veuillez tester" conduit à la question de savoir si OpenBLAS a la qualité qui permet le déploiement de roues Windows numpy basées sur OpenBLAS. Mais je ne suis pas sûr que l'utilisation d'atlas soit une meilleure solution. Peut-être que les roues numpy devraient être construites avec les deux variantes pour une première phase de test.

Je suppose / j'espère que nous parviendrons d'une manière ou d'une autre à obtenir qu'OpenBLAS soit de qualité acceptable. Mais, jusqu'à ce moment-là, il me semble raisonnable de commencer avec les roues numpy ATLAS, en espérant qu'en temps voulu, nous pourrons passer aux roues OpenBLAS. Cependant, nous devrons peut-être vérifier SSE2 pour les versions 32 bits : http://mingwpy.github.io/blas_lapack.html#atlas

Placer une case de progression en haut de la page PyPI peut attirer plus de personnes sur le problème (y compris celles qui peuvent faire un don pour soutenir l'initiative). La case peut lister la stratégie actuelle, les critères d'acceptation (lien vers le test de performance ?), le statut et l'action qui sera effectuée lorsque la version finale sera prête (augmenter la version majeure ?).

@matthew-brett, il n'est toujours pas clair pour moi que votre proposition de lancer quelque chose soit viable. Quel compilateur utiliseriez-vous ? Si MingwPy, nous avons un plan clair pour savoir dans quel ordre faire et cela semble maintenant trop tôt. S'il s'agit d'un autre gcc, nous revenons au problème de liaison statique et à la distribution de la douleur des DLL.

Mon idée était de compiler numpy avec ATLAS en utilisant MSVC. Bien sûr, cela ne pourrait pas fonctionner pour scipy, mais au moins les gens pourraient commencer à expédier leurs roues Windows, quelle que soit leur construction.

Je viens d'essayer et j'ai eu des erreurs de la forme unresolved external symbol __gfortran_compare_string , donc je suppose que les binaires d'ATLAS ont des références pendantes à l'exécution de gfortran. @carlkl - des suggestions sur la façon de déboguer ?

Mélanger des fichiers objets statiques provenant de différents compilateurs est quelque chose que vous devriez éviter comme le diable évite l'eau bénite. Dans certains cas, cela fonctionne, mais pour un ensemble différent de combinaisons de compilateurs, cela échouera.
BTW : MS lui-même ne prend pas officiellement en charge ou ne recommande pas de mélanger des objets statiques provenant de différentes versions de leur Visual Studio.

J'ai fait quelques tests il y a quelques semaines, lorsque cette question apparaît : la bibliothèque statique npymath.a créée par mingwpy peut-elle être utilisée avec les compilateurs MSVC ? En principe , cela peut fonctionner si certains objets sélectionnés dans les bibliothèques d'exécution de gcc sont ajoutés à cette bibliothèque. J'en suis venu à la conclusion qu'une telle approche est instable et fragile.

Si l'atlas est une option pour construire des roues numpy, j'essaierais de le construire en tant que DLL, des objections?

Mélanger des fichiers objets statiques provenant de différents compilateurs est quelque chose que vous devriez éviter comme le diable évite l'eau bénite.

Je pense que https://mingwpy.github.io/motivation.html (page Pourquoi) manque d'explications très simples et directes du problème pour les modules chargés dynamiquement . J'ai parlé avec les gars de Far Manager, dont le gestionnaire de fichiers est natif de Windows, construit sur des plugins, qui sont chargés à partir de .dll écrits dans différentes langues, et ils n'ont pas ce problème avec "exactement le même compilateur". Je me demande pourquoi Python l'a - il charge également des modules à partir de .dlls ..

@techtonik , mon commentaire concernait la liaison de fichiers objets produits par différents compilateurs en un seul fichier binaire (DLL ou EXE). C'est ce que je voulais dire avec _mélanger des fichiers d'objets statiques_. Une telle approche _peut_ fonctionner dans certaines situations bien testées si elle est manipulée avec soin. Mais c'est loin d'être un moyen robuste de construire des binaires.

L'interopérabilité des DLL de différents compilateurs dans un espace de processus commun est une chose complètement différente. Habituellement, une telle approche fonctionne bien en règle générale. Il faut s'assurer que ces binaires sont liés à la même DLL d'exécution MS s'ils partagent des descripteurs de fichiers. Il existe également d'autres problèmes possibles d'ABI qui doivent être traités. Et bien sûr, vous avez besoin d'un ensemble différent de débogueurs pour le débogage en fonction des compilateurs utilisés.

minwgpy est un projet de prise en charge de la création d'extensions python à l'aide de mingw-w64 pour une utilisation dans les versions standard MSVC CPython.

OK - J'ai réussi à créer numpy avec une liaison MSVC avec une version d'ATLAS.

ATLAS construit ici :

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

Il contient des instructions simples sur la façon de créer la dll ATLAS.

Tous les tests numpy réussissent à l'exception de la vérification du script f2py , je pense que c'est un échec bénin.

La dernière étape consiste à expédier la bibliothèque dynamique à l'intérieur de la roue. @carlkl - quelle est votre façon préférée de le faire actuellement ?

C'est bon à entendre, j'aimerais aussi comprendre comment créer une roue avec
binaires inclus - peut publier une version MKL et demander à d'autres de tester l'OpenBlas
un.
Le 11 février 2016 à 13h28, "Matthew Brett" [email protected] a écrit :

OK - J'ai réussi à créer numpy avec une liaison MSVC avec une version d'ATLAS.

ATLAS construit ici :

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

Il y a des instructions simples sur la façon de construire l'ATLAS
dll.

Tous les tests numpy réussissent à l'exception de la vérification du script f2py, je pense que c'est un
échec bénin.

La dernière étape consiste à expédier la bibliothèque dynamique à l'intérieur de la roue. @carlkl
https://github.com/carlkl - quelle est votre façon préférée de faire actuellement
cette?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-183021728 .

La dernière étape consiste à expédier la bibliothèque dynamique à l'intérieur de la roue.

Et le chèque SSE2 et le sauvetage gracieux ?

@mrslezak - le moyen le plus simple est de le placer dans le dossier numpy/core, car il est automatiquement chargé dans l'espace de processus lors de l'importation de multiarray.pyd.

La dernière étape consiste à expédier la bibliothèque dynamique à l'intérieur de la roue

@matthew-brett: Je suis sûr à 99% que la "bonne" façon de le faire est via les assemblys SxS, dont la documentation est rigoureusement pauvre, mais probablement faisable... Je sais que vous avez passé du temps à essayer de les comprendre, et je J'ai lu aussi, donc si vous voulez vous asseoir à un moment donné et essayer de régler les détails, faites-le moi savoir :-).

(Le problème avec toutes les autres approches est que les processus Windows IIUC conservent normalement un seul espace de noms global de toutes les dll importées. Cela signifie que si deux extensions contiennent toutes deux un fichier nommé foo.dll, l'extension chargée en premier aura sa version. de foo.dll "win" et l'autre extension finira par l'utiliser - le problème classique de "dll hell". Et IIUC, le seul moyen d'éviter ce comportement est de passer par la machinerie SxS, aussi moche soit-elle.)

Nathaniel - J'ai écrit ma compréhension des assemblys SxS ici : https://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-assemblies

Ma conclusion finale était que c'était sans espoir et que, dans tous les cas, renommer la DLL d'une manière unique par processus était une alternative raisonnable.

Ralf - suggestion pour formaliser la manière d'ajouter des crochets SSE2, etc. au processus d'installation : https://github.com/numpy/numpy/pull/7231

@matthew-brett : J'ai lu ces notes, ouais... et pouah soupir, sans espoir pourquoi ? En raison des problèmes liés au même répertoire ? Et avez-vous des idées sur la façon d'accomplir ce changement de nom ? (Je n'ai pas encore trouvé d'équivalent à patchelf --replace pour les fichiers PE, et la régénération des fichiers .lib n'est pas triviale -- bien que j'utilise mingw-w64 ce n'est pas si mal parce que vous pouvez lier directement le .dll . Au moins si vous n'avez pas besoin de renommer libgfortran ou similaire...)

(Il est possible qu'il y ait un PE équivalent à patchelf --replace quelque part sur cette liste : http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

Je ne vois pas de problème pour charger satlas.dll (ou alternativement libopenblaspy.dll ) avec multiarray.pyd, car ce répertoire est préféré lors de la recherche de DLL. Cette approche fonctionne du fait que cette DLL est chargée via LoadLibraryEx partir de python dans l'espace de processus. Le dossier numpy/core doit être utilisé, car voici la toute première occurrence d'une extension python dépendante de blas lors de l'importation. Toute autre tentative de chargement d'une DLL portant le même nom est simplement ignorée car cette DLL est déjà chargée dans l'espace de processus. Windows recherche simplement le nom de la DLL BTW.

Le début de l'enfer des DLL Si une telle bibliothèque dépend de _autres_ DLL, mais ce n'est pas le cas car satlas.dll et libopenblaspy.dll sont autonomes et ne dépendent que des DLL standard du système Windows. C'est ce que l'on appelle généralement les DLL liées de manière statique - cela signifie que le code d'exécution de gcc est lié de manière statique.

_Pour comparaison_ : pour importer les bibliothèques MKL, l'approche consiste à étendre temporairement le PATH à numpy/core . Malheureusement, cela échoue si les anciennes bibliothèques MKL sont placées dans les dossiers système de Windows.

@matthew-brett @njsmith : Renommage des DLL : à quoi ça sert ?

@carlkl : le cas qui nous inquiète est si numpy inclut atlas.dll , et aussi scipy inclut atlas.dll , et à un moment donné, l'utilisateur met à jour scipy (et obtient une version plus récente de atlas.dll ), mais scipy finit par utiliser l'ancienne version de atlas.dll qui provient du package numpy. C'est mauvais, car scipy peut dépendre de la version la plus récente -- donc les choses se briseront de manière aléatoire en fonction des versions exactes des packages impliqués et de l'ordre dans lequel l'utilisateur les importe. Cela se produit parce que si numpy inclut une DLL nommée atlas.dll alors cela "réclamera" le nom atlas.dll dans l'espace de noms DLL à l'échelle du processus, et cela empêchera tout autre package d'utiliser différentes DLL avec cela Nom.

Deux solutions possibles sont (a) si les éléments SxS/activation-contexts peuvent fonctionner, cela fournit un moyen de désactiver l'espace de noms DLL à l'échelle du processus, ou (b) si numpy contient numpy-atlas.dll , et scipy contient scipy-atlas.dll , alors ils peuvent partager le même espace de noms à l'échelle du processus sans entrer en collision.

Ou si les deux dépendent d'un package clib_atlas distinct qui fournit la dll ? Ensuite, les exigences de dépendance de version peuvent être exprimées comme d'habitude pour les packages python.

@tkelman : Nous devons trouver comment prendre en charge à la fois les DLL des fournisseurs et les DLL distribuées séparément, je pense, car les deux options sont appropriées dans différentes situations. Et le cas du vendeur est beaucoup plus facile pour commencer :-)

Je pense que la solution côte à côte nécessitera des droits d'administrateur pour être installée dans Windows system32. S'il te plaît, ne fais pas ça.

Il existe également des assemblys côte à côte « privés », où les assemblys se trouvent dans votre propre arbre binaire, mais il y a une limite de deux marqueurs de chemin de répertoire ascendant que vous pouvez utiliser pour pointer vers l'assembly, c'est-à-dire que vous pouvez pointer vers ..\..\some_assembly mais pas ..\..\..\some_assembly .

Ainsi, par exemple, scipy/first/second/third/something.pyd ne peut pointer que vers un assembly côte à côte dans les répertoires third ou second ou first mais pas dans scipy (ou d'autres répertoires à l'intérieur de celui-ci.

OK, j'ai construit des roues pour les tests, ici :

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

Comme d'habitude:

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

Automatisation de la construction très grossière ici : https://github.com/matthew-brett/np-wheel-builder

Wheels réussit tous les tests, à l'exception d'un faux échec lors de l'exécution du script f2py (un bogue dans ce test, je crois).

Ralf - SSE2 vérifier ici : https://github.com/matthew-brett/np-wheel-builder/blob/master/_distributor_init.py

J'ai également construit des programmes d'installation 64 bits pour Pythons 2.7, 3.4, 3.5, à la même adresse Web.

@matthew-brett, je n'ai pas la permission d'accéder à ces fichiers.

@matthew-brett, la technologie d'assemblage SxS n'est plus utilisée (depuis VS2010), voir https://en.wikipedia.org/wiki/Side-by-side_assembly.

Que diriez-vous d'ajouter des numéros de version aux noms de fichiers DLL : libopenblaspy_0.15..dll ou libatlas_3.10.1.dll ou similaire. Et puis utilisez un _proxy DLL_ qui est utilisé comme DLL de transfert vers les DLL versionnées. Les extensions Numpy et scipy doivent être construites sur une DLL proxy appelée _libblaslapack.dll_.

Si l'atlas est utilisé, cela permettrait en principe le chargement d'une DLL d'atlas optimisée au moment de l'exécution. (pas nécessaire si vous utilisez openblas)

Tout cela pourrait être géré à l'aide d'un package clib_openblas et/ou clib_atlas. (Maintenant, je dois apprendre à générer le code d'une DLL de transitaire). Numpy lui-même pourrait être équipé d'atlas ou d'openblas. Cela devrait être chargé si ni clib_openblas ni clib_atlas ne sont disponibles.

@carlkl : Je pense que la page wikipedia est déroutante, et essayer de dire que VS 2010 n'utilise pas SxS _pour certaines bibliothèques_, mais SxS en général est certainement toujours utilisé (par exemple plus tard sur cette même page : "À partir de Vista, le système d'exploitation utilise également WinSxS pour ses composants de base.")

Je crois que la façon dont vous construisez une dll de transitaire avec msvc consiste à écrire un fichier .def spécial, puis à l'utiliser lors de la génération de votre .dll. Mais, comment une dll de transitaire aide-t-elle? (Sur osx ou Linux, je pense que cela peut être un outil utile, mais sur Windows, vous avez toujours ce problème d'espace de noms dll global ennuyeux.)

@njsmith , nous devrions chercher une solution compréhensible. C'est vrai que SxS existe toujours. Il n'est généralement plus utilisé pour autre chose que le système d'exploitation lui-même.

(1) La solution la plus simple à mon humble avis est de lier Blas Lapack de manière statique. Cette approche crée d'énormes binaires et n'est donc pas recommandée (du moins par moi).
(2) La deuxième solution la plus simple consiste à installer la DLL dans numpy/core et c'est tout.
(3) La troisième solution consiste à _forcer_ une dépendance à un package Blas/Lapack externe, qui a été versionné et précharge simplement la DLL Blas Lapack. L'utilisation de pip garantit que la version correcte de la DLL est disponible.
(3) Si une telle dépendance contrainte n'est pas la bienvenue, elle pourrait être augmentée avec une DLL fournie par numpy et scipy lui-même. Ces DLL doivent être chargées _uniquement dans les situations_, où une DLL externe n'est pas installée. Cela signifie qu'un package Blas/Lapack externe serait préférable mais n'est pas strictement nécessaire.
Le gros avantage d'une telle solution est que les nouvelles versions d'openblas/atlas corrigées des bogues peuvent être échangées sans réinstaller numpy/scipy.
(4) Utilisation de manifestes et SxS. @njsmith , pouvez-vous remplir les détails de cette affaire ?

Désolé - j'ai corrigé les autorisations pour les roues - fonctionnent-elles maintenant ?

Désolé de ne pas revenir vers vous sur les assemblys SxS. Mon commentaire "désespérant" sur SxS n'a pas été très utile, je vais essayer de le déballer.

La question est de savoir si nous devrions utiliser des assemblys SxS « privés », qui sont des assemblys SxS que nous hébergeons dans notre propre arbre binaire. Les assemblys SxS peuvent également être "partagés". Les assemblys partagés vont dans votre dossier système Windows et doivent être installés par un package d'installation MS . Je pense que cela signifie que les assemblages partagés ne peuvent pas être installés via une roue et, dans tous les cas, auraient besoin d'autorisations d'administrateur, donc je pense que nous pouvons rejeter les assemblages partagés en option.

Alors, quels sont les problèmes liés à l'utilisation d'assemblages SxS privés ?

Le premier problème est que nous ouvririons une nouvelle voie si nous essayions de le faire. Je ne connais aucun autre projet open source qui les utilise. J'ai interrogé Steve Dower sur les assemblages SxS. Steve travaille chez MS et est actuellement le mainteneur Python de Windows. Il m'a suggéré de les éviter. Il semblait que personne avec qui il travaillait ne les connaissait. Mes notes liées ci-dessus étaient une tentative de comprendre les quelques cas qu'il connaissait de quelqu'un (apparemment) les utilisant avec succès. Il existe très peu de bonnes ressources pour les expliquer.

Connexe est l'observation que Carl a déjà soulevée selon laquelle la SEP elle-même semble être ambivalente quant à leur utilisation. Par exemple, pour le runtime MSVC, une application évidente des assemblys SxS, ils utilisent à la place des noms de DLL uniques (MSVCR90.DLL, MSVCR100.DLL, etc.).

Pour utiliser des assemblys SxS, je pense que nous devrions ajouter du code d'initialisation standard à chaque module compilé qui doit charger une autre DLL, afin de créer un "contexte d'activation". EDIT : Nathaniel m'a rappelé que Windows déclenchera automatiquement un nouveau contexte d'activation s'il voit la preuve d'un "manifeste" d'assemblage côte à côte associé à la DLL (qui peut être intégré dans la DLL, mais aussi être un fichier XML externe) .

Donc, pas désespéré, mais difficile.

Je suis désolé pour cette question très basique, mais, sous Windows, si je charge la bibliothèque foo.dll contenant my_symbol dans un module d'extension, que se passe-t-il si je charge la bibliothèque bar.dll , contenant également my_symbol , dans un autre module d'extension ? Je suppose qu'ils sont accessibles séparément dans mon processus, donc la première extension obtiendra foo: my_symbol et la deuxième extension obtiendra bar:my_symbol ? Quelqu'un peut-il m'indiquer une référence ?

Si c'est vrai, alors tout ce dont nous aurions besoin, pour éviter l'enfer des DLL, c'est d'avoir un nom de DLL qui était très peu susceptible d'être utilisé par accident dans le même processus (où l'utilisateur n'avait pas l'intention d'utiliser notre DLL exacte).

Lors de la liaison, chaque symbole est lié à une DLL spécifique identifiée par son nom. Pendant l'exécution, il faut s'assurer que la DLL correcte est chargée si plusieurs DLL avec le même nom peuvent être trouvées. Par conséquent, l'ordre de recherche est important.
Exemple Mes roues numpy anaconda.org utilisent la bibliothèque openblas avec le nom libopenblas_py_.dll pour éviter un conflit de nom avec une libopenblas,dll non standard utilisée par Julia.

Les versions récentes de julia utilisent désormais un nom différent libopenblas64_ pour refléter l'ABI non standard avec laquelle nous construisons. Sur 32 bits, nous ne renommons aucun symbole ni le nom de la bibliothèque car il n'y a pas vraiment de raison de choisir des entiers 64 bits dans l'interface là-bas.

L'ombrage des noms de symboles dans les bibliothèques partagées était en fait plus un problème sous Linux et OSX que Windows, mais nous avons fait la même chose partout pour plus de cohérence.

Bien que cela n'exclue pas la possibilité sur 32 bits où les ABI sont les mêmes que nous ne puissions pas nous séparer d'une autre manière, comme avoir besoin d'une version trop ancienne ou trop nouvelle pour l'autre.

J'ai peaufiné un peu le processus de construction - voir https://github.com/matthew-brett/np-wheel-builder

Maintenant que le processus est raisonnablement automatisé, je pense qu'il est pratique de continuer à construire ces roues au cours des prochaines versions si nous le devons. Je suis heureux de le faire en tant que gestionnaire de versions de Windows jusqu'à ce que mingwpy soit conforme aux spécifications.

J'ai testé ces roues sur Python 2.7, 3.4, 3.5 32 bits et 64 bits et quelques autres ont également testé, donc je pense qu'elles sont en bon état.

Y a-t-il autre chose que je puisse faire pour vous rassurer que ceux-ci valent la peine d'être affichés sur pypi, comme l'a demandé l'OP ?

Bonjour à tous! Je voulais juste me lancer dans cette discussion parce que j'ai été frustré par mon incapacité à installer numpy et scipy partir des sources pendant un certain temps, il est donc certainement bénéfique pour moi de lire ce qui est passe sur ce front.

@matthew-brett : Ce script d'automatisation est génial . Même s'il ne parvient pas tout à fait à PyPI, cela semble être un moyen très viable de construire numpy partir des sources (voir ce numéro que j'ai ouvert ici ). Il est également extrêmement proche de pouvoir construire scipy dans la mesure où je peux tout construire, mais les tests semblent alors provoquer une erreur de segmentation quelque part dans Python.

De plus, pour tous ceux qui ont réellement construit des roues numpy , j'ai essayé de rassembler une documentation soignée et à jour sur la construction de ces bibliothèques à partir des sources pour remplacer ce qui est actuellement en ligne, donc j'apprécierais grandement la contribution des gens sur ce front aussi !

Merci pour vos commentaires - et votre travail sur la documentation de la construction - qui seraient très utiles.

Je suppose que vous avez vu http://mingwpy.github.io - il y a une bonne quantité de choses là-bas, bien sûr, spécifiques au projet mingw-w64 et à la chaîne d'outils mingwpy.

Merci @matthew-brett ! Il passe numpy.test() . Le test f2py.py était un problème dans test_scripts() avec virtualenvs qui a été corrigé dans numpy-SHAd3d2f8e , mais je reçois 3 avertissements, 2 dépréciation et 1 exécution.

Une dernière demande, espérons-le mineure, est-il possible d'afficher un badge de build sur votre repo np-wheel-builder et/ou PyPI ? On dirait que buildbot 0.8 les a, et il y a même un package/repo python pour les rendre jolis, BuildbotEightStatusShields-0.1 .

De plus, je suis curieux, j'ai eu peur de la version 64 bits d'ATLAS Windows en raison du manque de paramètres de réglage. Cela a-t-il réellement « pris toute la journée » ou existe-t-il un ensemble approprié de paramètres architecturaux par défaut ?

Pour info : Continuum vient de sortir Anaconda avec mkl numpy optimisé. Je pense qu'ils ont suivi ce fil.

Maintenant, pour les versions scipy avec les mêmes bibliothèques d'atlas. Faut-il gfortran ?

Oui. Sinon, vous ne pourrez compiler aucun des fichiers .f dans scipy . Bonne chance avec ça ! Comme je l'ai dit plus tôt, je me suis _vraiment proche_, mais si vous réussissez à passer les tests, ce serait génial !

Oui, je crains que la construction d'ATLAS n'ait pris environ 8 heures sur une machine ne faisant rien d'autre. Le script de construction ATLAS se trouve dans le référentiel np-wheel-builder .

En ce qui concerne les nouvelles MKL , c'est super si vous êtes un utilisateur conda , même si je pense qu'utiliser une distribution Python avec numpy et scipy pré-installé est quelque chose qui a été encouragé pendant un certain temps. Parlez-moi quand vous pourrez également obtenir les bibliothèques MKL elles-mêmes gratuitement. :)

Pour construire avec gfortran - je pense que mingwpy est notre meilleur espoir.

@matthew-brett : Merci d'avoir pris le temps de créer ATLAS ! J'ai déjà essayé d'exécuter votre script et j'ai continué à rencontrer des problèmes, probablement en raison d'incompatibilités spécifiques à la machine.

Désolé pour les problèmes. Je viens de créer les binaires ATLAS dans le référentiel np-wheel-builder, c'était sur une nouvelle installation de Windows Server 2012 et de Cygwin 64 bits, avec les versions exactes d'ATLAS et de lapack répertoriées. Les archives sources que j'ai utilisées se trouvent sur http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/. Si vous avez une autre version d'ATLAS, cela pourrait facilement devenir velue.

Hmmm... c'est probablement le cas. Encore une fois, très apprécié étant donné l'effort qu'il vous a fallu pour le faire. Si vous êtes en mesure de trouver un moyen de déployer des versions d'ATLAS compatibles Windows qui ne nécessitent pas autant de temps et de ressources qu'aujourd'hui, ce serait formidable !

@gfyyoung

Parlez-moi quand vous pourrez également obtenir les bibliothèques MKL elles-mêmes gratuitement. :)

Voir https://software.intel.com/sites/campaigns/nest/ et https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 - ou vouliez-vous dire la source ?

@tkelman , je viens de le voir sur le nouveau site du projet mingwpy de @carlk mais la licence de la communauté Intel Nest n'a pas d' fort , et sans cela, comment scipy?

@tkelman : Oups, je ne sais pas pourquoi j'avais oublié cette licence communautaire. Cependant, @tkelman soulève un point valable.

@tkelman : Vous pourriez essayer avec le MinGW, mais d'après ce que j'ai vécu, cela ne fonctionne malheureusement pas. Cela ne vous fera même pas dépasser numpy en raison de problèmes de compatibilité.

@mikofski right, n'aide pas pour scipy étant donné le manque de compilateurs. Seules les options d'aujourd'hui pour les versions scipy seront mingwpy, ou la version all-gcc-all-the-time MSYS2 de Python (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- python-scipy). Ce dernier ne sera bien sûr pas compatible avec les binaires cpython ou pypi construits par msvc, il ne traitera donc pas tous les modules au-delà de scipy.

@matthew-brett : quel est le déficit de vitesse de ces roues ATLAS par rapport aux openblas et/ou MKL ?

Quelqu'un s'est-il penché sur PGI Fortran. Ce n'est pas mentionné sur le site du projet @carkl mingwpy. J'ai essayé de l'utiliser une fois, je suis allé assez loin dans ce terrier de lapin, mais je ne me souviens pas de l'arrêt du spectacle. Je pense que la licence est permissive même si c'est une source fermée. Peut-être que PGI Fortran jouera mieux avec msvc ?

@mikofski : Je ne l'ai pas sous les yeux, mais quand j'ai regardé PGI l'année dernière, je me souviens que ma conclusion était que c'était encore pire qu'Intel (en termes de vous obliger à ajouter des restrictions incompatibles avec les FOSS à votre licence) .

D'accord, peut-être que certains fonds ciblés peuvent être ciblés sur une solution BLIS/FLAME pour les architectures x86 ?

Apparemment, Nvidia/PGI apportera son front-end Fortran en tant qu'open source à LLVM d'ici la fin de cette année. https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

D'accord, peut-être que certains fonds ciblés peuvent être ciblés sur une solution BLIS/FLAME pour les architectures x86 ?

Ne le pense pas. BLIS ressemble à un projet très malsain (et libflame encore plus); peu d'activité en termes de commits, de trafic sur les listes de diffusion, etc. De plus, ils ont eu un financement important (https://github.com/flame/blis#funding), donc ce n'est pas comme si quelques milliers de dollars allaient les faire comme par magie les projets mûrissent.

Je ne vois pas très bien d'où vient ou va cette discussion : nous avons une solution provisoire que Matthew a presque terminée (en utilisant ATLAS), et plus important encore, nous avons une solution à long terme sur laquelle on travaille très activement (MingwPy + OpenBLAS). De plus, OpenBLAS est beaucoup plus largement utilisé ; l'utilisation de ce projet à la fois dans la pile Scipy et dans Julia devrait le faire mûrir plus rapidement.

@rgommers : La conversation est allée là où elle est allée parce que @mikofski et moi essayions tous les deux d'utiliser la solution @matthew-brett pour construire scipy . Cependant, il semble que nous soyons tous les deux confrontés au même problème : le compilateur Fortran. J'ai moi-même essayé d'utiliser le gfortran.exe installé pour MinGW32 et MinGW64 sans grand succès en raison de tonnes d'externalités non résolues pour une raison ou une autre.

La version de @gfyoung Matthew utilise MSVC. Il ne sert à rien d'essayer d'utiliser gfortran avec MSVC, il est connu que cela ne fonctionne pas. Le résumé de la situation de construction est :

• Pas de Fortran, alors vous pouvez utiliser MSVC maintenant.
• Avec Fortran, vous pouvez utiliser l'un des MingwPy, MSVC + ifort ou icc + ifort.
• Pour la pile Scipy, nous voulons une solution gratuite qui construit des roues pour numpy, scipy, etc. Pour cela, c'est MingwPy.

@rgommers Je suis désolé d'avoir fait dérailler la conversation. Vous avez tout à fait raison, la solution @matthew-brett pour les travaux numpy, et le projet mingwpy de @carlk est déjà financé par num focus. Je vais essayer de voir si je peux faire en sorte que mon entreprise le soutienne. Je suis déjà membre de num focus. Environ à mi-chemin de scipy 2829 et je suppose que je suis arrivé à la même conclusion. J'espère juste que ça marche. À court terme, nous continuerons à utiliser @cgohlke ou passerons à anaconda. Merci encore!

À part pousser les builds vers pypi, peut-être qu'un dernier problème pour @matthew-brett est un bouclier de buildbot sur son référentiel de scripts de build np ? Merci! Alors cela peut être fermé?

Avant que cela ne soit fermé, petite question : j'ai construit @matthew-brett numpy pour qu'il pointe vers ATLAS. Cependant, lorsque j'essaie de construire scipy en utilisant ifort , il récupère également mon autre fichier site.cfg qui utilise MKL situé dans mon répertoire personnel. Je suis en fait capable de construire avec succès contre numpy , et les tests réussissent à l'exception de quelques erreurs dues à des erreurs d'arrondi minute. Cependant, je suis curieux, qu'est-ce que scipy a fait quand je l'ai construit ? A-t-il utilisé les bibliothèques MKL ou a-t-il tenté d'utiliser les bibliothèques ATLAS déjà construites avec numpy ?

Il y a un résumé des compilateurs Windows Fortran dans https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows

@gfyoung - en passant simplement par une combinaison de suppositions et de mémoire lointaine - je pense que scipy récupérera d'abord le site.cfg dans son propre répertoire, et s'il manque, récupérera la configuration de la version numpy. Cela indiquera à son tour où se trouvent les bibliothèques, lorsque j'ai construit les roues. Vous devrez donc réécrire le site.cfg pour scipy pour récupérer les bibliothèques de l'atlas np-wheel-builder - le script build_numpy.py le fait pour la construction numpy.

BLIS ressemble à un projet très malsain (et libflame encore plus); peu d'activité en termes de commits, de trafic sur les listes de diffusion, etc.

Je ne suis pas sûr que je les qualifierais de malsains, car ils n'essaient pas d'être des projets FOSS gérés par la communauté ; ils sont essentiellement un spectacle à une personne, et ils aiment ça (pour l'instant du moins). J'ai été en contact permanent avec eux au cours de la dernière ~année, et la bonne nouvelle est que l'accent actuel de leurs efforts est exactement sur les choses dont nous avons besoin (sélection du noyau d'exécution et configuration des threads d'exécution) ; la mauvaise nouvelle est qu'il n'y a pas grand-chose à faire à part attendre qu'un architecte réarrange les choses à sa guise. Peut-être que 6 mois verront des résultats?

Il semble que BLIS, etc. soit une option assez éloignée à ce stade, et que nous devrons prévoir le cas où cela ne fonctionnerait pas.

Nathaniel - avez-vous des suggestions pour trouver de bons repères ? Je ne pense plus que numpy.bench() fasse quoi que ce soit. J'ai essayé d'exécuter asv , mais de nombreux tests échouent car Windows numpy n'a pas complex256 .

Je suppose que les parties de asv qui fonctionnent sont utiles ? Ou même %timeit np.dot(big_array, other_big_array) serait utile pour avoir au moins une idée grossière où nous en sommes :-)

Aussi BTW, voici une solution générale au problème d'espace de noms global Windows DLL, nous permettant d'écrire un Windows delocate : https://github.com/njsmith/redll

Malheureusement, l'échec asv complex256 casse des séquences entières de tests à travers les types. Je suppose que ce ne serait pas trop difficile à réparer cependant.

Test simple avec ceci:

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)

suggère que, comme Clint Whaley l'a déjà prévenu - ATLAS 64 bits n'est pas bien optimisé sur Windows. Avec MKL 64 bits via les roues de Christoph Gohlke :

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

Avec mes roues, construit avec ATLAS 64 bits :

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

La différence est bien moindre avec les roues 32 bits (sur une autre machine 32 bits). MKL :

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

vs ATLAS :

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

@rcwhaley - Je vous envoie, au cas où vous auriez des idées ici. Il s'agit d'ATLAS 3.10.1...

Voici une autre machine Windows 64 bits avec un processeur plus moderne - montre également un ralentissement d'environ 3 fois.

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

Oui, problème 256 complexe pas difficile à résoudre : https://github.com/numpy/numpy/pull/7251

3x c'est beaucoup, mais pas aussi dramatique qu'avec lapack_lite n'est-ce pas ? Je pense que c'est OK pour une solution à court terme. Et ce n'est pas comme si les anciens programmes d'installation .exe 32 bits étaient meilleurs.

Aussi BTW, voici une solution générale au problème d'espace de noms global Windows DLL, nous permettant d'écrire un delocate Windows : https://github.com/njsmith/redll

belle déclaration de licence :)

@gfyoung 'site.cfg' est recherché dans :

1) Répertoire du fichier setup.py principal en cours d'exécution.
2) Répertoire personnel de l'utilisateur exécutant le fichier setup.py en tant que ~/.numpy-site.cfg
3) Répertoire à l'échelle du système (emplacement de ce fichier...)

@rgommers Je suis désolé d'avoir fait dérailler la conversation.

Pas de soucis, rien n'a déraillé.

Vous avez tout à fait raison, la solution @matthew-brett pour les travaux numpy, et le projet mingwpy de @carlk est déjà financé par num focus. Je vais essayer de voir si je peux faire en sorte que mon entreprise le soutienne. Je suis déjà membre de num focus. Environ à mi-chemin de scipy 2829 et je suppose que je suis arrivé à la même conclusion. J'espère juste que ça marche. À court terme, nous continuerons à utiliser @cgohlke ou passerons à anaconda. Merci encore!

Cool. Et c'est bien de voir que MingwPy vous intéresse. Notez qu'il a maintenant son propre ML, ce qui peut être intéressant : https://groups.google.com/forum/#!forum/mingwpy

@rgommers , @matthew-brett : Ah, oui, on dirait qu'il a été construit avec MKL auparavant. J'ai directement pointé mon site.cfg vers la version ATLAS et scipy mais des erreurs de segmentation pendant les tests. Si près !

@rgommers - oui - les performances sont bien pires sans ATLAS (avec lapack_lite):

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

Je suppose que la question qui reste ici est de savoir s'il vaut la peine de standardiser vers un numpy OpenBLAS (avec tous les tests numpy réussis), en acceptant le risque que cela soit plus susceptible de provoquer des erreurs numériques dans les projets utilisant numpy.

Un argument pour le faire serait qu'il semble que nous devrons aller dans cette direction à court/moyen terme, et il serait peut-être préférable de commencer maintenant et de nous engager dans les misérables chasses aux bogues que cela entraînera. Au moins, nous serons en bonne compagnie des mainteneurs de Julia.

Numpy a également un ensemble assez différent de compromis entre la tolérance au risque et les performances, et le ratio utilisateurs/développeurs, que Julia. Je pense donc qu'il pourrait être très logique pour numpy d'adopter une approche plus conservatrice et d'opter pour une option lente mais fiable par défaut, en s'efforçant d'autoriser openblas comme choix par défaut. Bien que ces temps de construction de 8 heures ne semblent pas amusants, il n'est pas étonnant que personne ne nous ait demandé d'utiliser Atlas avec Julia.

travailler à autoriser openblas en tant que choix d'option non par défaut

Le problème est que je ne sais pas vraiment comment ce processus pourrait fonctionner :-/. Nous n'avons aucun bon moyen de distribuer des versions alternatives aux utilisateurs (à long terme, j'espère que nous pourrons obtenir des variantes de construction sur pypi comme numpy[openblas] et ainsi de suite, mais cela n'arrivera pas de sitôt) , nous n'avons aucun moyen d'améliorer les builds openblas à part les distribuer et attendre les rapports de bogues, et la principale alternative aux builds ATLAS pour les personnes motivées à en rechercher un ne sera pas les builds openblas, ce sera MKL construit à partir d'un tiers :-/.

Je suppose qu'une autre option à mettre sur la table serait de distribuer les versions BLIS en utilisant leur noyau de référence/SSE2. Parce que BLIS n'a toujours qu'une configuration de temps de construction, cela ne sera pas compétitif avec openblas, mais il pourrait être compétitif avec ATLAS, et les avantages par rapport à ATLAS sont que le temps de construction est _beaucoup_ plus rapide, et la chance que ce soit une bonne solution à long terme sont difficiles à estimer mais certainement meilleurs qu'ATLAS étant une bonne solution à long terme (que je mettrais à zéro). Si nous devions de toute façon AQ quelque chose alors au moins nous dirigerions cette énergie vers quelque chose qui _pourrait_ avoir un avenir.

Quelques questions auxquelles il faudrait répondre avant d'envisager sérieusement cette option :

(1) Je ne sais pas si le support multithread de BLIS est compétitif avec celui d'ATLAS (je sais qu'il existe des options de multithreading dans la source, et je sais que le développeur principal ne considère pas qu'il soit "fait" pour le moment , c'est-à-dire en concurrence avec MKL, mais il y a beaucoup de place entre ATLAS et MKL.)

(2) d'ailleurs, je n'ai également aucune idée de la façon dont BLIS dans un mode non réglé se comporte sur ces références ci-dessus.

(3) Je n'ai pas vraiment essayé de construire BLIS sur Windows, et il y a le problème à résoudre, c'est juste un BLAS, pas un LAPACK -- je ne sais pas à quel point c'est un problème pour numpy.

Quelle est la réactivité de BLIS aux rapports de bogues ? Openblas semble être assez bon
à propos de ça.

Le lundi 15 février 2016 à 15h48, Nathaniel J. Smith <
[email protected]> a écrit :

travailler à autoriser openblas en tant que choix d'option non par défaut

Le problème est que je ne sais pas vraiment comment ce processus pourrait fonctionner :-/.
Nous n'avons aucun bon moyen de distribuer des versions alternatives aux utilisateurs (dans le
à long terme, j'espère que nous pourrons obtenir des variantes de construction sur pypi en tant que numpy[openblas]
et ainsi de suite, mais cela n'arrivera pas de sitôt), nous n'avons aucun moyen de
améliorer les builds openblas sauf en les distribuant et en attendant le bogue
rapports, et la principale alternative aux versions ATLAS pour les personnes qui sont
motivé pour en chercher un ne sera pas des builds openblas, ce seront des builds MKL
d'un tiers :-/.

Je suppose qu'une autre option à mettre sur la table serait de distribuer BLIS
construit en utilisant leur noyau de référence/SSE2. Parce que BLIS n'a encore que la construction
configuration de temps ce ne sera pas compétitif avec openblas, mais cela pourrait être
compétitif avec ATLAS, et les avantages par rapport à ATLAS sont que la construction
le temps est _beaucoup_ plus rapide, et la chance que ce soit un bon long terme
solution sont difficiles à estimer mais certainement mieux qu'ATLAS étant un bon
solution à long terme (que je mettrais à zéro). Si nous allons être QAing
quelque chose de toute façon alors au moins nous dirigerions cette énergie vers quelque chose
qui _pourrait_ avoir un avenir.

Quelques questions auxquelles il faudrait répondre avant d'envisager sérieusement cette
option:

(1) Je ne sais pas si le support multithread de BLIS est
compétitif avec celui d'ATLAS (je sais qu'il existe des options multi-threads dans
la source, et je sais que le développeur principal ne le considère pas comme
"fait" encore, c'est-à-dire compétitif avec MKL, mais il y a beaucoup de place entre
ATLAS et MKL.)

(2) d'ailleurs, je n'ai aucune idée de la façon dont BLIS en mode non réglé se comporte
sur ces repères ci-dessus.

(3) Je n'ai pas vraiment essayé de construire BLIS sur Windows, et il y a le
problème à gérer c'est juste un BLAS, pas un LAPACK -- je ne sais pas comment
c'est un gros problème pour numpy.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-184387401 .

Je crois que libflame est l'équivalent lapack dans blis. Il existe une interface de compatibilité lapack2flame décrite dans la documentation de référence .

Quelle est la réactivité de BLIS aux rapports de bogues ?

Nous ne savons pas encore.

Sans avoir essayé BLIS, je pense que cela ressemble à de la folie d'aller expédier des binaires numpy construits contre ce qui est fondamentalement un projet individuel à faible activité que très peu de gens utilisent.

Je n'ai pas encore vu de bonne raison dans ce fil de s'écarter du plan MingwPy + OpenBLAS. Les binaires No-scipy-ATLAS-MSVC sont un bon palliatif, mais moins important que la solution MingwPy à moyen/long terme et si le palliatif se transforme en un effort majeur en soi, alors je dirais que cela n'en vaut pas la peine .

Les documents BLIS / libflame suggèrent que, si j'essayais de créer une bibliothèque BLAS / LAPACK complète sur Windows, ce serait un chemin solitaire.

Je suis heureux de le faire une fois que les développeurs conviennent que cela devrait fonctionner et est pris en charge.

ATLAS est depuis longtemps la bibliothèque par défaut sur Linux. Il ne semble pas déraisonnable d'imaginer que cela puisse être le cas pour les versions compatibles avec Windows BSD pendant un certain temps.

@tkelman - merci pour votre analyse - je pense que vous avez raison, ce numpy doit se concentrer sur l'exactitude. Mais, il serait bon d'unir nos forces pour s'appuyer sur certains des bogues OpenBLAS les plus épuisants et développer des tests plus complets. Ce bogue OpenBLAS me vient à l'esprit - quelque peu obscur, très difficile à déboguer.

Je pense que pour ce problème particulier, celui de fournir des roues numpy sur pypi afin qu'un utilisateur occasionnel du paquet "x" qui dépend de "y" (par exemple: matplotlib) qui dépend de numpy s'installe à l'aide de pip, sans provoquer le lancement d'un utilisateur occasionnel leurs bras en l'air et dire quelque chose comme "Python est trop difficile." et retournez sur MATLAB. Le Zen de Python dit qu'il devrait y avoir un moyen évident de le faire. Cela dit, tout ce qui se trouve sur pypi par numpy en particulier a un certain poids qu'il _est_ stable, ou plus qu'un projet parallèle aléatoire, à l'exception possible de cgohlke. De toute évidence, l'enthought et l'anaconda sont perçus au moins dans l'industrie comme plus stables.

Je pense qu'à court terme, la construction d'ATLAS devrait augmenter avec le message d'avertissement qu'il n'est pas possible de construire avec scipy. Si ce buildbot peut être automatisé, alors c'est fait, n'est-ce pas ? Les futures versions d'ATLAS de 8 heures devraient être, espérons-le, rares. Peut-être qu'un jour, le problème de Windows 64 bits sera résolu. Le problème de l'exception SSE2 est une déception, donc un autre message d'avertissement sur pypi. De plus, ATLAS est déjà la norme sur Linux et était la norme dans les packages superpack bdist_winst précédents, ce qui donne encore plus de support à cette voie.

Alors, dans un avenir proche, vous avez déjà choisi mingwpy. Ici, il existe de nombreuses options qui n'ont pas à être résolues pour le moment.

À long terme, je suis ravi que le bonheur/la flamme soient l'avenir. C'est un peu effrayant que beaucoup de nos outils mathématiques dépendent du code FORTRAN des années 70. La seule solution AC est une percée majeure et quelque chose à soutenir avec enthousiasme.

Mais plus, c'est toujours mieux pour les développeurs expérimentés, donc garder la documentation vivante pour les options non standard est également bien si ces développeurs expérimentés ont le temps et l'envie de construire et de tester ensuite.

Si vous n'essayez pas d'utiliser l'un des noyaux optimisés dans blis, vous ne rencontrerez probablement pas le problème (modifier: singulier) que j'ai ouvert depuis 2014. Je pense que le système de construction n'utilise que des liens symboliques pour l'optimisé noyaux, donc vous ne confondrez pas le git de msys2 si vous essayez de construire uniquement la configuration de référence là-bas. La construction à partir de cygwin a fonctionné la dernière fois que j'ai essayé, même si c'était il y a quelque temps et je ne me souviens pas de ce que j'ai pu avoir besoin de modifier localement. Cela vaut la peine de construire, de tester et d'évaluer si l'alternative est Atlas, mais considérez-le comme non prouvé et donc à haut risque à sa manière jusqu'à ce que vous le fassiez.

@mikofski pour être honnête Lapack est des années 90, c'est vraiment l'éléphant Fortran dans la salle.

@tkelman : pour être clair, les problèmes que vous avez signalés concernaient spécifiquement le système de construction natif de Windows, n'est-ce pas ? Par curiosité, je viens d'essayer la compilation croisée de blis pour Windows à partir de Linux (en utilisant le compilateur croisé mingw-w64 installé à partir des packages debian), et j'ai été surpris de constater que cela ne prenait que 2 minutes environ. J'ai fait "./configure reference; make -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=" et tout a fonctionné. ( CPICFLAGS= est juste pour supprimer un tas d'avertissements sur "ignorer -fPIC , parce que c'est la valeur par défaut", et probablement je n'ai même pas eu besoin de remplacer AR , mais bon pourquoi pas.) J'ai reçu quelques avertissements sur printfs dans bli_pool.c et bli_fprintm.c qui utilisent %ld pour imprimer des entiers intptr , donc il y a probablement quelques problèmes LLP64 Faire du fitness.

@rgommers :

Sans avoir essayé BLIS, je pense que cela ressemble à de la folie d'aller expédier des binaires numpy construits contre ce qui est fondamentalement un projet individuel à faible activité que très peu de gens utilisent.

Vous avez absolument raison! Le problème est que toutes nos options sont terribles :-(.

Donc, évidemment, MKL a une licence définitivement mauvaise.

ATLAS a définitivement de mauvaises performances qui ne s'amélioreront jamais.

Et OpenBLAS, je pense que nous avons les preuves à ce stade, n'est tout simplement pas maintenable et ne le deviendra probablement pas si tôt :-(. Le projet a cinq ans, il a encore des choses fondamentalement cassées comme l'exemple de Julian de volatile aléatoire

Donc, la raison pour laquelle je continue à parler de BLIS n'est pas que je pense que BLIS est définitivement la solution, mais comme une sorte d'optimisme calculé : BLIS _pourrait_ devenir aussi rapide que MKL/OpenBLAS, aussi fiable qu'ATLAS/MKL, et aussi ouvert à la communauté- contributions en tant qu'OpenBLAS ; ou encore, il se peut que non. Mais il ne semble pas y avoir d'autres projets qui aient un réel espoir d'atteindre tous ces critères. [Et cela ne mentionne même pas les autres avantages, comme le fait qu'il peut prendre en charge nativement les tableaux stridés ; il n'est pas inimaginable que nous puissions supprimer tout notre terrible code d'expédition BLAS spécial.]

IIUC, GotoBLAS a été maintenu par un seul développeur à temps plein (Kazushige Goto) travaillant à UT Austin avec Robert van de Geijn comme PI. BLIS est maintenu par un seul développeur à temps plein (Field G. Van-Zee) travaillant à UT Austin avec Robert van de Geijn comme PI. Donc ce n'est pas comme si cela ne pouvait pas fonctionner :-) pelouse devant avec des tentes comme "hé, nous y sommes, nous emménageons et faisons en sorte que cela fonctionne pour nous, j'espère que cela ne vous dérange pas". Et ce que nous avons vraiment besoin de savoir pour déterminer sa viabilité à long terme, c'est, par exemple, « à quel point est-il vraiment fiable » et « dans quelle mesure les correctifs sont-ils » et des trucs, ce que nous ne pouvons pas savoir à moins que nous commencions à le tester et à le soumettre patchs et ainsi de suite.

En conclusion : je ne sais vraiment pas quelle est notre meilleure option, mais mettre nos orteils dans l'eau du BLIS semble être une bonne idée ; même si nous décidons que nous voulons attendre, nous apprendrons au moins quelque chose.

J'ai déposé plusieurs numéros et un ou deux PR. Le fait qu'il y ait des liens symboliques dans le référentiel signifie que la construction à partir de msys2 est interrompue (ou ne fonctionne que si vous définissez les options msys2 d'une manière spécifique). La construction croisée à partir de cygwin ou de linux (je ne ferais pas confiance à wine pour exécuter les tests) devrait fonctionner, mais il y a eu des problèmes en 2014 avec malloc aligné et les noyaux de pont de sable se sont séparés lors d'un test. Je viens de reconstruire les noyaux de pont de sable sur le dernier maître de blis avec une croix cygwin (sur un ordinateur portable skylake plus récent) et le segfault a peut-être disparu maintenant. Qui sait quand ou ce qui l'a réparé, devrait couper en deux.

Je pense que cela a déjà été mentionné, mais nous pourrions créer des binaires ATLAS pour SSE2, SSE3, AVX et les mettre dans une structure de répertoires comme :

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

Nous pourrions ensuite utiliser le numpy/_distributor_init.py pour vérifier le processeur actuel et précharger la bibliothèque correspondante.

J'ai suggéré de faire essentiellement la même chose, mais pour le bonheur au lieu de l'atlas, à @njsmith. Cela vaut également la peine de comparer le fonctionnement du threading dans blis par rapport à atlas. La configuration de référence blis n'active pas le threading par défaut, bien qu'il suffise de peaufiner une définition dans un fichier d'en-tête pour changer cela.

J'ai configuré Appveyor pour construire les binaires. L'itération actuelle de la construction tourne ici : https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Les roues construites arrivent ici : https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

Tout autre problème dans la version Appveyor devrait être facile à résoudre, donc je pense que ces roues sont prêtes à être téléchargées sur pypi lorsque cela sera fait, probablement demain.

@rgommers , @matthew-brett : Concernant site.cfg , il semble que votre réponse ne s'applique qu'à numpy . Il semble que scipy ne recherche pas site.cfg dans le même répertoire que setup.py commence seulement à rechercher site.cfg dans votre répertoire personnel avant de définir par défaut le numpy config.

OK - script de construction exécuté sans erreur, y compris les tests de la roue installée : https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Roues ici : http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

Je les ai installés et testés sur une autre machine 64 bits et une autre machine 32 bits.

Donc, je pense que ceux-ci sont prêts à partir. Une objection à ce que je les télécharge sur pypi?

Ce pourrait être une bonne idée d'avoir une note sur pypi expliquant/liant à une explication de la différence entre ces roues et celles de gohlke (mkl) pour éviter la confusion par les personnes se demandant pourquoi les roues apparaissent maintenant sur pypi et quelle est la différence entre eux sont.

Une question secondaire, désolé, mais je me demandais ce que

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

dans le script appveyor signifie?

Bonne suggestion sur l'explication - je vais essayer de trouver comment l'ajouter pour cette version existante.

Wheel > 0.26 ajoute une balise ABI supplémentaire à la roue Windows. Wheel==0.26 donne un nom de roue comme celui-ci :

numpy-1.10.4-cp27-none-win32.whl

Avec Wheel > 0.26, vous obtenez une balise ABI supplémentaire, comme celle-ci :

numpy-1.10.4-cp27-cp27m-win32.whl

(Je pense) - qui spécifie l'ABI Windows. C'est ennuyeux car le pip antérieur n'installera pas ces gars, il me semble donc que le nom sans ABI est meilleur pour le moment.

OK - Je propose d'ajouter ce texte à la page pypi actuelle :

Toutes les roues numpy distribuées par pypi sont sous licence BSD.

Les roues Windows sont liées à la bibliothèque ATLAS BLAS / LAPACK, limitée aux instructions SSE2, et peuvent donc ne pas donner des performances d'algèbre linéaire optimales pour votre machine. Voir http://docs.scipy.org/doc/numpy/user/install.html pour des alternatives.

Je dirais différemment :

Ces roues Windows ont des performances d'algèbre linéaire sous-optimales (lien vers un benchmark comme http://speed.python.org), car elles sont liées à la bibliothèque ATLAS BLAS / LAPACK, qui sont restreintes aux instructions SSE2 (et quelles instructions non restreintes devraient Soyez là?). Si vous avez besoin de performances, vous pouvez prendre en charge le projet mingwpy qui vise à apporter plus de performances aux extensions Python compilées sur cette plate-forme. Voir ??? pour plus de détails et http://docs.scipy.org/doc/numpy/user/install.html pour des alternatives.

Eh bien, les versions actuelles de mingwpy numpy / scipy utilisent openblas, mais je pense que cela n'a rien à voir avec mingwpy vs MSVC en tant que compilateur. Nous pourrions également expédier des openblas avec ces roues, mais je craignais que openblas ne soit pas encore assez fiable pour être utilisé dans une roue standard que nous prenons en charge.

OpenBlas semble assez stable, je sais qu'Anaconda l'utilise pour leur Linux
construit maintenant. Il n'y a pas de versions mises à jour de Windows Python 3.5 x64
là, les repères montrent qu'il est à peu près égal à MKL. Je l'essayerais certainement si
quelqu'un pourrait assembler une roue.
Le 16 février 2016 à 22h36, "Matthew Brett" [email protected] a écrit :

Eh bien - les versions actuelles de numpy / scipy de mingwpy utilisent openblas, mais je
pense que ce n'est pas lié à mingwpy vs MSVC en tant que compilateur. Nous pourrions également expédier
openblas avec ces roues, mais je craignais que openblas ne soit pas encore
suffisamment fiable pour être utilisé dans une roue standard que nous prenons en charge.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -185017546.

D'accord. Je suis juste confus quant à la source des performances sous-optimales - je n'utilise pas ces bibliothèques BLAS et je ne sais pas ce qu'elles font et quelle est la différence, donc expliquer ces options pour les mortels aide à devenir... euh, plus scientifique, vous savez . =) Je pensais que l'absence de compilateur ouvert avec des performances optimales était le problème.

@mrslezak : concernant OpenBLAS, je suis tout à fait d'accord. Le package OpenBLAS fourni sur Cygwin, couplé au package Lapack, semble capable de créer à la fois NumPy et SciPy sans problème.

@mrslezak : où puis-je trouver des informations sur les benchmarks ? J'essaie d'écrire de la documentation sur la création de sources à partir de Windows pour scipy.org , et ce serait une excellente référence pour quiconque a besoin de performances avec ces bibliothèques.

Peut-être que l'approche du fusil de chasse est la bonne idée? Quelque chose comme:

• Stable : ATLAS avec performances, mises en garde sse2
• Dev : OpenBLAS voir mingwpy et bistar
• Alt : MKL @cgohlke , MKL @continuum et @enthought
  Attention : les binaires ne sont pas compatibles.
  Liens pour plus d'informations sur scipy et le wiki github numpy de Matthew Brett

@techtonik Je m'attendrais à ce que GCC fonctionne un peu moins bien que MSVC ou ICC sur un code équivalent que tous ces compilateurs sont capables de créer. Le problème est l'absence d'un compilateur gratuit (compatible python.org-cpython) capable de créer une version compétitive de Lapack, qui est en Fortran (SciPy a également d'autres composants Fortran). La partie BLAS pure d'OpenBLAS (et probablement Atlas aussi) peut en fait être construite avec MSVC, mais MSVC ne peut construire aucune des pièces qui nécessitent un assemblage en ligne, donc il ne sera pas non plus compétitif.

Je n'ai pas de MKL 64 bits à portée de main (j'en ai peut-être un 32 bits de conda quelque part si je creuse), mais voici quelques repères exécutés dans Julia comparant la dll Atlas que @matthew-brett a construite contre référence et sand- configurations de pont de BLIS et la version OpenBLAS fournie avec Julia https://gist.github.com/54da587b01b7fb163103

Résumé : openblas (sur un skylake, le dernier noyau d'openblas est haswell) est 23 fois plus rapide qu'atlas, 44 fois plus rapide que le blis de référence et 5,5 fois plus rapide que le sandbridge blis. Je pourrais essayer haswell blis pour voir à quel point c'est plus proche.

Hum - Je suppose que vous n'avez pas de scripts de build qui traînent pour vos compilations BLIS ?

Pensez-vous qu'il vaudrait la peine de créer des versions de BLIS pour une gamme de processeurs et d'en sélectionner un au moment de l'exécution ? Existe-t-il un petit sous-ensemble de processeurs qui capturerait la plupart des performances de la plupart des processeurs ?

C'est dans les commentaires, mais ici (exécuté 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

Voici ce qu'ils ont à disposition : https://github.com/flame/blis/tree/master/config

En termes d'Intel x86, la référence, dunnington, sandybridge et haswell couvrirait une assez bonne gamme. Aussi bulldozer, piledriver et carrizo pour AMD (qui a récemment arrêté de développer ACML en faveur de BLIS, donc c'est au moins un vote pour).

Il y a du code de détection automatique dans https://github.com/flame/blis/tree/master/build/auto-detect qui pourrait être réutilisable (il ne fonctionne actuellement qu'au moment de la configuration dans BLIS, mais cela ne veut pas dire que cela ne peut pas être réutilisé à d'autres fins), selon qu'il existe déjà un morceau de code d'identification de famille de processeurs en Python que vous souhaitez utiliser.

selon qu'il y a déjà un morceau de code d'identification de famille de processeurs en Python qui traîne

est-ce que cela aide? http://stackoverflow.com/a/35154827/239247

Vous voulez surtout la famille de processeurs qui en est dérivée, mais https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c n'est pas vraiment long ou compliqué. La source numexpr qui est liée à partir de SO effectue une correspondance regex sur la sortie de chaîne (au moins sur Linux) et ne semble pas avoir de nombreuses architectures récentes répertoriées.

openblas est 3,4 fois plus rapide que Haswell blis et 17 fois plus rapide que dunnington (essentiellement le même que nehalem penryn je pense) blis. Ce qui est intéressant, c'est que je ne pense pas que le multithreading fonctionne en blis sur ces exécutions. La configuration par défaut active openmp pour sandybridge et haswell, peut-être que les pthreads mingw fonctionneraient mieux. Le réglage OMP_NUM_THREADS ne semblait pas faire beaucoup de différence.

Je pense qu'ATLAS 3.11 devrait faire beaucoup mieux sur 64 bits que la version 3.10, mais je ne peux pas le construire pour le moment, en espérant l'aide de Clint Whaley.

Tony - Je suppose que vous n'avez pas le temps/l'énergie pour tester la roue ATLAS 32 bits ? Il devrait faire beaucoup mieux, relativement.

Ma propre préférence est d'aller de l'avant avec ces roues ATLAS, afin que d'autres emballeurs puissent compter sur nous pour expédier une sorte de roue. Si nous trouvons un bon moyen d'améliorer les performances, nous aurons bientôt une nouvelle version de numpy, et même pour la 1.10.4, nous pouvons toujours faire une version de maintenance pour mettre à jour les roues.

@matthew-brett : petite question, pourquoi numpy ne serait-il pas capable de détecter les ATLAS builds sur Cygwin ? J'ai pu les détecter parfaitement dans un environnement Windows natif, mais lorsque j'ai essayé d'exécuter votre script dans Cygwin, numpy n'a pas été compilé avec ATLAS .

Si vous utilisez le python de Cygwin, vous aurez probablement besoin d'une version d'atlas construite par Cygwin pour que les choses soient compatibles.

Julia 32 bits semble ne pas réussir à déployer la dll de l'atlas 32 bits. Vous ne savez pas pourquoi, peut-être parce que nous avons déjà un openblas 32 bits et que les noms des symboles sont en conflit ?

Mais la version @matthew-brett est construite avec Cygwin, et c'est pourquoi je suis confus.

Environnement de construction Cygwin, compilé de manière croisée vers une bibliothèque mingw. Voyez comment il est lié à msvcrt.dll plutôt qu'à cygwin1.dll ?

Dès que j'ai posté le commentaire, c'est ce que j'ai soudainement suspecté d'être le cas. Hélas, il semble que je devrai le construire à partir de zéro. Merci @tkelman !

problème dlopen compris (réf https://github.com/matthew-brett/np-wheel-builder/pull/1, et https://github.com/JuliaLang/julia/issues/15117 cachait la version utile de le message d'erreur).

Sur 32 bits, atlas est 3,6 fois plus lent qu'openblas. Les openblas 32 bits sont 3 fois plus lents que les openblas 64 bits pour le même problème de taille. Les dernières familles de noyaux ne sont pas activées dans openblas sur les systèmes 32 bits.

...
En conclusion : je ne sais vraiment pas quelle est notre meilleure option, mais mettre nos orteils dans l'eau du BLIS semble être une bonne idée ; même si nous décidons que nous voulons attendre, nous apprendrons au moins quelque chose.

C'est probablement utile, au moins quelques tests/analyses comparatives. Mais à ce stade, cela n'a pratiquement aucun rapport avec nos problèmes _Windows_. BLIS est uniquement Linux pour le moment ; il y a un PR ouvert pour la prise en charge des builds OSX, et Windows est très loin. Et pire, je l'ai essayé hier sur Linux 32 bits et même cela ne fonctionne pas. ./configure auto && make plante horriblement sur du code assembleur (pour sandybridge ). Je ne peux construire que reference .

Donc, je pense que l'étape 0 consiste à ajouter le support de BLIS dans numpy.distutils (ça fonctionne déjà pour la plupart), étape 1 pour tester sur Linux pour voir qu'au moins reference fonctionne, étape 2 quelques analyses comparatives, ..., étapequelque chose sur Windows.

@matthew-brett votre texte proposé pour PyPI me semble bien. Quelles versions pip ignorent le nom avec la balise ABI ? Pip vous harcèle beaucoup pour se mettre à niveau ces jours-ci, donc je m'attendrais à ce que beaucoup de gens aient la dernière version. Et les versions > 1(.5) ans n'installaient même pas de roues du tout par défaut.

@rgommers mes tests ci-dessus étaient sur windows. Pas MSVC, mais mingwpy ou openblas ne feront pas beaucoup de différence là-bas - clang fonctionnerait probablement mais nécessite une réorganisation du référentiel dans blis pour éviter les liens symboliques.

Je n'ai pas exécuté les tests de Julia ou numpy contre blis, mais blis réussissait ses propres tests unitaires. Les choses se sont bien mieux passées que mon expérience de 2014 m'a amené à penser qu'elles le feraient. Encore faut-il trouver comment faire fonctionner le multithreading correctement, mais avec cela, vous pourriez avoir des performances déjà compétitives.

Il semble que la configuration de référence soit la seule chose dans blis qui fonctionne pour le x86 32 bits en ce moment. Cela nécessiterait d'écrire de nouveaux micronoyaux d'assemblage, je pense que ce n'est peut-être pas le cas, voir les commentaires de njsmith ci-dessous.

@tkelman , concernant les noyaux OpenBLAS pour 32 bits https://github.com/numpy/numpy/issues/5479#issuecomment -185096062 : selon un priv. message que j'ai reçu de Werner Saar il y a quelque temps, personne ne travaille sur les noyaux Intel 32 bits pour les architectures plus récentes. C'est donc un fait qui est peu susceptible d'être changé à l'avenir. L'accent est mis sur les processeurs Intel 64 bits et ARM.

@tkelman , concernant C-runtime https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: IMHO ce n'est pas critique car ATLAS et OpenBLAS ne partagent pas les ressources du C-runtime (descripteurs de fichiers et tas ). _J'espère avoir raison_. Il peut être utile pour les versions ATLAS d'augmenter la taille de la pile. Cela peut être donné comme indicateur lors de la liaison, c'est-à-dire :

-Wl,--stack,16777216

concernant les discussions ATLAS vs OpenBLAS : grâce à @matthew-brett, des DLL ATLAS basées sur SSE2 sont désormais disponibles. Cette version d'Atlas doit être comparée à la version OpenBLAS par rapport à une cible compatible SSE2 (ou définissez simplement OPENBLAS_CORETYPE=NORTHWOOD - essentiellement PENTIUM4) pour désactiver la détection d'exécution du processeur. Bien sûr, une version générique d'OpenBLAS peut exploiter beaucoup plus de variantes de processeur grâce à la détection du temps d'exécution du processeur. C'est l'une des raisons pour lesquelles OpenBLAS est plus performant par rapport à ATLAS. Une autre question est la fiabilité d'OpenBLAS. Peut-être qu'un référentiel avec des tests BLAS et LAPACK rassemblés pourrait aider.

concernant BLIS/Flame : intéressant, mais un fruit suspendu au moins pour aujourd'hui.

La prise de décision sur la façon de choisir entre ATLAS et OpenBLAS n'est cependant pas claire pour moi.

Ralf - pip 8 installera les roues avec les nouvelles balises Windows ABI, pas pip 7. Le pip 7 et le pip 8 installeront les roues sans les balises ABI, sans avertissement.

Il y a encore beaucoup de pip 7 là-bas, il est sorti en août 2015 - donc je préférerais de loin m'en tenir au nom le plus compatible, au moins pendant un petit moment.

+1 pour enquêter sur BLIS. Cela semble être une bonne solution à long terme. Avons-nous pensé à Eigen ? Ils prennent en charge la construction d'une interface LAPACK partielle et la licence est MPL2 pour la plupart du code. Cela peut être suffisant pour NumPy.

J'ai remarqué dans le code de détection du processeur BLIS qu'il revient très souvent à l'implémentation de référence s'il ne trouve pas les instructions AVX, qui sont encore assez récentes.

Ian : c'est l'état d'Eigen il y a environ un an : http://mingwpy.github.io/blas_lapack.html#eigen - donc je pense que ce serait du travail de construire une bibliothèque utilisable pour numpy.

Et pire, je l'ai essayé hier sur Linux 32 bits et même cela ne fonctionne pas. ./configure auto && make plante horriblement sur du code assembleur (pour Sandbridge). Je ne peux que construire une référence.

Si vous regardez le contenu de config/ -- les diverses "configurations" nommées (comme "sandybridge", "haswell") sont en fait des configurations "de démarrage" pré-packagées qui incluent un tas de paramètres pré-spécifiés (pas seulement Paramètres liés au réglage du processeur, mais aussi paramètres du mode de thread, paramètres du compilateur, etc.). Et la configuration appelée "sandybridge" est une configuration x86-64. Cela ressemble à un bug que la configuration automatique l'a sélectionné, mais oui, cela ne fonctionnera pas sur x86-32 :-). BLIS semble être livré avec des noyaux x86 32 bits (voir kernels/x86 ), bien qu'il semble qu'aucune des configurations pré-packagées ne les utilise pour le moment. Faire de nouvelles configurations est la plupart du temps trivial ; le seul morceau de magie se trouve dans le fichier bli_kernel.h qui nomme quel noyau interne + quelques tailles de tampon. Nous pourrions demander en amont s'ils ont des suggestions pour x86-32.

Aussi:

BLIS est uniquement Linux pour le moment ; il y a un PR ouvert pour le support de build OSX, et Windows est très loin

Quelques commentaires ci-dessus, @tkelman construit et compare BLIS sur Windows :-)

Le précédent benchmark test_dot brut avec OpenBLAS 0.2.12 :

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

Par rapport à (résultat précédent de) MKL

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

ATLAS 64 bits :

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

Ainsi, lorsque je compare openblas et MKL (merci, conda) en série à la configuration Haswell BLIS, ils sont tous à au plus 10-20% les uns des autres sur dgemm. Voici un fichier docker qui a été construit avec succès sur docker hub pour compiler de manière croisée les dll Windows de chaque configuration (sauf bulldozer qui n'a pas été lié correctement https://github.com/flame/blis/pull/37#issuecomment-185480513, eh bien) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

Vous voudrez peut-être essayer de connecter quelque chose de similaire à la configuration services: docker de Travis et jouer avec le déploiement d'artefacts binaires sur les versions github/bintray/whatever.

Je regardais la détection du processeur BLIS -> code du modèle : https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

Voici une réécriture de Python, qui devrait être un peu plus libérale dans l'acceptation de l'un des modèles avancés (il est plus probable que le système d'exploitation puisse utiliser AVX que le code C) : https://gist.github.com/matthew-brett /a53778f99b7062cc332d

Sur toutes les machines sur lesquelles j'ai testé, cet algorithme renvoie « référence » - probablement parce que j'ai de vieilles machines que personne d'autre ne voulait utiliser, pour sauver ma ferme de buildbot.

Compiler numpy contre la référence BLIS, sans lapack, donne ce qui suit sur mon benchmark brut :

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

Juste le produit scalaire de deux (1000, 1000) tableaux est de 12 secondes. Ainsi, comme Tony l'a également découvert, la référence BLIS est la pire de nos options, autour de la même version par défaut sans bibliothèque de numpy avec lapack_lite.

Donc, je pense que nous aurons besoin soit de plus de modèles couvrant les machines plus anciennes, soit d'une détection de CPU plus libérale -> mappage de modèles afin de donner des performances raisonnables sur une large gamme de machines.

@matthew-brett, quand pouvons-nous nous attendre à ce que les nouvelles roues Windows 64 bits d'ATLAS soient opérationnelles ? Quelle version ? v1.10.2 ? Seront-ils uniquement chez pypi ou également source forge ? Allez-vous faire une quelconque annonce ? Merci beaucoup !

@matthew-brett quel était le rapport entre l'atlas et le blis de référence pour vous sur la même machine ? Comparable au facteur d'environ 2 que je voyais ? J'ai fait fonctionner le multithreading dans blis, je n'ai tout simplement pas rtfm correctement (https://github.com/flame/blis/wiki/Multithreading), il n'est pas automatiquement activé et il y a 4 vars d'environnement différentes avec lesquelles jouer . Avec ce correctif https://gist.github.com/0fc9497a75411fcc0ec5 pour activer le blis parallèle basé sur pthreads pour toutes les configurations et le paramètre BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 , le blis Haswell est essentiellement lié à mkl et openblas sur ma machine. Si je mets juste BLIS_JR_NT sur 2, alors la référence parallèle blis est presque entièrement rattrapée par l'atlas, et c'est plus rapide avec 3 threads.

@tkelman IMO, il serait utile que vous documentiez vos progrès sur BLIS dans les pages Wiki NumPy GitHub. Je pense aussi qu'il pourrait être intéressant de proposer un plan similaire à mingwpy pour faire une roue NumPy-BLIS-FLAME (et une roue SciPy-BLIS-FLAME si possible ?).

@tkelman : pour m'assurer que je suis clair -- votre atlas est fileté, non ?
une autre chose à considérer est d'ajouter -msse2 ou similaire aux paramètres de construction reference -- il semble que par défaut, il soit au maximum compatible et ne permet pas au compilateur d'utiliser SSE, mais au moins dans numpy-land Je sais que nous passons à SSE2 comme configuration minimale prise en charge de toute façon pour d'autres raisons...

Je ne sais pas si FLAME est pertinent ou pas en ce moment par rapport à LAPACK ordinaire - nous voudrions demander.

Peut-être devrions-nous ouvrir un nouveau numéro pour les trucs BLIS au lieu de continuer à encombrer celui-ci :-)

Pour ce fil de discussion - je pense que nous pouvons déjà expédier une roue avec divers noyaux BLIS sélectionnés au moment de l'exécution en utilisant les mêmes règles que BLIS utilise au moment de la construction, mais je pense que cela entraînerait de nombreuses machines avec la référence BLIS, et donc pire performances qu'ATLAS 64 bits, même si ATLAS 64 bits sous Windows est particulièrement mauvais (pour ATLAS).

Mais - si la version de référence est plus rapide que l'ATLAS 64 bits - disons avec -msse2 - ce serait une vraie option.

SSE2 est la configuration minimale pour 64 bits, il est donc sûr d'utiliser quelque chose comme -mfpmath=sse -msse2 pour la compilation de référence.

Peut-être devrions-nous ouvrir un nouveau numéro pour les trucs BLIS au lieu de continuer à encombrer celui-ci :-)

Ce serait une bonne idée (modifier : puis-je suggérer qu'il s'intitule "Occuper BLIS", étant donné le sentiment de @njsmith sur les pelouses dans https://github.com/numpy/numpy/issues/5479#issuecomment-184472378 ?) . Je pense que @matthew-brett procède au téléchargement de ses roues Atlas existantes serait suffisant pour fermer celle-ci pour le moment, les travaux futurs étant laissés à de nouveaux problèmes.

pour m'assurer que je suis clair -- votre atlas est enfilé, n'est-ce pas ?

Mon atlas est la dll de https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds , mais je ne l'ai pas encore vu utiliser avec succès plus d'un thread. Il me manque une variable d'environnement ?

une autre chose à considérer est d'ajouter -msse2 ou similaire aux paramètres de construction reference - il semble que par défaut, il soit au maximum compatible et ne permet pas au compilateur d'utiliser SSE

SSE2 fait partie de la spécification x86_64, donc cela ne serait pertinent que sur 32 bits. Dans Julia, nous ajoutons -march=pentium4 pour nos versions 32 bits.

Je ne sais pas si FLAME est pertinent ou pas en ce moment par rapport à LAPACK ordinaire - nous voudrions demander.

Je n'ai pas encore touché à la flamme, mais ça vaut le coup de jouer avec. Finalement, vous pourrez peut-être utiliser WIndows Clang comme alternative de plan de sauvegarde à mingwpy. (edit: en fait, cela ne résout pas le fortran dans scipy, alors peut-être pas)

@matthew-brett : Je pense (peut-être faux) que le noyau dunnington ne nécessite que SSE3, qui, selon la Steam Hardware Survey, est présent sur 99,94% des machines (contre 99,99% pour SSE2). Donc, cela semble faux si vous trouvez qu'une majorité de systèmes ne peuvent pas gérer cela - je ne sais pas s'il s'agit d'un bogue dans leur code cpuid, dans le fait que vous avez en quelque sorte un ensemble de machines de test vraiment non représentatif, ou à ma compréhension de ce dont ce noyau a besoin.

J'ai posté une réécriture Python du code de détection du processeur dans l'essentiel ci-dessus. Je suppose que la sélection du modèle est conservatrice, faisant référence par défaut à l'endroit où un autre modèle aurait pu fonctionner.

Pour me rappeler, pour créer un lien vers BLIS, j'avais besoin d'un site.cfg comme :

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

J'ai aussi fait cela, je suppose que c'est nécessaire (patch relatif à 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):

Utilitaire pour permettre la détection d'exécution du processeur : https://github.com/matthew-brett/x86cpu

Je suppose que cela pourrait être un candidat pour l'inclusion dans numpy lui-même, mais nous pouvons également copier le module cpuinfo compilé dans l'arborescence numpy pour la roue Windows.

Salut tout le monde. Une réflexion : si vous vouliez publier plusieurs roues numpy différentes construites avec diverses bibliothèques vectorielles, vous pouvez utiliser différents noms de packages 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

J'en ai enregistré 2 pour essayer de télécharger les roues de Gohlke, mais PyPI les a rejetées. Vous êtes le bienvenu sur l'URL.

gh-7294 ajoute la prise en charge de BLIS à numpy.distutils . Ce serait génial si quelqu'un pouvait vérifier que cela fonctionne comme prévu.

Il y a encore beaucoup de pip 7 là-bas, il est sorti en août 2015 - donc je préférerais de loin m'en tenir au nom le plus compatible, au moins pendant un petit moment.

Pip 7.0 n'est pas encore si vieux, donc c'est logique.

... BLIS semble être livré avec des noyaux x86 32 bits (voir kernels/x86), bien qu'il semble qu'aucune des configurations pré-packagées ne les utilise pour le moment

Cela explique, merci.

Merci Ralf - je vais tester.

Je me rends compte que cela peut nécessiter un nouveau fil, mais nous sommes maintenant très près de pouvoir utiliser les versions BLIS pour une version.

Je pense que tout ce dont nous avons besoin maintenant, ce sont des modèles recommandés pour une machine dotée de SSE2 et une machine dotée de SSE3, qui fonctionnent un peu plus rapidement que la version Windows d'ATLAS 64 bits.

Je me rends compte que cela peut nécessiter un nouveau fil, mais nous sommes maintenant très près de pouvoir utiliser les versions BLIS pour une version.

Eh, techniquement, il est peut-être possible de le faire fonctionner, mais ce n'est toujours pas un bon plan de jeter des constructions par-dessus le mur comme ça. Nous n'avons même pas encore testé sérieusement BLIS sur Linux ou OS X. Donc sous Windows, où la FAQ BLIS dit :

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.

, c'est définitivement trop tôt. En plus des tests, une analyse comparative est également une bonne idée, je pense.

Bien sûr, mais comme Tony l'a montré, il n'est en fait pas difficile de créer BLIS pour Windows, en utilisant la compilation croisée. La chose expérimentale - je crois - est leur système de construction MSVC, que nous n'utilisons pas.

Pour l'instant, je suggère seulement d'utiliser BLIS pour la roue Windows, mais bien sûr, ce serait très bien de le faire fonctionner également pour les versions de manylinux.

Je suis tout à fait d'accord pour dire que si nous n'obtenons pas une amélioration significative des performances en moyenne, nous ne devrions pas utiliser BLIS, et, pour le moment, je ne pense pas que nous le soyons, sauf pour les tout nouveaux processeurs. Cela pourrait être trivialement réparable avec quelques nouveaux modèles, j'aimerais savoir si c'était le cas.

Pour la justesse, je suis également d'accord. Et si nous montrons que

a) Tous les tests numpy réussissent sur toutes les versions de Windows ;
b) Tous les tests numpy et scipy passent sur le système manylinux ?

Nous pouvons rendre le modèle BLIS sélectionnable au moment de l'exécution et tester tous les noyaux sur une machine moderne. Je peux également tester sur de vieilles machines désagréables.

Pour l'instant, je suggère seulement d'utiliser BLIS pour la roue Windows, mais bien sûr, ce serait très bien de le faire fonctionner également pour les versions de manylinux.

Je pense que manylinux est moins important, car nous avons là-bas des gestionnaires de paquets avec une pile complète ainsi que des utilisateurs qui peuvent beaucoup plus facilement compiler des choses. Voyons d'abord l'ensemble du concept manylinux décoller avant de nous en préoccuper dans ce contexte numpy + BLAS/LAPACK :)

Pour Windows, je pense que nos priorités sont :

1) une solution full-stack (nécessite MingwPy, avec l'un des OpenBLAS/ATLAS/BLIS)
2) roues binaires provisoires (nous en avons une sur le point de monter avec votre version ATLAS)
3) augmenter les performances de (1). C'est là que BLIS pourrait intervenir.

Donc à mon humble avis, il n'est pas nécessaire d'être pressé avec BLIS sur Windows.

Je suis tout à fait d'accord pour dire que si nous n'obtenons pas une amélioration significative des performances en moyenne, nous ne devrions pas utiliser BLIS, et, pour le moment, je ne pense pas que nous le soyons, sauf pour les tout nouveaux processeurs. Cela pourrait être trivialement réparable avec quelques nouveaux modèles, j'aimerais savoir si c'était le cas.

D'accord, il devrait y avoir un gain important pour que cela ait du sens. Il est un peu difficile de voir combien de travail est nécessaire en effet.

Pour la justesse, je suis également d'accord. Et si nous montrons que

a) Tous les tests numpy réussissent sur toutes les versions de Windows ;
b) Tous les tests numpy et scipy passent sur le système manylinux ?

Ça sonne bien. Il serait logique d'inclure scikit-learn également, c'est un utilisateur de linalg assez important.

Je ne savais pas que blis et libflame faisaient partie de la base de code ACML, qui a été open source il y a quelque temps :

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/

Néanmoins : comment résoudre le problème pour comparer 4 implémentations BLAS/Lapack accélérées différentes pour numpy/scipy build avec MSVC ou mingwpy à tester sur de nombreuses architectures CPU : Pentium4 jusqu'à skylake ?

Belle trouvaille @carlk , j'ai vu qu'ils avaient annoncé l'abandon d'acml et d'acl open source, mais je ne me suis pas souvenu qu'ils avaient adopté blis/libflame. La licence bsd est une très bonne nouvelle ! Existe-t-il un moyen de travailler avec AMD et shpc à Austin pour cibler numpy et Julia ?

J'ai pu compiler le libblis.a en utilisant msys2 et la configuration haswell prête à l'emploi et en réussissant tous les tests en corrigeant les liens symboliques du noyau, mais je n'ai pas pu construire libflame - j'ai eu la même erreur "liste d'arguments trop longue" que dans mon message sur la liste de diffusion blis-discuss. De plus, personnellement, je n'arrivais pas à comprendre comment créer un lien vers libblis.a à partir de lapack, mais je n'ai pas essayé très fort.

Avec la licence communautaire de MKL, n'est-il pas possible de fournir une roue MKL sur pypi, les licences sont-elles vraiment incompatibles ? Ou n'est-il tout simplement pas possible de construire scipy sans effort ?

Un problème, et il appartient probablement à scipy, qui n'a pas été mentionné est les fichiers Fortran restants dans scipy. Désolé pour la question noob mais pourquoi doit-on les utiliser ? Pour moi, il semble que Fortran, et l'absence d'un compilateur multiplateforme gratuit, soit le vrai problème ici. N'est-ce pas après tout ce que mingwpy vise à résoudre. Avec un MKL gratuit ou un futur blis/flame magique d'acl, n'importe qui avec un compilateur c pourrait en construire la pile scipy n'était pas pour les fichiers *.f.

@mikofski , bon à entendre, que blis peut être compilé avec msys2. Est-ce aussi vrai pour libflame ? Je suppose que nous avons besoin de libflame pour l'API Lapack.
Personnellement, il est possible d'avoir un numpy compilé MSVC et de l'utiliser avec un scipy compilé mingwpy. Vous devez ajouter -mlong-double-64 aux indicateurs gcc pour vous assurer que long double == double.

Il est délicat de faire de ce comportement le comportement par défaut sur gcc, je joue sur ce problème depuis une semaine :(

Je suis venu demain avec des roues scipy. Ceux-ci seront basés sur Atlas fourni par les roues numpy de @matthew-brett.

Néanmoins, je suis favorable à l'utilisation d'OpenBLAS dès maintenant.

Un problème, et il appartient probablement à scipy, qui n'a pas été mentionné concerne les fichiers Fortran restants dans scipy. Désolé pour la question noob mais pourquoi devons-nous les utiliser ?

Parce que c'est beaucoup de code très utile et très performant. Et ce n'est pas seulement BLAS/LAPACK - beaucoup de scipy.sparse.linalg , scipy.linalg , scipy.special et scipy.interpolate par exemple est Fortran. De plus, Scipy n'est pas le seul projet avec du code Fortran, il existe d'autres packages comme bvp_solver ainsi que le propre code Fortran des utilisateurs qu'ils ont enveloppé avec f2py.

En effet, belle trouvaille Carl.

Néanmoins : comment résoudre le problème pour comparer 4 implémentations BLAS/Lapack accélérées différentes pour numpy/scipy build avec MSVC ou mingwpy à tester sur de nombreuses architectures CPU : Pentium4 jusqu'à skylake ?

Cela nécessite en effet un cadre de build/test/benchmark automatisé décent. Nous n'avons pas à nous soucier des architectures CPU très anciennes (tant que les choses fonctionnent là-bas, ça va) et pas non plus avec MSVC, je pense. Mais il faudra quand même du travail pour le configurer correctement.

@rgommers merci !

Salut tout le monde. Une réflexion : si vous vouliez publier plusieurs roues numpy différentes construites avec diverses bibliothèques vectorielles, vous pouvez utiliser différents noms de packages PyPI

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

J'en ai enregistré 2 pour essayer de télécharger les roues de Gohlke, mais PyPI les a rejetées. Vous êtes le bienvenu sur l'URL.

@hickford s'il vous plaît ne faites pas ça. C'est casser la licence MKL de redistribuer des binaires comme ça (à moins que vous n'ayez une licence personnelle), et ce n'est pas la bonne façon de le faire. À l'avenir, nous voudrons peut-être distribuer certaines saveurs via des extras ( numpy[atlas] , numpy[openblas] etc.).

De plus, redistribuer les roues de quelqu'un d'autre sur PyPi sans demander n'est probablement pas la chose à faire...

Mingwpy et tous les problèmes fortran qui reposent sur la liaison au même runtime c que cpython sont limités en débit sur @carlkl , l'expérimentation avec BLIS résout moins de problèmes mais peut être effectuée indépendamment par n'importe qui. J'ai malheureusement épuisé mon temps personnel pour regarder BLIS en ce moment, mais voir #7294.

Tony - merci beaucoup pour toute votre aide, cela a été inestimable.

J'ai ajouté une version ultérieure d'ATLAS (3.11.38) sur 64 bits

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

Il s'agit d'une version en série (non threadée), en raison de problèmes de compilation de 3.11.38 sous Windows, mais elle devrait être un peu plus rapide que 3.10.1, et correspond à mon simple benchmark :

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

par rapport à la version 3.10.1 précédente (voir ci-dessus) :

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

@tkelman - pouvez-vous comparer cette version sur Julia ?

Désolé d'intervenir ici avec une note préalable sur les binaires MKL - Intel propose le
version communautaire qui devrait permettre la redistribution car elle est gratuite pour tous...
Le 2 mars 2016 à 15 h 08, "Matthew Brett" [email protected] a écrit :

J'ai ajouté une version ultérieure d'ATLAS (3.11.38) sur 64 bits

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

Il s'agit d'une version en série (non threadée), en raison de problèmes de compilation de 3.11.38
sur Windows, mais il devrait être un peu plus rapide que 3.10.1, et est sur mon simple
référence:

Dans [2] : %timeit test_dot()
1 boucle, meilleur de 3 : 1,65 s par boucle

par rapport à la version 3.10.1 précédente (voir ci-dessus) :

Dans [10] : %timeit test_dot()
1 boucle, meilleur de 3 : 2,41 s par boucle

@tkelman https://github.com/tkelman - pouvez-vous comparer cette version sur
Julia?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment-191431331 .

@mrslezak - la licence autorise la redistribution, mais rend le redistributeur responsable des frais juridiques si Intel est poursuivi en justice en raison de l'utilisation du logiciel. De plus, le binaire résultant ne peut pas être sous licence BSD. Voir : http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

Cela pourrait-il être évité en ajoutant « fourni en l'état, sans aucune responsabilité pour tout
les pertes monétaires pouvant résulter de son utilisation » ou quelque chose qui l'affecte ?
Le 2 mars 2016 à 18h22, "Matthew Brett" [email protected] a écrit :

@mrslezak https://github.com/mrslezak - la licence permet
redistribution, mais rend le redistributeur responsable des frais juridiques si
Intel est poursuivi en justice en raison de l'utilisation du logiciel. Aussi, le résultat
binaire ne peut pas être sous licence BSD. Voir:
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -191505500.

Je ne pense pas que cela fonctionnerait, car nous devons accepter la licence d'Intel, et la licence d'Intel dit que nous sommes responsables de leurs frais juridiques s'ils sont poursuivis. Je suppose que nous pourrions exiger que les utilisateurs ne poursuivent pas Intel dans notre accord de licence, et donc peut-être que s'ils poursuivent Intel et qu'Intel nous demande l'argent, nous pouvons essayer de poursuivre l'utilisateur pour ces frais, mais quand même - mettre cela sur notre licence nous éloignerait encore plus de BSD, et nous obligerait à obtenir l'accord explicite de l'utilisateur, ce qui n'est pas pratique dans le cas des roues installées par pip.

La construction d'ATLAS pour SSE3 ne donne qu'un avantage de 5 % en termes de performances par rapport à l'ATLAS SSE2, mais la construction était délicate et j'ai dû désactiver les indicateurs d'activation les plus évidents pour SSE3 et utiliser simplement -msse3 .

J'ai écrit un mail à la mailing list numpy proposant de déployer ces roues : https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@matthew-brett En tant que personne qui prend en charge Windows avec les applications Python, merci.

@matthew-brett, j'ai ajouté 2 problèmes à votre référentiel atlas-build-scripts.
Voir https://github.com/matthew-brett/atlas-build-scripts/issues

Le premier https://github.com/matthew-brett/atlas-build-scripts/issues/1 est important, car numpy-atlas.dll exporte vers beaucoup de symboles et empêche ainsi une utilisation ultérieure avec mingwpy sans piratage de l'importation bibliothèque.

@matthew-brett désolé, j'ai été un peu occupé à faire d'autres analyses comparatives. L'une des versions précédentes de l'atlas était-elle multithread ? Je n'ai pas pu faire fonctionner la première version sur plusieurs cœurs. L'essentiel devrait être assez simple à exécuter même si vous n'êtes pas très familier avec Julia. Ou étiez-vous principalement intéressé par du matériel plus récent que celui auquel vous avez accès ?

Ne vous inquiétez pas, je ne m'attendais pas à ce que vous abandonniez tout et exécutiez des tests de performance.

En fait, ma dernière version d'atlas n'était pas multithread - ATLAS 3.11 a besoin de plus de travail pour que le thread fonctionne apparemment sous Windows.

Pour les benchmarks, je pensais qu'il serait plus facile de comparer avec les autres benchmarks que vous avez exécutés, et je n'ai que de l'ancien matériel avec Windows activé - je suppose que le succès est beaucoup plus important sur votre machine que sur la mienne.

Les roues Windows sont maintenant sur pypi : https://pypi.python.org/pypi/numpy/1.10.4

Désolé Tony - oui, les versions précédentes d'ATLAS 3.10 étaient (ou semblaient être) multithread.

Je suppose que nous pouvons clore ce problème maintenant. Peut-être que @matthew-brett vous devriez transférer votre https://github.com/matthew-brett/np-wheel-builder sous l'organisation numpy ou peut-être le contribuer en tant que PR au référentiel numpy sous le dossier tools .

Ralf - des suggestions sur l'endroit où np-wheel-builder devrait aller ? numpy/fournisseur peut-être ?

Je préférerais un nouveau dépôt séparé ( numpy-wheel-builder ?) sous l'organisation numpy je pense. Il y a un chevauchement avec numpy-vendor dans le but, mais pas beaucoup dans le code. Ce dépôt est assez volumineux, est vraiment destiné à être exécuté sous Wine, et la chaîne d'outils gcc qu'il contient est obsolète.

D'accord avec moi - d'accord avec vous pour aller de l'avant et créer ça ?

Très bien avec moi, mais si c'est spécifique à Windows (en ce moment c'est AFAICT ?), alors le nom du dépôt devrait contenir "windows" :-). Ou bien ce pourrait être là où nous mettons l'infrastructure analogue pour d'autres roues aussi. Je serais également d'accord pour le mettre directement dans le numpy quelque part s'il est suffisamment petit pour que cela ait un sens. Tout ce qui fonctionne :-)

Repo contient des binaires ATLAS assez volumineux, ce qui rendrait le repo numpy volumineux, voire inutile, je pense.

Que diriez-vous win-wheel-builder ?

Que diriez-vous windows-wheel-builder . Je ne suis pas fan de win ;)

Qu'en est-il de ne pas le rendre spécifique à Windows et d'avoir la configuration de la construction de la roue macosx et future manylinux1 au même endroit ?

Sinon +1 pour "windows" sur "win".

Qu'en est-il de ne pas le rendre spécifique à Windows et d'avoir la configuration de la construction de la roue macosx et future manylinux1 au même endroit ?

Ce serait plus facile de changer les choses sur toutes les plateformes. Mais je m'attendrais à ce que OS X et Linux n'aient besoin que de scripts de construction, tandis que pour Windows, nous avons les énormes binaires ATLAS. Si tout se passe dans un seul dépôt, les binaires ATLAS peuvent-ils être séparés d'une manière ou d'une autre (peut-être avec git-lfs) ?

Utiliser le stockage de fichiers volumineux (LFS) sur github pour les binaires

@rgommers : Je pense que nous allons bientôt proposer des binaires atlas-or-some-other-blas pour Linux, et peut-être aussi osx (par exemple, si nous décidons que nous en avons assez d'accélérer le multitraitement).

pourrait commencer à utiliser les versions de github ou bintray ou quelque chose au lieu de les enregistrer ... pas comme s'ils étaient si gros jusqu'à ce que vous commenciez à entrer dans les builds openblas activés par DYNAMIC_ARCH ou les combinaisons équivalentes de plusieurs configurations blis

Que diriez-vous de mettre le référentiel en tant que windows-wheel-builder pour le moment, et de le refactoriser/renommer quand il sera plus clair ce que nous allons faire avec Linux/OSX ?

Cela me semble bien.

bien avec moi aussi

Je pense que j'ai besoin des droits d'administrateur sur l'organisation numpy - ou je peux donner
quelqu'un a les droits d'administrateur sur le dépôt, et ils peuvent le faire, je suppose.​

@matthew-brett: Je suis très confus par la page des autorisations de github (et numpy en particulier est un gâchis), mais si vous voulez faire de moi un administrateur du référentiel ou me transférer le référentiel, je peux le déplacer dans numpy/

J'ai transféré le repo à @njsmith ...

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

Existe-t-il un compte numpy appveyor ? Quelqu'un peut-il activer les versions Appveyor pour ce référentiel ?

Je pense que nous utilisons le compte Appveyor de @charris...

Oui, voir ici https://ci.appveyor.com/project/charris/numpy/history

Le mer. 16 mars 2016 à 00h15, Nathaniel J. Smith <
[email protected]> a écrit :

Je pense que nous utilisons @charris https://github.com/charris's Appveyor
Compte...

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

En fait, je viens de créer un nouveau compte de groupe pour numpy chez appveyor (je voulais le faire de toute façon, et cela m'a incité à le faire :-)), et je l'ai activé ici :
https://ci.appveyor.com/project/numpy/windows-wheel-builder

@njsmith Comment avez-vous géré cela ? La dernière fois, j'ai regardé quelqu'un qui devait demander aux administrateurs de créer des comptes de projet et la façon d'en ajouter d'autres n'était pas complètement transparente.

Si le compte fonctionne, j'aimerais transférer la responsabilité du test numpy.

@charris : vérifiez votre messagerie :-). Je viens de créer un compte individuel avec numpy-steering-council @googlegroups.com en tant qu'individu. Je ne savais pas que les comptes de projet étaient une chose qui existait... En voulons-nous un ?

pour le bien de la file d'attente, vous souhaitez probablement répartir différents projets sur différents comptes

L'inconvénient de l'utilisation du courrier numpy-steering-council est qu'appveyor envoie des notifications lorsqu'un test de fusion échoue. Si les utilisateurs d'appveyor ont quelque chose de mieux ces jours-ci, ce serait bien de l'utiliser, mais étant donné le désordre que leur interface a été dans le passé, je ne parierais pas là-dessus.

@tkelman Bon point. De plus, si nous allons dépenser de l'argent pour obtenir une file d'attente plus rapide, nous voulons probablement quelque chose de plus officiel.

@charris : j'ai juste essayé d'activer le test de numpy/numpy dans le nouveau compte appveyor, et aussi de désactiver toutes les notifications, et aussi d'ajouter toutes les équipes numpy github pertinentes en tant qu'administrateurs sur le compte -- voyons ce qui se passe je devine...

@matthew-brett: Il me vient à l'esprit que l'approche la plus élégante pourrait être de ranger les versions BLAS quelque part comme numpy/windows-build-tools , mais d'exécuter les outils de construction de roues réels à partir du vrai référentiel numpy/numpy comme partie de la construction d'appveyor - ils pourraient retirer les binaires BLAS à la demande.

Merci pour tout l'excellent travail! Les roues de fenêtre numpy 1.11.0 seront-elles bientôt ajoutées à pypi ? https://pypi.python.org/pypi/numpy

oh oui, nous devons peut-être trouver comment mettre à jour nos procédures de publication ici ... IIUC l'expérience utilisateur en ce moment est que dès que la version source 1.11 a été téléchargée, toutes les machines Windows sont soudainement passées des roues de téléchargement (yay ) pour essayer de télécharger et de compiler la source (boo). Je suppose que la "bonne" façon de procéder est qu'une fois la version finale étiquetée, nous construisons et téléchargeons toutes les roues binaires _avant_ de télécharger le sdist. Aussi ennuyeux que cela soit...

@njsmith ce serait bien, mais un décalage de quelques minutes (ou même quelques heures) me conviendrait.

Juste pour clarifier, les fichiers whl Windows actuels sur PyPI pour la version 1.11.0 sont-ils compilés par rapport à ATLAS ? Existe-t-il un script de build qui peut être partagé ?

Oui, les roues sont construites contre ATLAS, mais nous pensons passer à OpenBLAS lorsque nous serons confiants dans les résultats.

La construction est automatisée via Appveyor : https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day . =)

Il est peut-être possible de créer une version hidden - au moins, il existe une option sur le formulaire PyPI https://pypi.python.org/pypi?%3Aaction=submit_form et de l'afficher lorsque tous les fichiers sont prêts.

Malheureusement, la fonctionnalité de version cachée empêche les gens d'obtenir cette version via la ligne de commande, elle ne les empêche que de voir la version via l'interface graphique pypi :

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

J'ai essayé l'installation Windows 64 bits de numpy et cela fonctionne très bien, donc merci à tous ceux qui ont travaillé là-dessus.

Ce que je me demande, c'est s'il existe toujours un plan pour faire la même chose avec les roues scipy ? Est-ce en attendant la décision de passer à OpenBLAS ?

Sur https://bitbucket.org/carlkl/mingw-w64-for-python/downloads , il y a quelques roues de test de scipy-0.17.0 . Ces roues ont été construites avec mingwpy contre les versions de @matthew-brett de numpy https://pypi.python.org/pypi/numpy/1.10.4

Le jeu. 28 avril 2016 à 12 h 48, carlkl [email protected] a écrit :

Sur https://bitbucket.org/carlkl/mingw-w64-for-python/downloads , il y a
quelques roues de test de scipy-0.17.0 . Ces roues ont été construites avec
mingwpy contre @matthew-brett https://github.com/matthew-brett 's
versions de numpy https://pypi.python.org/pypi/numpy/1.10.4

Désolé si vous l'avez déjà dit, et je l'ai raté - mais avez-vous un test
pannes pour ces roues?

Êtes-vous lié à l'ATLAS expédié à l'intérieur des roues numpy ?

@matthew-brett, j'ai annoncé ces versions il y a un mois, mais je ne me souviens plus où. Quoi qu'il en soit, ces builds sont liés à l'atlas numpy fourni par vos roues numpy.

scipy-0.17.0-cp35-cp35m-win##.whl sont liés au _wrong_ C-runtime msvcrt.dll. Pour scipy, cela semble être OK. Les journaux de test sont ici : https://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

C'est le bon journal ? Il a NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy à la fin.

Je me demandais si nous étions sur le point de pouvoir fournir une roue scipy, même si elle est dangereusement liée au mauvais runtime MSVC, mais il semble qu'il y ait beaucoup trop d'erreurs pour cette version.

Obtenez-vous moins d'erreurs pour la version 64 bits ? Pour la meilleure version actuelle contre openblas 0.2.18 ?

64bit n'a que 6 échecs tous avec :

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

Je sais : cela crie à la comparaison avec OpenBLAS. Cependant, je suis bloqué depuis les 4 dernières semaines pour plusieurs raisons comme vous l'avez peut-être remarqué. Espérons que la situation continuera de s'améliorer.

@matthew-brett, j'apprécierais d'utiliser les versions numpy MSVC avec OpenBLAS. Mes dernières versions sont ici :

• 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

Comme si mingwpy, conda-forge, Anaconda et Canopy ne suffisaient pas, voici la distribution Intel pour Python et elle est téléchargeable gratuitement . Il comprend uniquement les outils numériques (SciPy, NumPy, Numba, Scikit-Learn) ainsi que quelques extras (interface mpi4py Intel mp et analyse de données pyDAAL) et utilise conda.

Pas de soucis, la licence expire le 29/10/16 donc ces builds Intel ne sont qu'un
test bêta suivi probablement d'une redevance MKL+ etc. OpenBLAS construit
restera la solution open source donc merci de fournir ces
construit.
Le 28 avril 2016 à 19h21, "Mark Mikofski" [email protected] a écrit :

Comme si mingwpy, conda-forge, Anaconda et Canopy ne suffisaient pas, voici venir
la distribution Intel pour Python
https://software.intel.com/en-us/python-distribution et c'est gratuit pour
Télécharger
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation.
Il comprend uniquement les outils numériques (SciPy, NumPy, Numba, Scikit-Learn)
plus quelques extras (interface mpi4py Intel mp et analyse de données pyDAAL) et
utilise conda.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

Pour 1.11.1, il semble qu'il y ait une roue Windows manquante sur PyPi pour Python 3.5 amd64.

Y a-t-il une raison particulière à cela ? Si je vais en 1.11.0 (https://pypi.python.org/pypi/numpy/1.11.0), la roue est là.

Merci pour le rapport - je pense que nous avons dû télécharger trop tôt, et donc avant que toutes les roues ne soient construites. J'ai téléchargé la roue manquante. Il semble que nous ayons besoin d'un test pour nous assurer que cela ne se reproduira plus.

J'ai téléchargé la roue manquante.

Je viens de le tester et il fonctionne très bien !

Merci beaucoup pour tout le travail accompli pour rendre les roues Windows disponibles.

Clôture du problème - les roues sont disponibles depuis les dernières versions.

Je comprends que ce problème est clos, mais je pense que nous devrions envisager de le rouvrir.

Cela reste un problème pour les utilisateurs de Windows essayant de faire fonctionner leur pile scientifique sans avoir à recourir à conda. J'ai toujours besoin d'utiliser les versions @cgohlke 'MKL' voir ce problème scipy connexe qui reste ouvert. Bien que des roues soient en cours de création, sans être compatibles avec scipy, elles ne sont pas utilisables pour beaucoup.

@waynenilsen , vous avez les instructions pour installer les nouvelles roues dans le fil de la liste de diffusion qui est lié au problème que vous venez de mentionner :

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

Donc si tu fais

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

Il devrait fonctionner pour vous.

Il n'y a plus rien à faire pour Numpy, donc le problème est clos. le
Le problème de Scipy est toujours ouvert, et il sera probablement résolu dans le prochain
Libération.

Cela fonctionne très bien pour moi @Juanlu001 J'ai vraiment hâte que ce soit sur pypi !