Numpy: Pypi의 Windows 휠 패키지(.whl)

좋은 말씀입니다. 그리고 실제로 @carlkl 이 이를 실현하기 위해 뒤에서 많은 노력을 기울이고 있습니다. 나는 우리가 이제 거의 다 왔다고 생각합니다 - @carlkl - 언제 공개할 것 같습니까?

컨텍스트: 이것이 사소하지 않은 이유는 연결한 바이너리가
Intel의 독점 런타임 및 수학 라이브러리에 의존하기 위해
재배포를 복잡하게 만듭니다.

binstar에 최신 OpenBLAS 기반 numpy 및 scipy 휠을 배포했습니다. 다음을 사용하여 설치할 수 있습니다.

핍 설치 -i https://pypi.binstar.org/carlkl/simple numpy
핍 설치 -i https://pypi.binstar.org/carlkl/simple scipy

이것은 python-2.7 및 python-3.4에서 작동합니다. 바퀴는 '실험용'으로 표시됩니다. 피드백을 환영합니다.

광범위한 테스트를 원한다면 이것을 목록으로 보내야 합니다 :-)

2015년 1월 22일 목요일 오후 8시 54분에 carlkl [email protected] 에서 다음과 같이 썼습니다.

binstar에 최신 OpenBLAS 기반 numpy 및 scipy 휠을 배포했습니다.
다음을 사용하여 설치할 수 있습니다.

핍 설치 -i https://pypi.binstar.org/carlkl/simple numpy
핍 설치 -i https://pypi.binstar.org/carlkl/simple scipy

이것은 python-2.7 및 python-3.4에서 작동합니다. 바퀴는 다음과 같이 표시됩니다.
'실험적'이다. 피드백을 환영합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -71096693.

나다니엘 J. 스미스
박사후 연구원 - 정보학 - University of Edinburgh
http://vorpus.org

fwiw 저는 개인적으로 공식 바이너리를 제공하기 전에 win64의 기본 정수 크기를 변경하고 싶습니다. 하지만 제가 마지막으로 제안했을 때도 약간의 저항이 있었습니다. 또한 아마도 이미 너무 늦었을 것입니다. (

또한 Openblas에 대해 말하면 누군가 디버깅을 좋아하지만 지쳤습니다 (openblas로 scipy를 깨는 동일한 실패처럼 보입니다).

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)

사용된 OpenBLAS 버전은 0.2.12입니다. 나는 아직 이 버전에서 심각한 문제를 경험하지 않았습니다.

scipy 실패는 https://gist.github.com/carlkl/b05dc6055fd42eba8cc7에 복사됩니다.

http://sourceforge.net/p/mingw-w64/bugs/367 로 인한 32비트 전용 numpy 오류

======================================================================
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)

나는 win64 정수 크기를 변경하는 것에 동의하지 않지만 그것이
바퀴에서 분리되어야 하는 별도의 문제. 이랬다면
처음으로 win64 numpy 빌드가 널리 사용 가능해지면
그것들을 연결하는 것이 합리적이지만 이 시점에서 이미 수많은 사용자가 있습니다.
몇 년 동안 그들은 cgholke나 anaconda 등을 사용하고 있습니다. 그래서 하자
그것을 독립적인 토론으로 취급합니까?

(엄밀히 말하면 backcompat break지만 그래도 그럴싸해 보인다.
실제로 감소하므로
플랫폼 간 비호환성 -- 모든 이식 가능한 코드는 64비트를 처리해야 합니다.
dtype=int 이미.)

2015년 1월 22일 목요일 오후 8시 59분, Julian Taylor [email protected]
썼다:

fwiw 개인적으로 기본 정수의 크기를 변경하고 싶습니다.
우리가 실제로 공식 바이너리를 제공하기 전에 win64
내가 마지막으로 그것을 제안했을 때 저항도, 아마도 아나콘다와
다른 타사 바이너리는 이미 너무 늦었습니다.

또한 Openblas에 대해 말하면 디버깅을 좋아하는 사람이 있습니다. 나는 그것에 지쳤습니다.
(openblas로 scipy를 깨는 것과 동일한 실패처럼 보입니다):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== 크기 16의 잘못된 읽기
==31931== 0x7B28EB9에서: ddot_k_NEHALEM(/usr/lib/libopenblasp-r0.2.10.so에서)
==31931== 0x6DBDA90 기준: DOUBLE_dot(arraytypes.c.src:3127)
==31931== 0x6E93DEC 기준: cblas_matrixproduct(cblasfuncs.c:528)
==31931== 0x6E6B7B3 기준: PyArray_MatrixProduct2(multiarraymodule.c:994)
==31931== 0x6E6E29B 기준: array_matrixproduct(multiarraymodule.c:2276)

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -71097408.

나다니엘 J. 스미스
박사후 연구원 - 정보학 - University of Edinburgh
http://vorpus.org

저도 이것에 관심이 있습니다. 프로세스를 지원하는 방법이 있습니까?

OpenBLAS는 INTERFACE64=1 로 컴파일할 수 있고 numpy는 첫 번째 시도에서 -fdefault-integer-8 로 컴파일할 수 있습니다.

그냥 머리 위로. blas에서 64비트 정수를 사용하는 것은 끔찍한 생각입니다. 그 길을 너무 멀리 떨어지기 전에 멈추십시오. 내가 가서 수정하기 전에 Matlab과 Julia는 이 작업을 수행했으며 blas에서 기존의 32비트 정수를 가정하는 모든 타사 라이브러리를 중단합니다.

우리가 지난 ~5개월 동안 Julia에서 수행한 작업은 실제로 openblas의 모든 기호 이름을 변경하여 64비트 int 버전에 대해 _64 접미사를 추가하는 것입니다. 그렇게 하면 선형 대수학을 수행할 수 있습니다. 원하는 경우 정말 거대한 배열에 있지만 외부 라이브러리를 동일한 프로세스에 로드하면 이름 섀도잉과 잘못된 ABI로 dgemm 호출을 시도하여 segfault가 발생하지 않습니다.

여러분, Numpy에서 사용할 수 있는 바퀴 파일에 대한 업데이트가 있습니까?

내가 지금 알고 있는 것은 아닙니다.
2015년 6월 25일 오전 4시 27분에 "guyverthree" [email protected] 이 작성했습니다.

안녕하세요 여러분, 사용 가능한 바퀴 파일에 대한 업데이트가 있습니까?
넘피?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -115215236.

@guyverthree Christoph Gohlke는 Intel의 MKL을 바퀴로 사용하여 NumPy를 출시 하고 있습니다.

또한 NumPy 바퀴에 대한 내 블로그 게시물을 참조하십시오. Carl Kleffner의 수정된 mingw-w64 도구 체인 과 Zhang Xianyi의 GotoBLAS OpenBLAS 포트를 사용하여 Dropbox에서 NumPy 휠을 만들었습니다. Olivier Grisel은 내가 게시한 OpenBLAS Google 그룹 스레드 에서 사용된 것과 동일한 단계를 반복하도록 NumPy 빌드봇을 수정하는 데 도움을 찾고 있었습니다.

내 최신 버전은 binstar.org에서 구할 수 있지만 anaconda.org가 현재 선호되는 새로운 이름인지 확실하지 않습니다.
py-2.6 .. 3.4(32/64비트)용 휠은 약 2개월입니다.

• numpy-1.9.2
• scipy-0.15.1
• scikit-이미지-0.11.2

내 https://bitbucket.org/carlkl/mingw-w64-for-python 및 다소 최근의 OpenBLAS로 빌드하십시오.
핍 설치:

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

+1 @carlkl 그리고 이것이 치즈 공장의 NumPy 빌드 에도 추가될 수 있기를 바랍니다.

+1 나도 이런 일이 일어나는 것을 보고 싶다.

IMHO: 이 빌드가 승인되기 전에 해결해야 할 문제가 적어도 세 가지 있습니다.

• numpy 저장소에 대한 mingwpy 패치를 다시 만들어야 합니다.
• 아직 수동으로 빌드하는 것 외에 빌드 메커니즘이 없습니다.
• 바이너리가 MKL DLL에 대해 하드 링크되어 있기 때문에 많은 타사 Windows 패키지(C. Gohlke에 의해 배포됨)는 명시적으로 numpy-MKL에 의존합니다. scipy는 이제 scipy BLAS/Lapack 구현에 대한 암시적 종속성을 위한 메커니즘을 제공하므로 이는 향후 변경될 수 있습니다. 따라서 (numpy-MKL 및 scipy-MKL) 또는 (numpy-OpenBLAS 및 scipy-OpenBLAS)를 설치하면 향후 다른 모든 패키지에 충분합니다.

@carlkl : FWIW, 저는 @cgohlke 의 패키지에 대해 별로 걱정하지 않습니다. 그러면 저절로 해결될 것입니다. 그리고 저는 멋진 빌드 메커니즘이 있다는 사실에 대해 별로 걱정하지도 않습니다. 단계를 문서화하는 텍스트 파일이 있는 한 수동 빌드는 괜찮습니다.

내가 걱정하는 주요 문제는 지속 가능성입니다. 이 항목을 업스트림으로 가져올 수 없으면 새 버전의 gcc/mingw-w64/msvc가 나올 때마다 패치를 다시 확인하고 다시 수행해야 합니다. 아마 일어나지 않을 것입니다. 우리는 빌드 제공을 시작하는 함정에 빠지고 싶지 않지만, 시간이 지남에 따라 이를 수행하기 위해 까다롭고 오래된 컴파일러를 처리해야 하므로 이는 점점 더 번거로워집니다.

이것이 제가 이 업스트림을 지원하기 위해 자금을 모으려고 노력한 이유입니다... +1은 훌륭하고 모든 것이지만 누군가가 돈을 기부하고 싶거나 일반적으로 파이썬에 gcc를 사용할 수 있도록 만드는 데 관심이 있는 회사를 알고 있는 경우 Windows에서 확장 프로그램을 사용하고 이메일을 보내주세요 :-) ([email protected])

$$가 없지만 여전히 돕고 싶다면 mingw-w64에 패치를 보내 sin 및 cos와 같은 초월 함수에 대한 지원을 개선하는 것이 좋습니다. (MSVC ABI는 x87 FPU 단위가 어떻게 구성되어야 하는지에 대해 다른 모든 사람들과 의견이 일치하지 않아 대부분의 무료 소프트웨어 수학 함수가 제대로 작동하지 않는 것으로 나타 났습니다.) 다행히 Android의 " bionic" libc 이므로 ABI 문제에 대한 수학적 마술이나 깊은 통찰력이 필요하지 않습니다. 관련 소스 파일을 찾아 추출한 다음 올바른 위치의 mingw-w64 트리에 놓는 대부분의 기계적 문제일 뿐입니다. 관심 있는 사람이 있으면 이에 대한 자세한 내용도 제공할 수 있습니다.

이것이 numfocus가 자금을 조달해야 하는 종류의 것 아닌가요? 그렇지 않은 경우 다시 돌아가서 PSF에 지원하는 것을 다시 볼 수 있습니다.

우리는 얼마나 많은 돈을 이야기하고 있습니까?

+1 Windows용 휠을 PyPI https://pypi.python.org/pypi/numpy 에 게시하십시오.

기본 제공되는 Python Windows 설치에서 pip install numpy 를 시도하면 악명 높게 도움이 되지 않는 오류 메시지 "vcvarsall.bat를 찾을 수 없습니다"가 표시됩니다.

+1은 Windows 사용자에게 정말 도움이 됩니다.

이 때문에 https://github.com/glumpy/glumpy 에서 재생할 수 없습니다. Numpy가 Windows에서 작동하도록 하는 수동 빌드 단계는 무엇입니까? AppVeyor 작업 이 있는 것 같으므로 GitHub에 아티팩트를 업로드하는 데 문제가 없습니다.

지금 당장은 Windows에서 빠른 BSD 라이선스 버전의 numpy를 구축하는 것이 말 그대로 불가능합니다. 우리는 이 문제를 해결하기 위해 노력하고 있지만 기술적 한계입니다. +1은 어느 쪽이든 영향을 미치지 않습니다. (appveyor 작업은 Windows에서 빌드되지만 실제 작업에 실제로 적합하지 않은 대체 최적화되지 않은 선형 대수학 라이브러리를 사용합니다.) 이 정렬이 완료될 때까지 Christoph Gohlke의 웹사이트에서 휠을 다운로드하거나 Anaconda를 사용하는 것이 좋습니다. 또는 다른 과학적 파이썬 배포판 .

@njsmith 좀 더 구체적으로 말씀해 주시겠습니까? 작동하지 않는 정확한 명령을 사용하는 것이 좋습니다. 현재 이 항목은 실행할 수 없습니다.

저는 '불가능'이 너무 강하다고 생각합니다. 그러나 확실히 일반적인 일반적인 방법은 아직 없습니다. 현재 상태에 대한 위키 페이지를 여기에 올렸습니다. https://github.com/numpy/numpy/wiki/Whats-with-Windows-builds . 관심 있는 분들은 자유롭게 수정/수정해주세요.

@techtonik : "작동하지 않는 정확한 명령"은 없습니다. 문제는 우리가 필요로 하는 기능을 조합한 컴파일러가 없다는 것입니다. mingwpy.github.io는 그러한 컴파일러를 만들기 위한 우리의 노력의 현재 상태를 문서화합니다.

@matthew-brett 좋아요. We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler. scipy용이죠? numpy에 왜 필요한가요?

@njsmith http://mingwpy.github.io/issues.html 은 좋은 분석이 포함된 멋진 이니셔티브입니다. 업스트림(Python)이 절대 지원하지 않는다는 점은 아쉽습니다(MSVS를 맹목적으로 사용하는 경우). 하지만 현재 상황에서 명확한 그림을 얻으려고 노력하고 있습니다.

1. "오픈 작업을 위한 오픈 툴체인"의 문제입니까 아니면 MSVS가 실제로 numpy의 C 부분을 컴파일할 수 없습니까?
2. mingw로 컴파일된 확장에 여전히 충돌이 있습니까?

지금은 초점을 좁히기 위해 Python 2.7 + Win32만 있다고 가정하겠습니다. 성능은 필요하지 않지만(그곳에서 테스트하기 위해 응용 프로그램을 실행하고 싶습니다) 해당 성능에 대한 벤치마크 데이터가 필요합니다.

그렇다면 PyPI에서 Windows 휠을 사용할 수 있도록 이 구성에 대해 수행해야 하는 다음 작업은 무엇입니까?

@techtonik , 이제 https://anaconda.org/carlkl/numpy 및 https://anaconda.org/carlkl/scipy에서 numpy 및 scipy 휠의 예비 버전을 사용할 수 있습니다. 성능은 거의 gohlke의 +MKL 휠만큼 좋습니다. 나는 집에서 내 윈도우 박스와 함께 segfaults를 만나지 않았다.

이 접근 방식과 관련된 몇 가지 문제가 논의되었으며 http://mingwpy.github.io (공사 중)에 요약되어 있습니다. mingw-w64 기반 툴체인 _mingwpy_와 OpenBLAS의 조합은 Windows 플랫폼으로 가는 길입니다.

_mingwpy_는 가장 잘 알려진 mingw-w64 기반 툴체인(예: _mingw-builds_, _tdm_ ...

이 모든 것과 그 이상은 https://github.com/mingwpy/mingwpy.github.io에 설명되어 있습니다. 문제 또는 PR을 자유롭게 여십시오.

@techtonik : 업스트림 python.org의 입장에 대한 심각한 오해/오해라고 생각합니다. 나는 그들이 Windows CPython 지원의 분열을 여러 호환되지 않는 ABI로 홍보하는 것을 거부한다고 말하고 싶습니다(그리고 이에 동의합니다). 공식 업스트림 Windows 빌드를 유지 관리하는 Steve Dower는 mingwpy가 이러한 빌드와 호환되도록 하는 방법을 알아내는 데 도움을 주었습니다.

pypi에 numpy 휠을 설치하기 위한 IMO의 전제 조건은 (a) 성능, (b) 유지 관리 가능, (c) 적절하게 라이선스가 부여되어야 한다는 것입니다. 프로젝트에서 다른 기준 세트를 적용하기를 원하면(즉, 휠에 끔찍한 성능을 제공하기 위해 노력해야 함) 다음 단계는 기준이 더 나은 경우를 만드는 numpy 메일링 리스트에 이메일을 보내는 것입니다.

MSVS는 numpy 자체를 빌드할 수 있지만 적절하게 라이선스가 부여된 고품질 BLAS 구현을 빌드할 수는 없습니다. 업스트림 mingw-w64는 numpy + BLAS(패치 포함)를 빌드할 수 있지만 업스트림 CPython과 함께 사용하려고 하면 결과가 충돌합니다. Carl의 mingwpy 도구 체인은 numpy + BLAS(패치 포함)를 빌드할 수 있으며 결과는 일부 버전의 python(3.5는 아님)에서 작동하지만 도구 체인은 취약하고 현재 상태에서 유지 관리할 수 없습니다. 말 그대로 Carl을 제외하고는 아무도 그것이 어떻게 만들어 졌는지 또는 그것을 다시 만들 수 있는지 모릅니다. numpy 프로젝트의 어느 누구도 이러한 제한 사항이 있는 도구 체인을 사용하여 "공식 빌드"를 제공하는 데 전념할 준비가 되어 있지 않으므로 이를 수정하는 데 집중하고 있습니다.

Windows에는 고품질 numpy 빌드에 대해 간단하게 사용할 수 있는 여러 소스가 있습니다. 정말 궁금합니다. 왜 PyPI에 있을 수 있도록 낮은 품질의 빌드를 던져야 한다고 고집하십니까?

@njsmith 내 사용 사례(개발자 리소스 투자 자체를 정당화할 수 없음을 인정함)는 matplotlib 에 의존하는 PyPI에 매우 간단한 패키지를 배포하는 것이라고 말하고 싶었습니다. numpy 에 따라 다릅니다.

내 사용 사례의 경우 성능은 문제가 되지 않지만 Windows 사용자가 matplotlib , numpy 등을 재귀적으로 설치하는 패키지를 pip install ____ $ 하면 훨씬 쉽습니다. 특히 Python 빌드 생태계를 이해하지 못하는 사용자를 위해 설치할 URL을 알려주는 것보다 설명하십시오. 따라서 대부분 설치 지침을 단순화하기 위한 것입니다.

다시 말하지만, 제 경우를 정당화하려는 것이 아니라 단지 여러분이 궁금해 하는 대로 공유하고 싶었습니다.

@johnthagen : 아, 물론입니다. 걱정 마세요! 나는 이것이 일반적으로 바람직한 이유를 완전히 이해합니다. 이 댓글에서 내가 심술궂게 느껴진다면 그것은 바로 나와 다른 사람들이 이 문제를 해결하기 위해 지난 1년 동안 엄청난 시간을 보냈기 때문입니다 :-). 나는 단지 @techtonik 에게 물어본 것입니다. 왜냐하면 그들이 "나는 단지 하나의 작은 응용 프로그램을 시도하고 싶기 때문에 성능은 신경 쓰지 않습니다"라고 말하는 것처럼 들렸기 때문입니다. 그러나 그들이 단지 하나의 작은 응용 프로그램을 시도하고 싶다면 나는 그들이 PyPI 부분에 관심을 갖는 이유를 알고 있습니다 :-)

