Numpy: Pacote de roda do Windows (.whl) no Pypi

Bem dito - e, de fato, há muito trabalho de @carlkl nos bastidores para que isso aconteça. Acredito que estamos quase lá agora - @carlkl - quando você vai a público, você acha?

Por contexto: a razão pela qual isso não é trivial é que os binários que você vinculou
depender da biblioteca de tempo de execução e matemática proprietária da Intel, que
complica redistribuindo-os.

Eu implantei as recentes rodas numpy e scipy baseadas em OpenBLAS no binstar. Você pode instalá-los com:

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

Isso funciona para python-2.7 e para python-3.4. As rodas estão marcadas como 'experimentais'. O feedback é bem-vindo.

Se você deseja testes generalizados, envie isso para a lista :-)

Em quinta-feira, 22 de janeiro de 2015 às 20h54, carlkl [email protected] escreveu:

Eu implantei as recentes rodas numpy e scipy baseadas em OpenBLAS no binstar.
Você pode instalá-los com:

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

Isso funciona para python-2.7 e para python-3.4. As rodas são marcadas como
'experimental'. O feedback é bem-vindo.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -71096693.

Nathaniel J. Smith
Pesquisador de pós-doutorado - Informática - Universidade de Edimburgo
http://vorpus.org

fwiw Eu pessoalmente gostaria de alterar o tamanho do inteiro padrão no win64 antes de realmente fornecermos binários oficiais, embora houvesse alguma resistência também quando eu o propus pela última vez, também possivelmente com anaconda e outros binários de terceiros provavelmente já é tarde demais: (

também falando de openblas, alguém gosta de depurar, estou cansado disso (parece a mesma falha que quebra o scipy com o 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)

A versão do OpenBLAS usada é 0.2.12. Eu não tive problemas significativos com esta versão ainda.

As falhas do scipy são copiadas para https://gist.github.com/carlkl/b05dc6055fd42eba8cc7.

32 bits apenas falhas numpy devido a http://sourceforge.net/p/mingw-w64/bugs/367

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

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

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

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

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

Eu não discordo sobre mudar o tamanho inteiro do win64, mas acho que é
uma questão separada que deve ser dissociada das rodas. Se este fosse o
primeira vez que as compilações numpy win64 estavam se tornando amplamente disponíveis, então
faz sentido vinculá-los, mas neste momento já existem muitos usuários
por anos, eles estão apenas usando cgholke ou anaconda ou qualquer outra coisa. Então vamos
tratar isso como uma discussão independente?

(Estritamente falando, é uma pausa de retrocompatibilidade, mas mesmo assim parece razoável
que podemos ser capazes de retirá-lo, uma vez que na verdade reduz
incompatibilidade entre plataformas -- todo código portátil tem que lidar com 64 bits
dtype=int já.)

Na quinta-feira, 22 de janeiro de 2015 às 20h59, Julian Taylor [email protected]
escreveu:

fwiw, pessoalmente, gostaria de alterar o tamanho do inteiro padrão em
win64 antes de realmente fornecermos binários oficiais, embora houvesse alguns
resistência também quando eu a propus pela última vez, também possivelmente com anaconda e
outros binários de terceiros provavelmente já é tarde demais :(

também falando de openblas, alguém gosta de depuração, estou cansado disso
(parece a mesma falha que quebra scipy com openblas):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Leitura inválida de tamanho 16
==31931== em 0x7B28EB9: ddot_k_NEHALEM (em /usr/lib/libopenblasp-r0.2.10.so)
==31931== por 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931== por 0x6E93DEC: cblas_matrixproduct (cblasfuncs.c:528)
==31931== por 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931== por 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -71097408.

Nathaniel J. Smith
Pesquisador de pós-doutorado - Informática - Universidade de Edimburgo
http://vorpus.org

Também estou interessado nisso. Existe alguma forma de auxiliar no processo?

OpenBLAS pode ser compilado com INTERFACE64=1 e numpy pode ser compilado com -fdefault-integer-8 para uma primeira tentativa.

Apenas um alerta. Usar inteiros de 64 bits em blas é uma péssima ideia. Pare antes de ir muito longe nessa estrada. Matlab e Julia antes de eu ir e consertá-lo, fizeram isso e quebra qualquer biblioteca de terceiros que assume inteiros convencionais de 32 bits em blas.

O que temos feito em Julia nos últimos 5 meses é, na verdade, renomear todos os símbolos em openblas para adicionar um sufixo _64 a eles para a versão de 64 bits, dessa forma você pode fazer álgebra linear em matrizes realmente grandes, se você quiser, mas carregar bibliotecas externas no mesmo processo não será falha por sombreamento de nomes e tentar chamar dgemm com a ABI errada.

Ei pessoal, existe alguma atualização sobre os arquivos das rodas sendo disponibilizados para o Numpy?

Não que eu saiba agora.
Em 25 de junho de 2015 04:27, "guyverthree" [email protected] escreveu:

Olá pessoal existe alguma atualização sobre os arquivos das rodas sendo disponibilizados para
Numpy?

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -115215236.

@guyverthree Christoph Gohlke está lançando o NumPy usando o MKL da Intel como rodas há algum tempo.

Além disso, veja minha postagem no blog sobre rodas NumPy . Eu fiz algumas rodas NumPy no meu Dropbox usando a cadeia de ferramentas mingw-w64 modificada de Carl Kleffner e a porta OpenBLAS de Zhang Xianyi de GotoBLAS . Olivier Grisel estava procurando ajuda para modificar o buildbot NumPy para repetir as mesmas etapas usadas no tópico de grupos do Google OpenBLAS que eu postei no .

Minha versão mais recente está disponível em binstar.org, embora eu não tenha certeza se anaconda.org é o novo nome preferido agora.
As rodas para py-2.6 .. 3.4 (32/64bit) têm cerca de 2 meses:

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

construa com meu https://bitbucket.org/carlkl/mingw-w64-for-python e um OpenBLAS mais ou menos recente.
pip instalar:

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

+1 @carlkl e eu gostaria que eles também pudessem ser adicionados à compilação NumPy na Cheese Factory .

+1 Eu adoraria ver isso acontecer também.

IMHO: há pelo menos três problemas a serem resolvidos antes que essas compilações sejam aceitas:

• os patches mingwpy para o repositório numpy devem ser recriados
• não há nenhum mecanismo de compilação além da construção manual ainda
• muitos pacotes de janelas de terceiros (despolitizados por C. Gohlke) dependem explicitamente de numpy-MKL, porque os binários são vinculados a DLLs MKL. Isso pode mudar no futuro, pois o scipy agora fornece um mecanismo para uma dependência implícita na implementação do scipy BLAS/Lapack. Portanto, instalar (numpy-MKL & scipy-MKL) OU (numpy-OpenBLAS & scipy-OpenBLAS) deve ser suficiente para todos os outros pacotes no futuro.

@carlkl : FWIW, não estou realmente preocupado com os pacotes do @cgohlke - isso se resolverá (assim como não há grandes problemas agora devido a pessoas tentando combinar scipy-MKL com anaconda numpy). E eu nem estou realmente preocupado com a existência de algum mecanismo de compilação sofisticado - uma compilação manual está bem desde que haja um arquivo de texto documentando as etapas.

A principal questão que me preocupa é a sustentabilidade: se não conseguirmos obter essas coisas upstream, teremos que revalidar e refazer os patches toda vez que uma nova versão do gcc / mingw-w64 / msvc chegar fora, e provavelmente não vai acontecer. Não queremos ser pegos na armadilha em que começamos a fornecer compilações, mas isso se torna cada vez mais oneroso com o tempo, pois temos que lidar com um compilador antigo e mal-humorado para fazer isso.

É por isso que estou tentando arrecadar fundos para apoiar esse upstream ... +1's são ótimos e tudo, mas se alguém quiser doar algum dinheiro ou conhecer uma empresa que possa estar interessada em tornar o gcc geralmente utilizável para python extensões no Windows, envie-me um e-mail :-) ([email protected])

Se você não tem $$, mas ainda quer ajudar, então uma maneira de fazer isso seria enviar patches para o mingw-w64 melhorando seu suporte para funções transcendentais como sin e cos. (Acontece que a MSVC ABI discorda de todos os outros sobre como a unidade x87 FPU deve ser configurada, então a maioria das funções matemáticas de software livre não funciona muito bem.) Felizmente, existem implementações boas e compatíveis com licenças no Android " bionic" libc , portanto, isso não requer nenhuma magia matemática ou uma visão profunda dos problemas de ABI - é apenas uma questão mecânica de encontrar e extrair os arquivos de origem relevantes e, em seguida, soltá-los na árvore mingw-w64 no lugar certo. Podemos fornecer mais detalhes sobre isso também se alguém estiver interessado.

Não é esse o tipo de coisa que a numfocus deveria financiar? Se não, então talvez possamos voltar e revisitar a candidatura ao PSF.

De quanto dinheiro estamos falando?

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

Se você tentar pip install numpy em uma instalação do Windows Python pronta para uso, receberá a mensagem de erro infame e inútil "Não foi possível encontrar vcvarsall.bat".

+1 realmente ajudaria os usuários do Windows.

Não é possível jogar com https://github.com/glumpy/glumpy por causa disso. Quais são as etapas de compilação manual para que o Numpy funcione no Windows? Parece que o trabalho do AppVeyor está lá , então não deve ser problema fazer upload de artefatos para o GitHub .

No momento, é literalmente impossível construir uma versão rápida e licenciada pelo BSD do numpy no Windows. Estamos trabalhando para corrigir isso, mas é uma limitação técnica; Os +1s não terão nenhum efeito de qualquer maneira. (O trabalho do appveyor é construído no Windows, mas usa uma biblioteca de álgebra linear não otimizada de fallback que não é realmente adequada para o trabalho real.) Até resolvermos isso, recomendo baixar as rodas do site de Christoph Gohlke ou usar o Anaconda ou outra distribuição python científica .

@njsmith você pode ser mais específico? De preferência com comandos exatos que não funcionam. No momento, esse material não é acionável.

Acho que 'impossível' é muito forte - mas certamente ainda não há um caminho geral óbvio a seguir. Eu coloquei uma página wiki sobre o status atual aqui: https://github.com/numpy/numpy/wiki/Whats-with-Windows-builds . Por favor, sinta-se à vontade para editar/alterar todos vocês que se importam.

@techtonik : não existem "comandos exatos que não funcionam", o problema é que não existem compiladores que tenham a combinação de recursos que precisamos. mingwpy.github.io documenta o status atual de nossos esforços para criar tal compilador.

@matthew-brett legal. We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler. É para scipy, certo? Por que é necessário para numpy?

@njsmith http://mingwpy.github.io/issues.html é uma iniciativa incrível com uma boa análise. Pena que o upstream (Python) nunca o suportará (promove o uso do MSVS cegamente). Mas estou tentando obter uma imagem clara do status atual.

1. é um problema de "ter uma cadeia de ferramentas aberta para trabalho aberto" ou o MSVS realmente não pode compilar a parte C do numpy?
2. ainda existem falhas com extensões compiladas pelo mingw?

Para restringir o foco por enquanto, digamos que seja apenas Python 2.7 + Win32. Nenhum desempenho é necessário (só quero executar o aplicativo para testá-lo lá), mas são necessários dados de referência sobre esse desempenho.

Então, qual é a próxima ação que deve ser feita para que essa configuração disponibilize a roda do Windows a partir do PyPI?

@techtonik , agora existem versões preliminares das rodas numpy e scipy disponíveis em https://anaconda.org/carlkl/numpy e https://anaconda.org/carlkl/scipy. O desempenho é quase tão bom quanto as rodas +MKL do gohlke. Não encontrei falhas de segmentação com minha caixa do Windows em casa.

Vários problemas com essa abordagem foram discutidos e serão resumidos em http://mingwpy.github.io (em construção). A combinação da cadeia de ferramentas baseada em mingw-w64 chamada _mingwpy_ e OpenBLAS é o caminho a seguir para a plataforma Windows.

_mingwpy_ tem uma configuração especial que garante uma melhor compatibilidade e um uso mais conveniente em comparação com as cadeias de ferramentas baseadas em mingw-w64 mais conhecidas, ou seja, _mingw-builds_, _tdm_ ...

Tudo isso e muito mais é explicado em https://github.com/mingwpy/mingwpy.github.io. Sinta-se à vontade para abrir questões ou PRs lá.

@techtonik : Acho que é um sério mal-entendido/deturpação da posição do python.org upstream. Eu diria que eles se recusam a promover o cisma do suporte do Windows CPython em várias ABIs incompatíveis (e eu concordo com eles nisso). Steve Dower, que mantém as compilações oficiais do Windows upstream, tem nos ajudado a descobrir como tornar o mingwpy compatível com essas compilações.

O pré-requisito da IMO para colocar rodas numpy no pypi é que elas sejam (a) de alto desempenho, (b) de manutenção, (c) devidamente licenciadas. Se você deseja que o projeto aplique um conjunto diferente de critérios (ou seja, que devemos nos esforçar para fornecer rodas com desempenho terrível), o próximo passo é enviar um e-mail para a lista de discussão numpy argumentando que seus critérios são melhores.

O MSVS pode construir o próprio numpy, mas não pode construir nenhuma das implementações BLAS de alta qualidade devidamente licenciadas. O upstream mingw-w64 pode compilar numpy + BLAS (com patches), mas o resultado falhará se você tentar usá-lo com o CPython upstream. A cadeia de ferramentas mingwpy de Carl pode construir numpy + BLAS (com patches), e o resultado funcionará em algumas versões do python (mas não 3.5), mas a cadeia de ferramentas é frágil e insustentável em seu estado atual; literalmente ninguém, exceto Carl, sabe como foi construído ou poderia recriá-lo. Ninguém no projeto numpy está pronto para se comprometer a fornecer "compilações oficiais" usando uma cadeia de ferramentas com essas limitações, então estamos nos concentrando em corrigi-las.

Existem várias fontes trivialmente disponíveis de compilações numpy de alta qualidade no Windows. Estou genuinamente curioso: por que você insiste tanto que devemos lançar algumas compilações de baixa qualidade apenas para que elas estejam no PyPI?

@njsmith Só queria dizer que meu caso de uso (que admito de forma alguma justificaria um investimento de recursos do desenvolvedor por conta própria) é distribuir um pacote muito simples no PyPI que depende de matplotlib , que por sua vez depende de numpy .

Para o meu caso de uso, o desempenho não é uma preocupação, mas poder ter um usuário do Windows simplesmente pip install ____ meu pacote que instala recursivamente matplotlib , numpy , etc é muito mais fácil de explicar do que apontá-los para URLs para instalar também, especialmente para usuários que não entendem o ecossistema de compilação do Python. Portanto, é principalmente para uma simplificação das instruções de instalação.

Novamente, não estou tentando usar meu caso como justificativa, mas só queria compartilhar como você ficou curioso.

@johnthagen : Ah, claro, não se preocupe! Eu entendo totalmente por que isso é desejável em geral; se eu parecer mal-humorado nesses comentários, é exatamente porque eu e outros passamos muito tempo no ano passado tentando consertar isso :-). Eu estava perguntando especificamente ao @techtonik porque parecia que eles estavam dizendo "Eu só quero experimentar um pequeno aplicativo, então não me importo com o desempenho", mas se eles querem apenas experimentar um pequeno aplicativo, eu não saiba por que eles se preocupam com a parte PyPI :-)

