Numpy: Paket roda Windows (.whl) di Pypi

Bagus sekali - dan memang ada banyak pekerjaan yang dilakukan oleh @carlkl di belakang layar untuk mewujudkannya. Saya yakin kita hampir sampai sekarang - @carlkl - kapan Anda akan go public, menurut Anda?

Untuk konteks: alasan mengapa ini tidak sepele adalah karena binari yang Anda tautkan
bergantung pada runtime dan perpustakaan matematika milik Intel, yang
mempersulit pendistribusian ulang.

Saya menggunakan roda numpy dan scipy berbasis OpenBLAS baru-baru ini di binstar. Anda dapat menginstalnya dengan:

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

Ini berfungsi untuk python-2.7 dan untuk python-3.4. Roda ditandai sebagai 'eksperimental'. Umpan balik diterima.

Jika Anda ingin pengujian luas maka Anda harus mengirim ini ke daftar :-)

Pada Kamis, 22 Januari 2015 pukul 20:54, carlkl [email protected] menulis:

Saya menggunakan roda numpy dan scipy berbasis OpenBLAS baru-baru ini di binstar.
Anda dapat menginstalnya dengan:

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

Ini berfungsi untuk python-2.7 dan untuk python-3.4. Roda ditandai sebagai
'eksperimental'. Umpan balik diterima.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -71096693.

Nathaniel J. Smith
Peneliti pascadoktoral - Informatika - Universitas Edinburgh
http://vorpus.org

fwiw Saya pribadi ingin mengubah ukuran integer default di win64 sebelum kami benar-benar menyediakan binari resmi, meskipun ada beberapa penolakan juga ketika saya terakhir mengusulkannya, juga mungkin dengan anaconda dan binari pihak ketiga lainnya mungkin sudah terlambat: (

juga berbicara tentang openblas, seseorang menyukai beberapa debugging, saya bosan dengan itu (sepertinya kegagalan yang sama yang merusak scipy dengan 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)

Versi OpenBLAS yang digunakan adalah 0.2.12. Saya belum mengalami masalah yang signifikan dengan versi ini.

Kegagalan scipy disalin ke https://Gist.github.com/carlkl/b05dc6055fd42eba8cc7.

32bit hanya kegagalan numpy karena 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)

Saya tidak setuju tentang mengubah ukuran integer win64, tapi saya pikir itu
masalah terpisah yang harus dipisahkan dari roda. Jika ini adalah
pertama kali build numpy win64 menjadi tersedia secara luas, maka itu akan
masuk akal untuk menautkannya, tetapi pada titik ini sudah ada banyak pengguna
selama bertahun-tahun, mereka hanya menggunakan cgholke atau anaconda atau apa pun. Jadi ayo
memperlakukan itu sebagai diskusi independen?

(Sebenarnya ini adalah jeda backcompat, tetapi meskipun demikian tampaknya masuk akal
bahwa kita mungkin bisa melakukannya, karena itu benar-benar berkurang
ketidakcocokan antar platform -- semua kode portabel harus menangani 64-bit
dtype=int sudah.)

Pada Kamis, 22 Jan 2015 jam 20:59, Julian Taylor [email protected]
menulis:

fwiw Saya pribadi ingin mengubah ukuran bilangan bulat default di
win64 sebelum kami benar-benar menyediakan binari resmi, meskipun ada beberapa
resistensi juga ketika saya terakhir mengusulkannya, juga mungkin dengan anaconda dan
binari pihak ketiga lainnya mungkin sudah terlambat :(

juga berbicara tentang openblas, seseorang menyukai beberapa debugging, saya bosan dengan itu
(sepertinya kegagalan yang sama yang merusak scipy dengan openblas):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== Pembacaan ukuran 16 tidak valid
==31931== di 0x7B28EB9: ddot_k_NEHALEM (di /usr/lib/libopenblasp-r0.2.10.so)
==31931== oleh 0x6DBDA90: DOUBLE_dot (arraytypes.c.src:3127)
==31931== oleh 0x6E93DEC: cblas_matrixproduct (cblasfuncs.c:528)
==31931== oleh 0x6E6B7B3: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931== oleh 0x6E6E29B: array_matrixproduct (multiarraymodule.c:2276)

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -71097408.

Nathaniel J. Smith
Peneliti pascadoktoral - Informatika - Universitas Edinburgh
http://vorpus.org

Saya juga tertarik dengan ini. Apakah ada cara untuk membantu prosesnya?

OpenBLAS dapat dikompilasi dengan INTERFACE64=1 dan numpy dapat dikompilasi dengan -fdefault-integer-8 untuk percobaan pertama.

Hanya kepala ke atas. Menggunakan bilangan bulat 64 bit dalam blas adalah ide yang buruk. Berhentilah sebelum Anda terlalu jauh menyusuri jalan itu. Matlab, dan Julia sebelum saya pergi dan memperbaikinya, melakukan ini, dan itu merusak perpustakaan pihak ketiga yang mengasumsikan bilangan bulat 32-bit konvensional di blas.

Apa yang telah kami lakukan di Julia selama ~5 bulan terakhir sebenarnya mengganti nama semua simbol di openblas untuk menambahkan akhiran _64 untuk mereka untuk versi 64-bit-int, dengan cara itu Anda dapat melakukan aljabar linier pada array yang sangat besar jika Anda mau, tetapi memuat pustaka eksternal ke dalam proses yang sama tidak akan segfault dengan membayangi nama dan mencoba memanggil dgemm dengan ABI yang salah.

Hai teman-teman apakah ada pembaruan pada file roda yang tersedia untuk Numpy?

Bukannya aku sadar sekarang.
Pada 25 Jun 2015 4:27 AM, "guyverthree" [email protected] menulis:

Hai teman-teman apakah ada pembaruan pada file roda yang tersedia untuk
lumpuh?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -115215236.

@guyverthree Christoph Gohlke telah merilis NumPy menggunakan MKL Intel sebagai roda untuk sementara waktu sekarang.

Juga, lihat posting blog saya di roda NumPy . Saya membuat beberapa roda NumPy di ​​Dropbox saya menggunakan toolchain mingw-w64 Carl Kleffner yang dimodifikasi dan port OpenBLAS milik Zhang Xianyi dari GotoBLAS . Olivier Grisel sedang mencari bantuan untuk memodifikasi buildbot NumPy untuk mengulangi langkah-langkah yang sama yang digunakan dalam utas grup Google OpenBLAS yang saya posting ke .

Versi terbaru saya tersedia di binstar.org meskipun saya tidak yakin apakah anaconda.org adalah nama pilihan baru sekarang.
Roda untuk py-2.6 .. 3.4 (32/64bit) berumur sekitar 2 bulan:

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

buat dengan https://bitbucket.org/carlkl/mingw-w64-for-python saya dan OpenBLAS yang kurang lebih baru.
pemasangan pip:

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

+1 @carlkl dan saya berharap ini dapat ditambahkan ke NumPy build di Cheese Factory juga.

+1 Saya akan senang melihat ini terjadi juga.

IMHO: setidaknya ada tiga masalah yang harus diselesaikan sebelum build ini diterima:

• patch mingwpy untuk repositori numpy harus dibuat ulang
• belum ada mekanisme build selain build manual
• banyak paket windows pihak ke-3 (didepoli oleh C. Gohlke) secara eksplisit bergantung pada numpy-MKL, karena binari terkait erat dengan DLL MKL. Ini dapat berubah di masa mendatang, karena scipy sekarang menyediakan mekanisme untuk ketergantungan implisit pada implementasi scipy BLAS/Lapack. Jadi menginstal (numpy-MKL & scipy-MKL) ATAU (numpy-OpenBLAS & scipy-OpenBLAS) harus mencukupi untuk semua paket lain di masa mendatang.

@carlkl : FWIW, saya tidak terlalu khawatir tentang paket @cgohlke -- yang akan beres dengan sendirinya (seperti tidak ada masalah besar sekarang karena orang mencoba menggabungkan scipy-MKL dengan anaconda numpy). Dan saya bahkan tidak terlalu khawatir tentang adanya mekanisme pembuatan yang mewah -- pembuatan manual tidak masalah selama ada file teks yang mendokumentasikan langkah-langkahnya.

Masalah utama yang saya khawatirkan adalah keberlanjutan: jika kami tidak bisa mendapatkan hal ini di hulu, maka kami harus memvalidasi ulang dan melakukan tambalan setiap kali versi baru gcc / mingw-w64 / msvc datang keluar, dan itu mungkin tidak akan terjadi. Kami tidak ingin terjebak dalam perangkap di mana kami mulai menyediakan build, tetapi kemudian ini menjadi semakin berat seiring waktu karena kami harus berurusan dengan kompiler lama yang rewel untuk melakukannya.

Itulah sebabnya saya mencoba mengumpulkan dana untuk mendukung melakukan ini di hulu ... +1 bagus dan semuanya, tetapi jika ada yang ingin menyumbangkan sejumlah uang atau mengetahui perusahaan yang mungkin tertarik untuk membuat gcc umumnya dapat digunakan untuk python ekstensi di windows, lalu kirimi saya email :-) ([email protected])

Jika Anda tidak memiliki $$ tetapi masih ingin membantu, maka salah satu cara untuk melakukannya adalah dengan mengirim patch ke mingw-w64 untuk meningkatkan dukungan mereka untuk fungsi transendental seperti sin dan cos. (Ternyata MSVC ABI tidak setuju dengan semua orang tentang bagaimana unit x87 FPU harus dikonfigurasi, sehingga sebagian besar fungsi matematika perangkat lunak bebas tidak bekerja dengan benar.) Untungnya ada implementasi yang baik dan kompatibel dengan lisensi di Android " bionic" libc , jadi ini tidak memerlukan sihir matematika atau wawasan mendalam tentang masalah ABI -- sebagian besar hanya masalah mekanis untuk menemukan dan mengekstrak file sumber yang relevan dan kemudian memasukkannya ke dalam pohon mingw-w64 di tempat yang tepat. Kami dapat memberikan detail lebih lanjut tentang ini juga jika ada yang tertarik.

Bukankah ini hal yang seharusnya didanai oleh numfocus? Jika tidak, maka mungkin kita bisa kembali dan mendaftar kembali ke PSF.

Berapa banyak uang yang kita bicarakan?

+1 tolong publikasikan roda untuk Windows ke PyPI https://pypi.python.org/pypi/numpy

Jika Anda mencoba pip install numpy pada instalasi Python Windows out-the-box, Anda mendapatkan pesan kesalahan yang sangat tidak membantu "Tidak dapat menemukan vcvarsall.bat".

+1 akan sangat membantu pengguna Windows.

Tidak dapat bermain dengan https://github.com/glumpy/glumpy karena ini. Apa langkah-langkah pembuatan manual untuk membuat Numpy bekerja di Windows? Sepertinya pekerjaan AppVeyor ada di sana , jadi seharusnya tidak ada masalah untuk mengunggah artefak ke GitHub .

Saat ini benar-benar tidak mungkin untuk membangun versi numpy berlisensi BSD yang cepat di windows. Kami sedang memperbaikinya, tetapi ini adalah batasan teknis; +1 juga tidak akan berpengaruh apa pun. (Pekerjaan appveyor dibangun di atas windows, tetapi menggunakan pustaka aljabar linier fallback yang tidak dioptimalkan yang tidak benar-benar cocok untuk pekerjaan nyata.) Sampai kami menyelesaikan ini, saya akan merekomendasikan mengunduh roda dari situs web Christoph Gohlke, atau menggunakan Anaconda atau distribusi python ilmiah lainnya .

@njsmith bisa lebih spesifik? Lebih disukai dengan perintah yang tepat yang tidak berfungsi. Saat ini hal ini tidak dapat ditindaklanjuti.

Saya pikir 'mustahil' terlalu kuat - tetapi tentu saja belum ada jalan umum yang jelas ke depan. Saya memasang halaman wiki pada status saat ini di sini: https://github.com/numpy/numpy/wiki/Whats-with-Windows-builds . Silakan mengedit / mengubah semua yang Anda pedulikan.

@techtonik : tidak ada "perintah persis yang tidak berfungsi", masalahnya adalah tidak ada kompiler yang memiliki kombinasi fitur yang kita butuhkan. mingwpy.github.io mendokumentasikan status terkini dari upaya kami untuk membuat kompiler semacam itu.

@matthew-brett bagus. We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler. Ini untuk scipy ya? Mengapa dibutuhkan untuk numpy?

@njsmith http://mingwpy.github.io/issues.html adalah inisiatif yang luar biasa dengan analisis yang baik. Sayang sekali bahwa upstream (Python) tidak akan pernah mendukungnya (mempromosikan menggunakan MSVS secara membabi buta). Tapi saya mencoba untuk mendapatkan gambaran yang jelas dari status saat ini.

1. apakah ini masalah "memiliki rantai alat terbuka untuk pekerjaan terbuka" atau MSVS benar-benar tidak dapat mengkompilasi bagian C dari numpy?
2. apakah masih ada crash dengan ekstensi yang dikompilasi mingw?

Untuk mempersempit fokus untuk saat ini, katakanlah hanya Python 2.7 + Win32. Tidak diperlukan kinerja (saya hanya ingin menjalankan aplikasi untuk mengujinya di sana), tetapi data benchmark tentang kinerja itu diperlukan.

Jadi, apa tindakan selanjutnya yang harus dilakukan untuk konfigurasi ini agar roda Windows tersedia dari PyPI?

@techtonik , sekarang ada versi awal roda numpy dan scipy yang tersedia di https://anaconda.org/carlkl/numpy dan https://anaconda.org/carlkl/scipy. Performanya hampir sebagus velg +MKL gohlke. Saya tidak menemukan segfaults dengan kotak windows saya di rumah.

Beberapa masalah dengan pendekatan ini telah dibahas dan akan diringkas di http://mingwpy.github.io (sedang dibangun). Kombinasi toolchain berbasis mingw-w64 yang disebut _mingwpy_ dan OpenBLAS adalah cara yang tepat untuk platform Windows.

_mingwpy_ memiliki konfigurasi khusus yang memastikan kompatibilitas yang lebih baik dan penggunaan yang lebih nyaman dibandingkan dengan rantai alat berbasis mingw-w64 yang paling terkenal, yaitu _mingw-builds_, _tdm_ ...

Semua ini dan lebih banyak lagi dijelaskan di https://github.com/mingwpy/mingwpy.github.io. Jangan ragu untuk membuka masalah atau PR di sana.

@techtonik : Saya pikir itu kesalahpahaman/kesalahpahaman yang serius tentang posisi python.org hulu. Saya akan mengatakan bahwa mereka menolak untuk mempromosikan perpecahan dukungan Windows CPython menjadi beberapa ABI yang tidak kompatibel (dan saya setuju dengan mereka dalam hal ini). Steve Dower, yang mengelola build upstream windows resmi, telah membantu kami mengetahui cara membuat mingwpy kompatibel dengan build ini.

IMO prasyarat untuk meletakkan roda numpy di pypi adalah bahwa mereka harus (a) berkinerja, (b) dapat dipelihara, (c) berlisensi dengan tepat. Jika Anda ingin proyek menerapkan serangkaian kriteria yang berbeda (yaitu bahwa kita harus berusaha menyediakan roda dengan kinerja yang buruk) maka langkah selanjutnya adalah mengirim email ke milis numpy yang menyatakan bahwa kriteria Anda lebih baik.

MSVS dapat membangun numpy sendiri, tetapi tidak dapat membangun implementasi BLAS berkualitas tinggi berlisensi yang sesuai. Upstream mingw-w64 dapat membangun numpy + BLAS (dengan tambalan), tetapi hasilnya akan macet jika Anda mencoba menggunakannya dengan CPython hulu. Rantai alat mingwpy Carl dapat membuat numpy + BLAS (dengan tambalan), dan hasilnya akan bekerja pada beberapa versi python (tetapi tidak 3.5), tetapi rantai alatnya rapuh dan tidak dapat dipertahankan dalam kondisi saat ini; secara harfiah tidak seorang pun kecuali Carl yang tahu bagaimana itu dibangun atau dapat membuatnya kembali. Tidak seorang pun di proyek numpy yang siap berkomitmen untuk menyediakan "bangunan resmi" menggunakan rantai alat dengan batasan ini, jadi kami berfokus untuk memperbaikinya.

Ada beberapa sumber numpy build berkualitas tinggi yang tersedia secara sepele di Windows. Saya benar-benar ingin tahu: mengapa Anda begitu ngotot bahwa kita harus membuang beberapa build berkualitas rendah hanya agar mereka ada di PyPI?

@njsmith Hanya ingin menyatakan bahwa kasus penggunaan saya (yang saya akui sama sekali tidak akan membenarkan investasi sumber daya pengembang sendiri) adalah untuk mendistribusikan paket yang sangat sederhana pada PyPI yang bergantung pada matplotlib , yang pada gilirannya tergantung pada numpy .

Untuk kasus penggunaan saya, kinerja tidak menjadi masalah, tetapi dapat memiliki pengguna Windows hanya pip install ____ paket saya yang secara rekursif menginstal matplotlib , numpy , dll jauh lebih mudah untuk jelaskan daripada mengarahkan mereka ke URL untuk juga menginstal, terutama bagi pengguna yang tidak memahami ekosistem build Python. Jadi ini sebagian besar untuk penyederhanaan petunjuk pemasangan.