(우리가 pypi에 올리는 모든 휠은 수만 명의 사람들이 즉시 사용하기 시작한다는 사실을 명심하는 것이 중요합니다. 대부분은 이 스레드를 읽지 않습니다. 따라서 우리는 무엇이든 우리는 실제로 광범위한 사용 사례에 대해 광범위하게 사용할 수 있다고 제시했습니다.)

ATLAS를 사용하여 Python 2.7용 32비트 numpy 휠을 출시하는 것은 본질적으로 간단할 것이라고 생각합니다. SSE2여야 하므로 SSE 지침 없이 충돌이 발생하지만 이는 극히 일부의 사용자에게만 영향을 미칩니다. 이를 위해 현재 릴리스 도구 모음을 사용할 수 있습니다. 이것은 pip가 32비트용 바이너리 휠을 제공하지만 64비트용 소스 설치로 폴백한다는 것을 의미합니다. 유용할까요?

@njsmith 정보 감사합니다! 모두의 노고에 경의를 표합니다 :)

ATLAS를 사용하여 Python 2.7용 32비트 numpy 휠을 출시하는 것은 본질적으로 간단할 것이라고 생각합니다. SSE2여야 하므로 SSE 지침 없이 충돌이 발생하지만 이는 극히 일부의 사용자에게만 영향을 미칩니다. 이를 위해 현재 릴리스 도구 모음을 사용할 수 있습니다. 이것은 pip가 32비트용 바이너리 휠을 제공하지만 64비트용 소스 설치로 폴백한다는 것을 의미합니다. 유용할까요?

@matthew-brett 현재 numpy-vendor 설정이 깨졌습니다. fromfile 에 segfault가 있습니다. 파일 핸들 처리가 엉망이 되었고 이것이 Wine 버전, Ubuntu 버전의 변경 또는 (아마도) numpy 자체의 변경으로 인한 것인지 확실하지 않습니다. 나는 그것에 더 많은 시간을 보내는 것은 시간 낭비라고 말하고 싶습니다. 그 시간을 mingwpy에 넣는 것이 훨씬 더 생산적입니다.

OpenBLAS(Int32 Windows 64, v0.2.15 사전 컴파일된 바이너리) 및 MKL(MKL의 커뮤니티 라이선스 사용, 즉 무료 배포)로 컴파일된 NumPy 1.10.4가 있습니다. 하지만... SciPy를 컴파일할 수 없습니다. 누군가 이 문제를 해결하는 방법에 대한 아이디어가 있는 경우 gfortran 컴파일러 "fortan 컴파일러를 찾을 수 없음"을 찾는 부분이 작은 것 같습니다. Ananconda는 이러한 빌드를 직접 플러그인으로 지원하므로 ifort.exe를 사용하고 있습니다. Microsoft Visual Studio Community 2015를 사용하여 Python 3.5용으로 컴파일했습니다. 배포용으로 패키징하는 방법을 알아낼 수 있는 사람이 있다면 github 또는 anaconda의 웹사이트에 업로드하겠습니다. 감사합니다.

@mrslezak : 아마도 가장 좋은 방법은 scipy 개발자 메일링 리스트에 게시하거나 임의의 기존 버그에 게시하는 것보다 scipy에서 새 버그를 여는 것입니다 :-)

정말 궁금합니다. 왜 PyPI에 있을 수 있도록 낮은 품질의 빌드를 던져야 한다고 고집하십니까?

야크 면도에 지쳤기 때문입니다. 나는 사람들이 성과를 원하고 누군가가 그것을 위해 자원을 가지고 있다는 것은 좋은 일이라는 것을 압니다. 하지만 개인적으로 이 작업을 완료하는 데 따르는 복잡성은 엄청나므로 여러분이 이 일을 할 수 있기를 바랄 뿐입니다. 절대 일어나지 않을 수도 있고 2~3년 안에 일어날 수도 있습니다. 이 기간 동안 사람들은 계속해서 벽에 부딪히고 NumPy를 간접 종속성의 직접 설치가 필요한 PyPI의 모든 Windows 바이너리 다운로드에 비례하여 시간을 낭비합니다.

헉. 아마 내가 평생 쓴 가장 긴 영어 문장일 것이다. =)

@techtonik - 나는 당신의 좌절을 공유합니다. 우리 중 많은 사람들이 이에 대해 좌절감을 느끼는 것 같습니다.

@carlkl - 여기에서 귀하의 피드백을 원합니다.

우리에게 numpy 윈도우 휠을 올려야 한다는 강한 압력이 분명히 있습니다. 다음은 몇 주 전에 모든 플랫폼에서 가장 많이 다운로드된 휠 목록입니다. https://gist.github.com/dstufft/1dda9a9f87ee7121e0ee . matplotlib, scikit-learn 및 pandas 창 휠은 위치 3, 4 및 5에 있습니다. numpy 창 휠에 대한 큰 시장이 있을 것입니다.

테이블에 있는 질문은 다음과 같습니다.

1) 단기에서 중기(예: 6개월)에 pypi에서 작동하고 거의 최적의 numpy 휠을 얻는 데 전념할 수 있습니까? 이에 대한 대답은 '예'입니다.
2) 그 동안 다른 사람들이 빌드할 수 있도록 최적화되지 않은 numpy 휠을 올릴 가치가 있습니까?

질문 2가 더 어렵습니다. "최적화되지 않음"은 느리거나(최적화된 blas/lapack 없음) 지원하기 어렵다(6개월 내에 빌드를 반복할 수 있다는 보장 없음)를 의미할 수 있습니다.

"느림"에 반대하는 주장을 볼 수 있습니다. 휠이 Windows에서 작동하기 시작할 때 "어카운트에서 pypi에서 numpy 휠을 다운로드하지 않음"에 대한 답변으로 스택오버플로 질문을 즉시 트리거하지 않도록 주의해야 합니다. 나는 그 대답이 합리적이고 우리에게 상처를 줄만큼 오래 갈 것이라고 생각합니다.

최적화되지 않은 의미, 빌드 프로세스를 지원하기 어렵습니다. 우리가 꽤 빨리 장기적인 솔루션을 찾는 데 정말로 전념한다면 함께 살 수 있다고 생각합니다.

얼마 전 저는 Windows용 ATLAS 바이너리를 구축했습니다. http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

이 ATLAS 바이너리를 사용하여 모든 테스트를 통과하는 numpy 바이너리를 이미 구축할 수 있다고 생각하는 것이 맞습니까?

어떤 경우에, 우리는 왜 그것들을 올려놓지 않습니까?

1) 단기에서 중기(예: 6개월)에 pypi에서 작동하고 거의 최적의 numpy 휠을 얻는 데 전념할 수 있습니까? 이에 대한 대답은 '예'입니다.

그렇게 되기를 바랍니다. 그렇지 않으면 그때쯤이면 mingwpy 제안에 예기치 않은 문제가 발생하거나 그것이 가능하게 하는 것에 대해 캐시하지 않았을 것입니다. :)

2) 그 동안 다른 사람들이 빌드할 수 있도록 최적화되지 않은 numpy 휠을 올릴 가치가 있습니까?

ATLAS 빌드가 Cygwin으로 완료된 것 같습니까? 아니면 그냥 디렉토리 이름을 지정하고 MingwPy의 일부 버전을 사용했습니까?

내 ATLAS 빌드는 Cygwin으로 완료되었지만 Cygwin.dll에 연결되지 않으므로 MSVC로 빌드하는 것이 안전할 것이라고 생각합니다.

mingwpy는 문제가 없지만 시간이 필요합니다. gcc 도구 체인, OpenBLAS를 빌드한 다음 다른 변형으로 numpy/scipy를 빌드하려면 빌드 및 테스트 시간이 걸립니다. 그리고 모든 빌드 스크립트를 먼저 게시하지 않고 바이너리를 게시하지 않을 것입니다. gcc-5.3.0을 기반으로 하는 mingwpy와 OpenBLAS가 거의 준비되었습니다. 다음 단계는 이를 기반으로 numpy 및 scipy 바퀴를 만드는 것입니다.

이 토론과 numpy 스레드 "Multi-distribution Linux wheel - please test"에 대한 최신 기여는 OpenBLAS가 OpenBLAS를 기반으로 하는 Windows numpy 휠을 배포할 수 있는 품질을 가지고 있는지 여부에 대한 질문으로 이어집니다. 그러나 대신 아틀라스를 사용하는 것이 더 나은 솔루션인지 확신할 수 없습니다. 테스트 단계에서 먼저 두 가지 변형으로 numpy 휠을 빌드해야 할 수도 있습니다.

나는 추측하고 / 우리가 OpenBLAS가 수용 가능한 품질이라는 단계를 어떻게든 얻을 수 있기를 바라고 있습니다. 그러나 그때까지는 ATLAS numpy 휠로 시작하는 것이 합리적으로 보입니다. 적절한 시기에 OpenBLAS 휠로 전환할 수 있을 것으로 기대하고 있습니다. 32비트 빌드에 대해 SSE2 검사를 입력해야 할 수도 있습니다. http://mingwpy.github.io/blas_lapack.html#atlas

PyPI 페이지 상단에 진행 상자를 배치하면 더 많은 사람들이 문제에 참여할 수 있습니다(이니셔티브를 지원하기 위해 기부할 수 있는 사람들 포함). 상자에는 현재 전략, 승인 기준(성능 테스트에 대한 링크?), 상태 및 최종 버전이 준비되었을 때 수행할 작업(주 버전을 높이시겠습니까?)이 나열될 수 있습니다.

@matthew-brett 무언가를 던지겠다는 당신의 제안이 실행 가능한지 아직 확실하지 않습니다. 어떤 컴파일러를 사용하시겠습니까? MingwPy라면 어떤 순서로 할 것인지에 대한 명확한 계획이 있고 지금은 너무 이른 것 같습니다. 다른 gcc인 경우 정적 연결 문제와 DLL 문제 배포로 돌아갑니다.

내 아이디어는 MSVC를 사용하여 ATLAS로 numpy를 컴파일하는 것이 었습니다. 물론 그것은 scipy에게는 작동하지 않지만 적어도 사람들은 창 바퀴를 배송하는 것을 시작할 수 있습니다.

방금 시도했는데 unresolved external symbol __gfortran_compare_string 형식의 오류가 발생하여 ATLAS 바이너리에 gfortran 런타임에 대한 일부 매달려 있는 참조가 있다고 가정합니다. @carlkl - 디버그 방법에 대한 제안 사항이 있습니까?

다른 컴파일러에서 오는 정적 개체 파일을 혼합하는 것은 악마가 성수를 피하는 것처럼 피해야 하는 것입니다. 어떤 경우에는 작동하지만 다른 컴파일러 조합 세트에서는 실패합니다.
BTW: MS 자체는 다른 버전의 Visual Studio에서 정적 개체를 혼합하는 것을 공식적으로 지원하거나 권장하지 않습니다.

몇 주 전에 이 질문이 뜨면서 몇 가지 테스트를 했습니다. mingwpy가 만든 정적 라이브러리 npymath.a를 MSVC 컴파일러와 함께 사용할 수 있습니까? 원칙적 으로 gcc 런타임 라이브러리에서 선택한 일부 개체가 이 라이브러리에 추가되면 작동할 수 있습니다. 나는 그러한 접근 방식이 불안정하고 취약하다는 결론에 도달했습니다.

아틀라스가 numpy 휠을 빌드하기 위한 옵션이라면 DLL로 빌드하려고 합니다. 이의가 있습니까?

다른 컴파일러에서 오는 정적 개체 파일을 혼합하는 것은 악마가 성수를 피하는 것처럼 피해야 하는 것입니다.

나는 https://mingwpy.github.io/motivation.html (Why page) 에 동적 로드 모듈에 대한 문제에 대한 매우 간단하고 직접적인 설명이 부족하다고 생각합니다. 나는 다른 언어로 작성된 .dll에서 로드되는 플러그인을 기반으로 하는 파일 관리자가 Windows에 기본이며 "정확히 동일한 컴파일러"에 대해 이 문제가 없는 Far Manager와 이야기했습니다. Python이 왜 그것을 가지고 있는지 궁금합니다. 또한 .dll에서 모듈을 로드합니다.

@techtonik , 내 의견은 다른 컴파일러에서 생성된 개체 파일을 단일 바이너리 파일(DLL 또는 EXE)로 연결하는 것에 관한 것입니다. 이것이 내가 _정적 개체 파일을 혼합하는 것을 의미하는 것입니다. 그러한 접근 방식은 주의해서 다루면 잘 테스트된 일부 상황에서 작동 _할 수_ 있습니다. 그러나 바이너리를 빌드하는 강력한 방법은 아닙니다.

공통 프로세스 공간에서 다른 컴파일러의 DLL 상호 운용성은 완전히 다릅니다. 일반적으로 이러한 접근 방식은 일반적으로 잘 작동합니다. 파일 설명자를 공유하는 경우 이러한 바이너리가 동일한 MS 런타임 DLL에 연결되어 있는지 확인해야 합니다. 처리해야 하는 다른 가능한 ABI 문제도 있습니다. 물론 사용 중인 컴파일러에 따라 디버깅을 위해 다른 디버거 세트가 필요합니다.

minwgpy는 표준 MSVC CPython 빌드 내부에서 사용하기 위해 mingw-w64의 도움으로 Python 확장 빌드를 지원하는 프로젝트입니다.

확인 - ATLAS 빌드에 대해 MSVC 링크를 사용하여 numpy를 빌드했습니다.

여기에서 ATLAS 빌드:

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

ATLAS dll을 빌드하는 방법에 대한 몇 가지 기본적인 지침이 있습니다.

모든 numpy 테스트는 f2py 스크립트 검사를 제외하고 통과합니다. 제 생각에는 이는 무난한 실패라고 생각합니다.

마지막 단계는 휠 내부에 동적 라이브러리를 제공하는 것입니다. @carlkl - 현재 가장 좋아하는 방법은 무엇입니까?

반갑습니다. 휠을 만드는 방법도 알고 싶습니다.
바이너리 포함 - MKL 빌드를 게시하고 다른 사람들이 OpenBlas를 테스트하도록 할 수 있습니다.
하나.
2016년 2월 11일 오후 1시 28분에 "Matthew Brett" [email protected] 이 다음과 같이 썼습니다.

확인 - ATLAS 빌드에 대해 MSVC 링크를 사용하여 numpy를 빌드했습니다.

여기에서 ATLAS 빌드:

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

ATLAS를 구축하는 방법에 대한 몇 가지 기본적인 지침이 있습니다.
DLL.

모든 numpy 테스트는 f2py 스크립트 검사와 별도로 통과합니다.
양성 실패.

마지막 단계는 휠 내부에 동적 라이브러리를 제공하는 것입니다. @carkl
https://github.com/carlkl - 현재 가장 좋아하는 방법
저것?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -183021728.

마지막 단계는 휠 내부에 동적 라이브러리를 제공하는 것입니다.

그리고 SSE2 수표와 우아한 구제금융?

@mrslezak - 가장 쉬운 방법은 multiarray.pyd를 가져오는 동안 프로세스 공간에 원자적으로 로드되기 때문에 numpy/core 폴더에 넣는 것입니다.

마지막 단계는 휠 내부에 동적 라이브러리를 배송하는 것입니다.

@matthew-brett: 이 작업을 수행하는 "올바른" 방법은 문서가 매우 열악하지만 아마도 실행할 수 있는 SxS 어셈블리를 통하는 것이라고 99% 확신합니다. 너무 많이 읽고 있으므로 어느 시점에 앉아서 세부 사항을 시도하고 싶다면 저에게 알려주십시오 :-).

(다른 모든 접근 방식의 문제는 IIUC 창 프로세스가 일반적으로 가져온 모든 dll의 단일 전역 네임스페이스를 유지한다는 것입니다. 이것이 의미하는 바는 두 개의 확장이 모두 foo.dll이라는 파일을 제공하는 경우 먼저 로드되는 확장이 해당 버전을 갖는다는 것입니다. foo.dll "win" 및 다른 확장은 결국 그것을 사용하게 됩니다 -- 고전적인 "dll 지옥" 문제 그리고 IIUC는 이 동작을 피하는 유일한 방법은 SxS 기계를 통하는 것만큼이나 추악합니다.)

Nathaniel - 여기에 SxS 어셈블리에 대한 이해를 썼습니다. https://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-assemblies

내 최종 결론은 희망이 없으며, 어쨌든 프로세스별로 고유한 방식으로 DLL 이름을 바꾸는 것이 합리적인 대안이라는 것이었습니다.

Ralf - 설치 프로세스에 SSE2 등 후크를 추가하는 방법을 공식화하기 위한 제안: https://github.com/numpy/numpy/pull/7231