(É importante ter em mente que qualquer roda que colocarmos no pypi começará imediatamente a ser usada por dezenas de milhares de pessoas, a maioria das quais não está lendo este tópico. que colocamos será de fato amplamente utilizável para uma ampla variedade de casos de uso.)

Eu acho que seria essencialmente trivial começar a enviar rodas numpy de 32 bits para Python 2.7, usando ATLAS. Eles provavelmente teriam que ser SSE2, então travar sem instruções SSE, mas isso afetaria apenas uma proporção muito pequena de usuários. Poderíamos usar nossa cadeia de ferramentas de lançamento atual para isso. Tenha em mente que isso significaria que o pip daria uma roda binária para 32 bits, mas voltaria para a instalação de origem para 64 bits. Isso seria útil?

@njsmith Obrigado pela informação! Aprecie todo o seu trabalho duro :)

Eu acho que seria essencialmente trivial começar a enviar rodas numpy de 32 bits para Python 2.7, usando ATLAS. Eles provavelmente teriam que ser SSE2, então travar sem instruções SSE, mas isso afetaria apenas uma proporção muito pequena de usuários. Poderíamos usar nossa cadeia de ferramentas de lançamento atual para isso. Tenha em mente que isso significaria que o pip daria uma roda binária para 32 bits, mas voltaria para a instalação de origem para 64 bits. Isso seria útil?

@matthew-brett a configuração atual do fornecedor numpy está quebrada, há uma falha de segmentação em fromfile . O manuseio do manipulador de arquivos está de alguma forma confuso, e não temos certeza se isso é devido a uma alteração na versão do Wine, na versão do Ubuntu ou (improvável) em uma alteração no próprio numpy. Eu diria que gastar mais tempo com isso é uma perda de tempo - colocar esse tempo no mingwpy é muito mais produtivo.

Eu tenho o NumPy 1.10.4 compilado com OpenBLAS (Int32 Windows 64, binário pré-compilado v0.2.15) e MKL (usando uma licença comunitária em MKL, ou seja, distribuição gratuita). Mas... não consigo compilar o SciPy - parece que uma pequena parte procura o compilador gfortran "fortan compiler not found" se alguém tiver uma idéia de como corrigir esse problema. Estou usando o ifort.exe, pois o Ananconda oferece suporte a essas compilações como plug-ins diretos. Compilado para Python 3.5 com Microsoft Visual Studio Community 2015, se alguém puder me ajudar a descobrir como empacotar isso para distribuição .... então farei o upload para o github ou o site do anaconda. Aprecie isso.

@mrslezak : provavelmente a melhor coisa a fazer é postar na lista de discussão dos desenvolvedores do scipy ou abrir um novo bug no scipy, em vez de postar em bugs existentes aleatórios :-)

Estou genuinamente curioso: por que você insiste tanto que devemos lançar algumas compilações de baixa qualidade apenas para que elas estejam no PyPI?

Só porque estou cansado de raspar iaques. Eu sei que as pessoas querem desempenho, e é bom que alguém tenha recursos para isso, mas para mim pessoalmente a complexidade de realizar essa tarefa é enorme, então só posso esperar que você consiga fazer isso, mas para mim isso pode nunca acontecer, ou pode acontecer em dois ou três anos, durante os quais as pessoas continuam batendo nas paredes e perdendo tempo em horas proporcionais aos downloads de todos os binários do Windows do PyPI que exigem a instalação do NumPy como uma dependência direta ou indireta.

Ufa. Provavelmente a frase em inglês mais longa que escrevi em toda a minha vida. =)

@techtonik - Compartilho sua frustração, acho que muitos de nós se sentem frustrados com isso.

@carlkl - Eu adoraria seu feedback aqui.

Há claramente uma forte pressão para colocarmos uma roda de janelas entorpecida. Aqui está uma lista das rodas mais baixadas para qualquer plataforma de algumas semanas atrás: https://gist.github.com/dstufft/1dda9a9f87ee7121e0ee . matplotlib, scikit-learn e rodas de janelas pandas vêm nas posições 3, 4 e 5. Haveria um grande mercado para rodas de janelas numpy.

Acho que as perguntas na mesa são:

1) Podemos nos comprometer a obter uma roda numpy funcional e quase ideal no pypi no curto a médio prazo (digamos, 6 meses). Eu diria que a resposta para isso é sim (feliz em ouvir desacordo);
2) Vale a pena colocar uma roda numpy não ideal enquanto isso para outros construirem?

A questão 2 é a mais difícil. "Não ideal" pode significar lento (sem blas / lapack otimizado) ou difícil de suportar (sem garantia de que poderíamos repetir a compilação em 6 meses).

Eu posso ver argumentos contra "lento". Precisamos ter cuidado para que, quando as rodas começarem a funcionar para o Windows, elas não acionem imediatamente perguntas de estouro de pilha com respostas "De forma alguma, baixe as rodas numpy do pypi". Acho que essas respostas seriam razoáveis ​​e durariam o suficiente para nos machucar.

Significado não ideal, difícil de suportar o processo de construção, acho que podemos conviver, se estivermos realmente comprometidos em encontrar uma solução de longo prazo em breve.

Um tempo atrás eu construí binários ATLAS para Windows: http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

Estou certo em pensar que já podemos construir binários numpy que passam em todos os testes usando esses binários ATLAS?

Nesse caso, por que não os colocamos?

1) Podemos nos comprometer a obter uma roda numpy funcional e quase ideal no pypi no curto a médio prazo (digamos, 6 meses). Eu diria que a resposta para isso é sim (feliz em ouvir desacordo);

Espero que sim, caso contrário, isso significa que, até lá, teremos problemas inesperados com a proposta mingwpy ou não armazenamos o que ela permite :)

2) Vale a pena colocar uma roda numpy não ideal enquanto isso para outros construirem?

Suas compilações do ATLAS parecem ser feitas com o Cygwin? Ou isso é apenas nomeação de diretório e você usou alguma versão do MingwPy?

Eu acho que minhas compilações ATLAS foram feitas com Cygwin, mas elas não estão vinculadas ao Cygwin.dll, então eu acho que elas seriam seguras para compilar com MSVC.

mingwpy não está com problemas, mas precisa de seu tempo. Construir a cadeia de ferramentas gcc, OpenBLAS e depois numpy/scipy com diferentes variantes leva tempo de compilação e teste. E não publicarei binários sem publicar primeiro todos os scripts de compilação. Um mingwpy baseado no gcc-5.3.0 está quase pronto, assim como o OpenBLAS. O próximo passo é construir rodas numpy e scipy com base nisso.

Esta discussão, bem como as contribuições mais recentes para o tópico numpy "Rodas Linux de distribuição múltipla - por favor, teste" levam à pergunta se o OpenBLAS tem a qualidade que permite a implantação de rodas numpy do Windows baseadas no OpenBLAS. Mas não tenho certeza de que usar o atlas seja a melhor solução. Talvez as rodas numpy devam ser construídas com ambas as variantes para uma fase de teste primeiro.

Estou supondo/esperando que de alguma forma chegaremos ao estágio de que o OpenBLAS é de qualidade aceitável. Mas, até esse momento, parece-me razoável começar com rodas numpy ATLAS, esperando que no devido tempo possamos mudar para rodas OpenBLAS. Talvez tenhamos que colocar a verificação SSE2 para as compilações de 32 bits: http://mingwpy.github.io/blas_lapack.html#atlas

Colocar uma caixa de progresso no topo da página PyPI pode trazer mais pessoas para o problema (incluindo aqueles que podem doar para apoiar a iniciativa). A caixa pode listar a estratégia atual, critérios de aceitação (link para teste de desempenho?), status e a ação que será feita quando a versão final estiver pronta (aumentar a versão principal?).

@matthew-brett ainda não está claro para mim se sua proposta de jogar algo é viável. Qual compilador você usaria? Se MingwPy, temos um plano claro de em que ordem fazer e agora parece muito cedo. Se for outro gcc, voltamos ao problema de vinculação estática e distribuindo a dor da DLL.

Minha ideia era compilar numpy com ATLAS usando MSVC. É claro que isso não funcionaria para o scipy, mas pelo menos as pessoas poderiam começar a enviar suas rodas para janelas, independentemente da construção.

Acabei de tentar isso e recebi alguns erros do formulário unresolved external symbol __gfortran_compare_string então suponho que os binários do ATLAS tenham algumas referências pendentes ao tempo de execução do gfortran. @carlkl - alguma sugestão de como depurar?

Misturar arquivos de objetos estáticos vindos de compiladores diferentes é algo que você deve evitar como o diabo evita água benta. Em alguns casos funciona, mas para um conjunto diferente de combinações de compiladores falhará.
BTW: o próprio MS não oferece suporte oficial ou recomenda misturar objetos estáticos de diferentes versões de seu Visual Studio.

Fiz alguns testes há algumas semanas, quando esta pergunta aparece: a biblioteca estática npymath.a criada pelo mingwpy pode ser usada com compiladores MSVC? Em princípio , pode funcionar se alguns objetos selecionados das bibliotecas de tempo de execução gcc forem adicionados a esta biblioteca. Cheguei à conclusão de que tal abordagem é instável e frágil.

Se o atlas for uma opção para construir rodas numpy, eu tentaria construí-lo como DLL, alguma objeção?

Misturar arquivos de objetos estáticos vindos de compiladores diferentes é algo que você deve evitar como o diabo evita água benta.

Eu sinto que https://mingwpy.github.io/motivation.html (Página Por que) falta uma explicação muito simples e direta do problema para módulos carregados dinâmicos . Falei com os caras do Far Manager, cujo gerenciador de arquivos é nativo do Windows, construído em plugins, que são carregados de .dlls escritos em diferentes idiomas, e eles não têm esse problema com "exatamente o mesmo compilador". Eu me pergunto por que o Python tem isso - ele também carrega módulos de .dlls ..

@techtonik , meu comentário foi sobre vincular arquivos de objetos produzidos por diferentes compiladores em um único arquivo binário (DLL ou EXE). Isso é o que eu quis dizer com _misturando arquivos de objetos estáticos_. Tal abordagem _pode_ funcionar em algumas situações bem testadas se manuseada com cuidado. Mas está longe de ser uma maneira robusta de construir binários.

A interoperabilidade de DLLs de compiladores diferentes em um espaço de processo comum é uma coisa completamente diferente. Normalmente, essa abordagem funciona bem como regra geral. É preciso garantir que esses binários estejam vinculados à mesma DLL de tempo de execução do MS se eles compartilharem descritores de arquivo. Existem outros possíveis problemas de ABI que precisam ser tratados. E é claro que você precisa de um conjunto diferente de depuradores para depuração, dependendo dos compiladores que estão sendo usados.

minwgpy é um projeto para suportar a construção de extensões python com a ajuda de mingw-w64 para uso dentro das compilações padrão do MSVC CPython.

OK - consegui construir numpy com MSVC vinculando a uma compilação do ATLAS.

ATLAS construa aqui:

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

Existem algumas instruções básicas sobre como construir a dll ATLAS.

Todos os testes numpy passam além da verificação de script f2py , acho que é uma falha benigna.

A última etapa é enviar a biblioteca dinâmica dentro da roda. @carlkl - qual é a sua maneira favorita de fazer isso atualmente?

Bom saber, eu também gostaria de descobrir como criar uma roda com
binários incluídos - pode postar uma compilação MKL e fazer com que outros testem o OpenBlas
1.
Em 11 de fevereiro de 2016, 13h28, "Matthew Brett" [email protected] escreveu:

OK - consegui construir numpy com MSVC vinculando a uma compilação do ATLAS.

ATLAS construa aqui:

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

Existem algumas instruções básicas sobre como construir o ATLAS
dll.

Todos os testes numpy passam além da verificação do script f2py, acho que é um
falha benigna.

A última etapa é enviar a biblioteca dinâmica dentro da roda. @carlkl
https://github.com/carlkl - qual é a sua maneira favorita de fazer atualmente
naquela?

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -183021728.

A última etapa é enviar a biblioteca dinâmica dentro da roda.

E o cheque SSE2 e o resgate gracioso?

@mrslezak - a maneira mais fácil é colocá-lo na pasta numpy/core, pois ele é carregado automaticamente no espaço do processo durante a importação de multiarray.pyd.

A última etapa é enviar a biblioteca dinâmica dentro da roda

@matthew-brett: Tenho 99% de certeza de que a maneira "certa" de fazer isso é por meio de assemblies SxS, cuja documentação é rigorosamente pobre, mas provavelmente factível ... Eu sei que você gastou tempo tentando entendê-los e eu Eu também tenho lido, então se você quiser se sentar em algum momento e tentar descobrir os detalhes, me avise :-).