Sekali lagi, tidak mencoba menggunakan kasus saya sebagai pembenaran, tetapi hanya ingin berbagi karena Anda penasaran.

@johnthagen : Oh, tentu, jangan khawatir! Saya benar-benar mengerti mengapa ini diinginkan secara umum; jika saya terlihat pemarah dalam komentar ini, itu persis karena saya dan orang lain telah menghabiskan banyak waktu selama setahun terakhir untuk mencoba memperbaikinya :-). Saya hanya bertanya kepada @techtonik secara khusus karena kedengarannya seperti mereka mengatakan "Saya hanya ingin mencoba satu aplikasi kecil, jadi saya tidak peduli dengan kinerja", tetapi jika mereka hanya ingin mencoba satu aplikasi kecil, saya tidak tahu mengapa mereka peduli dengan bagian PyPI :-)

(Penting untuk diingat bahwa roda apa pun yang kita pasang di pypi akan segera mulai digunakan oleh puluhan ribu orang, kebanyakan dari mereka tidak membaca utas ini. Jadi saya pikir ada kewajiban bagi kita untuk memastikan bahwa apa pun kami memasang sebenarnya akan dapat digunakan secara luas untuk berbagai kasus penggunaan.)

Saya pikir pada dasarnya akan sepele untuk mulai mengirimkan roda numpy 32-bit untuk Python 2.7, menggunakan ATLAS. Mereka mungkin harus SSE2, jadi crash tanpa instruksi SSE, tapi itu hanya akan mempengaruhi sebagian kecil pengguna. Kami dapat menggunakan rantai alat rilis kami saat ini untuk itu. Ingatlah bahwa ini berarti bahwa pip akan memberikan roda biner untuk 32-bit, tetapi kembali ke instalasi sumber untuk 64-bit. Apakah itu berguna?

@njsmith Terima kasih atas infonya! Hargailah semua kerja kerasmu :)

Saya pikir pada dasarnya akan sepele untuk mulai mengirimkan roda numpy 32-bit untuk Python 2.7, menggunakan ATLAS. Mereka mungkin harus SSE2, jadi crash tanpa instruksi SSE, tapi itu hanya akan mempengaruhi sebagian kecil pengguna. Kami dapat menggunakan rantai alat rilis kami saat ini untuk itu. Ingatlah bahwa ini berarti bahwa pip akan memberikan roda biner untuk 32-bit, tetapi kembali ke instalasi sumber untuk 64-bit. Apakah itu berguna?

@matthew-brett pengaturan numpy-vendor saat ini rusak, ada segfault di fromfile . Penanganan penanganan file entah bagaimana kacau, dan kami tidak yakin apakah itu karena perubahan dalam versi Wine, versi Ubuntu atau (tidak mungkin) perubahan pada numpy itu sendiri. Saya akan mengatakan bahwa menghabiskan lebih banyak waktu untuk itu adalah buang-buang waktu - memasukkan waktu itu ke mingwpy jauh lebih produktif.

Saya memiliki NumPy 1.10.4 yang dikompilasi dengan OpenBLAS (Int32 Windows 64, v0.2.15 biner yang telah dikompilasi) dan MKL (menggunakan lisensi komunitas di MKL, yaitu distribusi gratis). Tapi... Saya tidak bisa mengkompilasi SciPy - tampaknya sebagian kecil mencari kompiler gfortran "kompiler fortan tidak ditemukan" jika ada yang tahu cara memperbaiki masalah ini. Saya menggunakan ift.exe karena Ananconda mendukung build ini sebagai plug-in langsung. Dikompilasi untuk Python 3.5 dengan Microsoft Visual Studio Community 2015 jika ada yang bisa membantu saya mengetahui cara mengemas ini untuk distribusi.... maka saya akan mengunggah ke situs web github atau anaconda. Menghargai itu.

@mrslezak : mungkin hal terbaik yang harus dilakukan adalah memposting di milis pengembang scipy, atau membuka bug baru di scipy, daripada memposting bug acak yang ada :-)

Saya benar-benar ingin tahu: mengapa Anda begitu ngotot bahwa kita harus membuang beberapa build berkualitas rendah hanya agar mereka ada di PyPI?

Hanya karena saya lelah mencukur yak. Saya tahu bahwa orang menginginkan kinerja, dan ada baiknya seseorang memiliki sumber daya untuk melakukannya, tetapi bagi saya pribadi kerumitan dalam menyelesaikan tugas ini sangat besar, jadi saya hanya dapat berharap Anda dapat melakukannya, tetapi bagi saya itu mungkin tidak akan pernah terjadi, atau itu mungkin terjadi dalam dua atau tiga tahun, di mana orang terus menabrak tembok dan membuang waktu dalam hitungan jam sebanding dengan unduhan semua binari windows dari PyPI yang memerlukan pemasangan NumPy sebagai ketergantungan langsung tidak langsung.

Wah. Mungkin kalimat bahasa Inggris terpanjang yang saya tulis sepanjang hidup saya. =)

@techtonik - Saya berbagi rasa frustrasi Anda, saya pikir banyak dari kita merasa frustrasi tentang hal ini.

@carlkl - Saya akan senang dengan tanggapan Anda di sini.

Jelas ada tekanan kuat bagi kami untuk memasang roda jendela yang numpy. Berikut adalah daftar roda yang paling banyak diunduh untuk platform apa pun dari beberapa minggu yang lalu: https://Gist.github.com/dstufft/1dda9a9f87ee7121e0ee . matplotlib, scikit-learn dan pandas windows wheels berada di posisi 3, 4, dan 5. Akan ada pasar besar untuk numpy windows wheels.

Saya pikir pertanyaan di atas meja adalah:

1) Bisakah kita berkomitmen untuk mendapatkan roda numpy yang berfungsi dan hampir optimal di pypi dalam jangka pendek hingga menengah (katakanlah, 6 bulan). Saya akan mengatakan jawabannya adalah ya (senang mendengar ketidaksepakatan);
2) Apakah layak untuk sementara waktu memasang roda numpy yang tidak optimal untuk dibangun orang lain?

Pertanyaan 2 adalah yang paling sulit. "Tidak optimal" bisa berarti lambat (tidak ada blas / lapack yang dioptimalkan) atau sulit untuk mendukung (tidak ada jaminan kami dapat mengulangi pembangunan dalam waktu 6 bulan).

Saya bisa melihat argumen yang menentang "lambat". Kita perlu berhati-hati bahwa, ketika roda mulai bekerja untuk Windows, mereka tidak segera memicu pertanyaan stackoverflow dengan jawaban "Tidak ada akun, unduh roda numpy dari pypi". Saya pikir jawaban itu masuk akal dan akan bertahan cukup lama untuk menyakiti kita.

Maknanya tidak optimal, sulit untuk mendukung proses pembangunan, saya pikir kita bisa hidup dengannya, jika kita benar-benar berkomitmen untuk menemukan solusi jangka panjang dalam waktu dekat.

Beberapa waktu yang lalu saya membangun binari ATLAS untuk Windows: http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

Apakah saya benar dalam berpikir bahwa kita sudah dapat membangun binari numpy yang lulus semua tes menggunakan binari ATLAS ini?

Dalam hal ini, mengapa kita tidak memasangnya?

1) Bisakah kita berkomitmen untuk mendapatkan roda numpy yang berfungsi dan hampir optimal di pypi dalam jangka pendek hingga menengah (katakanlah, 6 bulan). Saya akan mengatakan jawabannya adalah ya (senang mendengar ketidaksepakatan);

Saya harap begitu, jika tidak, itu berarti bahwa pada saat itu kami akan mengalami masalah tak terduga dengan proposal mingwpy atau tidak menyimpan apa yang memungkinkannya :)

2) Apakah layak untuk sementara waktu memasang roda numpy yang tidak optimal untuk dibangun orang lain?

Build ATLAS Anda sepertinya sudah selesai dengan Cygwin? Atau apakah itu hanya penamaan direktori dan Anda menggunakan beberapa versi MingwPy?

Saya pikir ATLAS build saya sudah selesai dengan Cygwin, tetapi mereka tidak menautkan ke Cygwin.dll, jadi saya pikir mereka akan aman untuk dibangun dengan MSVC.

mingwpy tidak dalam masalah tetapi membutuhkan waktu. Membangun toolchain gcc, OpenBLAS dan kemudian numpy/scipy dengan varian yang berbeda membutuhkan waktu pembuatan dan pengujian. Dan saya tidak akan menerbitkan binari tanpa mempublikasikan semua skrip build terlebih dahulu. Sebuah mingwpy berdasarkan gcc-5.3.0 hampir siap, begitu juga dengan OpenBLAS. Langkah selanjutnya adalah membangun roda numpy dan scipy berdasarkan itu.

Diskusi ini serta kontribusi terbaru ke utas numpy "Roda multi-distribusi Linux - silakan uji" mengarah ke pertanyaan apakah OpenBLAS memiliki kualitas yang memungkinkan penyebaran roda numpy windows berdasarkan OpenBLAS. Tapi saya tidak yakin bahwa menggunakan atlas sebagai gantinya adalah solusi yang lebih baik. Mungkin roda numpy harus dibuat dengan kedua varian untuk fase pengujian terlebih dahulu.

Saya menduga / berharap bahwa entah bagaimana kita akan mendapatkan tahap bahwa OpenBLAS memiliki kualitas yang dapat diterima. Tapi, sampai saat itu, tampaknya masuk akal bagi saya untuk memulai dengan roda numpy ATLAS, berharap pada waktunya kita akan dapat beralih ke roda OpenBLAS. Kami mungkin harus memasukkan pemeriksaan SSE2 untuk build 32-bit: http://mingwpy.github.io/blas_lapack.html#atlas

Menempatkan kotak kemajuan di atas halaman PyPI dapat membawa lebih banyak orang ke masalah ini (termasuk mereka yang mungkin menyumbang untuk mendukung inisiatif). Kotak tersebut mungkin mencantumkan strategi saat ini, kriteria penerimaan (tautan ke uji kinerja?), status dan tindakan yang akan dilakukan ketika versi final sudah siap (meningkatkan versi utama?).

@matthew-brett masih belum jelas bagi saya bahwa proposal Anda untuk melontarkan sesuatu itu layak. Kompiler apa yang akan Anda gunakan? Jika MingwPy, kami memiliki rencana yang jelas tentang apa yang harus dilakukan dan sekarang tampaknya terlalu dini. Jika gcc lain, kami kembali ke masalah tautan statis dan mendistribusikan rasa sakit DLL.

Ide saya adalah mengkompilasi numpy dengan ATLAS menggunakan MSVC. Tentu saja itu tidak berhasil untuk scipy, tetapi setidaknya orang akan dapat memulai dengan mengirimkan roda jendela mereka, bagaimanapun bentuknya.

Saya baru saja mencobanya dan mendapatkan beberapa kesalahan formulir unresolved external symbol __gfortran_compare_string jadi saya kira binari ATLAS memiliki beberapa referensi yang menggantung ke run-time gfortran. @carlkl - ada saran untuk cara men-debug?

Mencampur file objek statis yang berasal dari kompiler berbeda adalah sesuatu yang harus Anda hindari seperti iblis menghindari air suci. Dalam beberapa kasus ini berfungsi, tetapi untuk kumpulan kombinasi kompiler yang berbeda itu akan gagal.
BTW: MS sendiri tidak secara resmi mendukung atau merekomendasikan pencampuran objek statis dari versi yang berbeda dari Visual Studio mereka.

Saya melakukan beberapa tes beberapa minggu yang lalu, ketika pertanyaan ini muncul: dapatkah perpustakaan statis npymath.a yang dibuat oleh mingwpy digunakan dengan kompiler MSVC? Pada prinsipnya ini dapat berfungsi jika beberapa objek yang dipilih dari pustaka runtime gcc ditambahkan ke pustaka ini. Saya sampai pada kesimpulan, bahwa pendekatan seperti itu tidak stabil dan rapuh.

Jika atlas adalah opsi untuk membuat roda numpy, saya akan mencoba membuatnya sebagai DLL, ada keberatan?

Mencampur file objek statis yang berasal dari kompiler berbeda adalah sesuatu yang harus Anda hindari seperti iblis menghindari air suci.

Saya merasa bahwa https://mingwpy.github.io/motivation.html (Halaman Mengapa) tidak memiliki penjelasan yang sangat sederhana dan lugas tentang masalah untuk modul yang dimuat secara dinamis . Saya berbicara dengan orang-orang Manajer Jauh, yang manajer filenya asli Windows, dibangun di atas plugin, yang dimuat dari .dlls yang ditulis dalam bahasa yang berbeda, dan mereka tidak memiliki masalah ini dengan "kompiler yang persis sama". Saya bertanya-tanya mengapa Python memilikinya - ia juga memuat modul dari .dlls..

@techtonik , komentar saya adalah tentang menautkan file objek yang dihasilkan oleh berbagai kompiler ke dalam satu file biner (DLL atau EXE). Itulah yang saya maksud dengan _mencampur file objek statis_. Pendekatan seperti itu _dapat_ bekerja dalam beberapa situasi yang teruji dengan baik jika ditangani dengan hati-hati. Tapi itu jauh dari cara yang kuat untuk membangun binari.

Interoperabilitas DLL dari kompiler yang berbeda dalam ruang proses umum adalah hal yang sama sekali berbeda. Biasanya pendekatan seperti itu berfungsi dengan baik sebagai aturan umum. Kita harus memastikan, bahwa binari ini terkait dengan DLL runtime MS yang sama jika mereka berbagi deskriptor file. Ada kemungkinan masalah ABI lain juga yang harus ditangani. Dan tentu saja Anda memerlukan satu set debugger yang berbeda untuk debugging tergantung pada kompiler yang digunakan.

minwgpy adalah proyek untuk mendukung pembuatan ekstensi python dengan bantuan mingw-w64 untuk digunakan di dalam build MSVC CPython standar.

OK - Saya berhasil membuat numpy dengan tautan MSVC dengan build ATLAS.

ATLAS membangun di sini:

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

Ada beberapa petunjuk sederhana di sana bagaimana membangun ATLAS dll.

Semua tes numpy lolos dari pemeriksaan skrip f2py , saya pikir itu kegagalan yang tidak berbahaya.

Langkah terakhir adalah mengirimkan perpustakaan dinamis di dalam roda. @carlkl - apa cara favorit Anda saat ini untuk melakukan itu?

Senang mendengarnya, saya juga ingin mengetahui cara membuat roda dengan
termasuk binari - dapat memposting build MKL dan meminta orang lain menguji OpenBlas
satu.
Pada 11 Februari 2016 13:28, "Matthew Brett" [email protected] menulis:

OK - Saya berhasil membuat numpy dengan tautan MSVC dengan build ATLAS.

ATLAS membangun di sini:

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

Ada beberapa petunjuk sederhana di sana bagaimana membangun ATLAS
dll.

Semua tes numpy lolos dari pemeriksaan skrip f2py, saya pikir itu a
kegagalan jinak.

Langkah terakhir adalah mengirimkan perpustakaan dinamis di dalam roda. @carlkl
https://github.com/carlkl - apa cara favorit Anda saat ini?
itu?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -183021728.

Langkah terakhir adalah mengirimkan perpustakaan dinamis di dalam roda.

Dan pemeriksaan SSE2 dan bailout yang anggun?

@mrslezak - cara termudah adalah memasukkannya ke dalam folder numpy/inti, karena secara atom dimuat ke dalam ruang proses selama impor multiarray.pyd.

Langkah terakhir adalah mengirimkan perpustakaan dinamis di dalam roda

@matthew-brett: Saya 99% yakin bahwa cara "benar" untuk melakukan ini adalah melalui rakitan SxS, yang dokumentasinya sangat buruk, tetapi mungkin dapat dilakukan ... Saya tahu Anda telah menghabiskan waktu untuk mencoba memahaminya, dan saya sudah membaca juga, jadi jika Anda ingin duduk di beberapa titik dan mencoba dan mengerjakan detailnya, beri tahu saya :-).

(Masalah dengan semua pendekatan lain adalah bahwa proses IIUC windows biasanya mempertahankan satu namespace global dari semua dll yang diimpor. Artinya adalah jika dua ekstensi mengirimkan file bernama foo.dll, maka ekstensi mana pun yang dimuat terlebih dahulu akan memiliki versinya dari foo.dll "win" dan ekstensi lainnya akan menggunakannya -- masalah klasik "dll hell". Dan IIUC satu-satunya cara untuk menghindari perilaku ini adalah melalui mesin SxS, seburuk itu.)

Nathaniel - Saya menulis pemahaman saya tentang rakitan SxS di sini: https://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-assemblies

Kesimpulan akhir saya adalah bahwa itu tidak ada harapan, dan bahwa, bagaimanapun, mengganti nama DLL dengan cara unik per proses adalah alternatif yang masuk akal.

Ralf - saran untuk memformalkan cara menambahkan kait SSE2 dll ke proses instalasi: https://github.com/numpy/numpy/pull/7231