@matthew-brett: 나는 그 노트를 읽었습니다. 예.... 그리고 헉 한숨, 가망 없는 이유는 무엇입니까? 같은 디렉토리 문제 때문에? 그리고 그 이름 바꾸기를 수행하는 방법에 대한 아이디어가 있습니까? (저는 아직 PE 파일에 대해 patchelf --replace 에 해당하는 것을 찾지 못했고 .lib 파일을 재생성하는 것은 사소한 일이 아닙니다. mingw-w64를 사용하는 것 같지만 그렇게 나쁘지는 않습니다. .dll 에 직접 연결할 수 있습니다.적어도 libgfortran 또는 이와 유사한 이름을 바꿀 필요가 없다면...)

(이 목록 어딘가에 patchelf --replace 에 해당하는 PE가 있을 수 있습니다: http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

이 디렉토리가 DLL 검색 중에 선호되기 때문에 multiarray.pyd와 함께 satlas.dll (또는 대안적으로 libopenblaspy.dll )를 로드하는 데 문제가 없습니다. 이 접근 방식은 이 DLL이 python에서 프로세스 공간으로 LoadLibraryEx 를 통해 로드된다는 사실 때문에 작동합니다. numpy/core 폴더를 사용해야 합니다. 가져오기 중에 blas 종속 python 확장이 가장 먼저 발생하기 때문입니다. 같은 이름의 DLL을 로드하려는 추가 시도는 이 DLL이 이미 프로세스 공간에 로드되어 있기 때문에 무시됩니다. Windows는 DLL BTW의 이름을 찾습니다.

DLL 지옥 시작 그러한 라이브러리가 _further_ DLL에 종속되지만 satlas.dll 및 libopenblaspy.dll 가 모두 자체 포함되어 있고 표준 Windows 시스템 DLL에만 의존하는 경우는 그렇지 않습니다. 이것은 일반적으로 정적으로 연결된 DLL이라고 하는 것입니다. 즉, gcc 런타임 코드가 정적으로 연결되어 있음을 의미합니다.

_비교용_: MKL 라이브러리를 가져오려면 PATH 을 numpy/core 로 일시적으로 확장합니다. 불행히도 이전 MKL 라이브러리가 Windows 시스템 폴더에 있는 경우 실패합니다.

@matthew-brett @njsmith : DLL 이름 변경: 어떤 용도로 좋은가요?

@carlkl : 우리가 걱정하는 경우는 numpy가 atlas.dll 를 포함하고 scipy가 atlas.dll 를 포함하고 어느 시점에서 사용자가 scipy를 업그레이드하고 atlas.dll 의 최신 버전을 얻는 경우입니다. atlas.dll 의 이전 버전을 사용하게 됩니다. 이것은 scipy가 최신 버전에 의존할 수 있기 때문에 좋지 않습니다. 따라서 정확히 어떤 패키지의 빌드가 관련되고 사용자가 패키지를 가져오는 순서에 따라 무작위로 중단됩니다. 이것은 numpy에 atlas.dll 라는 DLL이 포함되어 있으면 프로세스 전체 DLL 네임스페이스에서 atlas.dll 라는 이름을 "클레임"하고 다른 패키지가 해당 DLL을 사용하는 것을 차단하기 때문에 발생합니다. 이름.

두 가지 가능한 솔루션은 (a) SxS/activation-contexts 항목이 작동하도록 만들 수 있는 경우 프로세스 전체 DLL 네임스페이스를 비활성화하는 방법을 제공하거나 (b) numpy에 numpy-atlas.dll 및 scipy가 포함된 경우입니다. scipy-atlas.dll 포함하면 충돌 없이 동일한 프로세스 전체 네임스페이스를 공유할 수 있습니다.

또는 둘 다 dll을 제공하는 별도의 clib_atlas 패키지에 의존한다면? 그런 다음 버전 종속성 요구 사항은 Python 패키지에 대해 평소와 같이 표현할 수 있습니다.

@tkelman : 벤더 DLL과 별도로 배포된 DLL을 모두 지원하는 방법을 알아야 합니다. 두 옵션 모두 다른 상황에 적합하기 때문입니다. 그리고 판매 된 케이스는 시작하기가 훨씬 쉽습니다 :-)

나는 side-by-side 솔루션이 Windows system32에 설치하려면 관리자 권한이 필요하다고 생각합니다. 이러지 마세요.

어셈블리가 고유한 바이너리 트리에 있는 '비공개' 병렬 어셈블리도 있지만 어셈블리를 가리키는 데 사용할 수 있는 상위 디렉터리 경로 마커는 두 개로 제한됩니다. 즉, ..\..\some_assembly 을 가리킬 수 있습니다. ..\..\..\some_assembly 아닙니다.

예를 들어 scipy/first/second/third/something.pyd 는 third 또는 second 또는 first 디렉토리의 병렬 어셈블리만 가리킬 수 있지만 scipy 에는 없습니다. (또는 그 안의 다른 디렉토리.

자, 여기에서 테스트를 위해 몇 가지 바퀴를 만들었습니다.

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

평소와 같이:

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

여기에서 매우 조잡한 빌드 자동화: https://github.com/matthew-brett/np-wheel-builder

휠은 f2py 스크립트를 실행하는 가짜 실패를 제외하고 모든 테스트를 통과합니다(그 테스트의 버그라고 생각합니다).

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

또한 동일한 웹 주소에서 Python 2.7, 3.4, 3.5용 64비트 설치 프로그램을 구축했습니다.

@matthew-brett, 이 파일에 액세스할 수 있는 권한이 없습니다.

@matthew-brett, SxS 어셈블리 기술은 더 이상 사용되지 않습니다(VS2010 이후) . https://en.wikipedia.org/wiki/Side-by-side_assembly를 참조하세요.

DLL 파일 이름에 버전 번호를 추가하는 것은 어떻습니까: libopenblaspy_0.15..dll 또는 libatlas_3.10.1.dll 또는 유사. 그런 다음 버전이 지정된 DLL에 대한 전달자 DLL로 사용되는 _proxy DLL_을 사용합니다. Numpy 및 scipy 확장은 _libblaslapack.dll_이라는 프록시 DLL에 대해 빌드해야 합니다.

아틀라스를 사용하면 원칙적으로 런타임에 최적화된 아틀라스 DLL을 로드할 수 있습니다. (openblas를 사용하는 경우 필요하지 않음)

이 모든 것은 clib_openblas 및/또는 clib_atlas 패키지의 도움으로 처리할 수 있습니다. (이제 전달자 DLL에 대한 코드를 생성하는 방법을 배워야 합니다.) Numpy 자체에는 아틀라스 또는 오픈블라스가 장착될 수 있습니다. clib_openblas 또는 clib_atlas를 사용할 수 없는 경우 로드해야 합니다.

@carlkl : 위키피디아 페이지가 혼란스럽고 VS 2010이 _특정 라이브러리에 대해_ SxS를 사용하지 않는다고 말하려는 것 같지만, 일반적으로 SxS는 확실히 여전히 사용됩니다(예: 같은 페이지의 나중: "Vista부터, 운영 체제는 핵심 구성 요소에도 WinSxS를 사용합니다.")

msvc로 포워더 dll을 빌드하는 방법은 특별한 .def 파일을 작성한 다음 .dll을 생성할 때 사용하는 것이라고 생각합니다. 하지만 포워더 dll은 어떻게 도움이 될까요? (osx 또는 Linux에서는 유용한 도구가 될 수 있다고 생각하지만 Windows에서는 여전히 성가신 전역 dll 네임스페이스 문제가 있습니다.)

@njsmith , 우리는 이해할 수 있는 해결책을 찾아야 합니다. SxS sitll이 존재한다는 것은 사실입니다. 일반적으로 운영 체제 자체 이외의 다른 용도로는 더 이상 사용되지 않습니다.

(1) 가장 쉬운 IMHO 솔루션은 Blas Lapack을 정적으로 연결하는 것입니다. 이 접근 방식은 거대한 바이너리를 생성하므로 권장하지 않습니다(적어도 필자는).
(2) 두 번째로 쉬운 솔루션은 numpy/core 에 DLL을 설치하는 것입니다.
(3) 세 번째 솔루션은 외부 Blas/Lapack 패키지에 대한 종속성을 _force_ 하는 것입니다. 이 패키지는 버전이 지정되고 단순히 Blas Lapack DLL을 미리 로드합니다. pip를 사용하면 올바른 버전의 DLL을 사용할 수 있습니다.
(3) 그러한 제한된 종속성이 환영받지 못하는 경우 numpy 및 scipy 자체에서 제공하는 DLL로 추가될 수 있습니다. 이러한 DLL은 외부 DLL이 설치되지 않은 _상황에서만_ 로드해야 합니다. 즉, 외부 Blas/Lapack 패키지가 선호되지만 꼭 필요한 것은 아닙니다.
이러한 솔루션의 가장 큰 장점은 numpy/scipy를 다시 설치하지 않고도 openblas/atlas의 최신 버그 수정 릴리스를 교환할 수 있다는 것입니다.
(4) 매니페스트 및 SxS 사용. @njsmith , 이 경우에 대한 세부 정보를 입력할 수 있습니까?

죄송합니다 - 바퀴에 대한 권한을 수정했습니다 - 지금 작동합니까?

SxS 어셈블리에 대해 연락을 드리지 못해 죄송합니다. SxS에 대한 나의 '희망 없는' 의견은 그다지 유용하지 않았습니다. 압축을 풀어보도록 하겠습니다.

문제는 자체 바이너리 트리에서 호스팅하는 SxS 어셈블리인 "비공개" SxS 어셈블리를 사용해야 하는지 여부입니다. SxS 어셈블리는 "공유"할 수도 있습니다. 공유 어셈블리는 Windows 시스템 폴더로 이동 하며 MS 설치 프로그램 패키지로 설치해야 합니다 . 공유 어셈블리는 휠을 통해 설치할 수 없으며 어떤 경우에도 관리자 권한이 필요하므로 공유 어셈블리를 옵션으로 거부할 수 있다고 생각합니다.

그래서 - 사설 SxS 어셈블리를 사용할 때 어떤 문제가 있습니까?

첫 번째 문제는 우리가 이것을 시도하고 실행한다면 꽤 신선한 길을 열게 될 것이라는 점입니다. 나는 그것을 사용하는 다른 오픈 소스 프로젝트를 모릅니다. 나는 Steve Dower에게 SxS 어셈블리에 대해 물었습니다. Steve는 MS에서 근무하며 현재 Python Windows 관리자입니다. 그는 내가 그들을 피하라고 제안했습니다. 그와 함께 일한 사람 중 아무도 그들에 대해 잘 알고 있는 것 같았습니다. 위에 링크된 내 메모는 누군가가 (분명히) 성공적으로 사용하고 있다는 몇 가지 사례를 이해하려는 시도였습니다. 그것들을 설명할 수 있는 좋은 자료는 거의 없습니다.

이와 관련하여 Carl은 이미 MS 자체가 이를 사용하는 것에 대해 양면적인 태도를 보인다고 언급했습니다. 예를 들어, SxS 어셈블리의 명백한 애플리케이션인 MSVC 런타임의 경우 고유한 DLL 이름 을 대신 사용합니다(MSVCR90.DLL, MSVCR100.DLL 등).

SxS 어셈블리를 사용하려면 "활성화 컨텍스트"를 만들기 위해 다른 DLL을 로드해야 하는 모든 컴파일된 모듈에 초기화 상용구 코드를 추가해야 한다고 생각합니다. 편집: Nathaniel은 DLL(DLL에 포함할 수 있지만 외부 XML 파일일 수도 있음)과 관련된 병렬 어셈블리 "매니페스트"의 증거가 표시되면 Windows가 자동으로 새 활성화 컨텍스트를 트리거한다고 상기시켰습니다. .

그래서 희망이 없는 것이 아니라 힘든 것입니다.

이 매우 기본적인 질문에 대해 유감입니다. 하지만 Windows에서 my_symbol $를 포함하는 $ foo.dll 라이브러리를 하나의 확장 모듈에 로드하면 bar.dll 라이브러리를 로드하면 어떻게 됩니까? 다른 확장 모듈에 my_symbol 도 포함되어 있습니까? 내 프로세스에서 개별적으로 액세스할 수 있다고 가정하므로 첫 번째 확장은 foo: my_symbol 를 얻고 두 번째 확장은 bar:my_symbol 를 얻습니까? 아무도 나에게 참조를 가리킬 수 있습니까?

그것이 맞다면, DLL 지옥을 피하기 위해 우리가 필요로 하는 모든 것은 같은 프로세스(사용자가 우리의 정확한 DLL을 사용하려고 의도하지 않은 곳)에서 우연히 사용될 가능성이 매우 낮은 DLL 이름을 갖는 것입니다.

링크하는 동안 각 기호는 해당 이름으로 식별되는 특정 DLL에 바인딩됩니다. 런타임 동안 동일한 이름을 가진 DLL이 두 개 이상 있는 경우 올바른 DLL이 로드되었는지 확인해야 합니다. 따라서 검색 순서가 중요합니다.
예제 My anaconda.org numpy wheel은 Julia가 사용하는 비표준 libopenblas,dll과 이름 충돌을 피하기 위해 libopenblas_py_.dll이라는 이름의 openblas 라이브러리를 사용합니다.

julia의 최신 버전은 이제 다른 이름 libopenblas64_ 를 사용하여 빌드하는 비표준 ABI를 반영합니다. 32비트에서는 인터페이스에서 64비트 정수를 선택할 이유가 별로 없기 때문에 기호나 라이브러리 이름의 이름을 바꾸지 않습니다.

공유 라이브러리 내 심볼의 이름 섀도잉은 실제로 Windows보다 Linux와 osx에서 더 문제였지만 일관성을 위해 모든 곳에서 동일한 작업을 수행했습니다.

그렇다고 해서 ABI가 동일한 32비트에서 가능성이 배제되지는 않지만 서로를 위해 너무 오래되거나 너무 새로운 버전이 필요한 것과 같이 다른 방식으로 서로를 분리할 수 없었습니다.

빌드 프로세스를 약간 다듬었습니다. https://github.com/matthew-brett/np-wheel-builder 참조

이제 프로세스가 합리적으로 자동화되었으며, 필요한 경우 다음 몇 릴리스 동안 이러한 휠을 계속 구축하는 것이 실용적이라고 생각합니다. mingwpy가 사양에 도달할 때까지 Windows 릴리스 관리자로 이 작업을 수행하게 되어 기쁩니다.

저는 이 휠을 32비트 및 64비트 Python 2.7, 3.4, 3.5에서 테스트했으며 다른 몇 개도 테스트했기 때문에 상태가 양호하다고 생각합니다.

OP가 요청한 대로 pypi에 올릴 가치가 있다는 것을 모두 안심시키기 위해 제가 할 수 있는 다른 일이 있습니까?

여러분 안녕하세요! 꽤 오랫동안 소스에서 numpy 및 scipy 를 설치할 수 없다는 사실에 좌절했기 때문에 이 토론에 뛰어들고 싶었습니다. 이 전면에서 진행됩니다.

@matthew-brett: 이 자동화 스크립트는 훌륭 합니다. PyPI에 도달하지 못하더라도 이것은 소스에서 numpy 를 빌드하는 매우 실행 가능한 방법처럼 보입니다( 여기에서 내가 연 이 문제 참조). 또한 모든 것을 빌드할 수 있다는 점에서 scipy 를 빌드할 수 있는 것에 매우 가깝지만 테스트는 Python 어딘가에서 segfault를 일으키는 것 같습니다.

또한 실제로 numpy 휠을 구축한 사람을 위해 소스에서 이러한 라이브러리를 구축하여 현재 온라인에 있는 것을 대체하는 것에 대한 세련된 최신 문서를 만들려고 노력했습니다. 그 전면에 사람들의 의견도!

매우 유용할 피드백과 빌드 문서화 작업에 감사드립니다.

http://mingwpy.github.io 를 보셨을 거라 생각합니다. 물론 mingw-w64 프로젝트와 mingwpy 툴체인과 관련된 상당한 양의 자료가 있습니다.

@matthew-brett 감사합니다! numpy.test() 통과합니다. f2py.py 테스트는 numpy-SHAd3d2f8e 에서 수정된 virtualenvs의 test_scripts() 문제였지만 3개의 경고, 2개의 지원 중단 및 1개의 런타임을 받았습니다.

마지막으로 사소한 요청으로 repo np-wheel-builder 및/또는 PyPI에 빌드 배지를 표시할 수 있습니까? buildbot 0.8에 있는 것 같으며 보기 좋게 만들기 위한 python 패키지/리포지토리( BuildbotEightStatusShields-0.1 )도 있습니다.

또한 튜닝 매개 변수가 없기 때문에 ATLAS Windows 64비트 빌드 에서 멀리 떨어져 있는지 궁금합니다. 실제로 "하루 종일" 걸렸습니까? 아니면 적절한 아키텍처 기본값이 있습니까?

참고: Continuum은 최적화된 mkl numpy로 Anaconda를 출시했습니다. 나는 그들이 이 스레드를 모니터링했다고 생각합니다.

이제 동일한 아틀라스 라이브러리가 있는 scipy 빌드의 경우입니다. gfortran이 필요합니까?

예. 그렇지 않으면 scipy .f 파일을 컴파일할 수 없습니다. 행운을 빕니다! 앞서 말했듯이 저는 _정말 가까워졌습니다_. 하지만 테스트를 통과할 수 있다면 정말 좋을 것입니다!

예, ATLAS 빌드는 다른 작업을 수행하지 않는 시스템에서 약 8시간이 걸렸습니다. ATLAS 빌드 스크립트는 np-wheel-builder repo 에 있습니다.

MKL conda 사용자라면 좋은 소식이지만 numpy 및 scipy 가 사전 설치된 Python 배포판을 사용하는 것은 한동안 장려해 온 것. MKL 라이브러리 자체도 무료로 얻을 수 있을 때 저에게 말씀해 주십시오. :)

gfortran으로 빌드하는 경우 - mingwpy가 우리의 최선의 희망이라고 생각합니다.