(O problema com todas as outras abordagens é que os processos do Windows IIUC normalmente mantêm um único namespace global de todas as dlls importadas. O que isto significa é que se duas extensões enviarem um arquivo chamado foo.dll, a extensão que for carregada primeiro terá sua versão de foo.dll "win" e a outra extensão acabará usando-o - o clássico problema "dll hell".

Nathaniel - Eu escrevi meu entendimento dos assemblies SxS aqui: https://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-assemblies

Minha conclusão final foi que não havia esperança e que, em qualquer caso, renomear a DLL de uma maneira única por processo era uma alternativa razoável.

Ralf - sugestão para formalizar a maneira de adicionar ganchos SSE2 etc ao processo de instalação: https://github.com/numpy/numpy/pull/7231

@matthew-brett: Eu li essas notas, sim... e ugh suspiro, sem esperança por quê? Por causa dos problemas de mesmo diretório? E você tem alguma idéia de como realizar essa renomeação? (Ainda não encontrei nenhum equivalente a patchelf --replace para arquivos PE, e regenerar arquivos .lib não é trivial - embora eu ache que está usando mingw-w64 não é tão ruim porque você pode vincular diretamente ao .dll . Pelo menos se você não precisar renomear libgfortran ou similar...)

(É possível que haja algum PE equivalente a patchelf --replace em algum lugar desta lista: http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

Não vejo problema em carregar satlas.dll (ou, alternativamente libopenblaspy.dll ) ao lado de multiarray.pyd, pois esse diretório é preferido durante a pesquisa de DLL. Essa abordagem funciona devido ao fato de que essa DLL é carregada via LoadLibraryEx do python no espaço do processo. A pasta numpy/core deve ser usada, pois aqui está a primeira ocorrência de uma extensão python dependente de blas durante a importação. Quaisquer outras tentativas de carregar uma DLL com o mesmo nome são simplesmente ignoradas porque essa DLL já está carregada no espaço do processo. O Windows apenas procura o nome da DLL BTW.

A DLL hell start Se tal biblioteca é dependente de _further_ DLLs, mas este não é o caso, pois satlas.dll e libopenblaspy.dll são independentes e dependem apenas de DLLs padrão do sistema Windows. Isso é o que geralmente é chamado de DLLs vinculadas estaticamente - isso significa que o código de tempo de execução do gcc está vinculado estaticamente.

_Para comparação_: Para importar as bibliotecas MKL, a abordagem é estender temporariamente o PATH para numpy/core . Infelizmente, isso falha se as bibliotecas MKL mais antigas forem colocadas nas pastas do sistema Windows.

@matthew-brett @njsmith : Renomeação de DLL: para que serve?

@carlkl : o caso com o qual estamos preocupados é se numpy incluir atlas.dll e também scipy incluir atlas.dll e, em algum momento, o usuário atualizar o scipy (e obter uma versão mais recente de atlas.dll ), mas o scipy acaba usando a versão antiga de atlas.dll que vem do pacote numpy. Isso é ruim, porque o scipy pode depender de ter a versão mais recente - então as coisas vão quebrar aleatoriamente dependendo exatamente de quais compilações de quais pacotes estão envolvidos e de qual ordem o usuário os importa. Isso acontece porque, se o numpy incluir uma DLL chamada atlas.dll , isso "reivindicará" o nome atlas.dll no namespace DLL de todo o processo e bloqueará qualquer outro pacote de usar DLLs diferentes com isso nome.

Duas soluções possíveis são (a) se o material SxS/contextos de ativação puder ser feito para funcionar, ele fornece uma maneira de desabilitar o namespace DLL em todo o processo ou (b) se numpy contiver numpy-atlas.dll e scipy contém scipy-atlas.dll , eles podem compartilhar o mesmo namespace em todo o processo sem colidir.

Ou se ambos dependem de um pacote clib_atlas separado que fornece a dll? Em seguida, os requisitos de dependência de versão podem ser expressos como de costume para pacotes python.

@tkelman : Precisamos descobrir como oferecer suporte a DLLs fornecidas e DLLs distribuídas separadamente, acho, pois ambas as opções são apropriadas em diferentes situações. E o caso fornecido é muito mais fácil de começar :-)

Acredito que a solução lado a lado exigirá direitos de administrador para instalar no sistema Windows32. Por favor, não faça isso.

Há também assemblies lado a lado 'privados', onde os assemblies ficam em sua própria árvore binária, mas há um limite de dois marcadores de caminho de diretório ascendente que você pode usar para apontar para o assembly, ou seja, você pode apontar para ..\..\some_assembly mas não ..\..\..\some_assembly .

Por exemplo, scipy/first/second/third/something.pyd só pode apontar para um assembly lado a lado nos diretórios third ou second ou first mas não em scipy (ou outros diretórios dentro dele.

OK, eu construí algumas rodas para teste, aqui:

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

Como sempre:

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

Automação de construção muito grosseira aqui: https://github.com/matthew-brett/np-wheel-builder

As rodas passam em todos os testes, exceto por uma falha espúria ao executar o script f2py (um bug nesse teste, acredito).

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

Também construí instaladores de 64 bits para Pythons 2.7, 3.4, 3.5, no mesmo endereço da web.

@matthew-brett, não tenho permissão para acessar esses arquivos.

@matthew-brett, a tecnologia de montagem SxS não é mais usada (desde VS2010), consulte https://en.wikipedia.org/wiki/Side-by-side_assembly.

Que tal adicionar números de versão aos nomes dos arquivos DLL: libopenblaspy_0.15..dll ou libatlas_3.10.1.dll ou similar. E, em seguida, use um _proxy DLL_ que é usado como DLL encaminhador para as DLLs com versão. As extensões Numpy e scipy devem ser construídas em uma DLL proxy chamada _libblaslapack.dll_.

Se o atlas for usado, isso permitiria, em princípio, o carregamento de uma DLL de atlas otimizada em tempo de execução. (não é necessário se estiver usando openblas)

Tudo isso pode ser tratado com a ajuda de um pacote clib_openblas e/ou clib_atlas. (Agora tenho que aprender a gerar o código para uma DLL de encaminhador). O próprio Numpy pode ser equipado com atlas ou openblas. Isso deve ser carregado se nem clib_openblas ou clib_atlas estiver disponível.

@carlkl : Acho que a página da wikipedia é confusa e tenta dizer que o VS 2010 não usa SxS _para certas bibliotecas_, mas o SxS em geral certamente ainda é usado (por exemplo, mais tarde na mesma página: "Do Vista em diante, o sistema operacional também usa WinSxS para seus componentes principais.")

Acredito que a maneira como você cria uma dll de encaminhamento com msvc é escrever um arquivo .def especial e usá-lo ao gerar seu .dll. Mas, como uma dll de encaminhador ajuda? (No osx ou no Linux, acho que pode ser uma ferramenta útil, mas no Windows você ainda tem esse problema irritante de namespace de dll global.)

@njsmith , devemos procurar uma solução compreensível. É verdade que o SxS ainda existe. Normalmente, não é mais usado para nada além do próprio sistema operacional.

(1) A solução mais fácil IMHO é vincular Blas Lapack estaticamente. Essa abordagem cria binários enormes e, portanto, não é recomendada (pelo menos por mim).
(2) A segunda solução mais fácil é instalar a DLL em numpy/core e pronto.
(3) A terceira solução é _forçar_ uma dependência para um pacote Blas/Lapack externo, que foi versionado e simplesmente pré-carrega a DLL Blas Lapack. O uso de pip garante que a versão correta da DLL esteja disponível.
(3) Se tal dependência restrita não for bem-vinda, ela poderá ser aumentada com uma DLL fornecida pelo numpy e pelo próprio scipy. Essas DLLs devem ser carregadas _somente em situações_, onde uma DLL externa não está instalada. Isso significa que um pacote Blas/Lapack externo seria preferível, mas não é estritamente necessário.
A grande vantagem de tal solução é que as versões mais recentes corrigidas de bugs do openblas/atlas podem ser trocadas sem reinstalar o numpy/scipy.
(4) Usando manifestos e SxS. @njsmith , você pode preencher os detalhes deste caso?

Desculpe - consertei as permissões para as rodas - elas funcionam agora?

Desculpe não responder a você sobre as montagens SxS. Meu comentário 'sem esperança' no SxS não foi muito útil, vou tentar descompactá-lo.

A questão é se devemos usar assemblies SxS "privados", que são assemblies SxS que hospedamos em nossa própria árvore binária. Os assemblies SxS também podem ser "compartilhados". Os assemblies compartilhados vão para a pasta do sistema Windows e devem ser instalados por um pacote de instalação do MS . Acho que isso significa que os assemblies compartilhados não podem ser instalados por meio de uma roda e, em qualquer caso, precisariam de permissões de administrador, então acho que podemos rejeitar assemblies compartilhados como uma opção.

Então - quais são os problemas para usar assemblies SxS privados?

O primeiro problema é que estaríamos abrindo um caminho bem novo se tentássemos fazer isso. Não conheço nenhum outro projeto de código aberto que os esteja usando. Perguntei a Steve Dower sobre montagens SxS. Steve trabalha na MS e é o atual mantenedor do Python Windows. Ele sugeriu que eu os evitasse. Parecia que ninguém com quem ele estava trabalhando estava familiarizado com eles. Minhas notas vinculadas acima foram uma tentativa de entender os poucos casos em que ele sabia de alguém (aparentemente) usando-os com sucesso. Há muito poucos bons recursos para explicá-los.

Relacionada é a observação que Carl já fez de que o próprio MS parece ser ambivalente em usá-los. Por exemplo, para o tempo de execução do MSVC, um aplicativo óbvio de assemblies SxS, eles usam nomes de DLL exclusivos (MSVCR90.DLL, MSVCR100.DLL, etc).

Para usar assemblies SxS, acho que teríamos que adicionar código clichê de inicialização a cada módulo compilado que precisa carregar outra DLL, para criar um "contexto de ativação". EDIT: Nathaniel me lembrou que o Windows acionará automaticamente um novo contexto de ativação se vir evidências de um "manifesto" de montagem lado a lado associado à DLL (que pode ser incorporado na DLL, mas também ser um arquivo XML externo) .

Então, não desesperado, mas difícil.

Desculpe por esta pergunta muito básica, mas, no Windows, se eu carregar a biblioteca foo.dll contendo my_symbol em um módulo de extensão, o que acontece se eu carregar a biblioteca bar.dll , também contendo my_symbol , em outro módulo de extensão? Estou assumindo que eles são acessíveis separadamente no meu processo, então a primeira extensão obteria foo: my_symbol e a segunda extensão obteria bar:my_symbol ? Alguém pode me indicar uma referência?

Se estiver certo, então certamente tudo o que precisaríamos, para evitar o inferno da DLL, é ter um nome de DLL que dificilmente seria usado por acidente no mesmo processo (onde o usuário não pretendia usar nossa DLL exata).

Durante a vinculação, cada símbolo é vinculado a uma DLL específica identificada por seu nome. Durante o tempo de execução, é preciso garantir que a DLL correta seja carregada se mais de uma DLL com nome idêntico puder ser encontrada. Portanto, a ordem de busca é importante.
Exemplo Minhas rodas numpy do anaconda.org usam a biblioteca openblas com o nome libopenblas_py_.dll para evitar um conflito de nome com uma libopenblas,dll não padrão usada por Julia.

Versões recentes de julia agora usam um nome diferente libopenblas64_ para refletir a ABI não padrão com a qual construímos. Em 32 bits, não renomeamos nenhum símbolo ou o nome da biblioteca, pois não há muita razão para escolher ints de 64 bits na interface.

O sombreamento de nomes de símbolos dentro de bibliotecas compartilhadas era na verdade mais um problema no linux e no osx do que no Windows, mas fizemos a mesma coisa em todos os lugares para consistência.

Embora isso não exclua a possibilidade em 32 bits onde as ABIs são as mesmas que não conseguimos quebrar um ao outro de outras maneiras, como precisar de uma versão muito antiga ou muito nova para a outra.

Eu poli um pouco o processo de construção - veja https://github.com/matthew-brett/np-wheel-builder

Agora que o processo está razoavelmente automatizado, acredito que seja prático continuar construindo essas rodas nos próximos lançamentos, se for necessário. Fico feliz em fazer isso como gerenciador de lançamento do Windows até que o mingwpy atinja as especificações.

Eu testei essas rodas em Python 2.7, 3.4, 3.5 de 32 e 64 bits e alguns outros também testaram, então acho que estão em boa forma.

Existe mais alguma coisa que eu possa fazer para garantir a todos que vale a pena colocar no pypi, como o OP perguntou?

Olá a todos! Eu só queria entrar nessa discussão porque fiquei frustrado com minha incapacidade de instalar numpy e scipy da fonte por algum tempo, então certamente é benéfico para mim ler sobre o que é acontecendo nesta frente.

@matthew-brett: Este script de automação é incrível . Mesmo que não chegue ao PyPI, isso parece uma maneira muito viável de construir numpy partir da fonte (veja este problema que abri aqui ). Também está extremamente perto de poder construir scipy , pois posso construir tudo, mas os testes parecem causar uma falha de segmentação em algum lugar do Python.

Além disso, para quem realmente está construindo rodas numpy , eu tenho tentado montar uma documentação polida e atualizada sobre a construção dessas bibliotecas a partir da fonte para substituir o que está atualmente online, então eu agradeceria muito a opinião das pessoas nessa frente também!

Obrigado pelo feedback - e seu trabalho na documentação da compilação - que seria muito útil.

Acho que você viu http://mingwpy.github.io - há uma boa quantidade de coisas lá, é claro, específicas para o projeto mingw-w64 e a cadeia de ferramentas mingwpy.

Obrigado @matthew-brett! Passa numpy.test() . O teste f2py.py foi um problema em test_scripts() com virtualenvs que foi corrigido em numpy-SHAd3d2f8e , mas recebo 3 avisos, 2 depreciação e 1 tempo de execução.

Uma última solicitação, esperançosamente menor, é possível exibir um emblema de compilação no seu repo np-wheel-builder e/ou PyPI? Parece que o buildbot 0.8 os possui, e há um pacote/repo python para torná-los bonitos, BuildbotEightStatusShields-0.1 .

Além disso, estou curioso, fiquei assustado com a compilação ATLAS do Windows de 64 bits devido à falta de parâmetros de ajuste. Ele realmente "levou o dia todo" ou existe um conjunto adequado de padrões arquitetônicos?

FYI: Continuum acaba de lançar o Anaconda com mkl numpy otimizado. Acho que eles estão monitorando esse tópico.

Agora, para compilações scipy com as mesmas bibliotecas do atlas. É necessário gfortran?

sim. Caso contrário, você não poderá compilar nenhum dos arquivos .f em scipy . Boa sorte com isso! Como eu disse anteriormente, cheguei _muito perto_, mas se você conseguir passar nos testes, seria ótimo!

Sim, temo que a construção do ATLAS tenha levado cerca de 8 horas em uma máquina sem fazer mais nada. O script de compilação do ATLAS está no repositório np-wheel-builder .

Em relação às notícias MKL , isso é ótimo se você for um usuário conda , embora eu ache que usar uma distribuição Python com numpy e scipy pré-instalados é algo que foi incentivado por algum tempo. Fale comigo quando você puder obter as próprias bibliotecas MKL gratuitamente também. :)

Para construir com gfortran - acho que o mingwpy é nossa melhor esperança.

@matthew-brett: Obrigado por dedicar seu tempo para construir o ATLAS! Eu tentei executar seu script antes e continuei tendo problemas, provavelmente devido a incompatibilidades específicas da máquina.

Desculpe pelos problemas. Acabei de construir os binários ATLAS no repositório np-wheel-builder, foi em uma nova instalação do Windows Server 2012 e Cygwin de 64 bits, com as versões exatas do ATLAS e lapack listadas. Os arquivos de origem que usei estão em http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/. Se você tiver outra versão do ATLAS, pode facilmente ficar complicado.

Hmmm... provavelmente é o caso. Mais uma vez, muito apreciado, dado o esforço que vocês levaram para fazê-lo. Se vocês puderem encontrar uma maneira de lançar compilações ATLAS compatíveis com Windows que não exijam tanto tempo e recursos como agora, isso seria ótimo!

@gfyoung

Fale comigo quando você puder obter as próprias bibliotecas MKL gratuitamente também. :)