@matthew-brett: Saya sudah membaca catatan itu, ya .... dan ugh, putus asa mengapa? Karena masalah direktori yang sama? Dan apakah Anda punya ide tentang bagaimana mencapai penggantian nama itu? (Saya belum menemukan yang setara dengan patchelf --replace untuk file PE, dan membuat ulang file .lib bukanlah hal yang sepele -- meskipun saya kira menggunakan mingw-w64 tidak terlalu buruk karena Anda dapat menautkan ke .dll secara langsung. Setidaknya jika Anda tidak perlu mengganti nama libgfortran atau yang serupa...)

(Mungkin ada beberapa PE yang setara dengan patchelf --replace di suatu tempat di daftar ini: http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

Saya tidak melihat masalah untuk memuat satlas.dll (atau alternatifnya libopenblaspy.dll ) di samping multiarray.pyd, karena direktori ini lebih disukai selama pencarian DLL. Pendekatan ini bekerja karena fakta bahwa DLL ini dimuat melalui LoadLibraryEx dari python ke dalam ruang proses. Folder numpy/core harus digunakan, karena ini adalah kemunculan pertama dari ekstensi python yang bergantung pada bla selama impor. Upaya lebih lanjut untuk memuat DLL dengan nama yang sama akan diabaikan begitu saja karena DLL ini sudah dimuat ke dalam ruang proses. Windows hanya mencari nama DLL BTW.

DLL mulai jika perpustakaan seperti itu bergantung pada _further_ DLL, tetapi ini tidak terjadi karena keduanya satlas.dll dan libopenblaspy.dll mandiri dan hanya bergantung pada DLL sistem Windows standar. Inilah yang biasanya disebut DLL yang ditautkan secara statis - itu berarti kode runtime gcc ditautkan secara statis.

_Untuk perbandingan_: Untuk mengimpor pustaka MKL, pendekatannya adalah dengan memperpanjang sementara PATH menjadi numpy/core . Sayangnya ini gagal jika pustaka MKL yang lebih lama ditempatkan di folder sistem Windows.

@matthew-brett @njsmith : Penggantian nama DLL: apa gunanya?

@carlkl : kasus yang kami khawatirkan adalah jika numpy include atlas.dll , dan juga scipy termasuk atlas.dll , dan pada titik tertentu pengguna memutakhirkan scipy (dan mendapatkan versi atlas.dll yang lebih baru atlas.dll yang berasal dari paket numpy. Ini buruk, karena scipy mungkin bergantung pada versi yang lebih baru -- jadi semuanya akan rusak secara acak tergantung pada build apa dari paket mana yang terlibat, dan urutan mana yang diimpor pengguna. Ini terjadi karena jika numpy menyertakan DLL bernama atlas.dll maka itu akan "mengklaim" nama atlas.dll dalam namespace DLL seluruh proses, dan itu akan memblokir paket lain dari menggunakan DLL yang berbeda dengan itu nama.

Dua solusi yang mungkin adalah (a) jika hal-hal SxS/activation-contexts dapat dibuat berfungsi, ini menyediakan cara untuk menonaktifkan namespace DLL seluruh proses, atau (b) jika numpy berisi numpy-atlas.dll , dan scipy berisi scipy-atlas.dll , maka mereka ini dapat berbagi ruang nama seluruh proses yang sama tanpa bertabrakan.

Atau jika keduanya bergantung pada paket clib_atlas terpisah yang menyediakan dll? Kemudian persyaratan ketergantungan versi dapat dinyatakan seperti biasa untuk paket python.

@tkelman : Kami perlu mencari cara untuk mendukung DLL yang di-vendor dan DLL yang didistribusikan secara terpisah, saya pikir, karena kedua opsi tersebut sesuai dalam situasi yang berbeda. Dan kasing yang dijual jauh lebih mudah untuk memulai :-)

Saya percaya solusi berdampingan akan membutuhkan hak admin untuk menginstal ke windows system32. Tolong jangan lakukan ini.

Ada juga rakitan berdampingan 'pribadi', di mana rakitan duduk di pohon biner Anda sendiri, tetapi ada batas dua penanda jalur direktori atas yang dapat Anda gunakan untuk menunjuk ke Majelis, yaitu Anda dapat menunjuk ke ..\..\some_assembly tetapi tidak ..\..\..\some_assembly .

Jadi misalnya, scipy/first/second/third/something.pyd hanya dapat menunjuk ke rakitan berdampingan di direktori third atau second atau first tetapi tidak di scipy (atau direktori lain di dalamnya.

OK, saya membuat beberapa roda untuk pengujian, di sini:

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

Seperti biasanya:

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

Otomatisasi pembuatan yang sangat kasar di sini: https://github.com/matthew-brett/np-wheel-builder

Roda lulus semua tes selain dari kegagalan palsu menjalankan skrip f2py (bug dalam tes itu saya percaya).

Ralf - SSE2 periksa di sini: https://github.com/matthew-brett/np-wheel-builder/blob/master/_distributor_init.py

Saya juga membuat penginstal 64-bit untuk Python 2.7, 3.4, 3.5, di alamat web yang sama.

@matthew-brett, saya tidak memiliki izin untuk mengakses file-file ini.

@matthew-brett, teknologi perakitan SxS tidak digunakan lagi (sejak VS2010), lihat https://en.wikipedia.org/wiki/Side-by-side_assembly.

Bagaimana dengan menambahkan nomor versi ke nama file DLL: libopenblaspy_0.15..dll atau libatlas_3.10.1.dll atau yang serupa. Dan kemudian gunakan _proxy DLL_ yang digunakan sebagai penerus DLL ke versi DLL. Ekstensi numpy dan scipy harus dibuat terhadap proxy DLL yang disebut yaitu _libblapack.dll_.

Jika atlas digunakan, ini pada prinsipnya akan memungkinkan pemuatan DLL atlas yang dioptimalkan saat runtime. (tidak perlu jika menggunakan openblas)

Semua ini dapat ditangani dengan bantuan paket clib_openblas dan/atau clib_atlas. (Sekarang saya harus belajar cara menghasilkan kode untuk DLL forwarder). Numpy sendiri bisa dilengkapi dengan atlas atau openblas. Ini harus dimuat jika clib_openblas atau clib_atlas tidak tersedia.

@carlkl : Saya pikir halaman wikipedia membingungkan, dan mencoba mengatakan bahwa VS 2010 tidak menggunakan SxS _untuk perpustakaan tertentu_, tetapi SxS secara umum masih digunakan (misalnya nanti di halaman yang sama: "Dari Vista dan seterusnya, sistem operasi juga menggunakan WinSxS untuk komponen intinya.")

Saya percaya cara Anda membangun forwarder dll dengan msvc adalah dengan menulis file .def khusus dan kemudian menggunakannya saat membuat .dll Anda. Tapi, bagaimana bantuan forwarder dll? (Di osx atau Linux saya pikir ini bisa menjadi alat yang berguna, tetapi di windows Anda masih memiliki masalah namespace dll global yang mengganggu itu.)

@njsmith , kita harus mencari solusi yang dapat dipahami. Memang benar, SxS itu ada. Biasanya tidak digunakan lagi untuk hal lain selain sistem operasi itu sendiri.

(1) Solusi termudah IMHO adalah menautkan Blas Lapack secara statis. Pendekatan ini menciptakan binari besar dan karena itu tidak direkomendasikan (setidaknya oleh saya).
(2) Solusi termudah kedua adalah menginstal DLL di numpy/core dan hanya itu.
(3) Solusi ketiga adalah _memaksa_ ketergantungan ke paket Blas/Lapack eksternal, yang telah diversi dan cukup memuat DLL Blas Lapack. Penggunaan pip memastikan bahwa versi DLL yang benar tersedia.
(3) Jika ketergantungan terbatas seperti itu tidak diinginkan, itu dapat ditambah dengan DLL yang disediakan oleh numpy dan scipy itu sendiri. DLL ini harus dimuat _hanya dalam situasi_, di mana DLL eksternal tidak diinstal. Itu berarti paket Blas/Lapack eksternal akan lebih disukai tetapi tidak sepenuhnya diperlukan.
Nilai tambah besar dari solusi semacam itu adalah, rilis openblas/atlas yang diperbaiki bug yang lebih baru dapat ditukar tanpa menginstal ulang numpy/scipy.
(4) Menggunakan manifes dan SxS. @njsmith , dapatkah Anda mengisi detail untuk kasus ini?

Maaf - saya memperbaiki izin untuk roda - apakah mereka berfungsi sekarang?

Maaf tidak menghubungi Anda kembali di majelis SxS. Komentar 'putus asa' saya di SxS tidak terlalu berguna, saya akan mencoba membongkarnya.

Pertanyaannya adalah apakah kita harus menggunakan rakitan SxS "pribadi", yang merupakan rakitan SxS yang kita host di pohon biner kita sendiri. Rakitan SxS juga dapat "dibagi". Rakitan bersama masuk ke folder sistem Windows Anda, dan harus diinstal oleh paket penginstal MS . Saya pikir itu berarti rakitan bersama tidak dapat diinstal melalui roda, dan bagaimanapun juga akan memerlukan izin admin, jadi saya pikir kami dapat menolak rakitan bersama sebagai opsi.

Jadi - apa masalah menggunakan rakitan SxS pribadi?

Masalah pertama adalah bahwa kita akan memulai jejak yang cukup segar jika kita mencoba dan melakukan ini. Saya tidak tahu ada proyek sumber terbuka lain yang menggunakannya. Saya bertanya kepada Steve Dower tentang rakitan SxS. Steve bekerja di MS dan merupakan pengelola Python Windows saat ini. Dia menyarankan agar saya menghindarinya. Sepertinya tidak ada orang yang bekerja dengannya yang mengenal mereka. Catatan saya yang ditautkan di atas adalah upaya untuk memahami beberapa contoh yang dia ketahui tentang seseorang (tampaknya) berhasil menggunakannya. Ada sangat sedikit sumber daya yang baik untuk menjelaskannya.

Terkait adalah pengamatan Carl telah mengemukakan bahwa MS sendiri tampaknya ambivalen tentang menggunakannya. Misalnya, untuk runtime MSVC, aplikasi nyata dari rakitan SxS, mereka menggunakan nama DLL unik sebagai gantinya (MSVCR90.DLL, MSVCR100.DLL, dll).

Untuk menggunakan rakitan SxS, saya pikir kita harus menambahkan kode boilerplate inisialisasi ke setiap modul terkompilasi yang perlu memuat DLL lain, untuk membuat "konteks aktivasi". EDIT: Nathaniel mengingatkan saya bahwa Windows akan secara otomatis memicu konteks aktivasi baru jika melihat bukti "manifest" perakitan berdampingan yang terkait dengan DLL (yang dapat disematkan di DLL, tetapi juga menjadi file XML eksternal) .

Jadi, bukan putus asa, tapi tangguh.

Saya minta maaf untuk pertanyaan yang sangat mendasar ini, tetapi, di Windows, jika saya memuat perpustakaan foo.dll yang berisi my_symbol dalam satu modul ekstensi, apa yang terjadi jika saya memuat perpustakaan bar.dll , juga mengandung my_symbol , di modul ekstensi lain? Saya berasumsi mereka dapat diakses secara terpisah dalam proses saya, jadi ekstensi pertama akan mendapatkan foo: my_symbol dan ekstensi kedua akan mendapatkan bar:my_symbol ? Adakah yang bisa mengarahkan saya ke referensi?

Jika itu benar, maka tentunya yang kita perlukan, untuk menghindari DLL sih, adalah memiliki nama DLL yang sangat tidak mungkin digunakan secara tidak sengaja dalam proses yang sama (di mana pengguna tidak bermaksud menggunakan DLL persis kita).

Selama menghubungkan setiap simbol terikat ke DLL tertentu yang diidentifikasi dengan namanya. Selama runtime kita harus memastikan bahwa DLL yang benar dimuat jika lebih dari satu DLL dengan nama yang sama dapat ditemukan. Oleh karena itu urutan pencarian penting.
Contoh Roda numpy anaconda.org saya menggunakan perpustakaan openblas dengan nama libopenblas_py_.dll untuk menghindari bentrokan nama dengan libopenblas,dll non-standar yang digunakan oleh Julia.

Versi terbaru julia sekarang menggunakan nama yang berbeda libopenblas64_ untuk mencerminkan ABI non standar yang kami buat. Pada 32 bit kami tidak mengganti nama simbol atau nama perpustakaan karena tidak ada banyak alasan untuk memilih int 64 bit di antarmuka di sana.

Nama yang membayangi simbol dalam pustaka bersama sebenarnya lebih merupakan masalah di linux dan osx daripada windows, tetapi kami melakukan hal yang sama di mana-mana untuk konsistensi.

Meskipun itu tidak menutup kemungkinan pada 32 bit di mana ABI sama bahwa kita tidak dapat mengatur untuk menghancurkan satu sama lain dengan cara lain, seperti membutuhkan versi yang terlalu lama atau terlalu baru untuk yang lain.

Saya memoles sedikit proses pembuatan - lihat https://github.com/matthew-brett/np-wheel-builder

Sekarang prosesnya cukup otomatis, saya percaya praktis untuk terus membangun roda ini selama beberapa rilis berikutnya jika kita harus. Saya senang melakukan ini sebagai manajer rilis Windows hingga mingwpy mencapai spesifikasi.

Saya telah menguji roda ini pada 32-bit dan 64-bit Python 2.7, 3.4, 3.5, dan beberapa lainnya juga telah diuji, jadi saya pikir mereka dalam kondisi yang baik.

Apakah ada hal lain yang bisa saya lakukan untuk meyakinkan Anda semua bahwa ini layak dipasang di pypi, seperti yang diminta OP?

Halo semua! Saya hanya ingin masuk ke diskusi ini karena saya telah frustrasi dengan ketidakmampuan saya untuk menginstal numpy dan scipy dari sumber untuk beberapa waktu, jadi tentu bermanfaat bagi saya untuk membaca tentang apa itu terjadi di depan ini.

@matthew-brett: Skrip otomatisasi ini luar biasa . Bahkan jika itu tidak berhasil masuk ke PyPI, ini sepertinya cara yang sangat layak untuk membangun numpy dari sumber (lihat masalah ini yang saya buka di sini ). Ini juga sangat dekat untuk dapat membangun scipy karena saya dapat membangun semuanya, tetapi kemudian tes tampaknya menyebabkan segfault di suatu tempat di Python.

Juga, bagi siapa saja yang benar-benar telah membangun roda numpy , saya telah mencoba mengumpulkan dokumentasi terkini yang dipoles tentang membangun perpustakaan ini dari sumber untuk menggantikan apa yang sedang online, jadi saya akan sangat menghargai masukan orang di depan itu juga!

Terima kasih atas umpan baliknya - dan pekerjaan Anda dalam mendokumentasikan pembangunan - yang akan sangat berguna.

Saya kira Anda melihat http://mingwpy.github.io - ada cukup banyak barang di sana, tentu saja, khusus untuk proyek mingw-w64 dan rantai alat mingwpy.

Terima kasih @matthew-brett! Ini melewati numpy.test() . Tes f2py.py adalah masalah di test_scripts() dengan virtualenvs yang diperbaiki di numpy-SHAd3d2f8e , tapi saya mendapatkan 3 peringatan, 2 penghentian dan 1 runtime.

Satu permintaan terakhir, semoga kecil, apakah mungkin menampilkan lencana build di repo np-wheel-builder dan/atau PyPI Anda? Sepertinya buildbot 0.8 memilikinya, dan bahkan ada paket/repo python untuk membuatnya terlihat bagus, BuildbotEightStatusShields-0.1 .

Juga, saya ingin tahu, saya takut jauh dari ATLAS Windows 64-bit build karena kurangnya parameter penyetelan. Apakah itu benar-benar "memakan waktu sepanjang hari" atau apakah ada serangkaian default arsitektur yang tepat?

FYI: Continuum baru saja merilis Anaconda dengan mkl numpy yang dioptimalkan. Saya pikir mereka telah memantau utas ini.

Sekarang untuk scipy build dengan atlas libs yang sama. Apakah itu membutuhkan gfortran?

Ya. Jika tidak, Anda tidak akan dapat mengompilasi file .f apa pun di scipy . Semoga berhasil dengan ini! Seperti yang saya katakan sebelumnya, saya _sangat dekat_, tetapi jika Anda dapat melewati ujian dengan lulus, itu akan sangat bagus!

Ya, saya khawatir pembuatan ATLAS membutuhkan waktu sekitar 8 jam pada mesin yang tidak melakukan hal lain. Skrip pembangunan ATLAS ada di np-wheel-builder repo .

Mengenai berita MKL , itu bagus jika Anda adalah pengguna conda , meskipun saya pikir menggunakan distribusi Python dengan numpy dan scipy sudah diinstal sebelumnya sesuatu yang telah didorong untuk beberapa waktu. Bicaralah dengan saya ketika Anda bisa mendapatkan perpustakaan MKL sendiri secara gratis juga. :)

Untuk membangun dengan gfortran - Saya pikir mingwpy adalah harapan terbaik kami.

@matthew-brett : Terima kasih telah meluangkan waktu untuk membangun ATLAS! Saya mencoba menjalankan skrip Anda sebelumnya, dan saya terus mengalami masalah, mungkin karena ketidakcocokan khusus mesin.

Maaf tentang masalah. Saya baru saja membangun binari ATLAS di repo np-wheel-builder, itu pada instalasi baru Windows Server 2012, dan Cygwin 64-bit, dengan ATLAS dan versi lapack yang tepat terdaftar. Arsip sumber yang saya gunakan ada di http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/. Jika Anda memiliki ATLAS versi lain, itu bisa dengan mudah menjadi berbulu.

Hmm...mungkin memang begitu. Sekali lagi, sangat dihargai mengingat upaya yang Anda lakukan untuk melakukannya. Jika kalian dapat menemukan cara untuk meluncurkan ATLAS yang kompatibel dengan Windows yang tidak memerlukan banyak waktu dan sumber daya seperti sekarang, itu akan sangat bagus!

@gfyoung

Bicaralah dengan saya ketika Anda bisa mendapatkan perpustakaan MKL sendiri secara gratis juga. :)