@matthew-brett : 시간을 내어 ATLAS를 구축해 주셔서 감사합니다! 이전에 스크립트를 실행하려고 시도했지만 시스템별 비호환성으로 인해 계속 문제가 발생했습니다.

문제에 대해 죄송합니다. 방금 np-wheel-builder 리포지토리에 ATLAS 바이너리를 빌드했는데 Windows Server 2012 및 64비트 Cygwin을 새로 설치했으며 정확한 ATLAS 및 lapack 버전이 나열되어 있습니다. 내가 사용한 소스 아카이브는 http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/에 있습니다. 다른 버전의 ATLAS가 있으면 쉽게 털이 날 수 있습니다.

흠...그럴수도 있겠네요. 다시 한 번 말씀드리지만, 그렇게 하는 데 필요한 노력을 감안할 때 대단히 감사합니다. 지금처럼 많은 시간과 리소스가 필요하지 않은 Windows 호환 ATLAS 빌드를 출시할 방법을 찾을 수 있다면 정말 좋을 것입니다!

@gfyoung

MKL 라이브러리 자체도 무료로 얻을 수 있을 때 저에게 말씀해 주십시오. :)

https://software.intel.com/sites/campaigns/nest/ 및 https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 를 참조하십시오. 아니면 소스를 의미했습니까?

@tkelman , 방금 @carlk 의 새로운 mingwpy 프로젝트 사이트 에서 보았지만 Intel 커뮤니티 라이선스 Nest에는 ifort 가 없으며, 그것이 없으면 얼마나 scipy입니까?

@tkelman : 이런, 커뮤니티 라이선스를 잊어버린 이유가 확실하지 않습니다. 그러나 @tkelman 은 유효한 요점을 제시합니다.

@tkelman : MinGW로 시도해 볼 수 있지만 내가 경험한 바에 따르면 불행히도 작동하지 않습니다. 호환성 문제로 인해 numpy 를 초과하지도 않습니다.

@mikofski 맞습니다. 컴파일러가 부족하면 scipy에 도움이 되지 않습니다. 오늘날 scipy 빌드에 대한 옵션은 mingwpy 또는 모든 gcc-all-the-time Python 빌드(https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- python-scipy). 후자는 물론 msvc 빌드 cpython 또는 pypi 바이너리와 호환되지 않으므로 scipy 이외의 모든 모듈을 처리하지 않습니다.

@matthew-brett: Openblas 및/또는 MKL에 비해 이 ATLAS 휠의 속도 부족은 무엇입니까?

PGI Fortran을 살펴 본 사람이 있습니까? @carkl mingwpy 프로젝트 사이트에는 언급되어 있지 않습니다. 한번 써보고 그 토끼굴로 꽤 갔었는데 쇼 스토퍼가 뭐였는지 기억이 안나네요. 비공개 소스인데도 라이선스가 허용되는 것 같아요. PGI Fortran이 msvc에서 더 잘 재생될 수 있습니까?

@mikofski : 내 앞에는 없지만 작년에 PGI를 보았을 때 내 결론은 Intel보다 훨씬 더 나빴다는 것이었습니다(라이선스에 FOSS 비호환 제한을 추가해야 한다는 점에서) .

좋습니다. x86 아키텍처용 BLIS/FLAME 솔루션을 대상으로 일부 num focus 자금을 사용할 수 있습니까?

분명히 Nvidia/PGI는 올해 말까지 Fortran 프런트 엔드를 LLVM의 오픈 소스로 제공할 것입니다. https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

좋습니다. x86 아키텍처용 BLIS/FLAME 솔루션을 대상으로 일부 num focus 자금을 사용할 수 있습니까?

그렇게 생각하지 마세요. BLIS는 매우 건강에 해로운 프로젝트처럼 보입니다(libflame은 더욱 그렇습니다). 커밋, 메일링 리스트 트래픽 등의 측면에서 활동이 거의 없습니다. 게다가 상당한 자금을 확보하고 있기 때문에(https://github.com/flame/blis#funding), 수천 달러가 마법처럼 프로젝트가 성숙합니다.

이 논의가 어디서 왔는지, 어디로 가는지 잘 모르겠습니다. 우리는 Matthew가 거의 완료한 임시 해결책(ATLAS 사용)을 가지고 있으며, 더 중요한 것은 매우 적극적으로 작업 중인 장기 솔루션이 있다는 것입니다(MingwPy + OpenBLAS). 또한 OpenBLAS가 훨씬 더 널리 사용됩니다. Scipy 스택과 Julia 모두에서 해당 프로젝트를 사용하면 더 빨리 성숙해야 합니다.

@rgommers : @mikofski 와 저는 @matthew-brett 솔루션을 사용하여 scipy 를 구축하려고 했기 때문에 대화가 제대로 진행되었습니다. 그러나 우리 둘 다 포트란 컴파일러라는 동일한 문제에 직면해 있는 것 같습니다. 나 자신은 어떤 이유로든 수많은 미해결 외부 장치로 인해 많은 성공 없이 MinGW32와 MinGW64 모두에 설치된 gfortran.exe 를 사용하려고 시도했습니다.

@gfyoung Matthew의 빌드는 MSVC를 사용합니다. MSVC와 함께 gfortran 를 사용하려고 시도하는 것은 의미가 없으며 작동하지 않는 것으로 알려져 있습니다. 빌드 상황의 요약은 다음과 같습니다.

• 포트란이 없으면 지금 MSVC를 사용할 수 있습니다.
• Fortran에서는 MingwPy, MSVC + ifort 또는 icc + ifort 중 하나를 사용할 수 있습니다.
• Scipy 스택의 경우 numpy, scipy 등을 위한 휠을 만드는 무료 솔루션이 필요합니다. MingwPy가 그렇습니다.

@rgommers 대화를 @carlk으로 mingwpy 프로젝트는 이미 납입 초점에 의해 지원된다. 회사에서 지원을 받을 수 있는지 확인하려고 합니다. 저는 이미 num focus 회원입니다. scipy 2829의 중간쯤에 저도 같은 결론에 도달한 것 같습니다. 효과가 있기를 바랄 뿐입니다. 단기적으로는 @cgohlke를 계속 사용하거나

빌드를 pypi로 푸시하는 것 외에 @matthew-brett의 마지막 문제는 np 빌드 스크립트 리포지토리에 있는 buildbot 방패일까요? 감사 해요! 그러면 닫을 수 있습니까?

닫기 전에 간단한 질문: ATLAS를 가리키도록 @matthew-brett numpy 를 구축했습니다. 그러나 ifort #$ 를 사용하여 $ scipy 빌드를 시도하면 내 홈 디렉토리에 있는 MKL을 사용하는 다른 site.cfg 파일도 선택됩니다. 실제로 numpy 에 대해 성공적으로 빌드할 수 있으며 테스트는 분 반올림 오류로 인한 몇 가지 오류에 대해 저장을 통과합니다. 그런데 scipy 를 빌드할 때 무엇을 했는지 궁금합니다. MKL 라이브러리를 사용했습니까 아니면 numpy 로 이미 빌드된 ATLAS 라이브러리를 사용하려고 했습니까?

https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows 에 Windows Fortran 컴파일러 요약이

@gfyoung - 추측과 먼 기억의 조합으로 진행 - scipy는 자체 디렉토리에서 먼저 site.cfg 를 선택하고 이것이 없으면 numpy 빌드의 구성을 선택합니다. 이것은 차례로 내가 바퀴를 만들 때 라이브러리가 있는 곳을 가리킬 것입니다. 따라서 np-wheel-builder 아틀라스 라이브러리를 선택하려면 scipy에 대해 site.cfg 를 다시 작성해야 합니다. build_numpy.py 스크립트는 numpy 빌드에 대해 수행합니다.

BLIS는 매우 건강에 해로운 프로젝트처럼 보입니다(libflame은 더욱 그렇습니다). 커밋, 메일링 리스트 트래픽 등의 측면에서 활동이 거의 없습니다.

커뮤니티에서 운영하는 FOSS 프로젝트를 시도하지 않기 때문에 건강에 해롭다고 말할 수 있을지 모르겠습니다. 그들은 본질적으로 1인 쇼이고, 그들은 그런 식으로 그것을 좋아합니다(적어도 지금은). 나는 지난 ~1년 동안 그들과 계속해서 연락을 주고받았고 ​​좋은 소식은 현재 그들의 노력이 우리가 필요로 하는 것(런타임 커널 선택 및 런타임 스레딩 구성)에 정확히 초점을 맞추고 있다는 것입니다. 나쁜 소식은 한 건축가가 원하는 대로 물건을 재배치할 때까지 기다리는 것 외에는 할 일이 별로 없다는 것입니다. 6개월이 지나면 효과가 나타날까요?

BLIS 등은 현시점에서 상당히 먼 옵션인 것 같으며, 우리는 이것이 제대로 작동하지 않는 경우에 대비해야 할 것입니다.

Nathaniel - 좋은 벤치마크를 얻을 수 있는 위치에 대한 제안이 있습니까? numpy.bench() 이(가) 더 이상 아무 것도 하지 않는 것 같습니다. asv 실행을 시도했지만 Windows numpy에 complex256 이 없기 때문에 많은 테스트가 실패합니다.

asv 에서 작동하는 부분이 유용하다고 생각합니까? 또는 %timeit np.dot(big_array, other_big_array) 조차도 우리가 서 있는 위치에 대한 대략적인 아이디어를 얻는 데 유용할 것입니다 :-)

또한 BTW는 Windows delocate 를 작성할 수 있는 Windows DLL 전역 네임스페이스 문제에 대한 일반적인 솔루션입니다. https://github.com/njsmith/redll

불행히도 asv complex256 실패는 dtypes에서 전체 테스트 시퀀스를 중단합니다. 그래도 고치는 건 어렵지 않을 것 같아요.

이것으로 간단한 테스트:

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)

Clint Whale이 전에 경고했듯이 64비트 ATLAS는 Windows에서 잘 최적화되지 않았습니다. Christoph Gohlke의 휠을 통한 64비트 MKL 사용:

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

64비트 ATLAS로 제작된 내 휠:

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

차이는 32비트 휠(다른 32비트 시스템에서)에서 훨씬 적습니다. MKL:

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

대 아틀라스:

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

@rcwhaley - 여기에 몇 가지 생각이 있는 경우를 대비하여 참조합니다. 이것은 ATLAS 3.10.1입니다 ...

여기에 더 현대적인 프로세서를 탑재한 또 다른 Windows 64비트 컴퓨터가 있습니다. 또한 ~3배의 속도 저하를 보입니다.

MKL:

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

아틀라스:

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

네, 복잡한 256 문제는 해결하기 어렵지 않습니다: https://github.com/numpy/numpy/pull/7251

3x는 많지만 lapack_lite 만큼 극적이지는 않습니다. 맞나요? 단기적인 해결책으로는 괜찮다고 생각합니다. 그리고 예전의 32비트 .exe 설치 프로그램이 더 나은 것도 아닙니다.

또한 BTW, 여기에 Windows DLL 전역 네임스페이스 문제에 대한 일반적인 솔루션이 있어 Windows 할당을 작성할 수 있습니다. https://github.com/njsmith/redll

멋진 라이선스 설명:)

@gfyoung 'site.cfg' 는 다음에서 찾습니다.

1) 실행되고 있는 기본 setup.py 파일의 디렉토리.
2) setup.py 파일을 ~/.numpy-site.cfg 로 실행하는 사용자의 홈 디렉토리
3) 시스템 전체 디렉토리(이 파일의 위치...)

@rgommers 대화를 방해해서 죄송합니다.

걱정하지 마세요. 아무 것도 탈선하지 않았습니다.

numpy 작품을 위한 @matthew-brett 솔루션이 맞습니다. @carlk의 mingwpy 프로젝트는 이미 num focus로 자금을 지원받았습니다. 회사에서 지원을 받을 수 있는지 확인하려고 합니다. 저는 이미 num focus 회원입니다. scipy 2829의 중간쯤에 저도 같은 결론에 도달한 것 같습니다. 효과가 있기를 바랄 뿐입니다. 단기적으로는 @cgohlke를 계속 사용하거나 aconda 로 전환할 것입니다. 다시 한번 감사합니다!

시원한. MingwPy에 관심을 가져주셔서 반갑습니다. 이제 자체 ML이 있으므로 관심을 가질 수 있습니다. https://groups.google.com/forum/#!forum/mingwpy

@rgommers , @matthew-brett : 아, 예, 미리 MKL로 빌드한 것 같습니다. 나는 site.cfg 를 ATLAS 빌드로 직접 가리켰고 scipy 빌드를 했지만 테스트 중에 segfaults가 발생했습니다. 너무 가까이!

@rgommers - 예 - ATLAS가 없으면 성능이 훨씬 나빠집니다(lapack_lite 사용).

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

여기서 남은 질문은 OpenBLAS numpy(모든 numpy 테스트 통과)로 표준화할 가치가 있는지 여부이며, 이것이 numpy를 사용하는 프로젝트에서 수치 오류를 일으킬 가능성이 더 높다는 위험을 감수하는 것입니다.

이렇게 하는 것에 대한 한 가지 주장은 우리가 단기/중기적으로 이 방향으로 가야 할 것 같으며 지금 시작하고 그에 수반되는 비참한 버그 사냥에 전념하는 것이 더 나을 수 있다는 것입니다. 적어도 우리는 Julia 유지 보수의 좋은 회사에있을 것입니다.

Numpy는 또한 Julia와는 상당히 다른 위험 허용 범위와 성능 절충안, 사용자 대 개발자 비율을 가지고 있습니다. 따라서 numpy가 더 보수적인 접근 방식을 취하고 느리지만 안정적인 기본 설정을 사용하여 기본이 아닌 선택 항목으로 openblas를 허용하는 방향으로 작업하는 것이 합리적일 수 있다고 생각합니다. 8시간의 빌드 시간이 재미없게 들리지만 아무도 Julia와 Atlas를 함께 사용하는 것에 대해 묻지 않았습니다.

기본이 아닌 옵트인 선택으로 openblas를 허용하기 위해 노력하고 있습니다.

문제는 이 프로세스가 어떻게 작동하는지 잘 모르겠다는 것입니다 :-/. 우리는 사용자에게 대체 빌드를 배포할 수 있는 좋은 방법이 없습니다(장기적으로는 pypi에서 numpy[openblas] 등으로 빌드 변형을 얻을 수 있기를 희망하지만 곧 그렇게 되지는 않을 것입니다) , 우리는 배포하고 버그 보고를 기다리는 것 외에는 openblas 빌드를 개선할 방법이 없습니다. ATLAS 빌드에 대한 주요 대안은 Openblas 빌드가 아니라 MKL이 될 것입니다. 일부 타사에서 빌드:-/.

테이블에 올려놓을 또 다른 옵션은 참조/SSE2 커널을 사용하여 BLIS 빌드를 배포하는 것입니다. BLIS에는 여전히 빌드 시간 구성만 있기 때문에 이것은 openblas와 경쟁력이 없을 수 있지만 ATLAS와 경쟁력이 있을 수 있으며 ATLAS에 비해 이점은 빌드 시간이 _훨씬_ 빠르며 장기적으로 좋은 솔루션이 될 가능성이 있다는 것입니다. 추정하기 어렵지만 ATLAS가 장기적으로 좋은 솔루션이 되는 것보다 확실히 낫습니다(0으로 설정). 어쨌든 우리가 무언가를 QA할 예정이라면 적어도 그 에너지는 미래가 _가능성 있는_ 무언가로 향하게 될 것입니다.

이 옵션을 진지하게 고려하기 전에 답변이 필요한 몇 가지 질문:

(1) BLIS의 멀티스레딩 지원이 ATLAS와 경쟁적인지 여부가 확실하지 않습니다(소스에 일부 멀티스레딩 옵션이 있다는 것을 알고 있으며 주 개발자가 아직 "완료"된 것으로 간주하지 않는다는 것을 알고 있습니다. , 즉 MKL과 경쟁하지만 ATLAS와 MKL 사이에는 많은 여지가 있습니다.)

(2) 그 문제에 관해서는 조정되지 않은 모드의 BLIS가 위의 벤치마크에서 어떻게 작동하는지 전혀 모릅니다.

(3) 저는 실제로 Windows에서 BLIS를 빌드하려고 시도하지 않았으며 LAPACK이 아니라 BLAS일 뿐이라는 문제를 처리해야 합니다. 이것이 numpy에 얼마나 많은 문제가 있는지 확실하지 않습니다.

BLIS는 버그 보고에 얼마나 반응합니까? Openblas는 꽤 좋은 것 같습니다
이것에 대해서.

2016년 2월 15일 월요일 오후 3시 48분, Nathaniel J. Smith <
[email protected]>은 다음과 같이 썼습니다.

기본이 아닌 옵트인 선택으로 openblas를 허용하기 위해 노력하고 있습니다.

문제는 이 프로세스가 어떻게 작동하는지 잘 모르겠다는 것입니다 :-/.
대체 빌드를 사용자에게 배포할 좋은 방법이 없습니다(
장기적으로 pypi에서 numpy[openblas]로 빌드 변형을 얻을 수 있기를 바랍니다.
등등, 하지만 그것은 곧 일어나지 않을 것입니다), 우리는 할 방법이 없습니다
배포하고 버그를 기다리는 것을 제외하고 openblas 빌드를 개선하십시오.
보고서 및 ATLAS의 주요 대안은 다음과 같은 사람들을 위한 빌드입니다.
하나를 찾으려는 동기는 openblas 빌드가 아니라 MKL 빌드가 될 것입니다.
일부 타사에서 :-/.