Consulte https://software.intel.com/sites/campaigns/nest/ e https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 - ou você quis dizer fonte?

@tkelman , acabei de ver no site do novo projeto mingwpy @carlk, mas a licença da comunidade Intel Nest não tem ifort e, sem isso, quão scipy?

@tkelman : Ops, não sei por que esqueci o licenciamento da comunidade. No entanto, @tkelman traz um ponto válido.

@tkelman : Você poderia tentar com o MinGW, mas pelo que experimentei, isso não funciona infelizmente. Não vai nem passar de numpy devido a problemas de compatibilidade.

@mikofski certo, não ajuda no scipy devido à falta de compiladores. Apenas as opções hoje para compilações scipy serão mingwpy, ou a compilação MSYS2 all-gcc-all-the-time do Python (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- python-scipy). O último, é claro, não será compatível com os binários cpython ou pypi criados pelo msvc, portanto, não abordará todos os módulos além do scipy.

@matthew-brett: qual é o déficit de velocidade para essas rodas ATLAS versus openblas e/ou MKL?

Alguém já olhou para IGP Fortran. Não é mencionado no site do projeto @carkl mingwpy. Tentei usá-lo uma vez, fui bem longe naquela toca de coelho, mas não consigo lembrar qual era a rolha do show. Eu acho que a licença é permissiva mesmo sendo de código fechado. Talvez o PGI Fortran funcione melhor com o msvc?

@mikofski : Eu não tenho isso na minha frente, mas quando olhei para o PGI no ano passado, lembro que minha conclusão foi que era ainda pior que a Intel (em termos de forçar você a adicionar restrições incompatíveis com FOSS ao seu licenciamento) .

Ok, talvez alguns fundos de foco possam ser direcionados para uma solução BLIS/FLAME para arquiteturas x86?

Aparentemente, a Nvidia/PGI estará contribuindo com seu front-end Fortran como código aberto para o LLVM até o final deste ano. https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

Ok, talvez alguns fundos de foco possam ser direcionados para uma solução BLIS/FLAME para arquiteturas x86?

Não pense assim. BLIS parece um projeto muito insalubre (e libflame ainda mais); pouca atividade em termos de commits, tráfego de listas de discussão, etc. Além disso, eles tiveram um financiamento significativo (https://github.com/flame/blis#funding), então não é como se alguns milhares de dólares fossem magicamente fazer esses projetos amadurecem.

Eu não vejo bem de onde esta discussão está vindo ou indo: temos uma solução provisória que Matthew quase completou (usando ATLAS) e, mais importante, temos uma solução de longo prazo que está sendo trabalhada muito ativamente (MingwPy + OpenBLAS). Além disso, o OpenBLAS é muito mais amplamente utilizado; o uso desse projeto na pilha Scipy e em Julia deve amadurecer ainda mais mais rápido.

@rgommers : A conversa foi aonde foi porque @mikofski e eu estávamos tentando usar a solução @matthew-brett para construir scipy . No entanto, parece que nós dois estamos enfrentando o mesmo problema: o compilador Fortran. Eu mesmo tentei usar o gfortran.exe instalado para MinGW32 e MinGW64 sem muito sucesso devido a toneladas de externos não resolvidos por algum motivo ou outro.

A compilação de @gfyoung Matthew usa MSVC. Não adianta tentar usar gfortran com MSVC, sabe-se que não funciona. O resumo da situação de construção é:

• Sem Fortran, então você pode usar o MSVC agora.
• Com o Fortran, você pode usar um dos MingwPy, MSVC + ifort ou icc + ifort.
• Para a pilha Scipy, queremos uma solução gratuita que construa rodas para numpy, scipy, etc. Para isso, é o MingwPy.

@rgommers Desculpe por atrapalhar a conversa. Você está certo, @matthew-brett solução para numpy funciona, e o projeto mingwpy de @carlk já é financiado por num focus. Vou tentar ver se consigo que minha empresa o apoie. Eu já sou um membro do foco num. Mais ou menos na metade do scipy 2829 e acho que cheguei à mesma conclusão. Só espero que funcione. No curto prazo, continuaremos usando @cgohlke ou mudaremos para anaconda. Obrigado novamente!

Além de enviar compilações para pypi, talvez um último problema para @matthew-brett seja um escudo de buildbot em seu repositório de scripts de compilação np? Obrigado! Então isso pode ser fechado?

Antes que isso seja fechado, uma pergunta rápida: eu construí @matthew-brett numpy para que ele aponte para o ATLAS. No entanto, quando tento construir scipy usando ifort , ele também pega meu outro arquivo site.cfg que usa MKL localizado no meu diretório pessoal. Na verdade, sou capaz de construir com sucesso em numpy , e os testes são salvos por alguns erros devido a erros de arredondamento de minutos. No entanto, estou curioso, o que scipy fez quando eu o construí? Ele usou as bibliotecas MKL ou tentou usar as bibliotecas ATLAS já construídas com numpy ?

Há um resumo dos compiladores do Windows Fortran em https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows

@gfyoung - apenas passando por uma combinação de adivinhação e memória distante - acredito que o scipy pegará primeiro o site.cfg em seu próprio diretório e, se estiver faltando, pegará a configuração da compilação numpy. Isso, por sua vez, apontará para onde quer que as bibliotecas estejam, quando eu construí as rodas. Então você precisa reescrever o site.cfg para scipy para pegar as bibliotecas de atlas np-wheel-builder - o script build_numpy.py faz isso para a compilação numpy.

BLIS parece um projeto muito insalubre (e libflame ainda mais); pouca atividade em termos de commits, tráfego de listas de discussão, etc.

Não tenho certeza se os chamaria de insalubres, porque eles não estão tentando ser projetos FOSS administrados pela comunidade; eles são essencialmente um show de uma pessoa, e eles gostam desse jeito (pelo menos por enquanto). Eu estive em contato com eles durante o último ano, e a boa notícia é que o foco atual de seus esforços está exatamente nas coisas que precisamos (seleção do kernel em tempo de execução e configuração de encadeamento em tempo de execução); a má notícia é que não há muito o que fazer a não ser esperar que o arquiteto reorganize as coisas ao seu gosto. Talvez 6 meses verá alguns resultados?

Parece que BLIS etc são uma opção bastante distante neste momento, e que teremos que planejar o caso em que não funcionar.

Nathaniel - alguma sugestão sobre onde obter bons benchmarks? Acho que numpy.bench() não faz mais nada. Eu tentei executar asv , mas muitos testes falham porque o Windows numpy não tem complex256 .

Eu acho que as partes de asv que funcionam são úteis? Ou mesmo %timeit np.dot(big_array, other_big_array) seria útil para ter pelo menos uma ideia grosseira de onde estamos :-)

Além disso, aqui está uma solução geral para o problema de namespace global do Windows DLL, permitindo-nos escrever um Windows delocate : https://github.com/njsmith/redll

Infelizmente, a falha asv complex256 quebra sequências inteiras de testes em dtypes. Eu acho que não seria muito difícil de corrigir embora.

Teste simples com isso:

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)

sugere que, como Clint Whaley alertou antes - o ATLAS de 64 bits não está bem otimizado no Windows. Com MKL de 64 bits via rodas de Christoph Gohlke:

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

Com minhas rodas, construídas com ATLAS de 64 bits:

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

A diferença é muito menor com as rodas de 32 bits (em uma máquina diferente de 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 - Acompanhando você, caso você tenha alguma ideia aqui. Este é o ATLAS 3.10.1 ...

Aqui está outra máquina Windows de 64 bits com um processador mais moderno - também mostra uma desaceleração de ~3x.

MKL:

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

ATLAS:

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

Sim, problema 256 complexo não é difícil de corrigir: https://github.com/numpy/numpy/pull/7251

3x é muito, mas não tão dramático quanto com lapack_lite certo? Acho que está tudo bem para uma solução de curto prazo. E não é como se os antigos instaladores .exe de 32 bits fossem melhores.

Além disso, aqui está uma solução geral para o problema de namespace global do Windows DLL, permitindo-nos escrever uma localização do Windows: https://github.com/njsmith/redll

bela declaração de licença :)

@gfyoung 'site.cfg' é procurado em:

1) Diretório do arquivo setup.py principal que está sendo executado.
2) Diretório inicial do usuário que está executando o arquivo setup.py como ~/.numpy-site.cfg
3) Diretório de todo o sistema (localização deste arquivo...)

@rgommers Desculpe por atrapalhar a conversa.

Não se preocupe, nada foi descarrilado.

Você está certo, @matthew-brett solução para numpy funciona, e o projeto mingwpy de @cgohlke ou

Legal. E é bom ver que você está interessado no MingwPy. Observe que agora ele tem seu próprio ML, que pode ser interessante: https://groups.google.com/forum/#!forum/mingwpy

@rgommers , @matthew-brett : Ah, sim, parece que foi construído com MKL de antemão. Eu apontei diretamente meu site.cfg para a compilação do ATLAS, e scipy compila mas falhas de segmentação durante os testes. Tão perto!

@rgommers - sim - o desempenho é muito pior sem ATLAS (com lapack_lite):

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

Eu acho que a questão restante aqui é se vale a pena padronizar para um numpy OpenBLAS (com todos os testes numpy passando), aceitando o risco de que isso seja mais provável de causar erros numéricos em projetos usando numpy.

Um argumento para fazer isso seria que parece que teremos que ir nessa direção no curto/médio prazo, e pode ser melhor começar agora e nos comprometer com as miseráveis ​​caças de bugs que isso acarretará. Pelo menos estaremos na boa companhia dos mantenedores de Julia.

O Numpy também tem um conjunto bastante diferente de tolerância ao risco versus trocas de desempenho e proporção de usuários para desenvolvedores do que Julia. Portanto, acho que pode fazer muito sentido para o numpy adotar uma abordagem mais conservadora e optar por lento, mas confiável como padrão, trabalhando para permitir o openblas como uma opção não padrão. Embora esses tempos de construção de 8 horas não pareçam divertidos, não é de admirar que ninguém tenha nos perguntado sobre o uso do Atlas com Julia.

trabalhando para permitir o openblas como uma opção não padrão na escolha

O problema é que não tenho certeza de como esse processo poderia funcionar :-/. Não temos nenhuma boa maneira de distribuir compilações alternativas para os usuários (a longo prazo, espero que possamos obter variantes de compilação em pypi como numpy[openblas] e assim por diante, mas isso não acontecerá tão cedo) , não temos como melhorar as compilações do openblas exceto distribuindo-as e esperando por relatórios de bugs, e a principal alternativa às compilações ATLAS para pessoas motivadas a procurar uma não serão compilações openblas, será MKL compilações de algum terceiro :-/.

Eu acho que outra opção para colocar na mesa seria distribuir compilações do BLIS usando seu kernel de referência/SSE2. Como o BLIS ainda só tem configuração de tempo de compilação, isso não será competitivo com o openblas, mas pode ser competitivo com o ATLAS, e os benefícios em relação ao ATLAS são que o tempo de compilação é _muito_ mais rápido e a chance de ser uma boa solução de longo prazo são difíceis de estimar, mas certamente melhor do que o ATLAS sendo uma boa solução de longo prazo (que eu colocaria em zero). Se formos fazer o controle de qualidade de algo de qualquer maneira, pelo menos estaremos direcionando essa energia para algo que _pode_ ter um futuro.

Algumas perguntas que precisam ser respondidas antes de considerar seriamente esta opção:

(1) Não tenho certeza se o suporte multithreading do BLIS é ou não competitivo com o ATLAS (sei que existem algumas opções multithreading na fonte, e sei que o desenvolvedor principal ainda não o considera "pronto" , ou seja, competitivo com MKL, mas há muito espaço entre ATLAS e MKL.)

(2) por falar nisso, também não tenho ideia de como o BLIS em um modo desafinado se sai nos benchmarks acima.

(3) Na verdade, eu não tentei construir o BLIS no Windows, e há o problema de lidar com o fato de que é apenas um BLAS, não um LAPACK - não tenho certeza de quanto isso é um problema para o numpy.

Quão responsivo é o BLIS aos relatórios de bugs? Openblas parece ser muito bom
sobre isso.

Em segunda-feira, 15 de fevereiro de 2016 às 15h48, Nathaniel J. Smith <
[email protected]> escreveu:

trabalhando para permitir o openblas como uma opção não padrão na escolha

O problema é que não tenho certeza de como esse processo poderia funcionar :-/.
Não temos nenhuma boa maneira de distribuir compilações alternativas para usuários (no
a longo prazo, espero que possamos obter variantes de compilação no pypi como numpy [openblas]
e assim por diante, mas isso não acontecerá tão cedo), não temos como
melhorar as compilações do openblas exceto distribuindo-as e esperando por bug
relatórios, e a principal alternativa às construções ATLAS para pessoas que
motivado a procurar um não serão builds openblas, serão builds MKL
de algum terceiro :-/.

Acho que outra opção para colocar na mesa seria distribuir BLIS
compila usando seu kernel de referência/SSE2. Porque o BLIS ainda só tem build
configuração de tempo isso não será competitivo com o openblas, mas pode ser
competitivo com o ATLAS, e os benefícios em relação ao ATLAS são que a construção
o tempo é _muito_ mais rápido, e a chance de ser um bom prazo
solução são difíceis de estimar, mas certamente melhor do que o ATLAS sendo um bom
solução de longo prazo (que eu colocaria em zero). Se vamos fazer QAing
algo de qualquer maneira, então pelo menos estaríamos direcionando essa energia para algo
que _pode_ ter um futuro.

Algumas perguntas que precisam ser respondidas antes de considerar seriamente isso
opção:

(1) Não tenho certeza se o suporte multithreading do BLIS é
competitivo com ATLAS (sei que existem algumas opções multi-threading em
a fonte, e sei que o desenvolvedor principal não a considera
"feito" ainda, ou seja, competitivo com MKL, mas há muito espaço entre
ATLAS e MKL.)

(2) por falar nisso, também não tenho ideia de como o BLIS em um modo desafinado se sai
nesses benchmarks acima.

(3) Na verdade, eu não tentei construir o BLIS no Windows, e há o
problema para lidar com isso é apenas um BLAS, não um LAPACK - não sei como
muito de um problema isso é para numpy.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -184387401.

Eu acredito que libflame é o equivalente lapack em blis. Existe uma interface de compatibilidade lapack2flame descrita nos documentos de referência .

Quão responsivo é o BLIS aos relatórios de bugs?

Nós não sabemos ainda.

Sem ter experimentado o BLIS, acho que parece loucura ir e enviar binários numpy construídos contra o que é basicamente um projeto de um homem de baixa atividade que poucas pessoas usam.

Ainda não vi uma boa razão neste tópico para se desviar do plano MingwPy + OpenBLAS. No-scipy-ATLAS-MSVC-binaries são bons para ter um paliativo, mas menos importante do que a solução MingwPy de médio/longo prazo e se o paliativo se transformar em um grande esforço em si, então eu diria que não vale a pena o esforço .

Os documentos BLIS/libflame sugerem que, se eu fosse tentar construir uma biblioteca BLAS/LAPACK completa no Windows, seria um caminho solitário.

Fico feliz em fazer isso assim que os desenvolvedores concordarem que isso deve funcionar e é suportado.

ATLAS tem sido a biblioteca padrão no Linux por um longo tempo. Não parece irracional imaginar que pode ser o caso de compilações compatíveis com Windows BSD por um tempo.

@tkelman - obrigado pela sua análise - acho que você está certo, esse numpy deve se concentrar na correção. Mas, seria bom unir forças para se apoiar em alguns dos bugs mais exaustivos do OpenBLAS e desenvolver testes mais abrangentes. Este bug do OpenBLAS vem à mente - um tanto obscuro, muito difícil de depurar.

Acredito que para esse problema específico, fornecer rodas numpy no pypi para que um usuário casual do pacote "x" que dependa de "y" (por exemplo: matplotlib) que dependa de numpy instale usando pip, não fazendo com que o usuário casual jogue levantam os braços e dizem algo como "Python é muito difícil". e volte para o MATLAB. O Zen do python diz que deve haver uma maneira óbvia de fazer isso. Dito isto, qualquer coisa em pypi por numpy em particular carrega um certo peso que _é_ estável, ou mais do que um projeto paralelo aleatório, com possível exceção de cgohlke. Obviamente enthought e anaconda são percebidos pelo menos na indústria como mais estáveis.

Eu acho que a curto prazo a construção do ATLAS deve ir com a mensagem de advertência de que não é possível construir com scipy. Se este buildbot pode ser automatizado, então está feito, certo? As futuras compilações do ATLAS de 8 horas devem ser raras. Talvez um dia o problema do Windows 64bit seja resolvido. O problema de exceção SSE2 é uma chatice, portanto, outra mensagem de aviso no pypi. Além disso, o ATLAS já é o padrão no linux e foi o padrão nos pacotes anteriores do superpack bdist_winst, o que dá ainda mais suporte a esse caminho.

Então, para um futuro próximo, você já decidiu pelo mingwpy. Aqui há muitas opções que não precisam ser resolvidas agora.

A longo prazo, estou animado que blis/flame é o futuro. É um pouco assustador que muitas de nossas ferramentas matemáticas dependam do código FORTRAN dos anos 70. A única solução de AC é um grande avanço e imo algo para apoiar com entusiasmo.

Mas mais é sempre melhor para desenvolvedores experientes, portanto, manter a documentação ativa para opções não padrão também é bom se esses desenvolvedores experientes tiverem tempo e inclinação para construir e testar.

Se você não tentar usar um dos kernels otimizados no blis, provavelmente não atingirá o problema (editar: singular) Eu tenho aberto lá desde 2014. Acho que o sistema de compilação usa apenas links simbólicos para o otimizado kernels, então você não confundirá o git do msys2 se tentar construir apenas a configuração de referência lá. A construção do cygwin funcionou da última vez que tentei, embora tenha sido há algum tempo e não consigo lembrar o que talvez precisei modificar localmente. Vale a pena construir, testar e comparar se a alternativa for o Atlas, mas considere-o não comprovado e, portanto, de alto risco à sua maneira até que você o faça.

@mikofski para ser justo Lapack é dos anos 90, é mesmo o elefante Fortran da sala.

@tkelman : para ser claro, os problemas que você registrou foram especificamente com o sistema de compilação nativo do Windows, certo? Por curiosidade, tentei compilar blis para windows do linux (usando o compilador cruzado mingw-w64 instalado a partir de pacotes debian), e fiquei surpreso ao descobrir que levou apenas ~ 2 minutos. Eu fiz "./configure reference; make -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=" e tudo funcionou. ( CPICFLAGS= é apenas para suprimir um monte de avisos sobre "ignorar -fPIC , porque esse é o padrão", e provavelmente eu nem precisei substituir AR , mas ei por que não.) Tenho alguns avisos sobre printfs em bli_pool.c e bli_fprintm.c que usam %ld para imprimir intptr inteiros, então provavelmente há alguns problemas no LLP64 para dar certo.

@rgommers :

Sem ter experimentado o BLIS, acho que parece loucura ir e enviar binários numpy construídos contra o que é basicamente um projeto de um homem de baixa atividade que poucas pessoas usam.