Lihat https://software.intel.com/sites/campaigns/nest/ dan https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 - atau maksud Anda sumber?

@tkelman , baru saja melihatnya di @carlk situs proyek mingwpy baru tetapi lisensi komunitas Intel Nest tidak memiliki ifort , dan tanpa itu seberapa scipy?

@tkelman : Ups, tidak yakin mengapa saya lupa tentang lisensi komunitas itu. Namun, @tkelman memang memunculkan poin yang valid.

@tkelman : Anda bisa mencobanya dengan MinGW, tetapi dari apa yang saya alami, sayangnya itu tidak berhasil. Itu bahkan tidak akan membuat Anda melewati numpy karena masalah kompatibilitas.

@mikofski benar, tidak membantu untuk scipy mengingat kurangnya kompiler. Hanya opsi hari ini untuk build scipy yang akan menjadi mingwpy, atau build MSYS2 Python sepanjang waktu (https://github.com/Alexux/MINGW-packages/tree/master/mingw-w64- python-scipy). Yang terakhir tentu saja tidak akan kompatibel dengan binari cpython atau pypi yang dibuat msvc sehingga tidak akan menangani semua modul di luar scipy.

@matthew-brett: apa defisit kecepatan untuk roda ATLAS ini versus openblas dan/atau MKL?

Apakah ada yang melihat ke PGI Fortran. Itu tidak disebutkan di situs proyek @carkl mingwpy . Saya mencoba menggunakannya sekali, pergi cukup jauh ke lubang kelinci itu tapi saya tidak ingat apa itu show stopper. Saya pikir lisensinya permisif meskipun itu sumber tertutup. Mungkin PGI Fortran akan bermain lebih baik dengan msvc?

@mikofski : Saya tidak memilikinya di depan saya, tetapi ketika saya melihat PGI tahun lalu, saya ingat kesimpulan saya adalah bahwa itu bahkan lebih buruk daripada Intel (dalam hal memaksa Anda untuk menambahkan batasan yang tidak kompatibel dengan FOSS ke lisensi Anda) .

Oke, mungkin sejumlah dana fokus dapat ditargetkan pada solusi BLIS/FLAME untuk arsitektur x86?

Tampaknya Nvidia/PGI akan menyumbangkan front end Fortran mereka sebagai open source ke LLVM pada akhir tahun ini. https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

Oke, mungkin sejumlah dana fokus dapat ditargetkan pada solusi BLIS/FLAME untuk arsitektur x86?

Jangan berpikir begitu. BLIS terlihat seperti proyek yang sangat tidak sehat (dan libflame terlebih lagi); sedikit aktivitas dalam hal komitmen, lalu lintas milis, dll. Ditambah lagi, mereka memiliki pendanaan yang signifikan (https://github.com/flame/blis#funding), jadi bukan berarti beberapa ribu dolar akan secara ajaib menghasilkan semua itu proyek matang.

Saya tidak begitu mengerti dari mana diskusi ini berasal atau pergi: kami memiliki solusi sementara yang hampir diselesaikan Matthew (menggunakan ATLAS), dan yang lebih penting kami memiliki solusi jangka panjang yang sedang dikerjakan dengan sangat aktif (MingwPy + BukaBLAS). Selanjutnya OpenBLAS jauh lebih banyak digunakan; penggunaan proyek itu di tumpukan Scipy dan di Julia harus lebih matang lebih cepat.

@rgommers : Percakapan berlanjut karena @mikofski dan saya sama-sama mencoba menggunakan solusi @matthew-brett untuk membangun scipy . Namun, tampaknya kami berdua menghadapi masalah yang sama: kompiler Fortran. Saya sendiri telah mencoba menggunakan gfortran.exe yang diinstal untuk MinGW32 dan MinGW64 tanpa banyak hasil karena banyak eksternal yang belum terselesaikan untuk beberapa alasan atau lainnya.

@gfyoung Matthew's build menggunakan MSVC. Tidak ada gunanya mencoba menggunakan gfortran dengan MSVC, itu diketahui tidak berfungsi. Ringkasan situasi build adalah:

• Tidak ada Fortran, maka Anda dapat menggunakan MSVC sekarang.
• Dengan Fortran, Anda dapat menggunakan salah satu MingwPy, MSVC + ifort, atau icc + ifort.
• Untuk tumpukan Scipy, kami menginginkan solusi gratis yang membuat roda untuk numpy, scipy, dll. Untuk itu, MingwPy.

@rgommers Saya minta maaf karena menggagalkan percakapan. Anda benar, solusi @matthew-brett untuk pekerjaan numpy, dan proyek mingwpy oleh @carlk sudah didanai oleh num focus. Saya akan mencoba melihat apakah saya bisa membuat perusahaan saya mendukungnya. Saya sudah menjadi anggota num focus. Sekitar setengah jalan melalui scipy 2829 dan saya kira saya sampai pada kesimpulan yang sama. Saya hanya berharap itu berhasil. Dalam jangka pendek, kami akan terus menggunakan @cgohlke atau beralih ke anaconda. Terima kasih lagi!

Selain mendorong build ke pypi, mungkin satu masalah terakhir untuk @matthew-brett adalah perisai buildbot pada repo skrip build np-nya? Terima kasih! Lalu ini bisa ditutup?

Sebelum ini ditutup, pertanyaan singkat: Saya membuat @matthew-brett numpy sehingga menunjuk ke ATLAS. Namun, ketika saya mencoba membangun scipy menggunakan ifort , itu juga mengambil file site.cfg saya yang lain yang menggunakan MKL yang terletak di direktori home saya. Saya sebenarnya dapat membangun dengan sukses melawan numpy , dan tes lulus menyimpan beberapa kesalahan karena kesalahan pembulatan menit. Namun, saya penasaran, apa yang dilakukan scipy ketika saya membangunnya? Apakah itu menggunakan perpustakaan MKL atau apakah itu mencoba menggunakan perpustakaan ATLAS yang sudah dibangun dengan numpy ?

Ada ringkasan kompiler Windows Fortran di https://github.com/numpy/numpy/wiki/Numeric-software-on-Windows

@gfyoung - hanya menggunakan kombinasi tebakan dan memori yang jauh - Saya percaya bahwa scipy akan mengambil terlebih dahulu site.cfg di direktorinya sendiri, dan jika itu hilang, akan mengambil konfigurasi numpy build. Ini pada gilirannya akan menunjuk ke mana pun perpustakaan di mana, ketika saya membangun roda. Jadi, Anda perlu menulis ulang site.cfg agar scipy dapat mengambil pustaka atlas np-wheel-builder - skrip build_numpy.py melakukannya untuk numpy build.

BLIS terlihat seperti proyek yang sangat tidak sehat (dan libflame terlebih lagi); sedikit aktivitas dalam hal komit, lalu lintas milis, dll.

Saya tidak yakin saya akan menyebut mereka tidak sehat, karena mereka tidak mencoba menjadi proyek FOSS yang dijalankan komunitas; mereka pada dasarnya adalah pertunjukan satu orang, dan mereka menyukainya (setidaknya untuk saat ini). Saya telah berhubungan dengan mereka selama ~ tahun terakhir, dan kabar baiknya adalah bahwa fokus upaya mereka saat ini adalah tepat pada hal-hal yang kita butuhkan (pemilihan kernel runtime dan konfigurasi threading runtime); kabar buruknya adalah tidak banyak yang bisa dilakukan kecuali menunggu seorang arsitek mengatur ulang hal-hal yang disukainya. Mungkin 6 bulan akan melihat beberapa hasil?

Kedengarannya seperti BLIS dll adalah pilihan yang cukup jauh pada saat ini, dan bahwa kita harus merencanakan kasus di mana itu tidak berhasil.

Nathaniel - ada saran di mana mendapatkan benchmark yang bagus? Saya rasa numpy.bench() tidak melakukan apa-apa lagi. Saya mencoba menjalankan asv , tetapi banyak tes gagal karena Windows numpy tidak memiliki complex256 .

Saya kira bagian dari asv yang bekerja berguna? Atau bahkan %timeit np.dot(big_array, other_big_array) akan berguna untuk mendapatkan setidaknya beberapa gagasan kasar di mana kita berdiri :-)

Juga BTW, inilah solusi umum untuk masalah namespace global Windows DLL, memungkinkan kita untuk menulis Windows delocate : https://github.com/njsmith/redll

Sayangnya kegagalan asv complex256 memecah seluruh urutan tes di seluruh tipe d. Saya kira itu tidak akan terlalu sulit untuk diperbaiki.

Pengujian sederhana dengan ini:

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)

menunjukkan bahwa, seperti yang telah diperingatkan Clint Whaley sebelumnya - ATLAS 64 bit tidak dioptimalkan dengan baik di Windows. Dengan MKL 64-bit melalui roda Christoph Gohlke:

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

Dengan roda saya, dibuat dengan ATLAS 64-bit:

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

Perbedaannya jauh lebih sedikit dengan roda 32-bit (pada mesin 32-bit yang berbeda). 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 - Menghubungi Anda, jika Anda memiliki beberapa pemikiran di sini. Ini adalah ATLAS 3.10.1 ...

Inilah mesin Windows 64-bit lainnya dengan prosesor yang lebih modern - juga menunjukkan perlambatan ~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

Yup, masalah 256 kompleks tidak sulit untuk diperbaiki: https://github.com/numpy/numpy/pull/7251

3x banyak, tapi tidak sedramatis lapack_lite bukan? Saya pikir tidak apa-apa untuk solusi jangka pendek. Dan itu tidak seperti installer .exe 32-bit lama yang lebih baik.

Juga BTW, inilah solusi umum untuk masalah namespace global Windows DLL, memungkinkan kami untuk menulis delocate Windows: https://github.com/njsmith/redll

pernyataan lisensi yang bagus :)

@gfyoung 'site.cfg' dicari di:

1) Direktori file setup.py utama sedang dijalankan.
2) Direktori beranda pengguna yang menjalankan file setup.py sebagai ~/.numpy-site.cfg
3) Direktori luas sistem (lokasi file ini ...)

@rgommers Saya minta maaf karena menggagalkan percakapan.

Jangan khawatir, tidak ada yang tergelincir.

Anda benar, solusi @matthew-brett untuk pekerjaan numpy, dan proyek mingwpy oleh @carlk sudah didanai oleh num focus. Saya akan mencoba melihat apakah saya bisa membuat perusahaan saya mendukungnya. Saya sudah menjadi anggota num focus. Sekitar setengah jalan melalui scipy 2829 dan saya kira saya sampai pada kesimpulan yang sama. Saya hanya berharap itu berhasil. Dalam jangka pendek, kami akan terus menggunakan @cgohlke atau beralih ke anaconda. Terima kasih lagi!

Dingin. Dan senang melihat Anda tertarik dengan MingwPy. Perhatikan bahwa ia memiliki ML sendiri sekarang, yang mungkin menarik: https://groups.google.com/forum/#!forum/mingwpy

@rgommers , @matthew-brett : Ah, ya, sepertinya itu dibangun dengan MKL sebelumnya. Saya langsung mengarahkan site.cfg saya ke ATLAS build, dan scipy build tetapi segfaults selama pengujian. Sangat dekat!

@rgommers - ya - kinerja jauh lebih buruk tanpa ATLAS (dengan lapack_lite):

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

Saya kira pertanyaan yang tersisa di sini adalah apakah perlu menstandarisasi ke numpy OpenBLAS (dengan semua tes numpy lulus), menerima risiko bahwa ini akan lebih cenderung menyebabkan kesalahan numerik dalam proyek yang menggunakan numpy.

Salah satu argumen untuk melakukan ini adalah bahwa sepertinya kita harus pergi ke arah ini dalam jangka pendek / menengah, dan mungkin lebih baik untuk memulai sekarang dan berkomitmen pada perburuan serangga yang menyedihkan yang akan terjadi. Setidaknya kita akan berada di perusahaan yang baik dari pengelola Julia.

Numpy juga memiliki serangkaian toleransi risiko vs pengorbanan kinerja yang cukup berbeda, dan rasio pengguna terhadap pengembang, daripada Julia. Jadi saya pikir mungkin masuk akal bagi numpy untuk mengambil pendekatan yang lebih konservatif dan berjalan dengan lambat tetapi dapat diandalkan sebagai default, bekerja untuk memungkinkan openblas sebagai pilihan non-default. Meskipun waktu pembuatan 8 jam itu tidak terdengar menyenangkan, tidak heran tidak ada yang bertanya kepada kami tentang menggunakan Atlas dengan Julia.

bekerja untuk mengizinkan openblas sebagai pilihan keikutsertaan non-default

Masalahnya adalah saya tidak begitu yakin bagaimana proses ini bisa bekerja :-/. Kami tidak memiliki cara yang baik untuk mendistribusikan build alternatif kepada pengguna (dalam jangka panjang saya berharap kami bisa mendapatkan varian build di pypi sebagai numpy[openblas] dan seterusnya, tetapi itu tidak akan terjadi dalam waktu dekat) , kami tidak memiliki cara untuk meningkatkan build openblas kecuali mendistribusikannya dan menunggu laporan bug, dan alternatif utama untuk build ATLAS untuk orang yang termotivasi untuk mencarinya bukanlah build openblas, melainkan MKL dibangun dari beberapa pihak ketiga :-/.

Saya kira opsi lain untuk diletakkan di atas meja adalah dengan mendistribusikan build BLIS menggunakan kernel referensi/SSE2 mereka. Karena BLIS masih hanya memiliki konfigurasi waktu pembuatan, ini tidak akan bersaing dengan openblas, tetapi mungkin bersaing dengan ATLAS, dan manfaat versus ATLAS adalah waktu pembuatan _jauh_ lebih cepat, dan kemungkinan itu menjadi solusi jangka panjang yang baik sulit untuk diperkirakan tetapi tentu saja lebih baik daripada ATLAS menjadi solusi jangka panjang yang baik (yang saya anggap nol). Jika kita tetap akan menanyakan sesuatu maka setidaknya kita akan mengarahkan energi itu pada sesuatu yang _mungkin_ memiliki masa depan.

Beberapa pertanyaan yang perlu dijawab sebelum mempertimbangkan opsi ini secara serius:

(1) Saya tidak yakin apakah dukungan multithreading BLIS bersaing dengan ATLAS (saya tahu ada beberapa opsi multi-threading di sumbernya, dan saya tahu bahwa pengembang utama belum menganggapnya "selesai" , Yaitu kompetitif dengan MKL, tetapi ada banyak ruang antara ATLAS dan MKL.)

(2) dalam hal ini, saya juga tidak tahu bagaimana tarif BLIS dalam mode tidak disetel pada tolok ukur di atas.

(3) Saya belum benar-benar mencoba membangun BLIS di windows, dan ada masalah yang harus dihadapi bahwa itu hanya BLAS, bukan LAPACK -- tidak yakin seberapa besar masalah ini untuk numpy.

Seberapa responsif BLIS terhadap laporan bug? Openblas tampaknya cukup bagus
tentang ini.

Pada Senin, 15 Februari 2016 pukul 15:48, Nathaniel J. Smith <
[email protected]> menulis:

bekerja untuk mengizinkan openblas sebagai pilihan keikutsertaan non-default

Masalahnya adalah saya tidak begitu yakin bagaimana proses ini bisa bekerja :-/.
Kami tidak memiliki cara yang baik untuk mendistribusikan versi alternatif kepada pengguna (di
jangka panjang saya berharap kita bisa mendapatkan varian build di pypi sebagai numpy[openblas]
dan seterusnya, tapi itu tidak akan terjadi dalam waktu dekat), kita tidak punya cara untuk
perbaiki build openblas kecuali mendistribusikannya dan menunggu bug
laporan, dan alternatif utama untuk membangun ATLAS untuk orang-orang yang
termotivasi untuk mencari satu tidak akan membangun openblas, itu akan membangun MKL
dari pihak ketiga :-/.

Saya kira pilihan lain untuk diletakkan di atas meja adalah dengan mendistribusikan BLIS
dibangun menggunakan kernel referensi/SSE2 mereka. Karena BLIS masih hanya memiliki build
konfigurasi waktu ini tidak akan kompetitif dengan openblas, tetapi mungkin
kompetitif dengan ATLAS, dan keuntungan dibandingkan ATLAS adalah bahwa build
waktu _jauh_ lebih cepat, dan kemungkinan itu menjadi jangka panjang yang bagus
solusi sulit untuk diperkirakan tetapi tentu saja lebih baik daripada ATLAS yang bagus
solusi jangka panjang (yang saya akan menempatkan nol). Jika kita akan menjadi QAing
sesuatu, maka setidaknya kita akan mengarahkan energi itu pada sesuatu
bahwa _mungkin_ memiliki masa depan.