테이블에 올려 놓을 또 다른 옵션은 BLIS를 배포하는 것입니다.
참조/SSE2 커널을 사용하여 빌드합니다. BLIS에는 아직 빌드만 있기 때문에
시간 구성은 openblas와 경쟁적이지 않지만
ATLAS와 경쟁력이 있으며 ATLAS에 비해 이점은
시간은 _훨씬_ 빠르며 장기적으로 좋은 기회가 될 것입니다.
솔루션은 추정하기 어렵지만 ATLAS가 좋은 것보다 확실히 낫습니다.
장기 솔루션(저는 0으로 설정합니다). 우리가 QAing이 된다면
어쨌든 무엇인가 그렇다면 적어도 우리는 그 에너지를 무언가로 향하게 할 것입니다.
미래가 있을 수 있습니다.

이것을 진지하게 고려하기 전에 대답해야 할 몇 가지 질문
옵션:

(1) BLIS의 멀티스레딩 지원 여부가 확실하지 않습니다.
ATLAS와 경쟁적입니다(몇 가지 멀티 스레딩 옵션이 있다는 것을 알고
소스이며, 주요 개발자가 이를
아직 "완료", 즉 MKL과 경쟁하지만 사이에는 많은 여지가 있습니다.
ATLAS 및 MKL.)

(2) 그 문제에 대해, 나는 또한 조정되지 않은 모드의 BLIS 요금이 어떻게 되는지 전혀 모릅니다.
위의 벤치마크에서

(3) 실제로 Windows에서 BLIS를 빌드하려고 시도한 적이 없으며
LAPACK이 아니라 BLAS일 뿐이라는 문제를 해결해야 합니다.
이것은 numpy에 대한 많은 문제입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -184387401.

나는 libflame이 blis의 lapack에 해당한다고 믿습니다. 참조 문서 에 설명된 lapack2flame 호환성 인터페이스가 있습니다.

BLIS는 버그 보고에 얼마나 반응합니까?

우리는 아직 모른다.

BLIS를 시도하지 않고 기본적으로 매우 소수의 사람들이 사용하는 저활동 1인 프로젝트에 대해 빌드된 numpy 바이너리를 배포하는 것은 미친 짓처럼 들릴 것입니다.

이 스레드에서 아직 MingwPy + OpenBLAS 계획에서 벗어나는 좋은 이유를 보지 못했습니다. No-scipy-ATLAS-MSVC-바이너리는 임시방편이 있는 것이 좋지만 중장기 MingwPy 솔루션보다 덜 중요하며 임시방편이 그 자체로 주요 노력으로 바뀌면 노력할 가치가 없다고 말하고 싶습니다. .

BLIS/libflame 문서에 따르면 Windows에서 전체 BLAS/LAPACK 라이브러리를 구축하려고 하면 외로운 길이 될 것입니다.

개발자가 그것이 작동해야 하고 지원된다는 데 동의하면 기쁘게 생각합니다.

ATLAS는 오랫동안 Linux의 기본 라이브러리였습니다. 잠시 동안 Windows BSD 호환 빌드의 경우일 수 있다고 상상하는 것은 무리가 아닌 것 같습니다.

@tkelman - 분석해 주셔서 감사합니다 - 내 생각에 당신이 옳다고 생각합니다. 그 numpy는 정확성에 집중해야 합니다. 그러나 더 소모적인 OpenBLAS 버그에 의존하고 더 포괄적인 테스트를 개발하기 위해 힘을 합치는 것이 좋을 것입니다. 이 OpenBLAS 버그 가 떠오릅니다. 다소 모호하고 디버그하기가 매우 어렵습니다.

나는 이 특정 문제에 대해 pypi에 numpy 휠을 제공하여 numpy에 의존하는 "y"(예: matplotlib)에 의존하는 패키지 "x"의 일반 사용자가 pip를 사용하여 설치할 수 있도록 하여 일반 사용자가 던지지 않게 한다고 믿습니다. 팔을 들고 "Python은 너무 어렵습니다."라고 말합니다. 그리고 MATLAB으로 돌아갑니다. Zen of python은 한 가지 분명한 방법이 있어야 한다고 말합니다. 즉, pypi by numpy의 모든 항목은 cgohlke를 제외하고는 안정적이거나 임의의 사이드 프로젝트보다 더 안정적인 특정 가중치를 전달합니다. 분명히 사려 깊고 최소한 업계에서는 더 안정적인 것으로 인식됩니다.

단기적으로 ATLAS 빌드는 scipy로 빌드할 수 없다는 경고 메시지와 함께 올라야 한다고 생각합니다. 이 빌드봇을 자동화할 수 있다면 끝이겠죠? 향후 8시간 ATLAS 빌드는 드물기를 바랍니다. 언젠가는 Windows 64비트 문제가 해결될 것입니다. SSE2 예외 문제는 문제이므로 pypi에 대한 또 다른 경고 메시지입니다. 또한 ATLAS는 이미 Linux의 표준이며 이전 슈퍼팩 bdist_winst 패키지의 표준으로 이 경로를 더 많이 지원합니다.

그런 다음 가까운 장래에 이미 mingwpy를 결정했습니다. 여기에는 당장 해결하지 않아도 되는 많은 옵션이 있습니다.

장기적으로 나는 블리스/플레임이 미래라는 사실에 흥분합니다. 우리의 많은 수학적 도구가 70년대의 FORTRAN 코드에 의존한다는 것은 조금 무섭습니다. AC 전용 솔루션은 주요 돌파구이며 열정적으로 지원할 수 있는 것입니다.

그러나 경험이 많은 개발자에게는 항상 많을수록 좋기 때문에 경험이 많은 개발자가 빌드하고 테스트할 시간과 의향이 있다면 비표준 옵션에 대한 문서를 유지하는 것도 좋습니다.

blis에서 최적화된 커널 중 하나를 사용하려고 시도하지 않으면 2014년 이후로 열어본 문제(편집: 단수)에 부딪히지 않을 것입니다. 빌드 시스템은 최적화된 커널에만 심볼릭 링크를 사용한다고 생각합니다. 따라서 참조 구성만 빌드하려고 하면 msys2의 git을 혼동하지 않을 것입니다. cygwin에서 빌드하는 것이 마지막으로 시도했지만 얼마 전 일이고 로컬에서 수정하는 데 필요한 것이 무엇인지 기억이 나지 않습니다. 대안이 Atlas라면 구축, 테스트 및 벤치마킹할 가치가 있지만 입증되지 않은 것으로 간주하고 그렇게 할 때까지 자체 방식으로 높은 위험을 감수해야 합니다.

@mikofski 공정한 Lapack은 90년대 사람입니다. 방에 있는 정말 Fortran 코끼리입니다.

@tkelman : 분명히 말씀드리자면, 귀하가 제출한 문제는 특히 Windows 네이티브 빌드 시스템과 관련된 것이었습니다. 맞습니까? 호기심에 나는 리눅스에서 윈도우용 blis를 크로스 컴파일하려고 시도했고(데비안 패키지에서 설치된 mingw-w64 크로스 컴파일러 사용), 2분 정도밖에 걸리지 않는다는 사실에 놀랐습니다. 나는 "./configure reference; make -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=" 그리고 모든 것이 제대로 작동했습니다. ( CPICFLAGS= 은 " -fPIC 무시하는 것에 대한 많은 경고를 억제하기 위한 것입니다. 이것이 기본값이기 때문입니다." 그리고 아마도 AR 를 재정의할 필요조차 없었을 것입니다. 하지만 이봐 왜 안 됩니다.) %ld 를 사용하여 intptr 정수를 인쇄하는 $ bli_pool.c 및 bli_fprintm.c 의 printfs에 대한 몇 가지 경고가 있으므로 아마도 몇 가지 LLP64 꼬임이 있을 수 있습니다. 운동하기.

@rgommers :

BLIS를 시도하지 않고 기본적으로 매우 소수의 사람들이 사용하는 저활동 1인 프로젝트에 대해 빌드된 numpy 바이너리를 배포하는 것은 미친 짓처럼 들릴 것입니다.

당신이 절대적으로 옳습니다! 문제는 모든 옵션이 끔찍하다는 것입니다 :-(.

따라서 분명히 MKL에는 확실히 나쁜 라이센스가 있습니다.

ATLAS는 절대 개선되지 않을 확실히 나쁜 성능을 가지고 있습니다.

그리고 OpenBLAS는 이 시점에서 말할 수 있는 증거가 있다고 생각합니다. 유지 관리가 불가능하고 그렇게 빨리 되지는 않을 것입니다. -(. 프로젝트는 5년이 지났지만 여전히 Julian의 임의 volatile s와 뮤텍스를 사용하지 않는 스레딩 코드, 이 문제를 수정하는 업스트림에는 분명한 관심이 없으며 테스트를 위해 바이너리를 소규모 그룹(numpy-discussion)에 게시하는 즉시 여전히 그렇습니다. , 우리는 즉시 2-3개의 완전히 신비한 재현하기 어렵거나 불가능한 충돌 및 잘못된 결과 버그를 반환합니다. 그리고 BLIS 논문은 이것이 기본 GotoBLAS 아키텍처의 제한과 관련이 있다는 합리적으로 설득력 있는 사례를 제시합니다. 좀 더 다듬는 데 시간을 더 투자하면 쉽게 고칠 수 있는 것 소요 시간 오래된 깨지기 쉬운 코드는 사용자에게 유리하게 작동하지 않습니다. numpy 토론 목록에서 가장 재현 가능한 버그는 5년 전에 중단된 마이크로 아키텍처인 OpenBLAS의 Core2 커널에 있다고 의심되는 버그입니다.)

그래서 제가 BLIS를 계속 언급하는 이유는 BLIS가 확실히 해결책이라고 생각하기 때문이 아니라 일종의 계산된 낙관론으로 생각하기 때문입니다. BLIS는 _might_ MKL/OpenBLAS만큼 빠르고, ATLAS/MKL만큼 신뢰할 수 있으며, OpenBLAS로서의 기여; 그렇지 않을 수도 있습니다. 그러나 이러한 모든 기준을 충족할 수 있는 진정한 희망을 가진 다른 프로젝트는 없는 것 같습니다. [그리고 이것은 기본적으로 strided 배열을 지원할 수 있다는 사실과 같은 다른 이점에 대해서는 언급조차 하지 않습니다. 우리가 끔찍한 특수 케이스 BLAS 디스패치 코드를 모두 삭제할 수 있다는 것은 상상할 수 없는 일이 아닙니다.]

IIUC, GotoBLAS는 Robert van de Geijn을 PI로 UT Austin에서 일하는 단일 정규 개발자(Kazushige Goto)가 유지 관리했습니다. BLIS는 Robert van de Geijn을 PI로 UT Austin에서 일하는 단일 정규 개발자(Field G. Van-Zee)가 유지 관리합니다. 그래서 이것이 작동하지 않는 것은 아닙니다 :-) 그러나 예, 우리가 기다린다면 마술처럼 일어나지는 않을 것입니다. 주변에 개발자 커뮤니티가 있게 된다면 그것은 일부 커뮤니티가 자신의 텐트가 있는 앞 잔디밭에 "이봐, 여기 있다. 우리가 이사를 오고 있고 우리를 위해 이 일을 하고 있으니 신경쓰지 않길 바란다." 그리고 장기적인 실행 가능성을 결정하기 위해 우리가 정말로 알아야 할 것은 "그것이 실제로 얼마나 신뢰할 수 있는지"와 "패치에 얼마나 순응하는가"와 같은 것입니다. 우리가 그것을 테스트하고 제출하기 시작하지 않는 한 알 수 없습니다. 패치 등이 있습니다.

결론: 최선의 선택이 무엇인지 진지하게 모르지만 BLIS 물에 발가락을 담그는 것이 좋은 생각인 것 같습니다. 우리가 기다리기로 결정하더라도 우리는 적어도 무언가를 배울 것입니다.

여러 문제와 하나 또는 두 개의 PR을 제출했습니다. 저장소에 심볼릭 링크가 있다는 사실은 msys2에서 빌드가 중단되었음을 의미합니다(또는 msys2 옵션을 특정 방식으로 설정한 경우에만 작동함). cygwin 또는 Linux에서 교차 빌드(테스트를 실행하기 위해 와인을 신뢰하지는 않음)는 작동해야 하지만 2014년에 정렬된 malloc과 테스트에서 샌디 브리지 커널에 문제가 발생했습니다. 방금 cygwin 십자가를 사용하여 최신 master of blis에서 모래 다리 커널을 재구축했으며(최신 skylake 노트북에서) segfault가 이제 사라질 수 있습니다. 언제 또는 무엇을 고쳤는지 누가 알겠습니까? 이등분해야합니다.

나는 이것이 전에 언급되었다고 생각하지만 우리는 SSE2, SSE3, AVX용 ATLAS 바이너리를 빌드하고 다음과 같은 디렉토리 구조에 넣을 수 있습니다.

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

그런 다음 numpy/_distributor_init.py 를 사용하여 현재 CPU를 확인하고 일치하는 라이브러리를 미리 로드할 수 있습니다.

기본적으로 동일한 작업을 제안했지만 아틀라스 대신 blis의 경우 @njsmith에게 제안했습니다. 또한 blis의 스레딩이 아틀라스와 얼마나 잘 작동하는지 비교할 가치가 있습니다. blis 참조 구성은 기본적으로 스레딩을 활성화하지 않지만 헤더 파일의 정의를 조정하는 것만으로 이를 전환할 수 있습니다.

바이너리를 빌드하기 위해 Appveyor를 설정했습니다. 빌드의 현재 반복 작업이 여기에서 진행 중입니다. https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

제작된 바퀴가 여기에 도착합니다: https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

Appveyor 빌드에서 더 이상의 꼬임은 쉽게 고칠 수 있어야 하므로 이 작업이 완료되면 아마도 내일 언젠가는 이 휠을 pypi에 업로드할 준비가 되어 있다고 생각합니다.

@rgommers , @matthew-brett : site.cfg 와 관련하여 귀하의 응답은 numpy 에만 적용되는 것 같습니다. scipy 는 setup.py 와 동일한 디렉토리에서 site.cfg 를 검색 하지 않는 것 같습니다. $#를 기본값으로 지정하기 전에 홈 디렉토리에서 먼저 site.cfg 검색을 시작합니다 numpy 구성

확인 - 설치된 휠 테스트를 포함하여 오류 없이 실행되는 빌드 스크립트: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

여기 바퀴: http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

다른 64비트 컴퓨터와 다른 32비트 컴퓨터에 설치하고 테스트했습니다.

그래서 저는 이것들이 갈 준비가 되었다고 생각합니다. 이것들을 pypi에 업로드하는 것에 대해 이의가 있습니까?

바퀴가 지금 pypi에 나타나는 이유와 차이점이 무엇인지 궁금해하는 사람들의 혼란을 피하기 위해 pypi에 이 바퀴와 gohlke(mkl)의 차이점 에 대한 설명을 설명/링크 하는 메모를 두는 것이 좋습니다. 그들 사이에 있습니다.

부수적인 질문입니다 죄송합니다만 저는 무엇을

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

appveyor 스크립트에서 의미합니까?

설명에 대한 좋은 제안 - 이 기존 릴리스에 추가하는 방법을 시도하고 해결하겠습니다.

Wheel > 0.26은 Windows 휠에 ABI 태그를 추가합니다. Wheel==0.26은 다음과 같은 휠 이름을 제공합니다.

numpy-1.10.4-cp27-none-win32.whl

Wheel > 0.26에서는 다음과 같은 추가 ABI 태그를 얻습니다.

numpy-1.10.4-cp27-cp27m-win32.whl

(제 생각에는) - Windows ABI를 지정합니다. 이것은 이전 pip가 이 녀석들을 설치하지 않을 것이기 때문에 성가신 일입니다. 그래서 지금은 no-ABI 이름이 더 나은 것 같습니다.

확인 - 현재 pypi 페이지에 이 텍스트를 추가할 것을 제안합니다.

pypi에서 배포되는 모든 numpy 휠은 BSD 라이선스를 받았습니다.

Windows 휠은 ATLAS BLAS / LAPACK 라이브러리에 연결되어 있으며 SSE2 명령어로 제한되어 있으므로 시스템에 최적의 선형 대수 성능을 제공하지 않을 수 있습니다. 대안은 http://docs.scipy.org/doc/numpy/user/install.html 을 참조하십시오.

나는 다르게 말할 것이다:

이러한 Windows 휠은 최적이 아닌 선형 대수 성능(http://speed.python.org와 같은 벤치마크 링크)을 가지고 있습니다. 이는 SSE2 명령어로 제한된 ATLAS BLAS/LAPACK 라이브러리에 연결되어 있기 때문입니다(그리고 제한되지 않은 명령어는 있을래?). 성능이 필요한 경우 이 플랫폼에서 컴파일된 Python 확장에 더 많은 성능을 제공하는 것을 목표로 하는 mingwpy 프로젝트를 지원할 수 있습니다. 보다 ??? 자세한 내용은 http://docs.scipy.org/doc/numpy/user/install.html , 대안은 http://docs.scipy.org/doc/numpy/user/install.html을 참조하세요.

글쎄 - mingwpy의 현재 numpy / scipy 버전은 openblas를 사용하지만 컴파일러로서의 mingwpy 대 MSVC와는 관련이 없다고 생각합니다. 이 휠과 함께 openblas를 배송할 수도 있지만, openblas가 아직 우리가 지원하는 표준 휠에서 사용할 만큼 충분히 안정적이지 않다는 것이 걱정되었습니다.

OpenBlas는 충분히 안정적인 것 같습니다. Anaconda가 Linux에 사용하는 것으로 알고 있습니다.
지금 빌드합니다. 업데이트된 Windows Python 3.5 x64 빌드가 없습니다.
거기에서 벤치마크는 MKL과 거의 같다는 것을 보여줍니다. 나는 확실히 그것을 시도 할 것입니다 경우
누군가가 바퀴를 조립할 수 있습니다.
2016년 2월 16일 오후 10시 36분에 "Matthew Brett" [email protected] 이 다음과 같이 썼습니다.

글쎄 - mingwpy의 현재 numpy / scipy 버전은 openblas를 사용하지만
컴파일러로서의 MSVC 대 mingwpy와 관련이 없다고 생각하십시오. 우리는 또한 발송할 수 있었습니다
이 바퀴가 달린 openblas지만 나는 openblas가 아직
우리가 지원하는 표준 휠에서 사용하기에 충분히 안정적입니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -185017546.

확인. 나는 최적이 아닌 성능의 소스에 대해 혼란스러워합니다. 나는 그 BLAS 라이브러리를 사용하지 않으며 그들이하는 일과 차이점을 모릅니다. 그래서 필사자를위한 이러한 옵션을 설명하는 것이 도움이됩니다. 음, 더 과학적으로 알 수 있습니다. . =) 최적의 성능을 가진 개방형 컴파일러가 없는 것이 문제라고 생각했습니다.