Você está absolutamente correto! O problema é que todas as nossas opções são terríveis :-(.

Então, obviamente, MKL tem uma licença definitivamente ruim.

O ATLAS tem um desempenho definitivamente ruim que nunca melhorará.

E o OpenBLAS, acho que temos evidências para dizer neste momento, simplesmente não é sustentável e provavelmente não se tornará tão cedo :-(. O projeto tem cinco anos, ainda tem coisas fundamentalmente quebradas como o exemplo de Julian de volatile aleatório

Então, a razão pela qual eu continuo trazendo o BLIS não é porque eu acho que o BLIS é definitivamente a solução, mas como uma espécie de otimismo calculado: BLIS _pode_ se tornar tão rápido quanto MKL/OpenBLAS, tão confiável quanto ATLAS/MKL, e tão aberto à comunidade. contribuições como OpenBLAS; ou então, novamente, pode não ser. Mas não parece haver nenhum outro projeto que tenha uma esperança real de atingir todos esses critérios. [E isso sem mencionar as outras vantagens, como o fato de poder suportar arrays strided nativamente; não é inimaginável que possamos excluir todo o nosso terrível código de despacho BLAS de caso especial.]

IIUC, GotoBLAS foi mantido por um único desenvolvedor em tempo integral (Kazushige Goto) trabalhando na UT Austin com Robert van de Geijn como PI. O BLIS é mantido por um único desenvolvedor em tempo integral (Field G. Van-Zee) trabalhando na UT Austin com Robert van de Geijn como PI. Então não é como se isso não pudesse funcionar :-) Mas sim, isso não vai acontecer magicamente se esperarmos -- se houver uma comunidade de desenvolvedores ao redor disso, então será porque alguma comunidade mostrou seus gramado da frente com tendas como "ei, aqui estamos, estamos nos mudando e fazendo isso funcionar para nós, espero que você não se importe". E o que realmente precisamos saber para determinar sua viabilidade a longo prazo é, tipo, "quão confiável é realmente" e "quão passível de patches eles são" e outras coisas, que não podemos saber a menos que comecemos a testá-lo e enviar remendos e assim por diante.

Concluindo: não sei qual é a nossa melhor opção, mas enfiar os dedos dos pés na água do BLIS parece uma boa ideia; mesmo que decidamos esperar, pelo menos aprenderemos alguma coisa.

Eu arquivei várias questões e um ou dois PR. O fato de haver links simbólicos no repositório significa que a construção a partir do msys2 está quebrada (ou só funciona se você definir as opções do msys2 de uma maneira específica). A construção cruzada de cygwin ou linux (eu não confiaria no wine para executar os testes) deve funcionar, mas teve problemas em 2014 com malloc alinhado e os kernels da ponte arenosa falharam em um teste. Acabei de reconstruir os kernels da ponte arenosa no último master of blis com uma cruz cygwin (em um laptop skylake mais recente) e o segfault pode ter desaparecido agora. Quem sabe quando ou o que consertou, teria que bifurcar.

Acho que isso já foi mencionado antes, mas poderíamos construir binários ATLAS para SSE2, SSE3, AVX e colocá-los em uma estrutura de diretórios como:

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

Poderíamos então usar o numpy/_distributor_init.py para verificar a CPU atual e pré-carregar a biblioteca correspondente.

Eu sugeri fazer basicamente a mesma coisa, mas para blis em vez de atlas, para @njsmith. Também vale a pena comparar o quão bem o encadeamento no blis funciona com o atlas. A configuração de referência do blis não habilita o encadeamento por padrão, embora ajustar uma definição em um arquivo de cabeçalho deva ser tudo o que é necessário para mudar isso.

Eu configurei o Appveyor para construir os binários. A iteração atual da compilação está acontecendo aqui: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

As rodas construídas chegam aqui: https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

Quaisquer outras falhas na compilação do Appveyor devem ser fáceis de resolver, então acho que essas rodas estão prontas para serem carregadas no pypi quando isso for feito, presumivelmente amanhã em algum momento.

@rgommers , @matthew-brett : Em relação site.cfg , parece que sua resposta se aplica apenas a numpy . Parece que scipy não procura por site.cfg no mesmo diretório que setup.py apenas começa a procurar por site.cfg primeiro em seu diretório inicial antes de padronizar o numpy configuração.

OK - script de compilação rodando sem erro, incluindo testes da roda instalada: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Rodas aqui: http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

Eu instalei e testei em outra máquina de 64 bits e outra máquina de 32 bits.

Então, eu acho que estes estão prontos para ir. Alguma objeção a eu fazer o upload deles para o pypi?

Pode ser uma boa ideia ter uma nota no pypi explicando / vinculando a uma explicação da diferença entre essas rodas e as de gohlke (mkl) para evitar confusão por pessoas se perguntando por que as rodas aparecem agora no pypi e qual a diferença entre eles estão.

Uma pergunta paralela, desculpe, mas eu queria saber o que

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

no script appveyor significa?

Boa sugestão sobre a explicação - vou tentar descobrir como adicionar isso para esta versão existente.

Wheel > 0,26 adiciona uma tag ABI extra à roda do Windows. Wheel==0.26 dá um nome de roda como este:

numpy-1.10.4-cp27-none-win32.whl

Com Wheel > 0,26, você obtém uma tag ABI extra, assim:

numpy-1.10.4-cp27-cp27m-win32.whl

(eu acho) - que especifica a ABI do Windows. Isso é irritante porque o pip anterior não instala esses caras, então me parece que o nome no-ABI é melhor por enquanto.

OK - proponho adicionar este texto à página pypi atual:

Todas as rodas numpy distribuídas pelo pypi são licenciadas pelo BSD.

As rodas do Windows estão vinculadas à biblioteca ATLAS BLAS / LAPACK, restritas às instruções SSE2, portanto, podem não fornecer o desempenho ideal de álgebra linear para sua máquina. Consulte http://docs.scipy.org/doc/numpy/user/install.html para alternativas.

Eu diria diferente:

Essas rodas do Windows têm desempenho de álgebra linear abaixo do ideal (link para benchmark como http://speed.python.org), porque estão vinculadas à biblioteca ATLAS BLAS / LAPACK, que são restritas a instruções SSE2 (e quais instruções não restritas devem estar lá?). Se você precisar de desempenho, poderá oferecer suporte ao projeto mingwpy, que visa trazer mais desempenho às extensões Python compiladas nesta plataforma. Ver ??? para detalhes e http://docs.scipy.org/doc/numpy/user/install.html para alternativas.

Bem - as versões atuais numpy / scipy do mingwpy usam openblas, mas acho que isso não está relacionado ao mingwpy vs MSVC como compilador. Também poderíamos enviar openblas com essas rodas, mas eu estava preocupado que o openblas ainda não fosse confiável o suficiente para usar em uma roda padrão que suportamos.

O OpenBlas parece estável o suficiente, eu sei que o Anaconda o usa para o Linux
constrói agora. Não há compilações atualizadas do Windows Python 3.5 x64
lá, os benchmarks mostram que é quase igual ao MKL. Eu definitivamente tentaria se
alguém poderia montar uma roda.
Em 16 de fevereiro de 2016, 22h36, "Matthew Brett" [email protected] escreveu:

Bem - as versões atuais numpy / scipy do mingwpy usam openblas, mas eu
acho que não está relacionado ao mingwpy vs MSVC como compilador. Também poderíamos enviar
openblas com essas rodas, mas eu estava preocupado que o openblas ainda não
confiável o suficiente para usar em uma roda padrão que apoiamos.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -185017546.

OK. Estou apenas confuso sobre a fonte de desempenho abaixo do ideal - eu não uso essas bibliotecas BLAS e não sei o que elas fazem e qual é a diferença, então explicar essas opções para os mortais ajuda a se tornar .. erm, mais científico, você sabe . =) Eu pensei que a ausência de compilador aberto com desempenho ideal é o problema.

@mrslezak : em relação ao OpenBLAS, certamente posso concordar. O pacote OpenBLAS fornecido no Cygwin, juntamente com o pacote Lapack, parece ser capaz de construir o NumPy e o SciPy sem problemas.

@mrslezak : onde posso encontrar informações sobre os benchmarks? Estou tentando escrever documentação sobre como compilar o código-fonte do Windows para scipy.org , e isso seria uma ótima referência para quem precisa de desempenho com essas bibliotecas.

Talvez a abordagem de espingarda seja a ideia certa? Algo como:

• Estável: ATLAS com desempenho, advertências sse2
• Dev: OpenBLAS veja mingwpy e binstar
• Alt: MKL @cgohlke , MKL @continuum e @enthought
  Advertência: os binários não são compatíveis.
  Links para mais informações em scipy e github numpy wiki de Matthew Brett

@techtonik Eu esperaria que o GCC tivesse um desempenho um pouco pior que o MSVC ou o ICC em código equivalente que todos esses compiladores são capazes de construir. O problema é a falta de um compilador gratuito (compatível com python.org-cpython) que possa construir uma versão competitiva do Lapack, que está em Fortran (o SciPy também possui outros componentes do Fortran). A parte BLAS pura do OpenBLAS (e provavelmente o Atlas também) pode realmente ser construída com o MSVC, mas o MSVC não pode construir nenhuma das peças que exigem montagem em linha, portanto também não será competitivo.

Eu não tenho um MKL de 64 bits à mão (eu posso ter um de 32 bits de conda em algum lugar se eu for cavar), mas aqui estão alguns benchmarks executados em Julia comparando a dll Atlas que @matthew-brett construiu contra referência e sand- configurações de ponte do BLIS e a compilação OpenBLAS que vem com Julia https://gist.github.com/54da587b01b7fb163103

Resumo: openblas (em um skylake, o mais novo kernel openblas é haswell) é 23x mais rápido que o atlas, 44x mais rápido que o blis de referência e 5,5x mais rápido que o sandbridge blis. Eu poderia tentar Haswell blis para ver o quão perto está.

Hum - Eu não suponho que você tenha scripts de compilação por aí para suas compilações do BLIS?

Você acha que valeria a pena fazer compilações do BLIS para uma variedade de processadores e selecionar um em tempo de execução? Existe um pequeno subconjunto de processadores que capturaria a maior parte do desempenho da maioria dos processadores?

Está nos comentários, mas aqui (executado no 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

Aqui está o que eles têm disponível: https://github.com/flame/blis/tree/master/config

Em termos de Intel x86, a referência, dunnington, sandybridge e haswell cobririam uma faixa muito boa. Também bulldozer, piledriver e carrizo para a AMD (que recentemente parou de desenvolver ACML em favor do BLIS, então pelo menos é um voto a favor).

Há algum código de detecção automática em https://github.com/flame/blis/tree/master/build/auto-detect que pode ser reutilizável (atualmente, ele é executado apenas no momento da configuração no BLIS, mas isso não significa que não poderia ser reutilizado para outros propósitos), dependendo se já existe um pedaço de código de identificação da família de cpu em Python que você deseja usar.

dependendo se já existe um pedaço de código de identificação da família cpu em Python por aí

Isso ajuda? http://stackoverflow.com/a/35154827/239247

Você deseja principalmente a família de processadores derivada disso, mas https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c não é exatamente longo ou complicado. A fonte numexpr que está vinculada do SO está fazendo correspondência de regex na saída da string (pelo menos no linux) e não parece ter muitas arquiteturas recentes listadas.

openblas é 3,4x mais rápido que Haswell blis, e 17x mais rápido que dunnington (basicamente o mesmo que nehalem penryn eu acho) blis. O interessante é que não acho que o multithreading esteja funcionando em blis nessas execuções. A configuração padrão habilita openmp para sandybridge e haswell, talvez os pthreads mingw funcionem melhor. Definir OMP_NUM_THREADS não parecia fazer muita diferença.

Acredito que o ATLAS 3.11 deve se sair muito melhor em 64 bits do que a versão 3.10, mas não posso construí-lo no momento, esperando alguma ajuda de Clint Whaley.

Tony - Suponho que você não tenha tempo/energia para testar a roda ATLAS de 32 bits? Deve fazer muito melhor, relativamente.

Minha preferência é seguir em frente com essas rodas ATLAS, para que outros empacotadores possam depender de nós enviando algum tipo de roda. Se encontrarmos uma boa maneira de melhorar o desempenho, teremos uma nova versão numpy em breve, e mesmo para 1.10.4 sempre podemos fazer uma versão de manutenção para atualizar as rodas.

@matthew-brett: pergunta rápida, por que numpy não pode detectar as compilações ATLAS no Cygwin? Consegui detectá-los perfeitamente em um ambiente nativo do Windows, mas quando tentei executar seu script no Cygwin, numpy não compilou com ATLAS .

Se você estiver usando o python do Cygwin, provavelmente precisará de uma versão do atlas construída no cygwin para que as coisas sejam compatíveis.

Julia de 32 bits parece estar falhando ao abrir a dll atlas de 32 bits. Não sei por que, talvez porque já temos um openblas de 32 bits e os nomes dos símbolos são conflitantes?

Mas a versão @matthew-brett é construída com Cygwin, e é por isso que estou confuso.

Ambiente de compilação Cygwin, compilado de forma cruzada para uma biblioteca mingw. Veja como ele está vinculado a msvcrt.dll em vez de cygwin1.dll?

Assim que postei o comentário, foi o que de repente suspeitei que poderia ser o caso. Infelizmente, parece que vou ter que construí-lo do zero. Obrigado @tkelman !

problema dlopen descoberto (ref https://github.com/matthew-brett/np-wheel-builder/pull/1, e https://github.com/JuliaLang/julia/issues/15117 estava escondendo a versão útil do a mensagem de erro).

Em 32 bits, o atlas é 3,6 vezes mais lento que o openblas. Openblas de 32 bits é 3x mais lento que openblas de 64 bits para o mesmo problema de tamanho. As poucas famílias de kernel mais recentes não são habilitadas em openblas em sistemas de 32 bits.

...
Concluindo: não sei qual é a nossa melhor opção, mas enfiar os dedos dos pés na água do BLIS parece uma boa ideia; mesmo que decidamos esperar, pelo menos aprenderemos alguma coisa.

Isso provavelmente é útil, pelo menos alguns testes/benchmarking. Mas neste ponto não está relacionado aos nossos problemas de _Windows_. BLIS é apenas Linux no momento; há um PR aberto para suporte à compilação OSX, e o Windows está muito distante. E pior, eu tentei ontem no Linux de 32 bits e mesmo isso não funciona. ./configure auto && make trava horrivelmente em algum código assembler (para sandybridge ). Eu só posso construir reference .

Então eu acho que o passo 0 é adicionar suporte para BLIS em numpy.distutils (já está funcionando), passo 1 para testar no Linux para ver se pelo menos reference funciona, passo 2 alguns benchmarks, ..., degraualgo no Windows.

@matthew-brett seu texto proposto para PyPI parece bom para mim. Quais versões pip ignoram o nome com a tag ABI? Pip incomoda muito você para se atualizar hoje em dia, então eu esperaria que muitas pessoas tivessem a versão mais recente. E as versões com mais de 1(.5) anos nem sequer instalavam rodas por padrão.

@rgommers meus testes acima foram no windows. Não o MSVC, mas o mingwpy ou o openblas não farão muito diferente lá - o clang provavelmente funcionaria, mas precisa de reorganização do repositório no blis para evitar links simbólicos.

Eu não executei os testes de Julia ou numpy contra blis, mas blis estava passando em seus próprios testes de unidade. As coisas correram muito melhor do que a minha experiência de 2014 me levou a pensar que iriam. Ainda precisa descobrir como fazer com que o multithreading funcione corretamente, mas com isso você pode ter um desempenho blis já competitivo.

Parece que a configuração de referência é a única coisa no blis que funciona para x86 de 32 bits no momento. Isso exigiria escrever novos microkernels assemby, acredito que talvez não, veja os comentários de njsmith abaixo.

@tkelman , sobre kernels OpenBLAS para 32 bits https://github.com/numpy/numpy/issues/5479#issuecomment -185096062: de acordo com um priv. mensagem que recebi de Werner Saar algum tempo atrás, não há ninguém trabalhando em kernels Intel de 32 bits para arquiteturas mais recentes. Portanto, este é um fato que dificilmente será alterado no futuro. O foco está nos processadores Intel de 64 bits e ARM.

@tkelman , em relação ao C-runtime https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: IMHO isso não é crítico, pois ATLAS e OpenBLAS não compartilham recursos do C-runtime (descritores de arquivo e heap ). _Espero que eu esteja certo_. Pode ser útil para compilações ATLAS aumentar o tamanho da pilha. Isso pode ser dado como sinalizador durante a vinculação, ou seja:

-Wl,--stack,16777216

sobre as discussões ATLAS vs. OpenBLAS: graças a @matthew-brett agora existem DLLs ATLAS baseadas em SSE2 disponíveis. Esta compilação do Atlas deve ser comparada à compilação do OpenBLAS em relação a um Target habilitado para SSE2 (ou simplesmente defina OPENBLAS_CORETYPE=NORTHWOOD - basicamente PENTIUM4) para desativar a detecção de tempo de execução da CPU. É claro que uma versão genérica do OpenBLAS pode explorar muito mais variantes de CPU graças à detecção de tempo de execução da CPU. Esta é uma das razões pelas quais o OpenBLAS é mais eficiente em comparação com o ATLAS. Outra questão é a confiabilidade do OpenBLAS. Talvez um repositório com testes BLAS e LAPACK reunidos possa ajudar.

em relação ao BLIS/Flame: interessante, mas uma fruta em alta pelo menos por hoje.

A tomada de decisão de como escolher entre ATLAS e OpenBLAS não é clara para mim.

Ralf - pip 8 instalará as rodas com as novas tags Windows ABI, pip 7 não. Pip 7 e pip 8 instalarão as rodas sem as etiquetas ABI, sem aviso prévio.

Ainda existem muitos pip 7s por aí, foi lançado em agosto de 2015 - então prefiro ficar com o nome mais compatível, pelo menos por um tempo.

+1 na investigação do BLIS. Essa parece ser uma boa solução a longo prazo. Já consideramos Eigen? Eles suportam a construção de uma interface LAPACK parcial e a licença é MPL2 para a maior parte do código. Isso pode ser bom o suficiente para o NumPy.

Percebi no código de detecção de CPU do BLIS que muitas vezes ele volta para a implementação de referência se não encontrar instruções AVX, que ainda são bastante recentes.

Ian : este é o estado para Eigen a partir de um ano ou mais atrás : http://mingwpy.github.io/blas_lapack.html#eigen - então eu acredito que seria um trabalho para construir uma biblioteca utilizável para numpy.

E pior, eu tentei ontem no Linux de 32 bits e mesmo isso não funciona. ./configure auto && make trava horrivelmente em algum código assembler (para sandybridge). Eu só posso construir referência.

Se você olhar para o conteúdo de config/ -- as várias "configurações" nomeadas (como "sandybridge", "haswell") são na verdade configurações "iniciais" pré-empacotadas que incluem um monte de configurações pré-especificadas (não apenas configurações relacionadas ao ajuste da CPU, mas também configurações do modo de encadeamento, configurações do compilador, etc.). E a configuração chamada "sandybridge" é uma configuração x86-64. Parece um bug que a configuração automática o selecionou, mas sim, não funcionará em x86-32 :-). O BLIS parece ser fornecido com kernels x86 de 32 bits (consulte kernels/x86 ), embora pareça que no momento nenhuma das configurações pré-empacotadas os usa. Fazer novas configurações é principalmente trivial; a mágica está no arquivo bli_kernel.h que nomeia qual kernel interno + alguns tamanhos de buffer. Podemos perguntar a montante se eles têm alguma sugestão para x86-32.

Além disso:

BLIS é apenas Linux no momento; há um PR aberto para suporte à compilação OSX, e o Windows está muito longe

Alguns comentários acima, @tkelman está construindo e comparando o BLIS no Windows :-)

O benchmark de petróleo bruto anterior test_dot com OpenBLAS 0.2.12:

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

Comparado com (resultado anterior de) MKL

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

ATLAS de 64 bits:

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

Então, quando comparo openblas e MKL (obrigado, conda) em série com a configuração Haswell BLIS, eles estão todos dentro de no máximo 10-20% um do outro no dgemm. Aqui está um arquivo docker que foi construído com sucesso no hub do docker para compilar dll do Windows de cada configuração (exceto bulldozer que não vinculou corretamente https://github.com/flame/blis/pull/37#issuecomment-185480513, tudo bem) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

Você pode tentar conectar algo semelhante à configuração services: docker do Travis e brincar com a implantação de artefatos binários em releases/bintray/whatever do github.

Eu estava olhando para a detecção da CPU do BLIS -> código do modelo: https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

Aqui está uma reescrita do Python, que deve ser um pouco mais liberal ao aceitar um dos modelos avançados (é mais provável que acredite que o sistema operacional pode usar o AVX do que o código C): https://gist.github.com/matthew-brett /a53778f99b7062cc332d

Em todas as máquinas em que testei, esse algoritmo retorna 'reference' - provavelmente porque tenho máquinas antigas que ninguém mais queria usar, para resgatar para meu farm de buildbot.

Compilando numpy contra a referência BLIS, sem lapack, dá o seguinte no meu benchmark bruto:

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

Apenas o produto escalar de dois (1000, 1000) arrays é de 12 segundos. Portanto, como Tony também descobriu, a referência BLIS é a pior de nossas opções, em torno da mesma compilação padrão sem biblioteca do numpy com lapack_lite.

Então, acho que precisaremos de mais modelos cobrindo máquinas mais antigas ou detecção de CPU mais liberal -> mapeamento de modelo para fornecer desempenho razoável em uma ampla variedade de máquinas.

@matthew-brett quando podemos esperar que as novas rodas do Windows de 64 bits do ATLAS estejam ativadas? Qual versão? v1.10.2? Eles estarão apenas no pypi ou também no source forge? Você vai fazer algum tipo de anúncio? Muito, muito obrigado!

@matthew-brett qual foi a proporção entre atlas e blis de referência para você na mesma máquina? Comparável ao fator de cerca de 2 que eu estava vendo? Eu tenho multithreading para trabalhar em blis, eu simplesmente não rtfm corretamente (https://github.com/flame/blis/wiki/Multithreading), ele não é ativado automaticamente e existem 4 vars de ambiente diferentes para brincar . Com este patch https://gist.github.com/0fc9497a75411fcc0ec5 para habilitar blis paralelos baseados em pthreads para todas as configurações e definindo BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 , o Haswell blis é basicamente amarrado com mkl e openblas na minha máquina. Se eu definir apenas BLIS_JR_NT para 2, então a referência paralela blis é a maior parte do caminho para atlas, e é mais rápido com 3 threads.

@tkelman IMO seria útil se você pudesse documentar seu progresso no BLIS nas páginas do NumPy GitHub Wiki. Eu também acho que pode ser interessante propor um plano semelhante ao mingwpy para fazer uma roda NumPy-BLIS-FLAME (e uma roda SciPy-BLIS-FLAME, se possível?).

@tkelman : para ter certeza de que estou claro - seu atlas está encadeado, certo?
outra coisa a considerar é adicionar -msse2 ou semelhante às configurações de compilação reference - parece que, por padrão, é compatível ao máximo e não permite que o compilador use SSE, mas pelo menos em numpy-land Eu sei que estamos aumentando para SSE2 como a configuração mínima suportada de qualquer maneira por outros motivos ...

Não sei se o FLAME é relevante ou não agora versus o LAPACK regular - gostaríamos de perguntar.

Possivelmente deveríamos abrir um novo problema para o material do BLIS em vez de continuar a desordenar este :-)

Para este segmento - acho que já podemos enviar uma roda com vários kernels BLIS selecionados em tempo de execução usando as mesmas regras que o BLIS usa em tempo de compilação, mas acho que isso resultaria em muitas máquinas com referência BLIS e, portanto, pior desempenho do que o ATLAS de 64 bits, embora o ATLAS de 64 bits no Windows seja particularmente ruim (para ATLAS).

Mas - se a compilação de referência for mais rápida que o ATLAS de 64 bits - digamos com -msse2 - essa seria uma opção real.

SSE2 é a configuração mínima para 64 bits, portanto, é seguro usar algo como -mfpmath=sse -msse2 para a compilação de referência.

Possivelmente deveríamos abrir um novo problema para o material do BLIS em vez de continuar a desordenar este :-)

Isso seria uma boa ideia (editar: posso sugerir que seja intitulado "Occupy BLIS", dado o sentimento de @njsmith sobre gramados em https://github.com/numpy/numpy/issues/5479#issuecomment-184472378 ?) . Acho que ter @matthew-brett continuando com o upload de suas rodas Atlas existentes seria suficiente para fechar este por enquanto, com trabalhos futuros deixados para novos problemas.

para ter certeza de que estou claro -- seu atlas está encadeado, certo?

Meu atlas é a dll de https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds , mas ainda não o vi usar com sucesso mais de 1 thread. Estou faltando uma variável de ambiente?

outra coisa a considerar é adicionar -msse2 ou semelhante às configurações de compilação reference - parece que, por padrão, é compatível ao máximo e não permite que o compilador use SSE

SSE2 faz parte da especificação x86_64, portanto, isso só seria relevante em 32 bits. Em Julia adicionamos -march=pentium4 para nossas compilações de 32 bits.

Não sei se o FLAME é relevante ou não agora versus o LAPACK regular - gostaríamos de perguntar.

Ainda não toquei na chama, mas vale a pena brincar. Eventualmente, você poderá usar o WIndows Clang como uma alternativa de plano de backup ao mingwpy. (edit: na verdade isso não corrige o fortran no scipy, então talvez não)

@matthew-brett: Eu acho (pode estar errado) o kernel dunnington requer apenas SSE3, que a Steam Hardware Survey afirma estar presente em 99,94% das máquinas (contra 99,99% para SSE2). Portanto, parece errado se você descobrir que a maioria dos sistemas não pode lidar com isso - não sei se isso é um bug no código cpuid, em você ter um conjunto realmente não representativo de máquinas de teste ou no meu entendimento do que esse kernel requer.

Eu postei uma reescrita em Python do código de detecção da CPU na essência acima. Eu estou supondo que a seleção do modelo é conservadora, padronizando a referência onde outro modelo pode ter funcionado.

Para me lembrar, para vincular ao BLIS, eu precisava de um site.cfg como:

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

Eu também fiz isso, suponho que seja necessário (patch relativo ao 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):

Utilitário para permitir a detecção em tempo de execução da CPU: https://github.com/matthew-brett/x86cpu

Eu acho que isso pode ser um candidato para inclusão no próprio numpy, mas também podemos copiar o único módulo cpuinfo compilado na árvore numpy para a roda do Windows.

Olá a todos. Um pensamento: se você quiser publicar várias rodas numpy diferentes criadas com várias bibliotecas de vetores, poderá usar diferentes nomes de pacotes 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

Registrei 2 para tentar fazer o upload das rodas do Gohlke, mas o PyPI os rejeitou. Você é bem-vindo ao URL.

gh-7294 adiciona suporte BLIS a numpy.distutils . Seria ótimo se alguém pudesse verificar se isso funciona como esperado.

Ainda existem muitos pip 7s por aí, foi lançado em agosto de 2015 - então prefiro ficar com o nome mais compatível, pelo menos por um tempo.

O Pip 7.0 ainda não é tão antigo, então faz sentido.

... BLIS parece ser fornecido com kernels x86 de 32 bits (consulte kernels/x86), embora pareça que no momento nenhuma das configurações pré-empacotadas os usa

Isso explica, obrigado.

Obrigado Ralf - vou testar.

Sei que isso pode precisar de um novo segmento, mas agora estamos muito perto de poder usar as compilações do BLIS para um lançamento.

Acho que tudo o que precisamos agora são modelos recomendados para uma máquina que tenha SSE2 e uma máquina que SSE3, que funcionem um pouco mais rápido do que a compilação ATLAS de 64 bits do Windows.

Sei que isso pode precisar de um novo segmento, mas agora estamos muito perto de poder usar as compilações do BLIS para um lançamento.

Eh, tecnicamente pode ser possível fazê-lo funcionar, mas ainda não é um bom plano lançar construções por cima do muro assim. Ainda não tivemos testes sérios do BLIS no Linux ou OS X. Então, no Windows, onde o FAQ do BLIS diz :

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

, é definitivamente muito cedo. Além de testar, alguns benchmarking também é uma boa ideia, eu acho.

Claro - mas como Tony mostrou, na verdade não é difícil construir BLIS para Windows, usando compilação cruzada. A coisa experimental - acredito - é o sistema de compilação MSVC, que não estamos usando.

Por enquanto, estou apenas sugerindo o uso do BLIS para a roda do Windows, mas é claro que seria muito bom fazê-lo funcionar também para as muitas compilações do Linux.

Concordo plenamente que, se não estivermos obtendo um aumento significativo de desempenho na média, não deveríamos estar usando o BLIS e, no momento, acho que não estamos, exceto para processadores muito novos. Isso pode ser corrigível trivialmente com alguns novos modelos, eu adoraria saber se esse fosse o caso.

Para correção, também concordo. Que tal se mostrarmos isso

a) Todos os testes numpy passam em todas as versões do Windows;
b) Todos os testes numpy e scipy passam no sistema manylinux?