Beberapa pertanyaan yang perlu dijawab sebelum mempertimbangkan ini dengan serius
pilihan:

(1) Saya tidak yakin apakah dukungan multithreading BLIS adalah
bersaing dengan ATLAS (saya tahu ada beberapa opsi multi-threading di
sumbernya, dan saya tahu bahwa pengembang utama tidak menganggapnya sebagai
"selesai", yaitu bersaing dengan MKL, tetapi ada banyak ruang antara
ATLAS dan MKL.)

(2) dalam hal ini, saya juga tidak tahu bagaimana tarif BLIS dalam mode tidak disetel
pada benchmark tersebut di atas.

(3) Saya belum benar-benar mencoba membangun BLIS di windows, dan ada
masalah untuk mengatasinya itu hanya BLAS, bukan LAPACK -- tidak yakin bagaimana
banyak masalah ini untuk numpy.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -184387401.

Saya percaya libflame adalah setara dengan lapack di blis. Ada antarmuka kompatibilitas lapack2flame yang dijelaskan dalam dokumen referensi .

Seberapa responsif BLIS terhadap laporan bug?

Kami belum tahu.

Tanpa mencoba BLIS, saya pikir kedengarannya seperti kegilaan untuk pergi dan mengirimkan binari numpy yang dibangun melawan apa yang pada dasarnya merupakan proyek satu orang aktivitas rendah yang sangat sedikit digunakan orang.

Saya belum melihat alasan bagus di utas ini untuk menyimpang dari paket MingwPy + OpenBLAS. No-scipy-ATLAS-MSVC-binary bagus untuk memiliki jeda, tetapi kurang penting daripada solusi MingwPy jangka menengah/panjang dan jika jeda berubah menjadi upaya besar dalam dirinya sendiri, maka saya akan mengatakan itu tidak sepadan dengan usaha .

Dokumen BLIS / libflame menyarankan bahwa, jika saya akan mencoba dan membangun perpustakaan BLAS / LAPACK lengkap di Windows, itu akan menjadi jalan yang sepi.

Saya senang melakukannya setelah pengembang setuju bahwa itu akan berfungsi dan didukung.

ATLAS telah menjadi pustaka default di Linux untuk waktu yang lama. Tampaknya tidak masuk akal untuk membayangkan bahwa hal itu mungkin terjadi pada build yang kompatibel dengan Windows BSD untuk sementara waktu.

@tkelman - terima kasih atas analisis Anda - saya pikir Anda benar, numpy itu harus berkonsentrasi pada kebenaran. Namun, akan lebih baik untuk menggabungkan kekuatan untuk bersandar pada beberapa bug OpenBLAS yang lebih melelahkan dan mengembangkan tes yang lebih komprehensif. Bug OpenBLAS ini muncul di pikiran - agak tidak jelas, sangat sulit untuk di-debug.

Saya percaya untuk masalah khusus ini, yaitu menyediakan roda numpy di pypi sehingga pengguna biasa paket "x" yang bergantung pada "y" (misalnya: matplotlib) yang bergantung pada numpy akan menginstal menggunakan pip, tidak menyebabkan pengguna biasa membuang tangan mereka ke atas dan mengatakan sesuatu seperti, "Python terlalu sulit." dan kembali ke MATLAB. Zen dari python mengatakan harus ada satu cara yang jelas untuk melakukannya. Yang mengatakan, apa pun di pypi oleh numpy khususnya membawa bobot tertentu yang _is_ stabil, atau lebih dari proyek sampingan acak, dengan kemungkinan pengecualian cgohlke. Jelas dipikirkan dan anaconda dianggap setidaknya dalam industri sebagai lebih stabil.

Saya pikir dalam jangka pendek ATLAS build harus naik dengan pesan peringatan bahwa tidak mungkin untuk membangun dengan scipy. Jika buildbot ini dapat diotomatisasi maka selesai, bukan? Pembuatan ATLAS 8 jam di masa mendatang semoga jarang terjadi. Mungkin suatu hari masalah windows 64bit akan terpecahkan. Masalah pengecualian SSE2 mengecewakan, jadi pesan peringatan lain di pypi. ATLAS juga sudah menjadi standar di linux dan merupakan standar dalam paket bdist_winst superpack sebelumnya yang memberikan lebih banyak dukungan untuk jalur ini.

Kemudian untuk waktu dekat, Anda telah memutuskan mingwpy. Di sini ada banyak pilihan yang tidak harus diselesaikan sekarang.

Dalam jangka panjang saya senang bahwa blis/flame adalah masa depan. Agak menakutkan bahwa banyak alat matematika kami bergantung pada kode FORTRAN dari tahun 70-an. Solusi satu-satunya AC adalah terobosan besar dan imo sesuatu untuk mendukung dengan antusias.

Tetapi lebih banyak selalu lebih baik untuk pengembang berpengalaman sehingga menjaga dokumentasi tetap hidup untuk opsi non standar juga bagus jika pengembang berpengalaman tersebut memiliki waktu dan kecenderungan untuk membangun dan mengujinya.

Jika Anda tidak mencoba menggunakan salah satu kernel yang dioptimalkan dalam blis, maka Anda mungkin tidak akan menemukan masalah (edit: tunggal) Saya sudah membukanya sejak 2014. Saya pikir sistem build hanya menggunakan symlink untuk yang dioptimalkan kernel, jadi Anda tidak akan bingung dengan git msys2 jika Anda mencoba membuat konfigurasi referensi saja di sana. Membangun dari cygwin berfungsi terakhir kali saya mencoba, meskipun itu beberapa waktu lalu dan saya tidak dapat mengingat apa yang mungkin perlu saya modifikasi secara lokal. Ada baiknya membangun, menguji, dan membandingkan jika alternatifnya adalah Atlas, tetapi anggap itu tidak terbukti dan karena itu berisiko tinggi dengan caranya sendiri sampai Anda melakukannya.

@mikofski agar adil Lapack berasal dari tahun 90-an, itu benar-benar gajah Fortran di dalam ruangan.

@tkelman : untuk lebih jelasnya, masalah yang Anda ajukan secara khusus dengan sistem build asli windows, bukan? Karena penasaran saya baru saja mencoba mengkompilasi silang blis untuk windows dari linux (menggunakan kompilator silang mingw-w64 yang diinstal dari paket debian), dan saya terkejut menemukan bahwa itu hanya membutuhkan waktu ~2 menit. Saya melakukan "./configure reference; make -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=" dan semuanya bekerja. ( CPICFLAGS= hanya untuk menekan sekelompok peringatan tentang "mengabaikan -fPIC , karena itu default", dan mungkin saya bahkan tidak perlu menimpa AR , tapi hei mengapa tidak.) Mendapat beberapa peringatan tentang printfs di bli_pool.c dan bli_fprintm.c yang menggunakan %ld untuk mencetak bilangan bulat intptr , jadi mungkin ada beberapa kekusutan LLP64 untuk bekerja.

@rgommers :

Tanpa mencoba BLIS, saya pikir kedengarannya seperti kegilaan untuk pergi dan mengirimkan binari numpy yang dibangun melawan apa yang pada dasarnya merupakan proyek satu orang aktivitas rendah yang sangat sedikit digunakan orang.