@mrslezak : OpenBLAS에 관해서는 확실히 동의할 수 있습니다. Lapack 패키지와 함께 Cygwin에 제공된 OpenBLAS 패키지는 문제 없이 NumPy와 SciPy를 모두 빌드할 수 있는 것으로 보입니다.

@mrslezak : 벤치마크에 대한 정보는 어디에서 찾을 수 있나요? 저는 scipy.org 에 대한 Windows 소스 빌드에 대한 문서를 작성하려고 하고 있으며 이는 이러한 라이브러리의 성능이 필요한 모든 사람에게 훌륭한 참조가 될 것입니다.

샷건 방식이 올바른 생각일까요? 다음과 같은 것:

• 안정: 성능이 있는 ATLAS, sse2 주의 사항
• 개발자: OpenBLAS는 mingwpy 및 binstar 참조
• Alt: MKL @cgohlke , MKL @continuum 및 @enthought
  주의 사항: 바이너리는 호환되지 않습니다.
  scipy 및 Matthew Brett의 github numpy wiki에서 자세한 정보 링크

@techtonik 나는 GCC가 모든 컴파일러가 구축할 수 있는 동등한 코드에서 MSVC 또는 ICC보다 다소 성능이 떨어질 것으로 예상합니다. 문제는 Fortran에 있는 경쟁 버전의 Lapack을 빌드할 수 있는 무료(python.org-cpython 호환) 컴파일러가 없다는 것입니다(SciPy에는 다른 Fortran 구성 요소도 있음). OpenBLAS의 순수한 BLAS 부분(아마도 Atlas도)은 실제로 MSVC로 빌드할 수 있지만 MSVC는 인라인 어셈블리가 필요한 부분을 빌드할 수 없으므로 경쟁력이 없습니다.

편리한 64비트 MKL이 없지만(파기할 경우 어딘가에 conda에서 32비트를 사용할 수 있음) 다음은 @matthew-brett이 참조 및 모래에 대해 빌드한 Atlas dll을 비교하는 Julia에서 실행되는 몇 가지 벤치마크입니다. BLIS의 브리지 구성 및 Julia와 함께 제공되는 OpenBLAS 빌드 https://gist.github.com/54da587b01b7fb163103

요약: openblas(skylake에서 최신 openblas 커널은 haswell임)는 아틀라스보다 23배, 참조 블리스보다 44배, 샌드브리지 블리스보다 5.5배 빠릅니다. 하스웰 블리스가 얼마나 가까운지 확인하기 위해 시도해 볼 수 있습니다.

흠 - BLIS 컴파일을 위한 빌드 스크립트가 있는 것 같지 않습니까?

다양한 프로세서에 대해 BLIS 빌드를 만들고 런타임에 하나를 선택하는 것이 가치가 있다고 생각하십니까? 대부분의 프로세서에 대해 대부분의 성능을 캡처하는 프로세서의 작은 하위 집합이 있습니까?

주석에 있지만 여기 (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

사용 가능한 항목은 다음과 같습니다. https://github.com/flame/blis/tree/master/config

Intel x86과 관련하여 참조, 더닝턴, 샌드브리지 및 하스웰은 꽤 좋은 범위를 커버할 것입니다. 또한 AMD를 위한 불도저, 파일드라이버 및 캐리조(최근 BLIS에 찬성하여 ACML 개발을 중단했기 때문에 최소한 찬성 투표임).

https://github.com/flame/blis/tree/master/build/auto-detect 에 재사용할 수 있는 자동 감지 코드가 있습니다(현재 BLIS의 구성 시간에만 실행되지만 그것이 의미하는 것은 아닙니다. 다른 용도로 재사용할 수 없음), 사용하려는 Python에 이미 CPU 제품군 식별 코드가 있는지 여부에 따라 다릅니다.

Python에 이미 CPU 제품군 식별 코드가 있는지 여부에 따라

도움이 되나요? http://stackoverflow.com/a/35154827/239247

대부분 그로부터 파생된 프로세서 제품군을 원하지만 https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c 는 정확히 길거나 복잡하지 않습니다. SO에서 링크 된 numexpr 소스는 문자열 출력 (적어도 Linux에서는)에서 정규식 일치를 수행하고 있으며 최근 아키텍처가 많이 나열되지 않은 것 같습니다.

openblas는 Haswell blis보다 3.4배 빠르며 dunnington(기본적으로 내가 생각하는 nehalem penryn과 동일) blis보다 17배 빠릅니다. 흥미로운 점은 멀티스레딩이 이러한 실행에서 성공적으로 작동하고 있다고 생각하지 않는다는 것입니다. 기본 설정은 sandybridge 및 haswell에 대해 openmp를 활성화합니다. 아마도 mingw pthreads가 더 잘 작동할 것입니다. OMP_NUM_THREADS 를 설정해도 큰 차이가 없는 것 같습니다.

나는 ATLAS 3.11이 3.10 버전보다 64비트에서 훨씬 더 잘해야 한다고 생각하지만 Clint Whale의 도움을 기대하면서 현재로서는 빌드할 수 없습니다.

Tony - 32비트 ATLAS 휠을 테스트할 시간/에너지가 없다고 생각하십니까? 상대적으로 훨씬 더 잘해야합니다.

내 자신의 선호도는 이 ATLAS 휠을 사용하는 것이므로 다른 포장업자가 일종의 휠 배송에 의존할 수 있습니다. 성능을 개선할 수 있는 좋은 방법을 찾으면 곧 새로운 numpy 릴리스가 나올 것이며 1.10.4에서도 휠을 업데이트하기 위해 항상 유지 관리 릴리스를 수행할 수 있습니다.

@matthew-brett : 빠른 질문입니다. numpy 가 Cygwin에서 ATLAS 빌드를 감지하지 못하는 이유는 무엇입니까? 네이티브 Windows 환경에서는 완벽하게 감지할 수 있었지만 Cygwin에서 스크립트를 실행하려고 했을 때 numpy 가 ATLAS 로 컴파일되지 않았습니다.

Cygwin의 python을 사용하는 경우 호환성을 위해 cygwin에서 빌드한 아틀라스 버전이 필요할 수 있습니다.

32비트 Julia는 32비트 Atlas dll을 열지 못하는 것 같습니다. 이유는 모르겠지만 이미 32비트 Openblas가 있고 기호 이름이 충돌하기 때문일 수 있습니다.

하지만 @matthew-brett 버전은 Cygwin으로 빌드되었기 때문에 혼란스럽습니다.

mingw 라이브러리로 교차 컴파일된 Cygwin 빌드 환경. cygwin1.dll이 아닌 msvcrt.dll에 어떻게 연결되어 있는지 확인하시겠습니까?

댓글을 올리자마자 갑자기 그게 아닐까 하는 의심이 들었습니다. 아아, 처음부터 만들어야 할 것 같습니다. @tkelman 감사합니다!

dlopen 문제가 파악되었습니다(https://github.com/matthew-brett/np-wheel-builder/pull/1 참조 및 https://github.com/JuliaLang/julia/issues/15117 참조). 오류 메시지).

32비트에서 아틀라스는 오픈블라스보다 3.6배 느립니다. 32비트 openblas는 동일한 크기 문제에 대해 64비트 openblas보다 3배 느립니다. 최신 커널 제품군은 32비트 시스템의 openblas에서 활성화되지 않습니다.

...
결론: 최선의 선택이 무엇인지 진지하게 모르지만 BLIS 물에 발가락을 담그는 것이 좋은 생각인 것 같습니다. 우리가 기다리기로 결정하더라도 우리는 적어도 무언가를 배울 것입니다.

적어도 일부 테스트/벤치마킹은 유용할 것입니다. 그러나 이 시점에서는 _Windows_ 문제와 거의 관련이 없습니다. BLIS는 현재 Linux 전용입니다. OSX 빌드 지원을 위한 공개 PR이 있으며 Windows는 매우 멀리 떨어져 있습니다. 더군다나 어제 32비트 Linux에서 시도했지만 작동하지 않습니다. ./configure auto && make 일부 어셈블러 코드( sandybridge )에서 끔찍하게 충돌합니다. reference 만 만들 수 있습니다.

따라서 0단계는 numpy.distutils 에 BLIS 지원을 추가하는 것입니다(대부분 이미 작동함). 1단계는 Linux에서 테스트하여 reference 이상이 작동하는지 확인하고 2단계는 벤치마킹, ..., 단계Windows에서 뭔가.

@matthew-brett PyPI에 대해 제안한 텍스트가 괜찮은 것 같습니다. 어떤 pip 버전이 ABI 태그가 있는 이름을 무시합니까? Pip은 요즘 스스로를 업그레이드해야 한다고 잔소리를 많이 하므로 많은 사람들이 최신 버전을 사용하기를 바랍니다. 그리고 >1(.5)년 된 버전은 기본적으로 바퀴를 설치하지도 않았습니다.

@rgommers 위의 테스트는 Windows에서 수행되었습니다. MSVC는 아니지만 mingwpy 또는 openblas는 크게 다르지 않습니다. clang은 아마도 작동하지만 심볼릭 링크를 피하기 위해 blis에서 repo 재구성이 필요합니다.

나는 blis에 대해 Julia 또는 numpy의 테스트를 실행하지 않았지만 blis는 자체 단위 테스트를 통과하고 있었습니다. 2014년의 경험보다 상황이 훨씬 나아져서 그렇게 될 것이라고 생각했습니다. 여전히 멀티스레딩이 제대로 작동하도록 하는 방법을 알아내야 하지만 그것으로 이미 성능 경쟁력이 있는 blis가 있을 수 있습니다.

참조 구성이 현재 32비트 x86에서 작동하는 유일한 blis인 것 같습니다. 그렇게 하려면 새로운 어셈블리 마이크로커널을 작성해야 할 수도 있습니다. 아래 njsmith의 의견을 참조하십시오.

@tkelman , 32비트용 OpenBLAS 커널 관련 https://github.com/numpy/numpy/issues/5479#issuecomment -185096062: priv. 얼마 전에 Werner Saar로부터 받은 메시지 최신 아키텍처용 Intel 32비트 커널 작업을 하는 사람이 없습니다. 따라서 이것은 미래에 변경될 가능성이 없는 사실입니다. 초점은 Intel 64비트 및 ARM 프로세서에 있습니다.

@tkelman , C-runtime 관련 https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: IMHO ATLAS 및 OpenBLAS가 C-runtime(파일 설명자 및 힙 ). _제가 옳았으면 합니다_. ATLAS 빌드가 스택 크기를 늘리는 데 유용할 수 있습니다. 이것은 연결하는 동안 플래그로 제공될 수 있습니다. 예:

-Wl,--stack,16777216

토론 ATLAS 대 OpenBLAS: @matthew-brett 덕분에 이제 SSE2 기반 ATLAS DLL을 사용할 수 있습니다. CPU 런타임 감지를 비활성화하려면 이 Atlas 빌드를 SSE2 지원 대상에 대한 OpenBLAS 빌드와 비교해야 합니다(또는 단순히 OPENBLAS_CORETYPE=NORTHWOOD 설정 - 기본적으로 PENTIUM4). 물론 일반 OpenBLAS 빌드는 CPU 런타임 감지 덕분에 훨씬 더 많은 CPU 변형을 이용할 수 있습니다. 이것이 OpenBLAS가 ATLAS에 비해 성능이 더 좋은 이유 중 하나입니다. 또 다른 질문은 OpenBLAS의 신뢰성입니다. 수집된 BLAS, LAPACK 테스트가 있는 저장소가 도움이 될 수 있습니다.

BLIS/Flame 관련: 흥미롭지만 적어도 오늘만큼은 높이 매달린 과일입니다.

그러나 ATLAS와 OpenBLAS 중에서 선택하는 방법에 대한 결정은 나에게 명확하지 않습니다.

Ralf - pip 8은 새로운 Windows ABI 태그로 휠을 설치하지만 pip 7은 설치하지 않습니다. Pip 7 및 Pip 8은 경고 없이 ABI 태그 없이 바퀴를 설치합니다.

여전히 많은 pip 7이 있으며 2015년 8월에 출시되었습니다. 따라서 적어도 잠시 동안은 좀 더 호환되는 이름을 고수하는 것이 좋습니다.

BLIS 조사에 +1. 장기적으로 좋은 해결책인 것 같습니다. 우리는 Eigen을 전혀 고려하지 않았습니까? 부분적인 LAPACK 인터페이스 구축을 지원하며 대부분의 코드에 대한 라이선스는 MPL2입니다. NumPy에 충분할 수 있습니다.

나는 BLIS cpu 감지 코드에서 AVX 명령어를 찾지 못하면 참조 구현으로 대체되는 경우가 많다는 것을 알아차렸습니다.

Ian : 이것은 1년 정도 전의 Eigen 의 상태입니다.

더군다나 어제 32비트 Linux에서 시도했지만 작동하지 않습니다. ./configure auto && make 는 일부 어셈블러 코드(sandybridge용)에서 끔찍하게 충돌합니다. 참조를 구축할 수만 있습니다.

config/ 의 내용을 보면 -- "sandybridge", "haswell"과 같은 다양한 이름의 "구성"은 실제로 미리 지정된 설정을 포함하는 사전 패키지된 "스타터" 구성입니다. CPU 튜닝 관련 설정뿐만 아니라 스레딩 모드 설정, 컴파일러 설정 등). 그리고 "sandybridge"라는 구성은 x86-64 구성입니다. 자동 구성에서 선택한 버그처럼 들리지만 x86-32에서는 작동하지 않습니다 :-). BLIS는 32비트 x86 커널과 함께 제공되는 것으로 보이지만( kernels/x86 참조) 현재 사전 패키징된 구성에서 이를 사용하지 않는 것 같습니다. 새 구성을 만드는 것은 대부분 간단합니다. 마법의 한 조각은 bli_kernel.h 파일에 있으며 내부 커널과 몇 가지 버퍼 크기의 이름을 지정합니다. x86-32에 대한 제안 사항이 있으면 업스트림에 문의할 수 있습니다.

또한:

BLIS는 현재 Linux 전용입니다. OSX 빌드 지원을 위한 공개 PR이 있으며 Windows는 매우 멀리 떨어져 있습니다.

위의 몇 가지 의견, @tkelman 은 Windows에서 BLIS를 구축하고 벤치마킹하고 있습니다 :-)

OpenBLAS 0.2.12를 사용한 이전 원유 test_dot 벤치마크:

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

(이전 결과) MKL과 비교

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

64비트 ATLAS:

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

따라서 Openblas와 MKL(고마워요, conda)을 Haswell BLIS 구성과 직렬로 비교할 때 모두 dgemm에서 서로 최대 10-20% 내에 있습니다. 다음은 각 구성의 Windows dll을 교차 컴파일하기 위해 도커 허브에 성공적으로 구축된 도커 파일입니다(제외 https://github.com/flame/blis/pull/37#issuecomment-185480513, 제대로 연결되지 않은 불도저 제외) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

Travis의 services: docker 구성과 유사한 것을 연결하고 바이너리 아티팩트를 github 릴리스/bintray/무엇이든 배포하는 작업을 시도할 수 있습니다.

BLIS CPU 감지 -> 템플릿 코드를 보고 있었습니다. https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

다음은 Python 재작성입니다. 고급 템플릿 중 하나를 수락하는 데 조금 더 자유로워야 합니다(OS가 C 코드보다 AVX를 사용할 수 있다고 믿을 가능성이 더 높음): https://gist.github.com/matthew-brett /a53778f99b7062cc332d

내가 테스트한 모든 컴퓨터에서 이 알고리즘은 '참조'를 반환합니다. 아마도 다른 사람이 사용하고 싶지 않은 오래된 컴퓨터를 사용하여 빌드봇 팜을 구출했기 때문일 것입니다.

lapack 없이 참조 BLIS에 대해 numpy를 컴파일하면 원시 벤치마크에서 다음을 얻을 수 있습니다.

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

두 배열(1000, 1000)의 내적은 12초입니다. 따라서 Tony도 발견한 것처럼 참조 BLIS는 lapack_lite를 사용하는 동일한 numpy의 라이브러리가 없는 기본 빌드와 관련된 최악의 옵션입니다.

따라서 광범위한 시스템에서 합리적인 성능을 제공하려면 구형 시스템을 다루는 더 많은 템플릿이나 더 자유로운 CPU 감지 -> 템플릿 매핑이 필요하다고 생각합니다.

@matthew-brett 언제 새로운 ATLAS 64비트 Windows 휠이 나올 것으로 예상할 수 있습니까? 어떤 버전? v1.10.2? 그들은 pypi에만 있습니까 아니면 소스 포지에만 있습니까? 어떤 발표라도 하실 건가요? 정말 감사합니다!

@matthew-brett 같은 기계에서 아틀라스와 참조 블리스의 비율은 얼마였나요? 내가보고있는 약 2의 요소와 비교할 수 있습니까? blis에서 작동하도록 멀티스레딩을 얻었습니다. 제대로 rtfm하지 않았습니다(https://github.com/flame/blis/wiki/Multithreading). 자동으로 활성화되지 않고 4개의 다른 환경 변수가 있습니다. . 이 패치 https://gist.github.com/0fc9497a75411fcc0ec5 를 사용하여 모든 구성에 대해 pthreads 기반 병렬 blis를 활성화하고 BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 설정하면 Haswell blis는 기본적으로 내 컴퓨터의 mkl 및 openblas와 연결됩니다. BLIS_JR_NT 2로 설정하면 병렬 참조 blis가 대부분의 방법으로 아틀라스를 따라잡고 3개의 스레드로 더 빠릅니다.

@tkelman IMO NumPy GitHub Wiki 페이지에서 BLIS에 대한 진행 상황을 문서화할 수 있다면 유용할 것입니다. 또한 NumPy-BLIS-FLAME 휠(및 가능하다면 SciPy-BLIS-FLAME 휠)을 만들기 위해 mingwpy와 유사한 계획을 제안하는 것도 흥미로울 수 있다고 생각합니다.

@tkelman : 내가 명확히 하기 위해 -- 당신의 아틀라스는 쓰레드되어 있지 않습니까?
고려해야 할 또 다른 사항은 -msse2 또는 reference 빌드 설정과 유사한 것을 추가하는 것입니다. 기본적으로 최대로 호환되며 컴파일러가 SSE를 사용하도록 허용하지 않지만 적어도 numpy-land 나는 다른 이유로 어쨌든 지원되는 최소 구성으로 SSE2를 지원한다는 것을 알고 있습니다...

FLAME이 현재 일반 LAPACK과 관련이 있는지 없는지 모르겠습니다. 묻고 싶습니다.

아마도 우리는 이 문제를 계속 복잡하게 만드는 대신 BLIS 문제에 대한 새로운 문제를 열어야 할 것입니다 :-)

이 스레드의 경우 - BLIS가 빌드 타임에 사용하는 것과 동일한 규칙을 사용하여 런타임에 선택된 다양한 BLIS 커널과 함께 휠을 이미 출하할 수 있다고 생각합니다. Windows의 64비트 ATLAS가 특히 나쁨에도 불구하고(ATLAS의 경우) 64비트 ATLAS보다 성능이 떨어집니다.

그러나 - 참조 빌드가 64비트 ATLAS보다 빠른 경우 - 예를 들어 -msse2와 같이 - 실제 옵션이 될 것입니다.

SSE2는 64비트용 최소 구성이므로 참조 컴파일에 -mfpmath=sse -msse2 와 같은 것을 사용하는 것이 안전합니다.

아마도 우리는 이 문제를 계속 복잡하게 만드는 대신 BLIS 문제에 대한 새로운 문제를 열어야 할 것입니다 :-)