Podemos tornar o modelo BLIS selecionável em tempo de execução e testar todos os kernels em uma máquina moderna. Eu posso testar em algumas máquinas antigas e desagradáveis ​​também.

Por enquanto, estou apenas sugerindo o uso do BLIS para a roda do Windows, mas é claro que seria muito bom fazê-lo funcionar também para as muitas compilações do Linux.

manylinux é menos importante, eu acho, já que temos gerenciadores de pacotes lá com uma pilha completa, bem como usuários que podem compilar coisas muito mais facilmente. Vamos primeiro ver todo o conceito do manylinux decolando antes de nos preocuparmos com isso neste contexto numpy + BLAS/LAPACK :)

Para Windows, acho que nossos prios são:

1) uma solução full-stack (precisa do MingwPy, com um dos OpenBLAS/ATLAS/BLIS)
2) rodas binárias provisórias (temos uma prestes a subir com sua compilação ATLAS)
3) aumentando o desempenho de (1). É aqui que o BLIS pode entrar.

Portanto, não há necessidade de ter muita pressa com o BLIS no Windows.

Concordo plenamente que, se não estivermos obtendo um aumento significativo de desempenho na média, não deveríamos estar usando o BLIS e, no momento, acho que não estamos, exceto para processadores muito novos. Isso pode ser corrigível trivialmente com alguns novos modelos, eu adoraria saber se esse fosse o caso.

Concordo, deve haver um ganho significativo para que faça sentido. É um pouco difícil supervisionar quanto trabalho é realmente necessário.

Para correção, também concordo. Que tal se mostrarmos isso

a) Todos os testes numpy passam em todas as versões do Windows;
b) Todos os testes numpy e scipy passam no sistema manylinux?

Isso soa bem. Faria sentido incluir scikit-learn também, é um usuário linalg bastante significativo.

Eu não sabia que blis e libflame faziam parte da base de código ACML, que foi aberta há algum tempo:

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/

No entanto: como resolver o problema para comparar 4 diferentes implementações aceleradas de BLAS/Lapack para compilação numpy/scipy com MSVC ou mingwpy para serem testadas em várias arquiteturas de CPU: Pentium4 até skylake?

Bom achado @carlk , eu me lembrei deles anunciando a eliminação de acml e acl de código aberto, mas não me lembrava deles adotando blis/libflame. A licença bsd é uma notícia muito boa! Existe alguma maneira de trabalhar com AMD e shpc em ut Austin para direcionar numpy e Julia?

Consegui fazer a compilação cruzada do libblis.a usando msys2 e a configuração haswell pronta para uso e passando em todos os testes corrigindo os links simbólicos do kernel, mas não consegui compilar o libflame - recebi o mesmo erro "lista de argumentos muito longa" como em minha postagem na lista de discussão do blis-discuss. Além disso, eu pessoalmente não consegui descobrir como vincular a liblis.a a partir do lapack, mas não me esforcei muito.

Com o licenciamento comunitário do MKL, não é possível fornecer uma roda MKL no pypi, as licenças são realmente incompatíveis? Ou simplesmente não é possível construir scipy sem ifort?

Um problema, e provavelmente pertence ao scipy, que não foi mencionado são os arquivos Fortran restantes no scipy. Desculpe a pergunta noob, mas por que devemos usá-los? Para mim, parece que o Fortran, e a falta de um compilador multiplataforma gratuito, é o verdadeiro problema aqui. Afinal, não é isso que o mingwpy pretende resolver. Dado o MKL livre ou algum futuro acl blis/flame mágico, qualquer um com um compilador c poderia construir a pilha scipy dele, não fossem os arquivos *.f.

@mikofski , ótimo saber que blis pode ser compilado com msys2. Isso também é verdade para libflame? Acho que precisamos do libflame para a API Lapack.
Pessoalmente _é_ possível ter um numpy compilado MSVC e usá-lo junto com um scipy compilado mingwpy. Você precisa adicionar -mlong-double-64 aos sinalizadores gcc para garantir que long doubles == double.

É complicado tornar esse comportamento o padrão no gcc, estou jogando com esse problema há uma semana :(

Eu virei amanhã com rodas scipy. Estes serão baseados no Atlas fornecido pelas rodas numpy de @matthew-brett.

No entanto, sou a favor de usar o OpenBLAS agora.

Um problema, e provavelmente pertence ao scipy, que não foi mencionado são os arquivos Fortran restantes no scipy. Desculpe a pergunta noob, mas por que devemos usá-los?

Porque é muito código muito útil e de alto desempenho. E não é apenas BLAS/LAPACK - muito scipy.sparse.linalg , scipy.linalg , scipy.special e scipy.interpolate por exemplo é Fortran. Além disso, o Scipy não é o único projeto com código Fortran, existem outros pacotes como bvp_solver , bem como o próprio código Fortran das pessoas que eles envolveram com f2py.

De fato, bom encontrar Carl.

No entanto: como resolver o problema para comparar 4 diferentes implementações aceleradas de BLAS/Lapack para compilação numpy/scipy com MSVC ou mingwpy para serem testadas em várias arquiteturas de CPU: Pentium4 até skylake?

Isso realmente requer uma estrutura de compilação/teste/benchmark automatizada decente. Não precisamos nos preocupar com arquiteturas de CPU muito antigas (desde que as coisas funcionem lá, tudo bem) e também não com MSVC, eu acho. Mas ainda vai dar algum trabalho para configurar isso corretamente.

@rgommers obrigado!

Olá a todos. Um pensamento: se você quiser publicar várias rodas numpy diferentes criadas com várias bibliotecas de vetores, poderá usar diferentes nomes de pacotes PyPI

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

Registrei 2 para tentar fazer o upload das rodas do Gohlke, mas o PyPI os rejeitou. Você é bem-vindo ao URL.

@hickford por favor não faça isso. Está quebrando a licença MKL redistribuir binários assim (a menos que você tenha uma licença pessoal), e não é a maneira correta de fazer isso. No futuro, podemos querer distribuir alguns sabores via extras ( numpy[atlas] , numpy[openblas] etc.).

Além disso, redistribuir as rodas de outra pessoa no PyPi sem perguntar provavelmente não é a coisa a fazer ....

Mingwpy e quaisquer problemas de fortran que dependam da vinculação ao mesmo tempo de execução c que cpython são limitados por taxa em @carlkl , experimentar o BLIS resolve menos problemas, mas pode ser feito independentemente por qualquer pessoa. Infelizmente, esgotei meu suprimento pessoal de tempo para olhar para o BLIS agora, mas veja #7294.

Tony - muito obrigado por toda sua ajuda, foi inestimável.

Eu adicionei uma compilação do ATLAS posterior (3.11.38) em 64 bits

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

Esta é uma compilação serial (sem thread), por causa de problemas ao compilar 3.11.38 no Windows, mas deve ser um pouco mais rápido que 3.10.1 e está no meu benchmark simples:

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

em comparação com a versão 3.10.1 anterior (veja acima):

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

@tkelman - você pode comparar essa compilação em Julia?

Desculpe entrar aqui com uma nota prévia sobre binários MKL - a Intel oferece o
versão da comunidade que deve permitir a redistribuição, pois é gratuita para todos...
Em 2 de março de 2016, 15h08, "Matthew Brett" [email protected] escreveu:

Eu adicionei uma compilação do ATLAS posterior (3.11.38) em 64 bits

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

Esta é uma compilação serial (sem thread), devido a problemas ao compilar 3.11.38
no Windows, mas deve ser um pouco mais rápido que 3.10.1, e está no meu simples
referência:

Em [2]: %timeit test_dot()
1 loop, melhor de 3: 1,65 s por loop

em comparação com a versão 3.10.1 anterior (veja acima):

Em [10]: %timeit test_dot()
1 loop, melhor de 3: 2,41 s por loop

@tkelman https://github.com/tkelman - você pode comparar essa compilação
Júlia?

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -191431331.

@mrslezak - a licença permite redistribuição, mas torna o redistribuidor responsável por quaisquer taxas legais se a Intel for processada como resultado do uso do software. Além disso, o binário resultante não pode ser licenciado pelo BSD. Veja: http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

Isso poderia ser evitado acrescentando 'desde que tal como está, sem responsabilidade por qualquer
perdas monetárias que podem resultar de seu uso' ou algo que afete?
Em 2 de março de 2016, 18h22, "Matthew Brett" [email protected] escreveu:

@mrslezak https://github.com/mrslezak - a licença permite
redistribuição, mas torna o redistribuidor responsável por quaisquer honorários advocatícios se
A Intel é processada como resultado do uso do software. Também, o resultado
binário não pode ser licenciado pelo BSD. Ver:
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -191505500.

Eu não acho que isso funcionaria, porque nós temos que concordar com a licença da Intel, e a licença da Intel diz que nós somos responsáveis ​​por seus honorários legais se eles forem processados. Acho que podemos exigir que os usuários não processem a Intel em nosso contrato de licença, e talvez, se eles processarem a Intel, e a Intel nos pedir o dinheiro, podemos tentar processar o usuário por essas taxas, mas ainda assim - colocando isso em nosso licença nos afastaria ainda mais do BSD e exigiria que o usuário concordasse explicitamente, o que não é prático no caso de rodas instaladas por pip.

Construir o ATLAS para SSE3 só oferece um benefício de desempenho de 5% em comparação com o SSE2 ATLAS, mas a compilação foi complicada e eu tive que desabilitar os sinalizadores de habilitação mais óbvios para SSE3 e usar apenas -msse3 .

Eu escrevi um e-mail para a lista de discussão numpy propondo implantar essas rodas: https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@matthew-brett Como alguém que dá suporte ao Windows com aplicativos Python, obrigado.

@matthew-brett, adicionei 2 problemas ao seu repositório de scripts de compilação de atlas.
Veja https://github.com/matthew-brett/atlas-build-scripts/issues

O primeiro https://github.com/matthew-brett/atlas-build-scripts/issues/1 é importante, pois numpy-atlas.dll exporta para muitos símbolos e, portanto, impede o uso posterior com mingwpy sem hackear a importação biblioteca.

@matthew-brett desculpe, estive um pouco ocupado para fazer mais benchmarking. Alguma das versões anteriores do atlas era multithread? Não consegui executar a primeira compilação em vários núcleos. A essência deve ser bastante simples de executar, mesmo se você não estiver muito familiarizado com Julia. Ou você estava mais interessado em hardware mais novo do que você tem acesso?

Não se preocupe - não esperava que você largasse tudo e executasse benchmarks.

Na verdade, minha última compilação do atlas não foi multithread - o ATLAS 3.11 precisa de mais algum trabalho para que o threading funcione no Windows aparentemente.

Para os benchmarks, eu estava pensando que seria mais fácil comparar com os outros benchmarks que você executou, e eu só tenho hardware antigo com o Windows ligado - acho que o acerto é muito maior na sua máquina do que na minha.

As rodas do Windows agora estão no pypi: https://pypi.python.org/pypi/numpy/1.10.4

Desculpe Tony - sim, as compilações anteriores do ATLAS 3.10 eram (ou pareciam ser) multithread.

Acho que podemos encerrar este assunto agora. Talvez @matthew-brett você deva transferir seu https://github.com/matthew-brett/np-wheel-builder para a numpy org ou talvez contribua como um PR para o repositório numpy na pasta de ferramentas .

Ralf - alguma sugestão sobre onde np-wheel-builder deve ir? numpy/vendedor talvez?

Eu preferiria um novo repositório separado ( numpy-wheel-builder ?) sob a organização numpy, eu acho. Há sobreposição com numpy-vendor no propósito, mas não muito no código. Esse repositório é bastante grande, é realmente destinado a ser executado no Wine, e a cadeia de ferramentas gcc nele é obsoleta.

Tudo bem comigo - OK com vocês para ir em frente e criar isso?

Tudo bem comigo, embora se for específico do Windows (agora é AFAICT?) então o nome do repositório deve ter "windows" nele :-). Ou então pode ser onde colocamos a infraestrutura análoga para outras rodas também. Eu também ficaria bem em colocá-lo diretamente no repositório numpy em algum lugar se for pequeno o suficiente para que isso faça sentido. Qualquer coisa funciona :-)