Anda benar sekali! Masalahnya adalah semua pilihan kita buruk :-(.

Jadi jelas MKL memiliki lisensi yang pasti buruk.

ATLAS memiliki kinerja yang sangat buruk yang tidak akan pernah meningkat.

Dan OpenBLAS, saya pikir kami memiliki bukti untuk mengatakan pada saat ini, tidak dapat dipertahankan dan tidak mungkin menjadi begitu cepat :-(. Proyek ini berusia lima tahun, masih memiliki hal-hal yang secara fundamental rusak seperti contoh Julian dari volatile acak

Jadi alasan saya terus mengangkat BLIS bukan karena saya pikir BLIS pasti solusi, tetapi sebagai semacam optimisme yang diperhitungkan: BLIS _mungkin_ menjadi secepat MKL/OpenBLAS, dapat diandalkan seperti ATLAS/MKL, dan terbuka untuk komunitas- kontribusi sebagai OpenBLAS; atau sekali lagi, mungkin tidak. Tetapi tampaknya tidak ada proyek lain yang memiliki harapan nyata untuk memenuhi semua kriteria tersebut. [Dan ini bahkan tidak menyebutkan keuntungan lainnya, seperti fakta bahwa ia dapat mendukung array bertahap secara asli; itu tidak terbayangkan kami mungkin dapat menghapus semua kode pengiriman BLAS kasus khusus kami yang mengerikan.]

IIUC, GotoBLAS dikelola oleh satu pengembang penuh waktu (Kazushige Goto) yang bekerja di UT Austin dengan Robert van de Geijn sebagai PI. BLIS dikelola oleh satu pengembang penuh waktu (Field G. Van-Zee) yang bekerja di UT Austin dengan Robert van de Geijn sebagai PI. Jadi bukan seperti ini tidak bisa bekerja :-) Tapi ya, itu tidak akan terjadi begitu saja jika kita menunggu -- jika akan ada komunitas pengembang di sekitarnya maka itu akan terjadi karena beberapa komunitas muncul halaman depan dengan tenda seperti "hei, ini dia, kami akan pindah dan membuat ini bekerja untuk kami, semoga Anda tidak keberatan". Dan apa yang benar-benar perlu kita ketahui untuk menentukan kelayakan jangka panjangnya adalah, seperti, "seberapa andal itu sebenarnya" dan "seberapa dapat ditambal" dan hal-hal lain, yang tidak dapat kita ketahui kecuali kita mulai mengujinya dan mengirimkannya patch dan lain sebagainya.

Kesimpulannya: Saya benar-benar tidak tahu apa pilihan terbaik kami, tetapi memasukkan jari kaki kami ke dalam air BLIS sepertinya ide yang bagus; bahkan jika kita memutuskan bahwa kita ingin menunggu maka setidaknya kita akan belajar sesuatu.

Saya mengajukan beberapa masalah dan satu atau dua PR. Fakta bahwa ada symlink di repositori berarti membangun dari msys2 rusak (atau hanya berfungsi jika Anda menyetel opsi msys2 dengan cara tertentu). Pembuatan silang dari cygwin atau linux (saya tidak akan mempercayai anggur untuk menjalankan tes) harus berfungsi tetapi memiliki masalah pada tahun 2014 dengan malloc yang disejajarkan, dan kernel sandy bridge dipisahkan dalam pengujian. Saya baru saja membangun kembali kernel sandy bridge pada master blis terbaru dengan cygwin cross (pada laptop skylake yang lebih baru) dan segfault mungkin hilang sekarang. Siapa yang tahu kapan atau apa yang memperbaikinya, harus membagi dua.

Saya pikir ini telah disebutkan sebelumnya, tetapi kita dapat membangun binari ATLAS untuk SSE2, SSE3, AVX, dan memasukkannya ke dalam struktur direktori seperti:

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

Kami kemudian dapat menggunakan numpy/_distributor_init.py untuk memeriksa CPU saat ini dan melakukan pra-muat pustaka yang cocok.

Saya menyarankan untuk melakukan hal yang sama pada dasarnya, tetapi untuk blis alih-alih atlas, ke @njsmith. Ini juga layak membandingkan seberapa baik threading di blis bekerja vs atlas. Konfigurasi referensi blis tidak mengaktifkan threading secara default, meskipun hanya mengubah definisi dalam file header yang diperlukan untuk mengubahnya.

Saya mengatur Appveyor untuk membangun binari. Iterasi build saat ini sedang berputar di sini: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Roda buatan tiba di sini: https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

Kekusutan lebih lanjut dalam pembuatan Appveyor harus mudah untuk diselesaikan, jadi saya pikir roda ini siap untuk diunggah ke pypi ketika itu selesai, mungkin besok kapan-kapan.

@rgommers , @matthew-brett : Mengenai site.cfg , tampaknya tanggapan Anda hanya berlaku untuk numpy . Tampaknya scipy tidak mencari site.cfg di direktori yang sama dengan setup.py hanya mulai mencari site.cfg terlebih dahulu di direktori home Anda sebelum default numpy konfigurasi.

OK - buat skrip yang berjalan tanpa kesalahan, termasuk pengujian roda yang dipasang: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

Roda di sini: http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

Saya telah menginstal dan mengujinya di mesin 64 bit lain dan mesin 32-bit lainnya.

Jadi, saya pikir ini sudah siap untuk pergi. Adakah keberatan saya mengunggah ini ke pypi?

Mungkin ide yang baik untuk memiliki catatan di pypi yang menjelaskan/menautkan ke penjelasan tentang perbedaan antara roda ini dan yang oleh gohlke (mkl) untuk mencegah kebingungan oleh orang-orang yang bertanya-tanya mengapa roda muncul sekarang di pypi dan apa perbedaannya antara mereka adalah.

Sebuah pertanyaan sampingan, maaf, tapi aku bertanya-tanya apa

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

dalam skrip appveyor artinya?

Saran bagus tentang penjelasannya - Saya akan mencoba dan mencari cara untuk menambahkannya untuk rilis yang ada ini.

Wheel > 0.26 menambahkan tag ABI ekstra ke roda Windows. Wheel==0.26 memberikan nama roda seperti ini:

numpy-1.10.4-cp27-none-win32.whl

Dengan Roda > 0,26, Anda mendapatkan tag ABI tambahan, seperti ini:

numpy-1.10.4-cp27-cp27m-win32.whl

(Saya pikir) - yang menentukan ABI Windows. Ini menjengkelkan karena pip sebelumnya tidak akan menginstal orang-orang ini, jadi menurut saya nama no-ABI lebih baik untuk saat ini.

OK - Saya mengusulkan untuk menambahkan teks ini ke halaman pypi saat ini:

Semua roda numpy yang didistribusikan dari pypi berlisensi BSD.

Roda Windows ditautkan dengan perpustakaan ATLAS BLAS / LAPACK, terbatas pada instruksi SSE2, jadi mungkin tidak memberikan kinerja aljabar linier yang optimal untuk mesin Anda. Lihat http://docs.scipy.org/doc/numpy/user/install.html untuk alternatif.

Saya akan mengatakan secara berbeda:

Roda Windows ini memiliki kinerja aljabar linier suboptimal (tautan ke benchmark seperti http://speed.python.org), karena mereka terkait dengan perpustakaan ATLAS BLAS / LAPACK, yang dibatasi untuk instruksi SSE2 (dan instruksi yang tidak dibatasi harus berada di sana?). Jika Anda membutuhkan kinerja, Anda dapat mendukung proyek mingwpy yang bertujuan untuk membawa lebih banyak kinerja ke ekstensi Python yang dikompilasi pada platform ini. Melihat ??? untuk detail dan http://docs.scipy.org/doc/numpy/user/install.html untuk alternatif.

Yah - versi numpy/scipy mingwpy saat ini menggunakan openblas, tapi saya pikir itu tidak terkait dengan mingwpy vs MSVC sebagai kompiler. Kami juga dapat mengirimkan openblas dengan roda ini, tetapi saya khawatir openblas belum cukup andal untuk digunakan di roda standar yang kami dukung.

OpenBlas tampaknya cukup stabil, saya tahu Anaconda menggunakannya untuk Linux mereka
membangun sekarang. Tidak ada build Windows Python 3.5 x64 yang diperbarui
di sana, tolok ukur menunjukkan itu hampir sama dengan MKL. Saya pasti akan mencobanya jika
seseorang bisa menempatkan roda bersama-sama.
Pada 16 Februari 2016 22:36, "Matthew Brett" [email protected] menulis:

Yah - versi numpy/scipy mingwpy saat ini memang menggunakan openblas, tapi saya
pikir itu tidak terkait dengan mingwpy vs MSVC sebagai kompiler. Kami juga bisa mengirim
openblas dengan roda ini, tapi saya khawatir openblas belum
cukup andal untuk digunakan di velg standar yang kami dukung.

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -185017546.

Baik. Saya hanya bingung tentang sumber kinerja suboptimal - saya tidak menggunakan perpustakaan BLAS itu dan tidak tahu apa yang mereka lakukan dan apa bedanya, jadi menjelaskan opsi ini untuk manusia membantu menjadi .. erm, lebih ilmiah, Anda tahu . =) Saya pikir tidak adanya kompiler terbuka dengan kinerja optimal adalah masalahnya.

@mrslezak : tentang OpenBLAS, saya pasti setuju. Paket OpenBLAS yang disediakan di Cygwin, ditambah dengan paket Lapack, tampaknya mampu membangun NumPy dan SciPy tanpa masalah.

@mrslezak : di mana saya dapat menemukan informasi tentang tolok ukur? Saya mencoba menulis dokumentasi tentang membangun sumber dari Windows untuk scipy.org , dan itu akan menjadi referensi yang bagus untuk siapa saja yang membutuhkan kinerja dengan perpustakaan ini.

Mungkin pendekatan senapan adalah ide yang tepat? Sesuatu seperti:

• Stabil: ATLAS dengan kinerja, peringatan sse2
• Dev: OpenBLAS lihat mingwpy dan binstar
• Alt: MKL @cgohlke , MKL @continuum dan @enthought
  Peringatan: binari tidak kompatibel.
  Tautan untuk info lebih lanjut di scipy dan Matthew Brett's github numpy wiki

@techtonik Saya berharap GCC berkinerja lebih buruk daripada MSVC atau ICC pada kode yang setara yang dapat dibuat oleh semua kompiler tersebut. Masalahnya adalah kurangnya compiler gratis (python.org-cpython-compatible) yang dapat membangun versi kompetitif Lapack, yang ada di Fortran (SciPy juga memiliki komponen Fortran lainnya). Bagian BLAS murni dari OpenBLAS (dan mungkin Atlas juga) sebenarnya dapat dibangun dengan MSVC, tetapi MSVC tidak dapat membuat bagian mana pun yang memerlukan perakitan inline sehingga juga tidak akan kompetitif.

Saya tidak memiliki MKL 64 bit yang berguna (saya mungkin memiliki MKL 32 bit dari conda di suatu tempat jika saya menggali), tetapi berikut adalah beberapa tolok ukur yang dijalankan di Julia membandingkan Atlas dll yang dibuat oleh @matthew-brett dengan referensi dan sandy- menjembatani konfigurasi BLIS, dan build OpenBLAS yang disertakan dengan Julia https://Gist.github.com/54da587b01b7fb163103

Ringkasan: openblas (pada skylake, kernel openblas terbaru haswell) adalah 23x lebih cepat dari atlas, 44x lebih cepat dari referensi blis, dan 5,5x lebih cepat dari sandybridge blis. Saya mungkin mencoba haswell blis untuk melihat seberapa dekat itu.

Hum - Saya rasa Anda tidak memiliki skrip build untuk kompilasi BLIS Anda?

Apakah menurut Anda layak untuk membuat BLIS build untuk berbagai prosesor dan memilih satu saat run-time? Apakah ada sebagian kecil prosesor yang akan menangkap sebagian besar kinerja untuk sebagian besar prosesor?

Ada di komentar, tapi di sini (jalankan di 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

Inilah yang mereka dapatkan: https://github.com/flame/blis/tree/master/config

Dalam hal Intel x86, referensi, dunnington, sandybridge, dan haswell akan mencakup kisaran yang cukup baik. Juga buldoser, piledriver, dan carrizo untuk AMD (yang baru-baru ini berhenti mengembangkan ACML demi BLIS, jadi setidaknya itu suara yang mendukung).

Ada beberapa kode deteksi otomatis di https://github.com/flame/blis/tree/master/build/auto-detect yang mungkin dapat digunakan kembali (saat ini hanya berjalan pada waktu konfigurasi di BLIS, tetapi itu tidak berarti tidak dapat digunakan kembali untuk tujuan lain), tergantung pada apakah sudah ada bagian dari kode identifikasi keluarga cpu di Python tergeletak di sekitar yang ingin Anda gunakan.

tergantung pada apakah sudah ada sepotong kode identifikasi keluarga cpu dengan Python tergeletak di sekitar

Apakah ini membantu? http://stackoverflow.com/a/35154827/239247

Anda sebagian besar menginginkan keluarga prosesor yang berasal dari itu, tetapi https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c tidak terlalu panjang atau rumit. Sumber numexpr yang ditautkan dari SO melakukan pencocokan regex pada output string (setidaknya di linux), dan sepertinya tidak memiliki banyak arsitektur terbaru yang terdaftar.

openblas 3,4x lebih cepat dari Haswell blis, dan 17x lebih cepat dari dunnington (pada dasarnya sama dengan nehalem penryn saya pikir) blis. Yang menarik adalah saya tidak berpikir multithreading bekerja dengan baik pada proses ini. Pengaturan default memungkinkan openmp untuk sandybridge dan haswell, mungkin mingw pthreads akan bekerja lebih baik. Menetapkan OMP_NUM_THREADS tampaknya tidak membuat banyak perbedaan.

Saya percaya bahwa ATLAS 3.11 harus melakukan jauh lebih baik pada 64 bit daripada versi 3.10, tetapi saya tidak dapat membangunnya saat ini, berharap bantuan dari Clint Whaley.

Tony - Saya kira Anda tidak punya waktu / energi untuk menguji roda ATLAS 32-bit? Seharusnya jauh lebih baik, relatif.

Preferensi saya sendiri adalah melanjutkan dengan roda ATLAS ini, sehingga pembuat paket lain dapat bergantung pada kami untuk mengirimkan semacam roda. Jika kami mencari cara yang baik untuk meningkatkan kinerja, kami memiliki rilis numpy baru yang akan segera hadir, dan bahkan untuk 1.10.4 kami selalu dapat melakukan rilis pemeliharaan untuk memperbarui roda.

@matthew-brett : pertanyaan singkat, mengapa numpy tidak dapat mendeteksi ATLAS build di Cygwin? Saya dapat mendeteksinya dengan sangat baik di lingkungan Windows asli, tetapi ketika saya mencoba menjalankan skrip Anda di Cygwin, numpy tidak dapat dikompilasi dengan ATLAS .

Jika Anda menggunakan python Cygwin, maka Anda mungkin memerlukan versi atlas yang dibuat oleh cygwin agar semuanya kompatibel.

32 bit Julia tampaknya gagal untuk membuka atlas dll 32 bit. Tidak yakin mengapa, mungkin karena kita sudah memiliki openblas 32 bit dan nama simbolnya saling bertentangan?

Tapi versi @matthew-brett dibuat dengan Cygwin, dan itulah mengapa saya bingung.

Lingkungan build Cygwin, dikompilasi silang ke perpustakaan mingw. Lihat bagaimana itu ditautkan ke msvcrt.dll daripada cygwin1.dll?

Segera setelah saya memposting komentar, itulah yang tiba-tiba saya duga mungkin terjadi. Sayangnya, sepertinya saya harus membangunnya dari awal. Terima kasih @tkelman !

masalah dlopen ditemukan (ref https://github.com/matthew-brett/np-wheel-builder/pull/1, dan https://github.com/JuliaLang/julia/issues/15117 menyembunyikan versi berguna dari pesan kesalahan).

Pada 32 bit, atlas 3,6 kali lebih lambat dari openblas. Openblas 32 bit 3x lebih lambat dari openblas 64 bit untuk masalah ukuran yang sama. Beberapa keluarga kernel terbaru tidak diaktifkan di openblas pada sistem 32 bit.

...
Kesimpulannya: Saya benar-benar tidak tahu apa pilihan terbaik kami, tetapi memasukkan jari kaki kami ke dalam air BLIS sepertinya ide yang bagus; bahkan jika kita memutuskan bahwa kita ingin menunggu maka setidaknya kita akan belajar sesuatu.

Itu mungkin berguna, setidaknya beberapa pengujian/pembandingan. Tetapi pada titik ini hampir tidak ada hubungannya dengan masalah _Windows_ kami. BLIS hanya untuk Linux saat ini; ada PR terbuka untuk dukungan build OSX, dan Windows sangat jauh. Dan lebih buruk lagi, saya mencobanya kemarin di Linux 32-bit dan bahkan itu tidak berhasil. ./configure auto && make crash parah pada beberapa kode assembler (untuk sandybridge ). Saya hanya bisa membangun reference .

Jadi saya pikir langkah 0 adalah menambahkan dukungan untuk BLIS di numpy.distutils (sebagian besar sudah berfungsi), langkah 1 untuk menguji di Linux untuk melihat bahwa setidaknya reference berfungsi, langkah 2 beberapa pembandingan, ..., melangkahsesuatu di Windows.

@matthew-brett teks yang Anda usulkan untuk PyPI tampaknya baik-baik saja bagi saya. Versi pip mana yang mengabaikan nama dengan tag ABI? Pip sering mengganggu Anda untuk mengupgrade dirinya sendiri akhir-akhir ini, jadi saya berharap banyak orang memiliki versi terbaru. Dan versi >1(.5) tahun bahkan tidak memasang roda sama sekali secara default.

@rgommers tes saya di atas ada di windows. Bukan MSVC, tetapi mingwpy atau openblas tidak akan melakukan banyak perbedaan di sana - dentang mungkin akan berfungsi tetapi membutuhkan reorganisasi repo dalam blis untuk menghindari symlink.

Saya tidak menjalankan tes Julia atau numpy terhadap blis, tetapi blis melewati tes unitnya sendiri. Segalanya berjalan jauh lebih baik daripada pengalaman saya dari tahun 2014 membuat saya berpikir mereka akan melakukannya. Masih perlu mencari cara agar multithreading berfungsi dengan baik, tetapi dengan itu Anda mungkin sudah memiliki kinerja yang kompetitif.

Tampaknya konfigurasi referensi adalah satu-satunya hal di blis yang berfungsi untuk 32 bit x86 sekarang. Itu akan membutuhkan penulisan mikrokernel perakitan baru yang saya yakini mungkin tidak, lihat komentar njsmith di bawah.

@tkelman , tentang kernel OpenBLAS untuk 32 bit https://github.com/numpy/numpy/issues/5479#issuecomment -185096062: menurut priv. pesan yang saya dapatkan dari Werner Saar beberapa waktu lalu tidak ada yang mengerjakan kernel Intel 32 bit untuk arsitektur yang lebih baru. Jadi ini adalah fakta yang tidak mungkin berubah di masa depan. Fokusnya adalah pada prosesor Intel 64bit dan ARM.

@tkelman , tentang C-runtime https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: IMHO ini tidak penting karena ATLAS dan OpenBLAS tidak berbagi sumber daya C-runtime (deskriptor file dan tumpukan ). _Semoga saya benar_. Mungkin berguna untuk ATLAS build untuk meningkatkan ukuran tumpukan. Ini dapat diberikan sebagai tanda selama penautan, yaitu:

-Wl,--stack,16777216

mengenai diskusi ATLAS vs. OpenBLAS: terima kasih kepada @matthew-brett sekarang tersedia DLL ATLAS berbasis SSE2. Build Atlas ini harus dibandingkan dengan build OpenBLAS dengan Target yang diaktifkan SSE2 (atau cukup setel OPENBLAS_CORETYPE=NORTHWOOD - pada dasarnya PENTIUM4) untuk menonaktifkan deteksi runtime CPU. Tentu saja build OpenBLAS generik dapat mengeksploitasi lebih banyak varian CPU berkat deteksi runtime CPU. Ini adalah salah satu alasan OpenBLAS lebih berperforma dibandingkan dengan ATLAS. Pertanyaan lain adalah keandalan OpenBLAS. Mungkin repositori dengan BLAS yang dikumpulkan, tes LAPACK bisa membantu.

tentang BLIS/Flame: menarik, tapi paling tidak buah yang menggantung untuk hari ini.

Pengambilan keputusan tentang bagaimana memilih antara ATLAS dan OpenBLAS tidak jelas bagi saya.

Ralf - pip 8 akan memasang roda dengan tag Windows ABI baru, pip 7 tidak. Pip 7 dan pip 8 akan memasang roda tanpa tag ABI, tanpa peringatan.

Masih ada banyak pip 7 di luar sana, dirilis pada Agustus 2015 - jadi saya lebih memilih untuk tetap menggunakan nama yang lebih kompatibel, setidaknya untuk sementara waktu.

+1 untuk menyelidiki BLIS. Itu sepertinya solusi jangka panjang yang bagus. Sudahkah kita mempertimbangkan Eigen sama sekali? Mereka mendukung pembuatan antarmuka LAPACK parsial, dan lisensinya adalah MPL2 untuk sebagian besar kode. Itu mungkin cukup baik untuk NumPy.

Saya perhatikan dari kode deteksi cpu BLIS yang sangat sering jatuh kembali ke implementasi referensi jika tidak menemukan instruksi AVX, yang masih cukup baru.

Ian: ini adalah keadaan untuk Eigen pada sekitar satu tahun yang lalu: http://mingwpy.github.io/blas_lapack.html#eigen - jadi saya percaya itu akan menjadi pekerjaan untuk membangun perpustakaan yang dapat digunakan untuk numpy.

Dan lebih buruk lagi, saya mencobanya kemarin di Linux 32-bit dan bahkan itu tidak berhasil. ./configure auto && make crash parah pada beberapa kode assembler (untuk sandybridge). Saya hanya bisa membangun referensi.

Jika Anda melihat konten config/ -- berbagai "konfigurasi" bernama (seperti "sandybridge", "haswell") sebenarnya adalah konfigurasi "starter" yang sudah dikemas sebelumnya yang menyertakan sekumpulan pengaturan yang telah ditentukan sebelumnya (bukan hanya Pengaturan terkait penyetelan CPU, tetapi juga pengaturan mode threading, pengaturan kompiler, dll.). Dan konfigurasi yang disebut "sandybridge" adalah konfigurasi x86-64. Kedengarannya seperti bug yang dipilih oleh konfigurasi otomatis, tapi ya itu tidak akan berfungsi pada x86-32 :-). BLIS tampaknya dikirimkan dengan kernel x86 32-bit (lihat kernels/x86 ), meskipun sepertinya saat ini tidak ada konfigurasi yang dikemas sebelumnya yang menggunakannya. Membuat konfigurasi baru sebagian besar sepele; satu-satunya keajaiban ada di file bli_kernel.h yang menamai kernel bagian dalam + beberapa ukuran buffer. Kami dapat menanyakan ke hulu jika mereka memiliki saran untuk x86-32.

Juga:

BLIS hanya untuk Linux saat ini; ada PR terbuka untuk dukungan build OSX, dan Windows sangat jauh

Beberapa komentar di atas, @tkelman sedang membangun dan membandingkan BLIS di Windows :-)

Benchmark test_dot minyak mentah sebelumnya dengan OpenBLAS 0.2.12:

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

Dibandingkan dengan (hasil sebelumnya dari) MKL

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

ATLAS 64-bit:

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

Jadi ketika saya membandingkan openblas dan MKL (terima kasih, conda) secara serial dengan konfigurasi Haswell BLIS, mereka semua paling banyak 10-20% satu sama lain di dgemm. Inilah dockerfile yang berhasil dibangun di hub docker untuk mengkompilasi silang Windows dll dari setiap konfigurasi (kecuali buldoser yang tidak terhubung dengan benar https://github.com/flame/blis/pull/37#issuecomment-185480513, oh well) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

Anda mungkin ingin mencoba menghubungkan sesuatu yang mirip dengan konfigurasi services: docker Travis dan bermain dengan menyebarkan artefak biner ke rilis github/bintray/apa pun.

Saya melihat deteksi CPU BLIS -> kode templat: https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

Inilah penulisan ulang Python, yang seharusnya sedikit lebih liberal dalam menerima salah satu templat lanjutan (lebih mungkin untuk percaya OS dapat menggunakan AVX daripada kode C): https://Gist.github.com/matthew-brett /a53778f99b7062cc332d

Pada semua mesin yang saya uji, algoritme ini mengembalikan 'referensi' - mungkin karena saya memiliki mesin lama yang tidak ingin digunakan orang lain, untuk menyelamatkan pertanian buildbot saya.

Mengkompilasi numpy terhadap referensi BLIS, tanpa lapack, memberikan yang berikut ini pada patokan mentah saya:

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

Hanya produk titik dari dua (1000, 1000) array adalah 12 detik. Jadi, seperti yang juga ditemukan Tony, referensi BLIS adalah yang terburuk dari opsi kami, di sekitar build default no-library numpy yang sama dengan lapack_lite.

Jadi, saya pikir kita akan membutuhkan lebih banyak template yang mencakup mesin yang lebih tua atau deteksi CPU yang lebih liberal -> pemetaan template untuk memberikan kinerja yang wajar pada berbagai mesin.

@matthew-brett kapan kita bisa mengharapkan roda windows ATLAS 64-bit yang baru naik? Versi yang mana? v1.10.2? Apakah mereka hanya ada di pypi atau juga source forge? Apakah Anda akan membuat pengumuman apa pun? Terima kasih banyak!

@matthew-brett apa rasio antara atlas dan referensi blis untuk Anda di mesin yang sama? Sebanding dengan faktor sekitar 2 yang saya lihat? Saya membuat multithreading berfungsi di blis, saya hanya tidak rtfm dengan benar (https://github.com/flame/blis/wiki/Multithreading), itu tidak diaktifkan secara otomatis, dan ada 4 vars env berbeda untuk dimainkan . Dengan tambalan ini https://Gist.github.com/0fc9497a75411fcc0ec5 untuk mengaktifkan blis paralel berbasis pthreads untuk semua konfigurasi dan pengaturan BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 , blis Haswell pada dasarnya diikat dengan mkl dan openblas di mesin saya. Jika saya menetapkan hanya BLIS_JR_NT ke 2 maka blis referensi paralel sebagian besar mengikuti atlas, dan lebih cepat dengan 3 utas.

@tkelman IMO akan berguna jika Anda dapat mendokumentasikan kemajuan Anda di BLIS di halaman NumPy GitHub Wiki. Saya juga berpikir mungkin menarik untuk mengusulkan rencana yang mirip dengan mingwpy untuk membuat roda NumPy-BLIS-FLAME (dan roda SciPy-BLIS-FLAME jika memungkinkan?).

@tkelman : untuk memastikan saya jelas -- atlas Anda berulir, bukan?
hal lain yang perlu dipertimbangkan adalah menambahkan -msse2 atau mirip dengan pengaturan build reference -- sepertinya secara default ini kompatibel secara maksimal dan tidak mengizinkan kompiler untuk menggunakan SSE, tetapi setidaknya dalam numpy-land Saya tahu kami akan menggunakan SSE2 sebagai konfigurasi minimum yang didukung karena alasan lain...

Saya tidak tahu apakah FLAME relevan atau tidak saat ini versus LAPACK biasa -- kami ingin bertanya.

Mungkin kita harus membuka masalah baru untuk hal-hal BLIS daripada terus mengacaukan yang ini :-)

Untuk utas ini - Saya pikir kita sudah dapat mengirimkan roda dengan berbagai kernel BLIS yang dipilih saat run-time menggunakan aturan yang sama seperti yang digunakan BLIS pada waktu pembuatan, tetapi saya pikir itu akan menghasilkan banyak mesin dengan referensi BLIS, dan karenanya memiliki yang lebih buruk kinerja daripada ATLAS 64-bit, meskipun ATLAS 64-bit pada Windows sangat buruk (untuk ATLAS).

Tetapi - jika build referensi lebih cepat daripada ATLAS 64-bit - katakan dengan -msse2 - itu akan menjadi opsi nyata.

SSE2 adalah konfigurasi minimum untuk 64-bit sehingga aman untuk menggunakan sesuatu seperti -mfpmath=sse -msse2 untuk kompilasi referensi.

Mungkin kita harus membuka masalah baru untuk hal-hal BLIS daripada terus mengacaukan yang ini :-)

Itu akan menjadi ide yang bagus (edit: bolehkah saya menyarankan itu berjudul "Menempati BLIS," mengingat sentimen @njsmith tentang rumput di https://github.com/numpy/numpy/issues/5479#issuecomment-184472378 ?) . Saya pikir memiliki @matthew-brett melanjutkan dengan mengunggah roda Atlas yang ada akan cukup untuk menutup yang ini untuk saat ini, dengan pekerjaan di masa depan yang tersisa untuk masalah baru.

untuk memastikan saya jelas -- atlas Anda berulir, bukan?

Atlas saya adalah dll dari https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds , tetapi saya belum melihatnya berhasil menggunakan lebih dari 1 utas. Apakah saya kehilangan variabel lingkungan?

hal lain yang perlu dipertimbangkan adalah menambahkan -msse2 atau mirip dengan pengaturan build reference -- sepertinya secara default ini kompatibel secara maksimal dan tidak mengizinkan kompiler untuk menggunakan SSE

SSE2 adalah bagian dari spesifikasi x86_64 jadi ini hanya akan relevan pada 32 bit. Di Julia kami menambahkan -march=pentium4 untuk build 32 bit kami.

Saya tidak tahu apakah FLAME relevan atau tidak saat ini versus LAPACK biasa -- kami ingin bertanya.

Belum menyentuh api, tapi layak dimainkan. Akhirnya Anda mungkin dapat menggunakan WIndows Dentang sebagai alternatif rencana cadangan untuk mingwpy. (edit: sebenarnya ini tidak memperbaiki fortran di scipy, jadi mungkin tidak)

@matthew-brett: Saya pikir (bisa jadi salah) kernel dunnington hanya membutuhkan SSE3, yang menurut Steam Hardware Survey hadir pada 99,94% mesin (dibandingkan 99,99% untuk SSE2). Jadi sepertinya salah jika Anda menemukan bahwa sebagian besar sistem tidak dapat mengatasinya -- tidak tahu apakah itu bug dalam kode cpuid mereka, entah bagaimana Anda memiliki set mesin uji yang benar-benar tidak representatif, atau dalam pemahaman saya dari apa yang dibutuhkan kernel itu.

Saya memposting penulisan ulang Python dari kode deteksi CPU di Intisari di atas. Saya menduga pemilihan template konservatif, default ke referensi di mana template lain mungkin bekerja.

Untuk mengingatkan diri sendiri, untuk menautkan ke BLIS, saya membutuhkan site.cfg seperti:

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

Saya juga melakukan ini, saya menganggap itu perlu (tambalan relatif terhadap 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):

Utilitas untuk memungkinkan deteksi run-time CPU: https://github.com/matthew-brett/x86cpu

Saya kira ini mungkin kandidat untuk dimasukkan dalam numpy itu sendiri, tetapi kita juga dapat menyalin modul cpuinfo yang dikompilasi ke dalam pohon numpy untuk roda Windows.

Halo semua. Sebuah pemikiran: jika Anda ingin menerbitkan beberapa roda numpy berbeda yang dibuat dengan berbagai pustaka vektor, Anda dapat menggunakan nama paket PyPI yang berbeda

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

Saya mendaftarkan 2 untuk mencoba mengunggah roda Gohlke, tetapi PyPI menolaknya. Anda dipersilakan untuk URL.

gh-7294 menambahkan dukungan BLIS ke numpy.distutils . Akan lebih bagus jika seseorang dapat memverifikasi bahwa ini berfungsi seperti yang diharapkan.

Masih ada banyak pip 7 di luar sana, dirilis pada Agustus 2015 - jadi saya lebih memilih untuk tetap menggunakan nama yang lebih kompatibel, setidaknya untuk sementara waktu.

Pip 7.0 belum setua itu, jadi masuk akal.

... BLIS tampaknya dikirimkan dengan kernel x86 32-bit (lihat kernel/x86), meskipun sepertinya saat ini tidak ada konfigurasi yang sudah dikemas yang menggunakannya

Demikian penjelasannya, terima kasih.

Terima kasih Ralf - saya akan menguji.

Saya menyadari ini mungkin memerlukan utas baru, tetapi kami sekarang sangat dekat untuk dapat menggunakan BLIS build untuk rilis.

Saya pikir semua yang kita butuhkan sekarang adalah templat yang direkomendasikan untuk mesin yang memiliki SSE2, dan mesin yang SSE3, yang bekerja lebih cepat daripada ATLAS 64-bit Windows build.

Saya menyadari ini mungkin memerlukan utas baru, tetapi kami sekarang sangat dekat untuk dapat menggunakan BLIS build untuk rilis.

Eh, secara teknis mungkin untuk membuatnya bekerja, tapi itu masih bukan rencana yang baik untuk melemparkan bangunan ke atas tembok seperti itu. Kami bahkan belum melakukan pengujian serius terhadap BLIS di Linux atau OS X. Jadi di Windows, di mana FAQ BLIS mengatakan :

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.

, itu pasti terlalu dini. Selain pengujian, beberapa pembandingan juga merupakan ide yang bagus menurut saya.

Tentu - tetapi seperti yang telah ditunjukkan Tony, sebenarnya tidak sulit untuk membangun BLIS untuk Windows, menggunakan kompilasi silang. Hal eksperimental - saya percaya - adalah sistem build MSVC mereka, yang tidak kami gunakan.

Untuk saat ini, saya hanya menyarankan menggunakan BLIS untuk roda Windows, tetapi tentu saja akan sangat baik untuk membuatnya bekerja untuk banyak versi Linux juga.

Saya sepenuhnya setuju bahwa, jika kami tidak mendapatkan peningkatan kinerja rata-rata yang signifikan, maka kami tidak boleh menggunakan BLIS, dan, saat ini, saya rasa tidak, kecuali untuk prosesor yang sangat baru. Itu mungkin bisa diperbaiki dengan beberapa templat baru, saya ingin tahu apakah itu masalahnya.

Untuk kebenaran, saya juga setuju. Bagaimana kalau kita tunjukkan itu

a) Semua tes numpy lulus pada semua versi Windows;
b) Semua tes numpy dan scipy lulus pada sistem manylinux?