그것은 좋은 생각이 될 것입니다(편집: https://github.com/numpy/numpy/issues/5479#issuecomment-184472378에서 잔디에 대한 @njsmith 의 감정을 감안할 때 "Occupy BLIS"라는 제목을 제안해도 될까요?) . @matthew-brett이 기존 Atlas 휠을 업로드하는 것으로 진행하면 현재로서는 이 휠을 닫는 데 충분할 것이며 향후 작업은 새로운 문제에 맡겨야 한다고 생각합니다.

확실히 하기 위해 -- 당신의 아틀라스는 쓰레드로 되어 있습니다. 맞죠?

내 지도책은 https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds 의 dll이지만 아직 1개 이상의 스레드를 성공적으로 사용하는 것을 보지 못했습니다. 환경 변수가 누락되었습니까?

고려해야 할 또 다른 사항은 -msse2 또는 reference 빌드 설정과 유사한 것을 추가하는 것입니다. 기본적으로 최대한 호환되며 컴파일러가 SSE를 사용하는 것을 허용하지 않는 것처럼 보입니다.

SSE2는 x86_64 사양의 일부이므로 32비트에서만 관련이 있습니다. Julia에서는 32비트 빌드에 -march=pentium4 를 추가합니다.

FLAME이 현재 일반 LAPACK과 관련이 있는지 없는지 모르겠습니다. 묻고 싶습니다.

아직 불꽃을 만지지는 않았지만 가지고 놀 가치가 있습니다. 결국 mingwpy에 대한 백업 계획 대안으로 WINdows Clang을 사용할 수 있습니다. (편집: 실제로 이것은 scipy에서 포트란을 수정하지 않으므로 아닐 수도 있음)

@matthew-brett: (틀릴 수 있음) dunnington 커널에는 SSE3만 필요하며 Steam 하드웨어 설문조사에 따르면 시스템의 99.94%(SSE2의 경우 99.99%)에 존재한다고 주장합니다. 따라서 대다수의 시스템이 이를 처리할 수 없다는 것을 발견하면 잘못된 것 같습니다. 그것이 cpuid 코드의 버그인지, 어떻게 든 정말 대표성이 없는 테스트 시스템 세트를 갖고 있는지, 또는 제 이해로는 커널이 필요로 하는 것.

위의 요지에서 CPU 감지 코드의 Python 재작성을 게시했습니다. 템플릿 선택은 보수적이며 기본적으로 다른 템플릿이 작동했을 수 있는 위치를 참조하도록 설정되어 있습니다.

BLIS에 연결하려면 다음과 같은 site.cfg 가 필요했습니다.

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

나는 또한 이것을했고 그것이 필요하다고 가정합니다 (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):

CPU의 런타임 감지를 허용하는 유틸리티: https://github.com/matthew-brett/x86cpu

이것이 numpy 자체에 포함될 수 있는 후보일 수 있지만 컴파일된 단일 cpuinfo 모듈을 Windows 휠의 numpy 트리에 복사할 수도 있습니다.

안녕 모두. 생각: 다양한 벡터 라이브러리로 빌드된 여러 개의 다른 numpy 휠을 게시하려면 다른 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

Gohlke의 바퀴를 업로드하려고 2개를 등록했지만 PyPI에서 거부했습니다. URL에 오신 것을 환영합니다.

gh-7294는 numpy.distutils 에 BLIS 지원을 추가합니다. 누군가 이것이 예상대로 작동하는지 확인할 수 있다면 좋을 것입니다.

여전히 많은 pip 7이 있으며 2015년 8월에 출시되었습니다. 따라서 적어도 잠시 동안은 좀 더 호환되는 이름을 고수하는 것이 좋습니다.

Pip 7.0은 아직 그렇게 오래되지 않았으므로 의미가 있습니다.

... BLIS는 32비트 x86 커널과 함께 제공되는 것으로 보이지만(kernels/x86 참조) 현재 사전 패키징된 구성에서 이를 사용하지 않는 것 같습니다.

그것은 그것을 설명합니다. 감사합니다.

감사합니다 Ralf - 테스트하겠습니다.

나는 이것이 새로운 쓰레드를 필요로 한다는 것을 알고 있지만, 우리는 이제 릴리스를 위해 BLIS 빌드를 사용할 수 있는 것에 매우 가깝습니다.

지금 우리에게 필요한 것은 ATLAS 64비트 Windows 빌드보다 다소 빠르게 작동하는 SSE2가 있는 시스템과 SSE3이 있는 시스템에 권장되는 템플릿뿐입니다.

나는 이것이 새로운 쓰레드를 필요로 한다는 것을 알고 있지만, 우리는 이제 릴리스를 위해 BLIS 빌드를 사용할 수 있는 것에 매우 가깝습니다.

어, 기술적으로 작동하게 만드는 것이 가능할 수도 있지만, 그렇게 벽 너머로 빌드를 던지는 것은 여전히 ​​좋은 계획이 아닙니다. 우리는 아직 Linux나 OS X에서 BLIS에 대한 진지한 테스트조차 하지 않았습니다. 따라서 Windows에서 BLIS FAQ는 다음과 같이 말합니다 .

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.

, 확실히 너무 이르다. 테스트 외에도 일부 벤치마킹도 좋은 아이디어라고 생각합니다.

물론입니다. 하지만 Tony가 보여주듯이 크로스 컴파일을 사용하여 Windows용 BLIS를 빌드하는 것은 실제로 어렵지 않습니다. 실험적인 것은 - 내 생각에 - 우리가 사용하지 않는 MSVC 빌드 시스템입니다.

지금은 Windows 휠에 BLIS를 사용할 것을 제안하고 있지만 물론 manylinux 빌드에서도 작동하도록 하는 것이 매우 좋습니다.

평균적으로 상당한 성능 향상을 얻지 못한다면 BLIS를 사용해서는 안 되며 현재로서는 매우 새로운 프로세서를 제외하고는 사용하지 않아야 한다는 데 전적으로 동의합니다. 그것은 몇 가지 새로운 템플릿으로 간단하게 고칠 수 있습니다. 그런 경우인지 알고 싶습니다.

정확성을 위해 나도 동의합니다. 그걸 보여주면 어때

a) 모든 numpy 테스트는 모든 버전의 Windows에서 통과합니다.
b) 모든 numpy 및 scipy 테스트는 manylinux 시스템을 통과합니까?

BLIS 템플릿을 런타임에 선택 가능하게 만들고 최신 시스템에서 모든 커널을 테스트할 수 있습니다. 오래된 불쾌한 기계에서도 테스트할 수 있습니다.

지금은 Windows 휠에 BLIS를 사용할 것을 제안하고 있지만 물론 manylinux 빌드에서도 작동하도록 하는 것이 매우 좋습니다.

manylinux 는 덜 중요하다고 생각합니다. 전체 스택이 있는 패키지 관리자와 훨씬 더 쉽게 컴파일할 수 있는 사용자가 있기 때문입니다. 이 numpy + BLAS/LAPACK 컨텍스트에서 걱정하기 전에 먼저 전체 Manylinux 개념이 시작되는 것을 봅시다. :)

Windows의 경우 우리의 우선순위는 다음과 같습니다.

1) 전체 스택 솔루션(OpenBLAS/ATLAS/BLIS 중 하나와 함께 MingwPy 필요)
2) 스톱갭 바이너리 휠(ATLAS 빌드와 함께 올라갈 예정인 휠이 있습니다)
3) (1)의 성능을 증가시킨다. 여기에서 BLIS가 들어올 수 있습니다.

따라서 Windows에서 BLIS를 사용하여 크게 서두를 필요가 없습니다.

평균적으로 상당한 성능 향상을 얻지 못한다면 BLIS를 사용해서는 안 되며 현재로서는 매우 새로운 프로세서를 제외하고는 사용하지 않아야 한다는 데 전적으로 동의합니다. 그것은 몇 가지 새로운 템플릿으로 간단하게 고칠 수 있습니다. 그런 경우인지 알고 싶습니다.

동의합니다. 의미가 있으려면 상당한 이득이 있어야 합니다. 실제로 얼마나 많은 작업이 필요한지 확인하기가 약간 어렵습니다.

정확성을 위해 나도 동의합니다. 그걸 보여주면 어때

a) 모든 numpy 테스트는 모든 버전의 Windows에서 통과합니다.
b) 모든 numpy 및 scipy 테스트는 manylinux 시스템을 통과합니까?

그 좋은 소리. scikit-learn 도 포함하는 것이 합리적이며 이는 상당히 중요한 linalg 사용자입니다.

나는 blis와 libflame이 얼마 전에 공개된 ACML 코드베이스의 일부라는 것을 몰랐습니다.

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/

그럼에도 불구하고: 수많은 CPU 아키텍처에서 테스트할 MSVC 또는 mingwpy를 사용하여 numpy/scipy 빌드에 대한 4가지 다른 가속 BLAS/Lapack 구현을 비교하는 문제를 해결하는 방법: Pentium4에서 skylake까지?

@carlk 를 잘 찾았습니다. acml 및 오픈 소스 acl을 삭제한다고 발표한 것을 기억하지만 blis/libflame을 채택한 것은 기억나지 않습니다. bsd 라이선스는 매우 좋은 소식입니다! numpy와 Julia를 대상으로 하기 위해 ut Austin의 AMD 및 shpc와 협력할 방법이 있습니까?

msys2 및 haswell 구성을 사용하여 libblis.a를 교차 컴파일하고 커널 심볼릭 링크를 패치하여 모든 테스트를 통과할 수 있었지만 libflame을 빌드할 수 없었습니다. 내 행복 토론 메일 링리스트 게시물. 또한 개인적으로 lapack에서 libblis.a로 연결하는 방법을 알 수 없었지만 그다지 노력하지 않았습니다.

MKL의 커뮤니티 라이선스를 사용하면 pypi에서 MKL 휠을 제공할 수 없습니다. 라이선스가 실제로 호환되지 않습니까? 아니면 ifort 없이 scipy를 구축하는 것이 불가능합니까?

한 가지 문제는 아마도 scipy에 속할 것입니다. 언급되지 않은 것은 scipy의 나머지 Fortran 파일입니다. 멍청한 질문에 대해 죄송하지만 왜 우리가 그것들을 사용해야 합니까? 나에게 Fortran과 무료 멀티플랫폼 컴파일러의 부재가 여기에서 진짜 문제인 것 같습니다. 그것이 결국 mingwpy가 해결하고자 하는 것 아닙니까? 무료 MKL이나 미래의 마법 acl blis/flame이 주어지면 c-컴파일러를 가진 사람은 누구나 scipy 스택을 빌드할 수 있지만 *.f 파일이 아닙니다.

@mikofski , blis가 msys2로 컴파일될 수 있다는 소식을 듣게 되어 기쁩니다. libflame도 마찬가지인가요? Lapack API용 libflame이 필요하다고 생각합니다.
개인적으로 MSVC를 numpy로 컴파일하고 mingwpy로 컴파일된 scipy와 함께 사용하는 것이 _가능합니다_. long double == double이 되도록 하려면 gcc 플래그에 -mlong-double-64 를 추가해야 합니다.

이 동작을 gcc에서 기본으로 설정하는 것은 까다롭습니다. 저는 일주일부터 이 문제를 해결하고 있습니다.

내일은 scipy 바퀴를 가지고 올게요. 이것은 @matthew-brett의 numpy wheel에서 제공하는 Atlas를 기반으로 합니다.

그럼에도 불구하고 저는 지금 OpenBLAS를 사용하는 것에 찬성합니다.

한 가지 문제는 아마도 scipy에 속할 것입니다. 언급되지 않은 것은 scipy의 나머지 Fortran 파일입니다. 멍청한 질문에 대해 죄송하지만 왜 우리가 그것들을 사용해야 합니까?

매우 유용하고 고성능인 코드가 많기 때문입니다. BLAS/LAPACK 뿐만 아니라 scipy.sparse.linalg , scipy.linalg , scipy.special 및 scipy.interpolate 가 포트란입니다. 또한 Scipy는 Fortran 코드가 있는 유일한 프로젝트가 아니며 bvp_solver와 같은 다른 패키지와 f2py 로 래핑한 사람들의 Fortran 코드가 있습니다.

사실, Carl을 잘 찾았습니다.

그럼에도 불구하고: 수많은 CPU 아키텍처에서 테스트할 MSVC 또는 mingwpy를 사용하여 numpy/scipy 빌드에 대한 4가지 다른 가속 BLAS/Lapack 구현을 비교하는 문제를 해결하는 방법: Pentium4에서 skylake까지?

이것은 실제로 적절한 자동화된 빌드/테스트/벤치마크 프레임워크가 필요합니다. 우리는 아주 오래된 CPU 아키텍처(문제가 작동하는 한 괜찮음)에 신경 쓸 필요가 없으며 MSVC도 마찬가지라고 생각합니다. 그러나 이것을 올바르게 설정하려면 여전히 약간의 작업이 필요합니다.

@rgommers 감사합니다!

안녕 모두. 생각: 다양한 벡터 라이브러리로 빌드된 여러 개의 다른 numpy 휠을 게시하려면 다른 PyPI 패키지 이름을 사용할 수 있습니다.

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

Gohlke의 바퀴를 업로드하려고 2개를 등록했지만 PyPI에서 거부했습니다. URL에 오신 것을 환영합니다.

@hickford 제발 그러지 마세요. 이와 같은 바이너리를 재배포하는 것은 MKL 라이센스를 위반하는 것이며(개인 라이센스가 없는 한) 이를 수행하는 올바른 방법이 아닙니다. 앞으로는 추가 기능( numpy[atlas] , numpy[openblas] 등)을 통해 일부 맛을 배포할 수 있습니다.

또한 묻지 않고 PyPi에서 다른 사람의 바퀴를 재배포하는 것은 아마도 할 일이 아닐 것입니다....

Mingwpy 및 CPython과 같은 C 런타임에 연결에 의존하는 포트란 문제는 속도는 BLIS 해결할 수있는 문제 적은 문제와 실험을하지만, 누군가에 의해 독립적으로 수행 할 수 있습니다, @carlkl에 제한됩니다. 불행히도 지금 BLIS를 보기 위해 개인적인 시간을 다 써버렸지만 #7294를 참조하십시오.

Tony - 도움을 주셔서 대단히 감사합니다.

64비트에 최신 ATLAS(3.11.38) 빌드를 추가했습니다.

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

이것은 Windows에서 3.11.38을 컴파일하는 데 문제가 있기 때문에 직렬(스레드되지 않은) 빌드이지만 3.10.1보다 약간 더 빨라야 하며 내 간단한 벤치마크에 있습니다.

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

이전 3.10.1 빌드와 비교(위 참조):

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

@tkelman - Julia에서 이 빌드를 벤치마킹할 수 있습니까?

MKL 바이너리에 대한 사전 메모로 여기로 뛰어들어서 죄송합니다. 인텔은
모두에게 무료이므로 재배포를 허용해야 하는 커뮤니티 버전...
2016년 3월 2일 오후 3시 88분에 "Matthew Brett" [email protected] 이 다음과 같이 썼습니다.

64비트에 최신 ATLAS(3.11.38) 빌드를 추가했습니다.

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

이것은 3.11.38 컴파일 문제로 인해 직렬(스레드되지 않은) 빌드입니다.
Windows에서는 3.10.1보다 약간 더 빨라야 하며 내 간단한
기준:

[2]에서: %timeit test_dot()
루프 1개, 최고 3개: 루프당 1.65초

이전 3.10.1 빌드와 비교(위 참조):

[10]에서: %timeit test_dot()
루프 1개, 최고 3개: 루프당 2.41초

@tkelman https://github.com/tkelman - 이 빌드를 벤치마킹할 수 있습니까?
줄리아?

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -191431331.