O repositório possui binários ATLAS bastante grandes, o que tornaria o repositório numpy grande para um propósito não bom, eu acho.

Que tal win-wheel-builder ?

Que tal windows-wheel-builder . Não sou fã de win ;)

Que tal não torná-lo específico para o Windows e ter a configuração de compilação do macosx e do future manylinux1 wheel tudo em um só lugar?

Caso contrário, +1 para "windows" sobre "win".

Que tal não torná-lo específico para o Windows e ter a configuração de compilação do macosx e do future manylinux1 wheel tudo em um só lugar?

Seria mais fácil mudar as coisas em todas as plataformas. Mas eu esperaria que o OS X e o Linux precisassem apenas de scripts de compilação, enquanto para o Windows temos os enormes binários ATLAS. Se tudo estiver indo para um repositório, os binários do ATLAS podem ser separados de alguma forma (talvez com git-lfs)?

Use armazenamento de arquivos grandes (LFS) no github para binários

@rgommers : Acho que em breve estaremos carregando binários atlas-ou-algum-outro-blas também para Linux e possivelmente osx também (por exemplo, se decidirmos que estamos cansados ​​de acelerar o multiprocessamento).

poderia começar a usar versões do github ou bintray ou algo assim em vez de fazer check-in ... não como se fossem tão grandes até você começar a entrar em compilações openblas habilitadas para DYNAMIC_ARCH ou as combinações equivalentes de várias configurações blis

Que tal colocar o repo como windows-wheel-builder por enquanto, e refatorar/renomear quando estiver mais claro o que vamos fazer com Linux/OSX?

Parece bom para mim.

bem comigo também

Acho que preciso de direitos de administrador para a organização numpy - ou posso dar
alguém administra os direitos do repositório e pode fazê-lo, suponho.

@matthew-brett: Estou muito confuso com a página de permissões do github (e o numpy em particular é uma bagunça), mas se você quiser me tornar um administrador no repositório ou transferir o repositório para mim, posso movê-lo para numpy/

Eu transferi o repositório para @njsmith ...

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

Existe uma conta numpy appveyor? Alguém pode habilitar as compilações do Appveyor para este repositório?

Acho que estamos usando a conta Appveyor do @charris...

Sim, veja aqui https://ci.appveyor.com/project/charris/numpy/history

Na quarta-feira, 16 de março de 2016 às 12h15, Nathaniel J. Smith <
[email protected]> escreveu:

Acho que estamos usando @charris https://github.com/charris 's Appveyor
conta...

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

Na verdade, acabei de criar uma nova conta de grupo para numpy no appveyor (estava querendo fazer isso de qualquer maneira, e isso me levou a realmente fazer isso :-)) e habilitei lá:
https://ci.appveyor.com/project/numpy/windows-wheel-builder

@njsmith Como você conseguiu isso? Da última vez que olhei, alguém precisava pedir aos administradores para criar contas de projetos e a maneira de adicionar outras pessoas não era completamente transparente.

Se a conta funcionar, gostaria de transferir a responsabilidade pelo teste numpy.

@charris : verifique seu e-mail :-). Acabei de criar uma conta individual com numpy-steering-council @googlegroups.com como indivíduo. Eu não sabia que contas de projetos existiam... Queremos uma?

por causa da fila, você provavelmente deseja espalhar projetos diferentes em contas diferentes

A desvantagem de usar o numpy-steering-council mail é que o appveyor envia notificações quando um teste de mesclagem falha. Se o pessoal do appveyor tiver algo melhor hoje em dia, seria bom usar isso, mas dada a bagunça que a interface deles foi no passado, eu não apostaria nisso.

@tkelman Bom ponto. Além disso, se vamos gastar dinheiro para conseguir uma fila mais rápida, provavelmente queremos algo mais oficial.

@charris : Acabei de tentar habilitar o teste de numpy/numpy na nova conta do appveyor, e também desabilitar todas as notificações e também adicionar todas as equipes do github numpy relevantes como administra na conta - vamos ver o que acontece acho...

@matthew-brett: Ocorre-me que a abordagem mais elegante pode ser armazenar as compilações BLAS em algum lugar como numpy/windows-build-tools , mas executar as ferramentas reais de construção da roda do repositório numpy/numpy real como parte da compilação do appveyor - eles poderiam baixar os binários BLAS sob demanda.

Obrigado por todo o grande trabalho! As rodas de janela numpy 1.11.0 serão adicionadas ao pypi em breve? https://pypi.python.org/pypi/numpy

ah sim, possivelmente precisamos descobrir como atualizar nossos procedimentos de lançamento aqui ... IIUC a experiência do usuário agora é que assim que a versão 1.11 do código-fonte foi carregada, todas as máquinas Windows de repente mudaram de rodas de download (yay ) para tentar baixar e compilar a fonte (boo). Acho que a maneira "certa" de fazer isso é que, uma vez que a versão final seja marcada, construímos e carregamos todas as rodas binárias _antes_ de carregar o sdist. Por mais chato que isso seja...

@njsmith isso seria bom, mas alguns minutos de atraso (ou mesmo algumas horas) de atraso estariam bem para mim.

Apenas para esclarecer, os arquivos whl atuais do Windows estão no PyPI para a versão 1.11.0 do ATLAS? Existe um script de compilação que pode ser compartilhado?

Sim, as rodas são construídas contra o ATLAS, mas estamos pensando em mudar para o OpenBLAS quando estivermos confiantes nos resultados.

A compilação é automatizada via Appveyor: https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day . =)

Pode ser possível criar a versão hidden - pelo menos há uma opção no formulário PyPI https://pypi.python.org/pypi?%3Aaction=submit_form e reexibir quando todos os arquivos estiverem prontos.

Infelizmente, o recurso de versão oculta impede que as pessoas obtenham essa versão pela linha de comando, apenas as impede de ver a versão pela GUI do pypi:

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

Eu tentei a instalação do Windows de 64 bits do numpy e isso funciona muito bem, então obrigado a todos que trabalharam nisso.

O que eu estou querendo saber é se ainda existe um plano para fazer a mesma coisa com rodas scipy? Isso está aguardando a decisão de migrar para o OpenBLAS?

Em https://bitbucket.org/carlkl/mingw-w64-for-python/downloads existem algumas rodas de teste do scipy-0.17.0 . Essas rodas foram construídas com mingwpy contra as compilações de numpy de @matthew-brett https://pypi.python.org/pypi/numpy/1.10.4

Em qui, 28 de abril de 2016 às 12:48, carlkl [email protected] escreveu:

Em https://bitbucket.org/carlkl/mingw-w64-for-python/downloads existem
algumas rodas de teste do scipy-0.17.0 . Estas rodas foram construídas com
mingwpy contra @matthew-brett https://github.com/matthew-brett's
compilações de numpy https://pypi.python.org/pypi/numpy/1.10.4

Desculpe se você já disse, e eu perdi - mas você faz algum teste
falhas para essas rodas?

Você está ligando para o ATLAS enviado dentro das rodas numpy?

@matthew-brett, anunciei essas compilações há um mês, mas não me lembro onde. De qualquer forma, essas compilações são vinculadas ao numpy-atlas fornecido por suas rodas numpy.

scipy-0.17.0-cp35-cp35m-win##.whl estão vinculados ao _wrong_ C-runtime msvcrt.dll. Para scipy isso parece estar bem. Os logs de teste estão aqui: https://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

Esse é o registro certo? Tem NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy no final.

Eu queria saber se estamos perto de poder fornecer uma roda scipy, mesmo que ela se vincule perigosamente ao tempo de execução errado do MSVC, mas parece que há muitos erros para esta compilação.

Você recebe menos erros para a compilação de 64 bits? Para a melhor compilação atual contra o openblas 0.2.18 ?

64 bits tem apenas 6 falhas, todas com:

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

Eu sei: isso exige comparação com o OpenBLAS. No entanto, estou preso desde as últimas 4 semanas por vários motivos, como você deve ter notado. Espero que a situação continue a melhorar.

@matthew-brett, eu gostaria de usar compilações numpy MSVC com OpenBLAS. Minhas últimas builds estão aqui:

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

Como se mingwpy, conda-forge, Anaconda e Canopy não fossem suficientes, aqui vem a distribuição Intel para Python e é gratuito para download . Ele inclui apenas as ferramentas numéricas (SciPy, NumPy, Numba, Scikit-Learn) mais alguns extras (interface mpi4py Intel mp e análise de dados pyDAAL) e usa conda.

Não se preocupe, a licença expira em 29/10/16, então essas compilações da Intel são apenas um
teste beta seguido por provavelmente uma taxa de licença MKL+ etc. Compilações do OpenBLAS
continuará sendo a solução de código aberto, então obrigado por fornecer esses
constrói.
Em 28 de abril de 2016 19:21, "Mark Mikofski" [email protected] escreveu:

Como se mingwpy, conda-forge, Anaconda e Canopy não fossem suficientes, aí vem
a distribuição Intel para Python
https://software.intel.com/en-us/python-distribution e é gratuito para
download
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation.
Inclui apenas as ferramentas numéricas (SciPy, NumPy, Numba, Scikit-Learn)
além de alguns extras (interface mp da Intel mpi4py e análise de dados pyDAAL) e
usa conda.

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

Para 1.11.1, parece que há uma roda do Windows ausente no PyPi para Python 3.5 amd64.

Existe uma razão específica para isso? Se eu for para 1.11.0 (https://pypi.python.org/pypi/numpy/1.11.0), a roda estará lá.

Obrigado pelo relatório - acho que devemos ter carregado muito cedo e, portanto, antes de todas as rodas serem construídas. Carreguei a roda que faltava. Parece que precisamos de um teste para garantir que isso não aconteça novamente.

Carreguei a roda que faltava.

Acabei de testar, e funciona muito bem!

Muito obrigado por todo o trabalho feito para disponibilizar as rodas do Windows.

Fechando o problema - as rodas estão disponíveis nos últimos lançamentos.

Entendo que esta questão está encerrada, mas acredito que devemos considerar reabri-la.

Isso continua sendo um problema para usuários do Windows que tentam executar sua pilha científica sem precisar recorrer ao conda. Ainda preciso usar as compilações @cgohlke 'MKL' para ver esse problema relacionado ao scipy que permanece aberto. Embora as rodas estejam sendo criadas, sem serem compatíveis com o scipy, elas não são utilizáveis ​​para muitos.

@waynenilsen você tem as instruções para instalar as novas rodas no tópico da lista de discussão que está vinculado ao problema que você acabou de mencionar:

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

Então se você fizer

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

isso deve funcionar para você.

Não há mais nada a ser feito para o Numpy, então o problema está encerrado. O
O problema do Scipy ainda está em aberto e provavelmente será resolvido no próximo
lançamento.

Isso funciona muito bem para mim @Juanlu001 Estou realmente ansioso para quando isso estiver no pypi!