Kita dapat membuat template BLIS dapat dipilih saat run-time, dan menguji semua kernel pada mesin modern. Saya dapat menguji pada beberapa mesin jahat lama juga.

Untuk saat ini, saya hanya menyarankan menggunakan BLIS untuk roda Windows, tetapi tentu saja akan sangat baik untuk membuatnya bekerja untuk banyak versi Linux juga.

manylinux kurang penting menurut saya, karena kami memiliki manajer paket di sana dengan tumpukan penuh serta pengguna yang dapat dengan lebih mudah mengompilasi sesuatu. Mari kita lihat dulu keseluruhan konsep manylinux sebelum kita mengkhawatirkannya dalam konteks numpy + BLAS/LAPACK ini :)

Untuk Windows, menurut saya prio kami adalah:

1) solusi tumpukan penuh (membutuhkan MingwPy, dengan salah satu OpenBLAS/ATLAS/BLIS)
2) roda biner sementara (kami memiliki satu yang akan naik dengan build ATLAS Anda)
3) meningkatkan kinerja (1). Di sinilah BLIS bisa masuk.

Jadi saya tidak perlu terburu-buru dengan BLIS di Windows.

Saya sepenuhnya setuju bahwa, jika kami tidak mendapatkan peningkatan kinerja rata-rata yang signifikan, maka kami tidak boleh menggunakan BLIS, dan, saat ini, saya rasa tidak, kecuali untuk prosesor yang sangat baru. Itu mungkin bisa diperbaiki dengan beberapa templat baru, saya ingin tahu apakah itu masalahnya.

Setuju, harus ada keuntungan yang signifikan agar masuk akal. Memang agak sulit untuk mengawasi berapa banyak pekerjaan yang dibutuhkan.

Untuk kebenaran, saya juga setuju. Bagaimana kalau kita tunjukkan itu

a) Semua tes numpy lulus pada semua versi Windows;
b) Semua tes numpy dan scipy lulus pada sistem manylinux?

Boleh juga. Masuk akal untuk memasukkan scikit-learn juga, ini adalah pengguna linalg yang cukup signifikan.

Saya tidak menyadari bahwa blis dan libflame telah menjadi bagian dari basis kode ACML, yang telah bersumber terbuka beberapa waktu lalu:

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/

Namun demikian: bagaimana memecahkan masalah untuk membandingkan 4 implementasi BLAS/Lapack yang dipercepat yang berbeda untuk numpy/scipy build dengan MSVC atau mingwpy untuk diuji pada banyak arsitektur CPU: Pentium4 hingga skylake?

Nice find @carlk , saya terlihat mengingat mereka mengumumkan menjatuhkan acml dan open source acl, tetapi saya tidak ingat mereka mengadopsi blis/libflame. Lisensi bsd adalah berita yang sangat bagus! Apakah ada cara untuk bekerja dengan AMD dan shpc di ut Austin untuk menargetkan numpy dan Julia?

Saya dapat mengkompilasi silang libblis.a menggunakan msys2 dan konfigurasi haswell di luar kotak dan lulus semua tes dengan menambal symlink kernel, tetapi saya tidak dapat membangun libflame - saya mendapatkan kesalahan "daftar argumen terlalu panjang" yang sama seperti pada posting milis blis-discuss saya. Saya pribadi juga tidak tahu cara menautkan ke libblis.a dari lapack, tetapi saya tidak berusaha terlalu keras.

Dengan lisensi komunitas MKL, apakah tidak mungkin menyediakan roda MKL di pypi, apakah lisensinya benar-benar tidak kompatibel? Atau tidak mungkin membangun scipy tanpa ifort?

Satu masalah, dan mungkin milik scipy, yang belum disebutkan adalah file Fortran yang tersisa di scipy. Maaf untuk pertanyaan noob tapi mengapa kita harus menggunakannya? Bagi saya tampaknya Fortran, dan kurangnya kompiler multiplatform gratis, adalah masalah sebenarnya di sini. Bukankah itu yang ingin dipecahkan oleh mingwpy. Diberikan MKL gratis atau acl blis/flame ajaib di masa depan, siapa pun yang memiliki c-compiler dapat membuat tumpukan scipy itu bukan untuk file *.f.

@mikofski , senang mendengarnya, bahwa blis dapat dikompilasi dengan msys2. Apakah ini juga berlaku untuk libflame? Saya kira kita perlu libflame untuk Lapack API.
Secara pribadi _itu_ mungkin untuk memiliki numpy yang dikompilasi MSVC dan menggunakannya bersama dengan scipy yang dikompilasi mingwpy. Anda perlu menambahkan -mlong-double-64 ke flag gcc untuk memastikan bahwa long doubles == double.

Sulit untuk menjadikan perilaku ini sebagai default di gcc, saya memainkan masalah ini sejak satu minggu :(

Saya akan datang besok dengan roda scipy. Ini akan didasarkan pada Atlas yang disediakan oleh roda numpy dari @matthew-brett.

Namun demikian, saya mendukung penggunaan OpenBLAS sekarang.

Satu masalah, dan mungkin milik scipy, yang belum disebutkan adalah file Fortran yang tersisa di scipy. Maaf untuk pertanyaan noob tapi mengapa kita harus menggunakannya?

Karena itu banyak kode yang sangat berguna dan berkinerja tinggi. Dan bukan hanya BLAS/LAPACK - banyak scipy.sparse.linalg , scipy.linalg , scipy.special dan scipy.interpolate misalnya adalah Fortran. Juga, Scipy bukan satu-satunya proyek dengan kode Fortran, ada paket lain seperti bvp_solver serta kode Fortran milik orang yang mereka bungkus dengan f2py.

Memang, bagus menemukan Carl.

Namun demikian: bagaimana memecahkan masalah untuk membandingkan 4 implementasi BLAS/Lapack yang dipercepat yang berbeda untuk numpy/scipy build dengan MSVC atau mingwpy untuk diuji pada banyak arsitektur CPU: Pentium4 hingga skylake?

Ini memang membutuhkan kerangka kerja build/test/benchmark otomatis yang layak. Kami tidak perlu repot dengan arsitektur CPU yang sangat lama (selama semuanya berfungsi di sana, itu baik-baik saja) dan juga tidak dengan MSVC saya kira. Tapi tetap saja itu akan menjadi pekerjaan untuk mengatur ini dengan benar.

@rgommers terima kasih!

Halo semua. Sebuah pemikiran: jika Anda ingin menerbitkan beberapa roda numpy berbeda yang dibuat dengan berbagai pustaka vektor, Anda dapat menggunakan nama paket PyPI yang berbeda

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

Saya mendaftarkan 2 untuk mencoba mengunggah roda Gohlke, tetapi PyPI menolaknya. Anda dipersilakan untuk URL.

@hickford tolong jangan lakukan itu. Ini melanggar lisensi MKL untuk mendistribusikan ulang binari seperti itu (kecuali Anda memiliki lisensi pribadi), dan itu bukan cara yang tepat untuk melakukan ini. Di masa mendatang kami mungkin ingin mendistribusikan beberapa rasa melalui ekstra ( numpy[atlas] , numpy[openblas] dll.) sekalipun.

Juga, mendistribusikan ulang roda orang lain di PyPi tanpa bertanya mungkin bukan hal yang harus dilakukan....

Mingwpy dan masalah fortran apa pun yang bergantung pada penautan ke runtime c yang sama dengan cpython dibatasi pada @carlkl , bereksperimen dengan BLIS memecahkan lebih sedikit masalah tetapi dapat dilakukan secara mandiri oleh siapa saja. Sayangnya saya telah menghabiskan waktu pribadi saya untuk melihat BLIS sekarang, tetapi lihat #7294.

Tony - terima kasih banyak atas semua bantuan Anda, ini sangat berharga.

Saya menambahkan versi ATLAS (3.11.38) yang lebih baru pada 64-bit

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

Ini adalah build serial (unthreaded), karena masalah kompilasi 3.11.38 di Windows, tetapi seharusnya sedikit lebih cepat dari 3.10.1, dan pada benchmark sederhana saya:

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

dibandingkan dengan versi 3.10.1 sebelumnya (lihat di atas):

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

@tkelman - dapatkah Anda membandingkan bangunan ini di Julia?

Maaf untuk melompat ke sini dengan catatan sebelumnya tentang binari MKL - Intel menawarkan
versi komunitas yang memungkinkan redistribusi karena gratis untuk semua...
Pada 2 Mar 2016 15:08, "Matthew Brett" [email protected] menulis:

Saya menambahkan versi ATLAS (3.11.38) yang lebih baru pada 64-bit

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

Ini adalah build serial (unthreaded), karena masalah kompilasi 3.11.38
di Windows, tetapi seharusnya sedikit lebih cepat dari 3.10.1, dan sederhana
patokan:

Dalam [2]: %timeit test_dot()
1 putaran, terbaik dari 3: 1,65 detik per putaran

dibandingkan dengan versi 3.10.1 sebelumnya (lihat di atas):

Dalam [10]: %timeit test_dot()
1 putaran, terbaik dari 3: 2,41 detik per putaran

@tkelman https://github.com/tkelman - dapatkah Anda membandingkan build ini?
Julia?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -191431331.

@mrslezak - lisensi mengizinkan redistribusi, tetapi membuat redistributor bertanggung jawab atas biaya hukum apa pun jika Intel dituntut sebagai akibat dari penggunaan perangkat lunak. Juga, biner yang dihasilkan tidak dapat dilisensikan BSD. Lihat: http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

Bisakah itu dihindari dengan menambahkan 'asalkan apa adanya, tanpa kewajiban apa pun
kerugian moneter yang mungkin timbul dari penggunaannya' atau sesuatu yang mempengaruhi?
Pada 2 Mar 2016 18:22, "Matthew Brett" [email protected] menulis:

@mrslezak https://github.com/mrslezak - lisensi memungkinkan
redistribusi, tetapi membuat redistributor bertanggung jawab atas biaya hukum apa pun jika:
Intel dituntut karena menggunakan perangkat lunak tersebut. Juga, yang dihasilkan
biner tidak dapat dilisensikan BSD. Melihat:
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -191505500.

Saya tidak berpikir itu akan berhasil, karena kami harus menyetujui lisensi Intel, dan lisensi Intel mengatakan bahwa kami bertanggung jawab atas biaya hukum mereka jika mereka dituntut. Saya kira kami dapat meminta pengguna untuk tidak menuntut Intel dalam perjanjian lisensi kami, jadi mungkin, jika mereka menuntut Intel, dan Intel meminta uang kepada kami, kami dapat mencoba dan menuntut pengguna untuk biaya tersebut, tetapi tetap saja - menempatkan itu di kami lisensi akan membawa kita lebih jauh dari BSD, dan mengharuskan kita untuk membuat pengguna setuju secara eksplisit, yang tidak praktis dalam kasus roda dipasang oleh pip.

Membangun ATLAS untuk SSE3 hanya memberikan manfaat kinerja 5% dibandingkan dengan SSE2 ATLAS, tetapi pembangunannya rumit dan saya harus menonaktifkan tanda pengaktifan yang paling jelas untuk SSE3, dan cukup gunakan -msse3 .

Saya menulis email ke milis numpy yang mengusulkan untuk menggunakan roda ini: https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@matthew-brett Sebagai seseorang yang mendukung Windows dengan aplikasi Python, terima kasih.

@matthew-brett, saya menambahkan 2 masalah ke repositori atlas-build-scripts Anda.
Lihat https://github.com/matthew-brett/atlas-build-scripts/issues

Yang pertama https://github.com/matthew-brett/atlas-build-scripts/issues/1 penting, karena numpy-atlas.dll mengekspor ke banyak simbol dan dengan demikian mencegah penggunaan lebih lanjut dengan mingwpy tanpa meretas impor Perpustakaan.

@matthew-brett maaf saya agak sibuk untuk melakukan benchmarking lagi. Apakah ada dari atlas sebelumnya yang dibuat multithreaded? Saya tidak bisa menjalankan build pertama di banyak core. Intinya harus cukup mudah untuk dijalankan bahkan jika Anda tidak terlalu akrab dengan julia. Atau apakah Anda sebagian besar tertarik pada perangkat keras yang lebih baru daripada yang dapat Anda akses?

Jangan khawatir - tidak mengharapkan Anda untuk meninggalkan semuanya dan menjalankan benchmark.

Sebenarnya build atlas terbaru saya tidak multithreaded - ATLAS 3.11 membutuhkan lebih banyak pekerjaan untuk membuat threading bekerja pada Windows.

Untuk tolok ukur, saya pikir akan lebih mudah untuk membandingkan dengan tolok ukur lain yang Anda jalankan, dan saya hanya memiliki perangkat keras lama dengan Windows aktif - Saya kira pukulannya jauh lebih besar di mesin Anda daripada di saya.

Roda Windows sekarang ada di pypi: https://pypi.python.org/pypi/numpy/1.10.4

Maaf Tony - ya build 3.10 ATLAS sebelumnya (atau tampaknya) multithreaded.

Saya kira kita bisa menutup masalah ini sekarang. Mungkin @matthew-brett Anda harus mentransfer https://github.com/matthew-brett/np-wheel-builder Anda di bawah numpy org atau mungkin berkontribusi sebagai PR ke repo numpy di bawah folder alat .

Ralf - ada saran kemana np-wheel-builder harus pergi? numpy/vendor mungkin?

Saya lebih suka repo baru yang terpisah ( numpy-wheel-builder ?) di bawah numpy org saya pikir. Ada tujuan yang tumpang tindih dengan numpy-vendor , tetapi tidak banyak dalam kode. Repo itu cukup besar, benar-benar dimaksudkan untuk berjalan di bawah Wine, dan rantai alat gcc di dalamnya sudah usang.

Baik dengan saya - OK dengan Anda untuk melanjutkan dan membuatnya?

Baik dengan saya, meskipun jika itu khusus windows (sekarang AFAICT?) maka nama repo harus memiliki "windows" di dalamnya :-). Atau bisa juga di mana kita meletakkan infrastruktur analog untuk roda lain juga. Saya juga akan baik-baik saja dengan memasukkannya langsung ke repo numpy di suatu tempat jika cukup kecil untuk itu masuk akal. Apapun yang berhasil :-)