@mrslezak - 라이센스는 재배포를 허용하지만 인텔이 소프트웨어 사용의 결과로 소송을 당하는 경우 재배포자가 모든 법적 비용에 대해 책임을 지게 합니다. 또한 결과 바이너리는 BSD 라이선스를 받을 수 없습니다. 참조: http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

'있는 그대로 제공되며 어떠한 책임도 지지 않습니다.
그것의 사용으로 인해 발생할 수 있는 금전적 손실' 또는 그 영향에 대한 것?
2016년 3월 2일 오후 6시 22분에 "Matthew Brett" [email protected] 이 다음과 같이 썼습니다.

@mrslezak https://github.com/mrslezak - 라이센스가 허용합니다
재배포하지만 다음과 같은 경우 재배포자가 모든 법적 비용에 대해 책임을 지도록 합니다.
인텔은 소프트웨어 사용의 결과로 소송을 당합니다. 또한 그 결과
바이너리는 BSD 라이선스가 될 수 없습니다. 보다:
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -191505500.

우리는 Intel의 라이선스에 동의해야 하기 때문에 그것이 효과가 없을 것이라고 생각하지 않습니다. Intel의 라이선스에는 소송을 당할 경우 법적 비용을 지불해야 한다고 되어 있습니다. 라이선스 계약에서 사용자에게 인텔을 고소하지 않도록 요구할 수 있으며, 따라서 사용자가 인텔을 고소하고 인텔이 우리에게 돈을 요구하면 해당 비용에 대해 사용자를 고소할 수 있습니다. 라이선스는 우리를 BSD에서 더 멀리 데려갈 것이고 사용자가 명시적으로 동의하도록 요구할 것입니다. 이는 pip에 의해 설치된 바퀴의 경우 실용적이지 않습니다.

SSE3용 ATLAS를 빌드하면 SSE2 ATLAS에 비해 5%의 성능 이점만 제공되지만 빌드가 까다로웠고 SSE3에 대해 가장 분명한 활성화 플래그를 비활성화하고 -msse3 만 사용해야 했습니다.

나는 이 휠을 배포할 것을 제안하는 numpy 메일링 리스트에 메일을 썼습니다. https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@matthew-brett Python 응용 프로그램으로 Windows를 지원하는 사람으로서 감사합니다.

@matthew-brett, 아틀라스 빌드 스크립트 저장소에 2개의 문제를 추가했습니다.
https://github.com/matthew-brett/atlas-build-scripts/issues 참조

첫 번째 https://github.com/matthew-brett/atlas-build-scripts/issues/1 이 중요합니다. numpy-atlas.dll은 많은 기호로 내보내므로 가져오기를 해킹하지 않고 mingwpy를 더 이상 사용할 수 없습니다. 도서관.

@matthew-brett 더 이상 벤치마킹을 하느라 조금 바빠서 죄송합니다. 이전 아틀라스 빌드가 멀티스레드였습니까? 여러 코어에서 첫 번째 빌드를 실행할 수 없었습니다. julia에 대해 잘 알지 못하더라도 요점은 실행하기에 매우 간단해야 합니다. 아니면 액세스할 수 있는 것보다 새로운 하드웨어에 주로 관심이 있으셨습니까?

걱정하지 마십시오. 모든 것을 포기하고 벤치마크를 실행할 것이라고 기대하지 않았습니다.

사실 내 최신 아틀라스 빌드는 멀티스레드가 아니었습니다. ATLAS 3.11은 Windows에서 스레딩이 작동하도록 하려면 더 많은 작업이 필요합니다.

벤치마크의 경우 귀하가 실행한 다른 벤치마크와 비교하는 것이 더 쉬울 거라고 생각했는데 Windows가 켜진 오래된 하드웨어만 있습니다. 적중률은 내 컴퓨터보다 귀하 컴퓨터에서 훨씬 더 큽니다.

Windows 휠이 이제 pypi에 있습니다. https://pypi.python.org/pypi/numpy/1.10.4

Tony에게 죄송합니다. 예, 이전 3.10 ATLAS 빌드는 멀티스레드였습니다.

이제 이 문제를 종료할 수 있습니다. @matthew-brett numpy 조직 아래에서 https://github.com/matthew-brett/np-wheel-builder 를 전송하거나 도구 폴더 아래의 numpy 저장소에 PR로 기여해야 할 수도 있습니다.

Ralf - np-wheel-builder 이 어디로 가야 하는지에 대한 제안이 있으십니까? numpy/공급업체?

내가 생각하는 numpy 조직 아래에 별도의 새 저장소( numpy-wheel-builder ?)를 선호합니다. 의도적으로 numpy-vendor 와 중복되지만 코드에는 많지 않습니다. 그 리포지토리는 상당히 크고 실제로 Wine에서 실행하기 위한 것이며 그 안에 있는 gcc 도구 체인은 더 ​​이상 사용되지 않습니다.

괜찮습니다. 계속해서 만들어도 될까요?

괜찮습니다. Windows 전용인 경우(지금은 AFAICT입니까?) repo 이름에 "windows"가 있어야 합니다 :-). 또는 다른 바퀴에도 유사한 인프라를 배치할 수 있습니다. 나는 그것이 의미가있을만큼 충분히 작 으면 어딘가에 numpy 리포지토리에 직접 넣어도 괜찮습니다. 무엇이든 작동합니다 :-)

Repo에는 상당히 큰 ATLAS 바이너리가 있으며 numpy repo를 큰 목적으로 만들지 않을 것입니다.

win-wheel-builder 는 어떻습니까?

windows-wheel-builder 어때요? 나는 win 의 팬이 아닙니다 ;)

Windows 전용으로 만들지 않고 macosx 및 향후 manylinux1 휠 빌드 구성을 모두 한 곳에서 사용하는 것은 어떻습니까?

그렇지 않으면 "win"보다 "windows"에 대해 +1입니다.

Windows 전용으로 만들지 않고 macosx 및 향후 manylinux1 휠 빌드 구성을 모두 한 곳에서 사용하는 것은 어떻습니까?

모든 플랫폼에서 변경하는 것이 더 쉬울 것입니다. 그러나 OS X와 ​​Linux에는 빌드 스크립트만 필요하고 Windows에는 거대한 ATLAS 바이너리가 있을 것으로 예상합니다. 모두 하나의 리포지토리로 이동하는 경우 ATLAS 바이너리를 어떻게든 분리할 수 있습니까(아마도 git-lfs 사용)?

바이너리용 github에서 대용량 파일 저장소(LFS) 사용

@rgommers : 나는 우리가 곧 Linux용 atlas-or-some-other-blas 바이너리를 제공할 것이라고 생각합니다. 아마도 osx도 마찬가지일 것입니다.

체크인하는 대신 github 릴리스 또는 bintray 또는 다른 것을 사용할 수 있습니다... DYNAMIC_ARCH 활성화된 openblas 빌드 또는 여러 blis 구성의 동등한 조합에 들어가기 전까지는 크기가 그다지 크지 않습니다.

지금은 repo를 windows-wheel-builder 로 설정하고 Linux/OSX로 무엇을 할 것인지가 더 명확해지면 리팩토링/이름 변경은 어떻습니까?

나에게 좋은 소리.

나랑도 괜찮아

numpy 조직에 대한 관리자 권한이 필요하다고 생각합니다.
누군가 리포지토리에 대한 관리자 권한을 갖고 있고, 그들은 할 수 있다고 생각합니다.

@matthew-brett: github의 권한 페이지가 매우 혼란스럽습니다(특히 numpy는 엉망입니다). 하지만 저를 저장소의 관리자로 지정하거나 저장소를 나에게 이전하려면 numpy/

repo를 @njsmith 로 옮겼습니다 ...

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

numpy appveyor 계정이 있습니까? 누군가 이 리포지토리에 대해 Appveyor 빌드를 활성화할 수 있습니까?

@charris 의 Appveyor 계정을 사용하고 있는 것 같아요...

예, 여기를 참조하십시오 https://ci.appveyor.com/project/charris/numpy/history

2016년 3월 16일 수요일 오전 12시 15분, Nathaniel J. Smith <
[email protected]>은 다음과 같이 썼습니다.

@charris https://github.com/charris 의 Appveyor를 사용하고 있다고 생각합니다.
계정...

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

사실, 저는 방금 appveyor에서 numpy에 대한 새 그룹 계정을 만들고(어쨌든 이것을 하려는 의미였고, 이것은 제가 실제로 그것을 하도록 유도했습니다 :-)), 거기에서 활성화했습니다:
https://ci.appveyor.com/project/numpy/windows-wheel-builder

@njsmith 어떻게 관리하셨나요? 마지막으로 관리자에게 프로젝트 계정을 생성하도록 요청해야 하는 사람을 보았는데 다른 사람을 추가하는 방법이 완전히 투명하지 않았습니다.

계정이 제대로 작동하면 numpy 테스트에 대한 책임을 이전하고 싶습니다.

@charris : 이메일을 확인하세요 :-). 방금 numpy-steering-council @googlegroups.com을 개인으로 하는 개인 계정을 만들었습니다. 나는 프로젝트 계정이 존재한다는 것을 몰랐습니다... 우리는 하나를 원합니까?

대기열을 위해 다른 계정에 다른 프로젝트를 분산하고 싶을 것입니다.

numpy-steering-council 메일 사용의 단점은 병합 테스트가 실패할 때 appveyor가 알림을 보낸다는 것입니다. 앱베이어 사람들이 요즘 더 나은 것을 가지고 있다면 그것을 사용하는 것이 좋겠지만 그들의 인터페이스가 과거에 엉망이었던 것을 감안할 때 나는 그것에 내기를 걸지 않을 것입니다.

@tkelman 좋은 지적입니다. 또한 더 빠른 대기열을 얻기 위해 돈을 쓰려면 더 공식적인 것을 원할 것입니다.

@charris : 방금 새 appveyor 계정에서 numpy/numpy 테스트를 활성화하고 모든 알림을 비활성화하고 모든 관련 numpy github 팀을 계정의 관리자로 추가하려고 시도했습니다. 추측하다...

@matthew-brett: 가장 우아한 접근 방식은 numpy/windows-build-tools 와 같은 위치에 BLAS 빌드를 숨기지만 실제 numpy/numpy 저장소에서 실제 휠 빌드 도구를 다음과 같이 실행하는 것입니다. appveyor 빌드의 일부 -- 그들은 요청 시 BLAS 바이너리를 풀 수 있습니다.

모든 훌륭한 작업에 감사드립니다! numpy 1.11.0 창 휠이 곧 pypi에 추가됩니까? https://pypi.python.org/pypi/numpy

오 예, 여기에서 릴리스 절차를 업데이트하는 방법을 알아내야 할 수도 있습니다... IIUC 현재 사용자 경험은 1.11 소스 릴리스가 업로드되자마자 거기에 있는 모든 Windows 시스템이 다운로드 휠에서 갑자기 전환되었다는 것입니다(예 ) 소스를 다운로드하고 빌드하려고 합니다(boo). 이렇게 하는 "올바른" 방법은 최종 릴리스에 태그가 지정되면 sdist를 업로드하기 _전에_ 모든 바이너리 휠을 빌드하고 업로드하는 것입니다. 짜증날정도로...

@njsmith 는 좋겠지만 몇 분 지연(또는 몇 시간) 지연은 괜찮습니다.

명확히 하기 위해 1.11.0 릴리스용 PyPI의 현재 Windows whl 파일이 ATLAS에 대해 빌드됩니까? 공유할 수 있는 빌드 스크립트가 있습니까?

예, 휠은 ATLAS에 맞게 제작되었지만 결과가 확신이 들 때 OpenBLAS로 이동할 생각입니다.

빌드는 Appveyor를 통해 자동화됩니다. https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day . =)

hidden 릴리스를 만드는 것이 가능할 수 있습니다. 최소한 PyPI 양식 https://pypi.python.org/pypi?%3Aaction=submit_form 에 옵션이 있고 모든 파일이 준비되면 숨기기를 해제합니다.

슬프게도 숨겨진 릴리스 기능은 사람들이 명령줄을 통해 해당 릴리스를 가져오는 것을 막고 pypi GUI를 통해 릴리스를 보는 것만 중지합니다.

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

numpy의 64비트 Windows 설치를 시도했는데 훌륭하게 작동하므로 이 작업에 참여해 주신 모든 분들께 감사드립니다.

궁금한 점은 scipy 바퀴로 동일한 작업을 수행할 계획이 여전히 있는지 여부입니다. OpenBLAS로의 이전 결정을 기다리고 있습니까?

https://bitbucket.org/carlkl/mingw-w64-for-python/downloads 에는 scipy-0.17.0 의 테스트 휠이 있습니다. 이 휠은 @matthew-brett의 numpy 빌드에 대해 mingwpy로 빌드되었습니다. https://pypi.python.org/pypi/numpy/1.10.4

2016년 4월 28일 목요일 오후 12시 48분에 carlkl [email protected] 에서 다음과 같이 썼습니다.

https://bitbucket.org/carlkl/mingw-w64-for-python/downloads 에는
scipy-0.17.0의 일부 테스트 휠 . 이 바퀴는
@matthew-brett https://github.com/matthew-brett 's에 대한 mingwpy
numpy https://pypi.python.org/pypi/numpy/1.10.4 빌드

죄송합니다. 이미 말했는데 놓쳤습니다. 하지만 테스트를 받을 수 있나요?
이 바퀴에 대한 실패?

numpy 바퀴 내부에 배송된 ATLAS에 연결하고 있습니까?

@matthew-brett, 한 달 전에 이 빌드를 발표했지만 어디에서인지 기억이 나지 않습니다. 어쨌든, 이것들은 numpy 바퀴에서 제공하는 numpy-atlas에 대한 링크를 빌드합니다.

scipy-0.17.0-cp35-cp35m-win##.whl은 _wrong_ C 런타임 msvcrt.dll에 대해 연결됩니다. scipy의 경우 이것은 괜찮은 것 같습니다. 테스트 로그는 다음과 같습니다. https://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

그 로그가 맞나요? 끝에 NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy 가 있습니다.

잘못된 MSVC 런타임에 대해 위험하게 연결되더라도 scipy wheel을 제공할 수 있는지 궁금합니다. 하지만 이 빌드에는 너무 많은 오류가 있는 것처럼 보입니다.

64비트 빌드의 경우 오류가 더 적습니까? Openblas 0.2.18에 대한 현재 최고의 빌드를 위해?

64비트에는 다음과 같은 오류가 모두 6개뿐입니다.

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

알고 있습니다. 이것은 OpenBLAS와 비교하기 위한 것입니다. 그러나, 나는 당신이 눈치 챘을 수도 있는 몇 가지 이유로 지난 4주 동안 멈췄습니다. 상황이 계속 개선되기를 바랍니다.

@matthew-brett, OpenBLAS와 함께 numpy MSVC 빌드를 사용해 주셔서 감사합니다. 내 최신 빌드는 다음과 같습니다.

• 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

mingwpy, conda-forge, Anaconda 및 Canopy만으로는 충분하지 않은 것처럼 Python용 Intel Distribution 이 제공되며 무료로 다운로드할 수 있습니다. 여기에는 수치 도구(SciPy, NumPy, Numba, Scikit-Learn)와 일부 추가 기능(mpi4py Intel mp 인터페이스 및 pyDAAL 데이터 분석)만 포함되며 conda를 사용합니다.

라이센스가 10/29/16에 만료되므로 걱정하지 마십시오. 이러한 Intel 빌드는
베타 테스트 후 MKL+ 등의 라이센스 비용이 발생할 수 있습니다. OpenBLAS 빌드
오픈 소스 솔루션으로 남을 것이므로 제공해주셔서 감사합니다.
빌드.
2016년 4월 28일 오후 7시 21분에 "Mark Mikofski" [email protected] 이 작성했습니다.

mingwpy, conda-forge, Anaconda, Canopy 만으로는 부족해 여기 온다
Python용 인텔 배포판
https://software.intel.com/en-us/python-distribution 및 무료
다운로드
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation.
여기에는 수치 도구(SciPy, NumPy, Numba, Scikit-Learn)만 포함됩니다.
추가 기능(mpi4py Intel mp 인터페이스 및 pyDAAL 데이터 분석) 및
콘다를 사용합니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

1.11.1의 경우 Python 3.5 amd64용 PyPi에 누락된 Windows 휠이 있는 것 같습니다.

특별한 이유가 있나요? 1.11.0(https://pypi.python.org/pypi/numpy/1.11.0)으로 이동하면 바퀴가 있습니다.

보고서에 감사드립니다. 너무 빨리 업로드하고 모든 바퀴가 만들어지기 전에 업로드해야 한다고 생각합니다. 빠진 휠을 올렸습니다. 다시는 이런 일이 발생하지 않도록 테스트가 필요한 것 같습니다.

빠진 휠을 올렸습니다.

방금 테스트했는데 잘 작동합니다!

Windows 휠을 사용할 수 있도록 하는 모든 작업에 감사드립니다.

문제 마무리 -- 지난 몇 번의 릴리스에서 휠을 사용할 수 있습니다.

이 문제가 종료되었음을 이해하지만 다시 여는 것을 고려해야 한다고 생각합니다.

이것은 conda에 의존하지 않고 과학적 스택을 실행하려는 Windows 사용자에게 여전히 문제입니다. 여전히 @cgohlke 'MKL' 빌드 를 사용해야 하며 이 관련 scipy 문제 는 열려 있습니다. 바퀴가 만들어지고 있지만 scipy와 호환되지 않고 많은 사람들이 사용할 수 없습니다.

@waynenilsen 방금 언급한 문제에 연결된 메일링 리스트 스레드에 새 바퀴를 설치하는 방법에 대한 지침이 있습니다.

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

그래서 당신이 할 경우

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

그것은 당신을 위해 작동해야합니다.

Numpy에 대해 수행할 작업이 남아 있지 않으므로 문제가 종료되었습니다. 그만큼
Scipy 문제는 아직 진행 중이며 다음 시간에 해결될 것입니다.
풀어 주다.

이것은 저에게 효과적입니다 @Juanlu001 저는 이것이 pypi에 있을 때를 정말로 고대하고 있습니다!