Repo memiliki binari ATLAS yang cukup besar di dalamnya, akan membuat repo numpy besar untuk tujuan yang tidak baik, saya pikir.

Bagaimana dengan win-wheel-builder ?

Bagaimana dengan windows-wheel-builder . Saya bukan penggemar win ;)

Bagaimana dengan tidak membuatnya khusus untuk windows dan memiliki macosx dan konfigurasi build roda manylinux1 masa depan semuanya di satu tempat?

Kalau tidak, +1 untuk "jendela" di atas "menang".

Bagaimana dengan tidak membuatnya khusus untuk windows dan memiliki macosx dan konfigurasi build roda manylinux1 masa depan semuanya di satu tempat?

Akan lebih mudah untuk mengubah banyak hal di semua platform. Tapi saya berharap OS X dan Linux hanya perlu membangun skrip, sedangkan untuk Windows kami memiliki binari ATLAS yang sangat besar. Jika semuanya menjadi satu repo, dapatkah binari ATLAS dipisahkan entah bagaimana (mungkin dengan git-lfs)?

Gunakan penyimpanan file besar (LFS) di github untuk binari

@rgommers : Saya pikir kami akan segera membawa binari atlas-or-some-other-blas untuk Linux juga, dan mungkin juga osx (misalnya jika kami memutuskan bahwa kami lelah mempercepat pemecahan multiprosesor).

bisa mulai menggunakan rilis github atau bintray atau sesuatu daripada memeriksanya ... tidak seperti mereka semua yang besar meskipun sampai Anda mulai masuk ke build openblas yang diaktifkan DYNAMIC_ARCH atau kombinasi setara dari beberapa konfigurasi blis

Bagaimana kalau menempatkan repo sebagai windows-wheel-builder untuk saat ini, dan refactoring / rename ketika lebih jelas apa yang akan kita lakukan dengan Linux / OSX?

Terdengar bagus untukku.

baik dengan saya juga

Saya pikir saya memerlukan hak admin untuk organisasi numpy - atau saya dapat memberikan
seseorang admin hak atas repo, dan mereka bisa melakukannya, saya kira.​

@matthew-brett: Saya sangat bingung dengan halaman izin github (dan khususnya numpy berantakan), tetapi jika Anda ingin menjadikan saya admin di repo atau mentransfer repo kepada saya maka saya dapat memindahkannya ke numpy/

Saya mentransfer repo ke @njsmith ...

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

Apakah ada akun appveyor numpy? Adakah yang bisa mengaktifkan Appveyor build untuk repo ini?

Saya pikir kami menggunakan akun Appveyor @charris...

Ya, lihat di sini https://ci.appveyor.com/project/charris/numpy/history

Pada Rab, 16 Mar 2016 jam 12:15, Nathaniel J. Smith <
[email protected]> menulis:

Saya pikir kami menggunakan @charris https://github.com/charris 's Appveyor
Akun...

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

Sebenarnya, saya baru saja membuat akun grup baru untuk numpy di appveyor (bermaksud melakukan ini, dan ini mendorong saya untuk benar-benar melakukannya :-)), dan mengaktifkannya di sana:
https://ci.appveyor.com/project/numpy/windows-wheel-builder

@njsmith Bagaimana Anda mengaturnya? Terakhir saya melihat seseorang perlu meminta admin untuk membuat akun proyek dan cara menambahkan orang lain ke dalamnya tidak sepenuhnya transparan.

Jika akun berhasil, saya ingin mengalihkan tanggung jawab untuk pengujian numpy.

@charris : cek email kamu :-). Saya baru saja membuat akun individu dengan numpy-steering-council @googlegroups.com sebagai individu. Saya tidak tahu bahwa akun proyek adalah sesuatu yang ada... Apakah kita menginginkannya?

demi antrian, Anda mungkin ingin menyebarkan proyek yang berbeda di akun yang berbeda

Kelemahan dari penggunaan numpy-steering-council mail adalah appveyor mengirimkan pemberitahuan ketika uji penggabungan gagal. Jika orang-orang appveyor memiliki sesuatu yang lebih baik akhir-akhir ini, akan lebih baik untuk menggunakannya, tetapi mengingat kekacauan antarmuka mereka di masa lalu, saya tidak akan bertaruh.

@tkelman Poin bagus. Juga, jika kita akan menghabiskan uang untuk mendapatkan antrian yang lebih cepat, kita mungkin menginginkan sesuatu yang lebih resmi.

@charris : Saya baru saja mencoba mengaktifkan pengujian numpy/numpy di akun appveyor baru, dan juga menonaktifkan semua notifikasi, dan juga menambahkan semua tim github numpy yang relevan sebagai pengelola di akun -- mari kita lihat apa yang terjadi Tebak...

@matthew-brett: Terpikir oleh saya bahwa pendekatan yang paling elegan mungkin untuk menyimpan build BLAS di suatu tempat seperti numpy/windows-build-tools , tetapi untuk menjalankan alat pembuatan roda yang sebenarnya dari repositori numpy/numpy yang sebenarnya sebagai bagian dari pembuatan appveyor -- mereka dapat menarik binari BLAS sesuai permintaan.

Terima kasih untuk semua pekerjaan hebat! Akankah numpy 1.11.0 Window wheels segera ditambahkan ke pypi? https://pypi.python.org/pypi/numpy

oh ya, kami mungkin perlu mencari cara untuk memperbarui prosedur rilis kami di sini ... IIUC pengalaman pengguna saat ini adalah segera setelah rilis sumber 1.11 diunggah, semua mesin windows di luar sana tiba-tiba beralih dari roda pengunduhan (yay ) untuk mencoba mengunduh dan membangun sumber (boo). Saya kira cara yang "benar" untuk melakukan ini adalah setelah rilis final diberi tag, kami membuat dan mengunggah semua roda biner _before_ mengunggah sdist. Sama menyebalkannya seperti itu...

@njsmith itu akan menyenangkan, tetapi jeda beberapa menit (atau bahkan beberapa jam) tidak masalah bagi saya.

Hanya untuk memperjelas apakah file whl Windows saat ini di PyPI untuk rilis 1.11.0 build melawan ATLAS? Apakah ada skrip build yang dapat dibagikan?

Ya, roda dibuat dengan ATLAS, tetapi kami berpikir untuk pindah ke OpenBLAS saat kami yakin dengan hasilnya.

Build otomatis melalui Appveyor: https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day . =)

Dimungkinkan untuk membuat rilis hidden - setidaknya ada opsi pada formulir PyPI https://pypi.python.org/pypi?%3Aaction=submit_form dan perlihatkan saat semua file sudah siap.

Sayangnya, fitur rilis tersembunyi tidak menghentikan orang mendapatkan rilis itu melalui baris perintah, itu hanya menghentikan mereka melihat rilis melalui GUI pypi:

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

Saya telah mencoba instalasi numpy windows 64-bit dan itu berfungsi dengan baik, jadi terima kasih kepada semua yang telah mengerjakan ini.

Yang saya ingin tahu adalah apakah masih ada rencana untuk melakukan hal yang sama dengan roda scipy? Apakah ini menunggu keputusan untuk pindah ke OpenBLAS?

Di https://bitbucket.org/carlkl/mingw-w64-for-python/downloads ada beberapa roda uji scipy-0.17.0 . Roda ini telah dibuat dengan mingwpy terhadap @matthew-brett build dari numpy https://pypi.python.org/pypi/numpy/1.10.4

Pada Kam, 28 April 2016 jam 12:48, carlkl [email protected] menulis:

Di https://bitbucket.org/carlkl/mingw-w64-for-python/downloads ada
beberapa roda uji scipy-0.17.0 . Roda ini telah dibuat dengan
mingwpy melawan @matthew-brett https://github.com/matthew-brett 's
build dari numpy https://pypi.python.org/pypi/numpy/1.10.4

Maaf jika Anda sudah mengatakannya, dan saya melewatkannya - tetapi apakah Anda mendapatkan tes?
kegagalan untuk roda ini?

Apakah Anda menautkan ke ATLAS yang dikirimkan di dalam roda numpy?

@matthew-brett, saya mengumumkan build ini sebulan yang lalu, tetapi saya tidak ingat di mana. Bagaimanapun, ini membangun tautan terhadap numpy-atlas yang disediakan oleh roda numpy Anda.

scipy-0.17.0-cp35-cp35m-win##.whl ditautkan dengan _wrong_ C-runtime msvcrt.dll. Untuk scipy ini tampaknya baik-baik saja. Log pengujian ada di sini: https://Gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

Apakah itu log yang benar? Ini memiliki NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy di akhir.

Saya bertanya-tanya apakah kami hampir dapat menyediakan roda scipy, bahkan jika itu berbahaya terhubung dengan runtime MSVC yang salah, tetapi sepertinya ada terlalu banyak kesalahan untuk build ini.

Apakah Anda mendapatkan lebih sedikit kesalahan untuk build 64-bit? Untuk build terbaik saat ini melawan openblas 0.2.18 ?

64bit hanya memiliki 6 kegagalan semua dengan:

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

Saya tahu: ini seruan untuk dibandingkan dengan OpenBLAS. Namun, saya terjebak sejak 4 minggu terakhir karena beberapa alasan seperti yang mungkin Anda perhatikan. Semoga keadaan terus membaik.

@matthew-brett, saya akan menghargai menggunakan numpy MSVC builds dengan OpenBLAS. Build terbaru saya ada di sini:

• 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

Seolah-olah mingwpy, conda-forge, Anaconda dan Canopy tidak cukup, inilah Distribusi Intel untuk Python dan gratis untuk diunduh . Ini hanya mencakup alat numerik (SciPy, NumPy, Numba, Scikit-Learn) ditambah beberapa tambahan (antarmuka mp Intel mpi4py dan analitik data pyDAAL) dan menggunakan conda.

Jangan khawatir lisensinya kedaluwarsa 29/10/16 jadi build Intel ini hanya
uji beta diikuti oleh biaya lisensi MKL+ dll. Membangun OpenBLAS
akan tetap menjadi solusi open source jadi terima kasih telah menyediakan ini
membangun.
Pada 28 Apr 2016 19:21, "Mark Mikofski" [email protected] menulis:

Seolah-olah mingwpy, conda-forge, Anaconda dan Canopy tidak cukup datang
Distribusi Intel untuk Python
https://software.intel.com/en-us/python-distribution dan gratis untuk
unduh
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation.
Ini hanya mencakup alat numerik (SciPy, NumPy, Numba, Scikit-Learn)
ditambah beberapa tambahan (antarmuka mp4 mpi4py Intel dan analitik data pyDAAL) dan
menggunakan konda.

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung atau lihat di GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

Untuk 1.11.1, sepertinya ada roda Windows yang hilang di PyPi untuk Python 3.5 amd64.

Apakah ada alasan khusus untuk itu? Jika saya pergi ke 1.11.0 (https://pypi.python.org/pypi/numpy/1.11.0), roda ada di sana.

Terima kasih atas laporannya - saya pikir kami harus mengunggah terlalu cepat, dan karena itu sebelum semua roda dibuat. Saya telah mengunggah roda yang hilang. Sepertinya kita perlu tes untuk memastikan ini tidak terjadi lagi.

Saya telah mengunggah roda yang hilang.

Saya baru saja mengujinya, dan itu berfungsi dengan baik!

Terima kasih banyak untuk semua pekerjaan yang dilakukan untuk membuat roda Windows tersedia.

Menutup masalah -- roda telah tersedia untuk beberapa rilis terakhir.

Saya mengerti bahwa masalah ini sudah selesai tetapi saya yakin kita harus mempertimbangkan untuk membukanya kembali.

Ini tetap menjadi masalah bagi pengguna windows yang mencoba menjalankan tumpukan ilmiah mereka tanpa harus menggunakan conda. Saya masih perlu menggunakan build @cgohlke 'MKL' untuk melihat masalah scipy terkait ini yang tetap terbuka. Meskipun roda sedang dibuat, tanpa kompatibel dengan scipy, mereka tidak dapat digunakan untuk banyak orang.

@waynenilsen Anda memiliki instruksi untuk memasang roda baru di utas milis yang ditautkan dalam masalah yang baru saja Anda sebutkan:

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

Jadi jika Anda melakukannya

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

itu harus bekerja untuk Anda.

Tidak ada lagi yang bisa dilakukan untuk Numpy, jadi masalahnya sudah selesai. Itu
Masalah scipy masih terbuka, dan kemungkinan akan diselesaikan di masa depan
melepaskan.

Ini sangat bagus untuk saya @ Juanlu001 Saya sangat menantikan saat ini ada di pypi!