Numpy: विंडोज व्हील पैकेज (.whl) Pypi पर

अच्छा कहा - और वास्तव में ऐसा करने के लिए दृश्यों के पीछे @carlkl द्वारा बहुत काम किया जा रहा है। मेरा मानना ​​​​है कि हम अब लगभग वहां हैं - @carlkl - आप कब सार्वजनिक होंगे, क्या आपको लगता है?

संदर्भ के लिए: इसका कारण यह तुच्छ नहीं है कि आपके द्वारा लिंक किए गए बायनेरिज़
इंटेल के मालिकाना रनटाइम और गणित पुस्तकालय पर निर्भर होने के लिए, जो
उनके पुनर्वितरण को जटिल बनाता है।

मैंने बिनस्टार पर हाल ही में OpenBLAS आधारित सुन्न और डरावने पहियों को तैनात किया है। आप उन्हें इसके साथ स्थापित कर सकते हैं:

पाइप इंस्टाल -i https://pypi.binstar.org/carlkl/simple numpy
पाइप इंस्टाल -i https://pypi.binstar.org/carlkl/simple scipy

यह अजगर-2.7 और अजगर-3.4 के लिए काम करता है। पहियों को 'प्रायोगिक' के रूप में चिह्नित किया गया है। प्रतिक्रिया का स्वागत है।

यदि आप व्यापक परीक्षण चाहते हैं तो आपको इसे सूची में भेजना चाहिए :-)

गुरु, 22 जनवरी, 2015 को रात 8:54 बजे, carlkl [email protected] ने लिखा:

मैंने बिनस्टार पर हाल ही में OpenBLAS आधारित सुन्न और डरावने पहियों को तैनात किया है।
आप उन्हें इसके साथ स्थापित कर सकते हैं:

पाइप इंस्टाल -i https://pypi.binstar.org/carlkl/simple numpy
पाइप इंस्टाल -i https://pypi.binstar.org/carlkl/simple scipy

यह अजगर-2.7 और अजगर-3.4 के लिए काम करता है। पहियों को के रूप में चिह्नित किया गया है
'प्रयोगात्मक'। प्रतिक्रिया का स्वागत है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -71096693।

नथानिएल जे स्मिथ
पोस्टडॉक्टोरल शोधकर्ता - सूचना विज्ञान - एडिनबर्ग विश्वविद्यालय
http://vorpus.org

fwiw मैं व्यक्तिगत रूप से win64 में डिफ़ॉल्ट पूर्णांक के आकार को बदलना चाहता हूं, इससे पहले कि हम वास्तव में आधिकारिक बायनेरिज़ प्रदान करते हैं, हालांकि कुछ प्रतिरोध भी था जब मैंने इसे पिछली बार प्रस्तावित किया था, संभवतः एनाकोंडा और अन्य तीसरे पक्ष के बायनेरिज़ के साथ शायद पहले से ही बहुत देर हो चुकी है: (

ओपनब्लास के बारे में भी बात करते हुए, कोई कुछ डिबगिंग की कल्पना करता है, मैं इससे थक गया हूं (वही विफलता की तरह दिखता है जो ओपनब्लास के साथ scipy को तोड़ता है):

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

उपयोग किया गया OpenBLAS संस्करण 0.2.12 है। मैंने अभी तक इस संस्करण के साथ महत्वपूर्ण समस्याओं का अनुभव नहीं किया है।

scipy विफलताओं को https://gist.github.com/carlkl/b05dc6055fd42eba8cc7 पर कॉपी किया जाता है।

http://sourceforge.net/p/mingw-w64/bugs/367 के कारण केवल 32 बिट विफल विफलताएं

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

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

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

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

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

मैं win64 पूर्णांक आकार बदलने के बारे में असहमत नहीं हूं, लेकिन मुझे लगता है कि
एक अलग मुद्दा जिसे पहियों से अलग किया जाना चाहिए। अगर यह थे
पहली बार win64 numpy बिल्ड व्यापक रूप से उपलब्ध हो रहे थे, तो यह होगा
उन्हें जोड़ने के लिए समझ में आता है, लेकिन इस बिंदु पर पहले से ही बहुत सारे उपयोगकर्ता हैं
वर्षों से, वे सिर्फ cgholke या anaconda या जो कुछ भी उपयोग कर रहे हैं। तो चलें
इसे एक स्वतंत्र चर्चा के रूप में मानें?

(कड़ाई से बोलना यह एक बैककॉमेट ब्रेक है, लेकिन फिर भी यह उचित लगता है
कि हम इसे दूर करने में सक्षम हो सकते हैं, क्योंकि यह वास्तव में कम करता है
प्लेटफार्मों के बीच असंगति -- सभी पोर्टेबल कोड को 64-बिट को संभालना होगा
dtype=int पहले से ही।)

गुरु, 22 जनवरी, 2015 को रात 8:59 बजे, जूलियन टेलर सूचनाएं @github.com
लिखा था:

fwiw मैं व्यक्तिगत रूप से डिफ़ॉल्ट पूर्णांक के आकार को बदलना चाहता हूं
win64 इससे पहले कि हम वास्तव में आधिकारिक बायनेरिज़ प्रदान करते, हालांकि कुछ थे
जब मैंने पिछली बार इसे प्रस्तावित किया था, तब भी इसका विरोध किया था, संभवतः एनाकोंडा और . के साथ भी
अन्य तृतीय पक्ष बाइनरी शायद पहले ही बहुत देर हो चुकी है :(

ओपनब्लास की भी बात कर रहे हैं, किसी को कुछ डिबगिंग पसंद है, मैं इससे थक गया हूं
(उसी विफलता की तरह दिखता है जो ओपनब्लास के साथ scipy को तोड़ता है):

test_einsum_sums_float64 (test_einsum.TestEinSum) ... ==31931== आकार 16 का अमान्य पठन
==31931== 0x7B28EB9 पर: ddot_k_NEHALEM (में /usr/lib/libopenblasp-r0.2.10.so)
==31931== 0x6DBDA90 द्वारा: DOUBLE_dot (arraytypes.c.src:3127)
==31931== 0x6E93DEC द्वारा: cblas_matrixproduct (cblasfuncs.c:528)
==31931== 0x6E6B7B3 द्वारा: PyArray_MatrixProduct2 (multiarraymodule.c:994)
==31931== 0x6E6E29B द्वारा: array_matrixproduct (multiarraymodule.c:2276)

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -71097408।

नथानिएल जे स्मिथ
पोस्टडॉक्टोरल शोधकर्ता - सूचना विज्ञान - एडिनबर्ग विश्वविद्यालय
http://vorpus.org

मुझे इसमें भी दिलचस्पी है। क्या प्रक्रिया में सहायता करने का कोई तरीका है?

OpenBLAS को INTERFACE64=1 के साथ संकलित किया जा सकता है और पहली कोशिश के लिए numpy को -fdefault-integer-8 के साथ संकलित किया जा सकता है।

बिलकुल चौकन्ना। ब्लास में 64 बिट पूर्णांकों का उपयोग करना एक भयानक विचार है। इससे पहले कि आप उस सड़क से बहुत नीचे उतरें, रुकें। मैटलैब, और जूलिया इससे पहले कि मैं गया और इसे ठीक किया, ऐसा किया, और यह किसी भी तीसरे पक्ष की लाइब्रेरी को तोड़ देता है जो ब्लै में पारंपरिक 32-बिट पूर्णांक मानता है।

पिछले ~5 महीनों से हम जूलिया में जो कर रहे हैं, वह वास्तव में 64-बिट-इंट संस्करण के लिए _64 प्रत्यय जोड़ने के लिए ओपनब्लास में सभी प्रतीकों का नाम बदल रहा है, इस तरह आप रैखिक बीजगणित कर सकते हैं यदि आप चाहते हैं तो वास्तव में विशाल सरणी पर, लेकिन बाहरी पुस्तकालयों को उसी प्रक्रिया में लोड करने से नाम छायांकन और गलत एबीआई के साथ dgemm पर कॉल करने का प्रयास नहीं किया जाएगा।

अरे दोस्तों क्या Numpy के लिए व्हील्स फाइल उपलब्ध कराने के बारे में कोई अपडेट है?

ऐसा नहीं है कि मुझे अभी इसकी जानकारी है।
25 जून 2015 को सुबह 4:27 बजे, " guyverthree " [email protected] ने लिखा:

अरे दोस्तों क्या पहियों की फाइलों के लिए कोई अपडेट उपलब्ध कराया जा रहा है
सुन्न?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -115215236।

@guyverthree क्रिस्टोफ़ गोहलके कुछ समय से इंटेल के एमकेएल को पहियों के रूप में इस्तेमाल करते हुए NumPy जारी कर रहे हैं।

साथ ही, मेरे ब्लॉग पोस्ट को NumPy Wheels पर देखें। मैंने कार्ल क्लेफनर के संशोधित mingw- w64 टूलचेन और गोटोब्लास के झांग ज़ियानी के ओपनब्लास पोर्ट का उपयोग करके अपने ड्रॉपबॉक्स में कुछ न्यूमपी व्हील बनाए। ओलिवियर ग्रिसेल NumPy बिल्डबॉट को संशोधित करने में मदद की तलाश में था ताकि OpenBLAS Google समूह थ्रेड I में पोस्ट किए गए समान चरणों को दोहराने के लिए ।

मेरा नवीनतम संस्करण binstar.org पर उपलब्ध है, हालांकि मुझे यकीन नहीं है कि anaconda.org अब नया पसंदीदा नाम है या नहीं।
py-2.6 .. 3.4 (32/64bit) के पहिए लगभग 2 महीने पुराने हैं:

• सुन्न-1.9.2
• scipy-0.15.1
• स्किकिट-इमेज-0.11.2

मेरे https://bitbucket.org/carlkl/mingw-w64-for-python और कमोबेश हाल के OpenBLAS के साथ निर्माण करें।
पाइप स्थापित करें:

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

+1 @carlkl और मेरी इच्छा है कि इन्हें पनीर फैक्ट्री में भी NumPy बिल्ड में जोड़ा जा सके।

+1 मुझे यह भी होता देखना अच्छा लगेगा।

आईएमएचओ: इन बिल्डों को स्वीकार किए जाने से पहले हल करने के लिए कम से कम तीन समस्याएं हैं:

• खस्ता भंडार के लिए मिंगवपी पैच को फिर से बनाना होगा
• मैन्युअल रूप से अभी तक निर्माण के अलावा कोई निर्माण तंत्र नहीं है
• कई 3-rd पार्टी विंडोज़ पैकेज (सी. गोहलके द्वारा डिपोलिड) स्पष्ट रूप से numpy-MKL पर निर्भर करते हैं, क्योंकि बायनेरिज़ MKL DLL के विरुद्ध हार्ड लिंक्ड होते हैं। यह भविष्य में बदल सकता है, क्योंकि scipy अब scipy BLAS/Lapack कार्यान्वयन पर एक अंतर्निहित निर्भरता के लिए एक तंत्र प्रदान करता है। इसलिए (numpy-MKL & scipy-MKL) OR (numpy-OpenBLAS & scipy-OpenBLAS) इंस्टाल करना भविष्य में अन्य सभी पैकेजों के लिए पर्याप्त होना चाहिए।

@carlkl : एफडब्ल्यूआईडब्ल्यू, मैं वास्तव में @cgohlke के पैकेजों के बारे में चिंतित नहीं हूं - जो खुद को सुलझा लेगा (जैसे कि अब कोई बड़ी समस्या नहीं है क्योंकि लोग scipy-MKL को एनाकोंडा numpy के साथ संयोजित करने का प्रयास कर रहे हैं)। और मैं वास्तव में कुछ फैंसी बिल्ड मैकेनिज्म होने के बारे में भी चिंतित नहीं हूं - मैन्युअल बिल्ड तब तक ठीक है जब तक चरणों को दस्तावेज करने वाली टेक्स्ट फ़ाइल होती है।

मुख्य मुद्दा जिसके बारे में मैं चिंतित हूं वह है स्थिरता: यदि हम इस सामान को अपस्ट्रीम नहीं प्राप्त कर सकते हैं, तो हमें हर बार gcc / mingw-w64 / msvc का एक नया संस्करण आने पर पैच को फिर से सत्यापित और फिर से करना होगा। बाहर, और यह शायद नहीं होगा। हम उस जाल में नहीं फंसना चाहते जहां हम बिल्ड प्रदान करना शुरू करते हैं, लेकिन फिर यह समय के साथ और अधिक कठिन हो जाता है क्योंकि हमें इसे करने के लिए एक पुराने पुराने कंपाइलर से निपटना पड़ता है।

यही कारण है कि मैं इस अपस्ट्रीम को करने में सहायता के लिए फंडिंग को राउंड अप करने का प्रयास कर रहा हूं ... +1 महान और सभी हैं, लेकिन अगर कोई कुछ पैसे दान करना चाहता है या ऐसी कंपनी को जानता है जो जीसीसी को आम तौर पर पायथन के लिए प्रयोग करने योग्य बनाने में रुचि रखता है। विंडोज़ पर एक्सटेंशन, फिर मुझे एक ईमेल भेजें :-) ([email protected])

यदि आपके पास $$ नहीं है, लेकिन फिर भी आप मदद करना चाहते हैं, तो ऐसा करने का एक तरीका यह होगा कि mingw-w64 को पैच भेजकर पाप और कॉस जैसे पारलौकिक कार्यों के लिए उनके समर्थन में सुधार किया जाए। (यह पता चला है कि MSVC ABI अन्य सभी के साथ असहमत है कि x87 FPU इकाई को कैसे कॉन्फ़िगर किया जाना चाहिए, इसलिए अधिकांश मुफ्त सॉफ्टवेयर गणितीय कार्य बिल्कुल सही काम नहीं करते हैं।) सौभाग्य से एंड्रॉइड में अच्छे, लाइसेंस-संगत कार्यान्वयन हैं " bionic" libc है, इसलिए इसके लिए किसी गणितीय विजार्ड्री या ABI मुद्दों में गहरी अंतर्दृष्टि की आवश्यकता नहीं है - यह प्रासंगिक स्रोत फ़ाइलों को खोजने और निकालने और फिर उन्हें सही जगह पर mingw-w64 ट्री में छोड़ने का केवल एक यांत्रिक मामला है। अगर किसी की दिलचस्पी है तो हम इस पर अधिक विवरण भी प्रदान कर सकते हैं।

क्या यह उस तरह की चीज नहीं है जिसके लिए न्यूफोकस फंडिंग होनी चाहिए? यदि नहीं, तो शायद हम वापस जा सकते हैं और पीएसएफ में आवेदन करने पर फिर से विचार कर सकते हैं।

हम कितने पैसे की बात कर रहे हैं?

+1 कृपया विंडोज़ के लिए पहिए को PyPI में प्रकाशित करें https://pypi.python.org/pypi/numpy

यदि आप किसी आउट-द-बॉक्स Python Windows स्थापना पर pip install numpy प्रयास करते हैं, तो आपको कुख्यात अनुपयोगी त्रुटि संदेश "vcvarsall.bat खोजने में असमर्थ" मिलता है।

+1 वास्तव में विंडोज उपयोगकर्ताओं की मदद करेगा।

इस वजह से https://github.com/glumpy/glumpy के साथ नहीं खेल सकते। Numpy को विंडोज़ पर काम करने के लिए मैनुअल बिल्ड स्टेप्स क्या हैं? ऐसा लगता है कि AppVeyor का काम है , इसलिए GitHub पर कलाकृतियों को अपलोड करने में कोई समस्या नहीं होनी चाहिए।

अभी विंडोज़ पर numpy का तेज़, बीएसडी-लाइसेंस प्राप्त संस्करण बनाना सचमुच असंभव है। हम इसे ठीक करने पर काम कर रहे हैं, लेकिन यह एक तकनीकी सीमा है; +1 का किसी भी तरह से कोई प्रभाव नहीं पड़ने वाला है। (Appveyor जॉब विंडोज़ पर निर्मित होता है, लेकिन यह एक फ़ॉलबैक अडॉप्टिमाइज़्ड लीनियर अलजेब्रा लाइब्रेरी का उपयोग करता है जो वास्तव में वास्तविक कार्य के लिए उपयुक्त नहीं है।) जब तक हम इसे सॉर्ट नहीं कर लेते, तब तक मैं क्रिस्टोफ़ गोहल्के की वेबसाइट से पहियों को डाउनलोड करने या एनाकोंडा का उपयोग करने की सलाह दूंगा। या कोई अन्य वैज्ञानिक अजगर वितरण ।

@njsmith क्या आप अधिक विशिष्ट हो सकते हैं? अधिमानतः सटीक आदेशों के साथ जो काम नहीं करते हैं। अभी यह सामान कार्रवाई योग्य नहीं है।

मुझे लगता है कि 'असंभव' बहुत मजबूत है - लेकिन निश्चित रूप से अभी तक एक स्पष्ट सामान्य रास्ता नहीं है। मैंने यहां वर्तमान स्थिति पर एक विकी पृष्ठ डाला है: https://github.com/numpy/numpy/wiki/Whats-with-Windows-builds । कृपया बेझिझक संपादित करें / उन सभी को संशोधित करें जो परवाह करते हैं।

@techtonik : कोई "सटीक आदेश नहीं हैं जो काम नहीं करते" हैं, समस्या यह है कि ऐसे कोई कंपाइलर नहीं हैं जिनके पास हमें आवश्यक सुविधाओं का संयोजन है। mingwpy.github.io ऐसे कंपाइलर को बनाने के हमारे प्रयासों की वर्तमान स्थिति का दस्तावेजीकरण करता है।

@ मैथ्यू-ब्रेट अच्छा। We can't use MSVC++ on its own to compile scipy because we need a Fortran compiler. यह scipy के लिए है, है ना? सुन्न के लिए इसकी आवश्यकता क्यों है?

@njsmith http://mingwpy.github.io/issues.html एक अच्छे विश्लेषण के साथ एक शानदार पहल है। बहुत बुरा है कि अपस्ट्रीम (पायथन) कभी भी इसका समर्थन नहीं करेगा (एमएसवीएस का आँख बंद करके प्रचार करता है)। लेकिन मैं वर्तमान स्थिति से एक स्पष्ट तस्वीर प्राप्त करने की कोशिश कर रहा हूं।

1. क्या यह "खुले काम के लिए खुले टूलचेन होने" की समस्या है या एमएसवीएस वास्तव में सी भाग को numpy संकलित नहीं कर सकता है?
2. क्या मिंगव-संकलित एक्सटेंशन के साथ अभी भी क्रैश हैं?

अभी के लिए फोकस को कम करने के लिए, मान लें कि यह केवल Python 2.7 + Win32 है। कोई प्रदर्शन आवश्यक नहीं है (मैं केवल वहां परीक्षण करने के लिए एप्लिकेशन चलाना चाहता हूं), लेकिन उस प्रदर्शन के बारे में एक बेंचमार्क डेटा की आवश्यकता है।

तो, अगली कार्रवाई क्या है जो इस कॉन्फ़िगरेशन के लिए किया जाना चाहिए ताकि विंडोज़ व्हील को पीपीपीआई से उपलब्ध कराया जा सके?

@techtonik , अब https://anaconda.org/carlkl/numpy और https://anaconda.org/carlkl/scipy पर numpy और scipy व्हील्स के प्रारंभिक संस्करण उपलब्ध हैं। प्रदर्शन लगभग उतना ही अच्छा है जितना कि गोहलके + एमकेएल पहिए। मुझे घर पर अपने विंडोज़ बॉक्स के साथ segfaults का सामना नहीं करना पड़ा।

इस दृष्टिकोण के साथ कई मुद्दों पर चर्चा की गई है और http://mingwpy.github.io (निर्माणाधीन) पर संक्षेप में प्रस्तुत किया गया है। mingw-w64 आधारित टूलचेन का संयोजन जिसे _mingwpy_ और OpenBLAS कहा जाता है, विंडोज प्लेटफॉर्म के लिए जाने का तरीका है।

_mingwpy_ में एक विशेष कॉन्फ़िगरेशन है जो सबसे प्रसिद्ध mingw-w64 आधारित टूलचेन, यानी _mingw-builds_, _tdm_ की तुलना में बेहतर संगतता और अधिक सुविधाजनक उपयोग सुनिश्चित करता है ...

यह सब और बहुत कुछ https://github.com/mingwpy/mingwpy.github.io पर समझाया गया है। वहां मुद्दे या पीआर खोलने के लिए स्वतंत्र महसूस करें।

@techtonik : मुझे लगता है कि यह अपस्ट्रीम python.org की स्थिति की गंभीर गलतफहमी/गलत बयानी है। मैं कहूंगा कि वे कई असंगत एबीआई में विंडोज सीपीथॉन समर्थन के विभाजन को बढ़ावा देने से इनकार करते हैं (और मैं इस पर उनके साथ सहमत हूं)। स्टीव डावर, जो आधिकारिक अपस्ट्रीम विंडो बिल्ड का रखरखाव करता है, हमें यह पता लगाने में मदद कर रहा है कि इन बिल्ड के साथ मिंगवपी को कैसे संगत बनाया जाए।

पीपीआई पर सुन्न पहियों को लगाने के लिए आईएमओ की शर्त यह है कि वे (ए) प्रदर्शन करने वाले, (बी) रखरखाव योग्य, (सी) उचित लाइसेंस प्राप्त होने चाहिए। यदि आप चाहते हैं कि परियोजना मानदंड के एक अलग सेट को लागू करे (अर्थात हमें भयानक प्रदर्शन के साथ पहियों को प्रदान करने के लिए प्रयास करना चाहिए) तो अगला कदम यह है कि आपके मानदंड बेहतर हैं, यह मामला बनाने के लिए खस्ता मेलिंग सूची में एक ईमेल भेजना है।

MSVS स्वयं numpy का निर्माण कर सकता है, लेकिन यह उचित रूप से लाइसेंस प्राप्त उच्च-गुणवत्ता वाले BLAS कार्यान्वयनों में से कोई भी निर्माण नहीं कर सकता है। अपस्ट्रीम mingw-w64 numpy + BLAS (पैच के साथ) बना सकता है, लेकिन यदि आप इसे अपस्ट्रीम CPython के साथ उपयोग करने का प्रयास करते हैं तो परिणाम क्रैश हो जाएगा। कार्ल का मिंगवपी टूलचेन numpy + BLAS (पैच के साथ) बना सकता है, और परिणाम अजगर के कुछ संस्करणों (लेकिन 3.5 नहीं) पर काम करेगा, लेकिन टूलचेन अपनी वर्तमान स्थिति में नाजुक और अप्राप्य है; वस्तुतः कार्ल को छोड़कर कोई भी नहीं जानता कि इसे कैसे बनाया गया था या इसे फिर से बना सकता था। सुपीरियर प्रोजेक्ट में कोई भी इन सीमाओं के साथ टूलचैन का उपयोग करके "आधिकारिक बिल्ड" प्रदान करने के लिए खुद को प्रतिबद्ध करने के लिए तैयार नहीं है, इसलिए हम उन्हें ठीक करने पर ध्यान केंद्रित कर रहे हैं।

विंडोज़ पर उच्च-गुणवत्ता वाले numpy बिल्ड के कई तुच्छ-उपलब्ध स्रोत हैं। मैं वास्तव में उत्सुक हूं: आप इतने आग्रह क्यों कर रहे हैं कि हमें कुछ निम्न-गुणवत्ता वाले बिल्ड अप को फेंक देना चाहिए ताकि वे पीईपीआई पर हों?

@njsmith बस यह बताना चाहता था कि मेरा उपयोग मामला (जिसे मैं किसी भी तरह से डेवलपर संसाधनों के निवेश को उचित ठहराता हूं) पीईपीआई पर एक बहुत ही सरल पैकेज वितरित करना है जो matplotlib पर निर्भर करता है, जो बदले में numpy पर निर्भर करता है।

मेरे उपयोग के मामले के प्रदर्शन के लिए कोई चिंता नहीं है, लेकिन एक विंडोज़ उपयोगकर्ता को केवल pip install ____ मेरे पैकेज में सक्षम होने के कारण matplotlib , numpy , आदि को दोबारा स्थापित करना बहुत आसान है उन्हें स्थापित करने के लिए URL की ओर इंगित करने के बजाय समझाएं, विशेष रूप से उन उपयोगकर्ताओं के लिए जो पायथन बिल्ड इकोसिस्टम को नहीं समझते हैं। तो यह ज्यादातर इंस्टाल निर्देशों के सरलीकरण के लिए है।

फिर से, मेरे मामले को औचित्य के रूप में इस्तेमाल करने की कोशिश नहीं कर रहा था, लेकिन सिर्फ इसलिए साझा करना चाहता था क्योंकि आप उत्सुक थे।

@johnthagen : ओह, ज़रूर, कोई चिंता नहीं! मैं पूरी तरह से समझता हूं कि यह सामान्य रूप से वांछनीय क्यों है; अगर मैं इन टिप्पणियों में क्रोधी के रूप में सामने आता हूं, तो यह ठीक है क्योंकि मैं और अन्य लोग पिछले एक साल में इसे ठीक करने की कोशिश में भारी मात्रा में समय बिता रहे हैं :-)। मैं सिर्फ @techtonik से विशेष रूप से पूछ रहा था क्योंकि यह ऐसा लग रहा था जैसे वे कह रहे थे "मैं सिर्फ एक छोटे से आवेदन की कोशिश करना चाहता हूं, इसलिए मुझे प्रदर्शन की परवाह नहीं है", लेकिन अगर वे सिर्फ एक छोटे से आवेदन की कोशिश करना चाहते हैं, तो मैं नहीं जानिए वे PyPI भाग की परवाह क्यों करते हैं :-)

(यह ध्यान रखना महत्वपूर्ण है कि कोई भी पहिया जो हम पीपीआई पर लगाते हैं, वह तुरंत हजारों लोगों द्वारा उपयोग किया जाना शुरू हो जाएगा, जिनमें से अधिकांश इस धागे को नहीं पढ़ रहे हैं। इसलिए मुझे लगता है कि यह सुनिश्चित करने के लिए हम पर कुछ दायित्व है। हम वास्तव में उपयोग के मामलों की एक विस्तृत श्रृंखला के लिए व्यापक रूप से प्रयोग करने योग्य होंगे।)

मुझे लगता है कि एटलस का उपयोग करते हुए, पायथन 2.7 के लिए 32-बिट सुन्न पहियों की शिपिंग शुरू करना अनिवार्य रूप से तुच्छ होगा। वे संभवतः SSE2 होंगे, इसलिए SSE निर्देशों के बिना क्रैश हो जाएगा, लेकिन यह केवल उपयोगकर्ताओं के बहुत छोटे अनुपात को प्रभावित करेगा। हम उसके लिए अपने वर्तमान रिलीज़ टूलचेन का उपयोग कर सकते हैं। ध्यान रखें कि इसका मतलब यह होगा कि पीआईपी 32-बिट के लिए एक बाइनरी व्हील देगा, लेकिन 64-बिट के लिए सोर्स इंस्टाल पर वापस आ जाएगा। क्या यह उपयोगी होगा?

@njsmith जानकारी के लिए धन्यवाद! आप सभी की मेहनत को नमन :)

मुझे लगता है कि एटलस का उपयोग करते हुए, पायथन 2.7 के लिए 32-बिट सुन्न पहियों की शिपिंग शुरू करना अनिवार्य रूप से तुच्छ होगा। वे संभवतः SSE2 होंगे, इसलिए SSE निर्देशों के बिना क्रैश हो जाएगा, लेकिन यह केवल उपयोगकर्ताओं के बहुत छोटे अनुपात को प्रभावित करेगा। हम उसके लिए अपने वर्तमान रिलीज़ टूलचेन का उपयोग कर सकते हैं। ध्यान रखें कि इसका मतलब यह होगा कि पीआईपी 32-बिट के लिए एक बाइनरी व्हील देगा, लेकिन 64-बिट के लिए सोर्स इंस्टाल पर वापस आ जाएगा। क्या यह उपयोगी होगा?

@ मैथ्यू-ब्रेट वर्तमान सुन्न-विक्रेता सेटअप टूट गया है, इसमें एक segfault है fromfile । फ़ाइल हैंडल हैंडलिंग किसी तरह गड़बड़ है, और हमें यकीन नहीं है कि यह वाइन संस्करण, उबंटू संस्करण में बदलाव या (संभावना नहीं) numpy में बदलाव के कारण है। मैं कहूंगा कि उस पर अधिक समय व्यतीत करना समय की बर्बादी है - उस समय को मिंगवपी में डालना अधिक उत्पादक है।

मेरे पास ओपनबीएलएएस (इंट 32 विंडोज 64, v0.2.15 प्रीकंपिल्ड बाइनरी) और एमकेएल (एमकेएल पर एक सामुदायिक लाइसेंस का उपयोग करके, यानी मुफ्त वितरण) दोनों के साथ संकलित NumPy 1.10.4 है। लेकिन... मैं SciPy को संकलित नहीं कर सकता - ऐसा लगता है कि एक छोटा सा हिस्सा gfortran कंपाइलर "फोर्टन कंपाइलर नहीं मिला" के लिए दिखता है अगर किसी के पास इस मुद्दे को ठीक करने का विचार है। मैं ifort.exe का उपयोग कर रहा हूं क्योंकि एनाकोंडा इन बिल्ड को डायरेक्ट प्लग-इन के रूप में सपोर्ट करता है। माइक्रोसॉफ्ट विजुअल स्टूडियो कम्युनिटी 2015 के साथ पायथन 3.5 के लिए संकलित अगर कोई मुझे यह पता लगाने में मदद कर सकता है कि वितरण के लिए इसे कैसे पैकेज किया जाए .... तो मैं जीथब या एनाकोंडा की वेबसाइट पर अपलोड करूंगा। इसकी प्रशंसा करना।

@mrslezak : शायद सबसे अच्छी बात यह है कि scipy डेवलपर्स मेलिंग सूची पर पोस्ट करना है, या यादृच्छिक मौजूदा बग पर पोस्ट करने के बजाय, scipy पर एक नया बग खोलना है :-)

मैं वास्तव में उत्सुक हूं: आप इतने आग्रह क्यों कर रहे हैं कि हमें कुछ निम्न-गुणवत्ता वाले बिल्ड अप को फेंक देना चाहिए ताकि वे पीईपीआई पर हों?

सिर्फ इसलिए कि मैं याक की शेविंग करते-करते थक गया हूं। मुझे पता है कि लोग प्रदर्शन चाहते हैं, और यह अच्छा है कि किसी के पास इसके लिए जाने के लिए संसाधन हैं, लेकिन मेरे लिए व्यक्तिगत रूप से इस कार्य को करने की जटिलता बहुत बड़ी है, इसलिए मैं केवल यह आशा कर सकता हूं कि आप इसे करने में कामयाब रहे, लेकिन मेरे लिए वह ऐसा कभी नहीं हो सकता है, या यह दो या तीन वर्षों में हो सकता है, जिसके दौरान लोग दीवारों से टकराते रहते हैं और PyPI से सभी विंडोज़ बायनेरिज़ के डाउनलोड के अनुपात में घंटों में समय बर्बाद करते हैं, जिसके लिए NumPy को अप्रत्यक्ष निर्भरता के प्रत्यक्ष रूप में स्थापित करने की आवश्यकता होती है।

वाह। अंग्रेजी का शायद सबसे लंबा वाक्य जो मैंने अपने पूरे जीवन में लिखा था। =)

@techtonik - मैं आपकी निराशा साझा करता हूं, मुझे लगता है कि हम में से कई इस बारे में निराश महसूस करते हैं।

@carlkl - मुझे यहां आपकी प्रतिक्रिया पसंद आएगी।

हम पर स्पष्ट रूप से एक खस्ता खिड़कियों का पहिया लगाने का दबाव है। यहाँ कुछ हफ़्ते पहले किसी भी प्लेटफ़ॉर्म के लिए सबसे अधिक डाउनलोड किए गए पहियों की सूची दी गई है: https://gist.github.com/dstufft/1dda9a9f87ee7121e0ee । मैटप्लोटलिब, स्किकिट-लर्न और पांडा विंडो व्हील्स 3, 4 और 5 पोजीशन पर आते हैं। खस्ता खिड़कियों के पहियों के लिए एक बड़ा बाजार होगा।

मुझे लगता है कि मेज पर प्रश्न हैं:

1) क्या हम लघु से मध्यम अवधि (जैसे, 6 महीने) में पीपीआई पर एक कामकाजी और लगभग-इष्टतम सुन्न पहिया प्राप्त करने के लिए खुद को प्रतिबद्ध कर सकते हैं। मैं कहूंगा कि इसका उत्तर हां है (असहमति सुनकर खुशी हुई);
2) क्या इस दौरान दूसरों के खिलाफ निर्माण करने के लिए एक इष्टतम नुकीला पहिया लगाने लायक नहीं है?

प्रश्न 2 कठिन है। "इष्टतम नहीं" का अर्थ धीमा (कोई अनुकूलित ब्लास / लैपैक नहीं) या समर्थन करना मुश्किल हो सकता है (कोई गारंटी नहीं है कि हम 6 महीने के समय में निर्माण को दोहरा सकते हैं)।

मैं "धीमे" के खिलाफ तर्क देख सकता हूं। हमें सावधान रहने की जरूरत है कि, जब पहिए विंडोज के लिए काम करना शुरू करते हैं, तो वे तुरंत स्टैकओवरफ्लो प्रश्नों को उत्तर के साथ ट्रिगर नहीं करते हैं "किसी भी खाते में पीपीआई से सुन्न पहियों को डाउनलोड न करें"। मुझे लगता है कि वे उत्तर उचित होंगे और वे हमें चोट पहुँचाने के लिए पर्याप्त समय तक चलेंगे।

इष्टतम अर्थ नहीं, निर्माण प्रक्रिया का समर्थन करना मुश्किल है, मुझे लगता है कि हम साथ रह सकते हैं, अगर हम वास्तव में जल्द ही दीर्घकालिक समाधान खोजने के लिए प्रतिबद्ध हैं।

कुछ समय पहले मैंने विंडोज़ के लिए एटलस बायनेरिज़ का निर्माण किया था: http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

क्या मैं यह सोचने में सही हूं कि हम पहले से ही नुकीले बायनेरिज़ का निर्माण कर सकते हैं जो इन एटलस बायनेरिज़ का उपयोग करके सभी परीक्षण पास करते हैं?

किस मामले में, हम उन्हें क्यों नहीं डालते?

1) क्या हम लघु से मध्यम अवधि (जैसे, 6 महीने) में पीपीआई पर एक कामकाजी और लगभग इष्टतम सुन्न पहिया प्राप्त करने के लिए खुद को प्रतिबद्ध कर सकते हैं। मैं कहूंगा कि इसका उत्तर हां है (असहमति सुनकर खुशी हुई);

मुझे आशा है कि, अन्यथा इसका मतलब है कि तब तक हम या तो mingwpy प्रस्ताव के साथ अप्रत्याशित समस्या में भाग चुके होंगे या जो इसे सक्षम करता है उस पर कैश नहीं किया था :)

2) क्या इस दौरान दूसरों के खिलाफ निर्माण करने के लिए एक इष्टतम नुकीला पहिया डालना उचित नहीं है?

ऐसा लगता है कि आपका एटलस बिल्ड सिगविन के साथ किया गया है? या यह सिर्फ निर्देशिका का नामकरण है और आपने MingwPy के कुछ संस्करण का उपयोग किया है?

मुझे लगता है कि मेरे एटलस बिल्ड सिगविन के साथ किए गए थे, लेकिन वे सिग्विन.डीएलएल से लिंक नहीं करते हैं, इसलिए मुझे लगता है कि वे एमएसवीसी के साथ निर्माण के लिए सुरक्षित होंगे।

mingwpy मुश्किल में नहीं है, लेकिन इसके लिए समय चाहिए। जीसीसी टूलचेन, ओपनबीएलएएस और फिर विभिन्न रूपों के साथ numpy/scipy बनाने में निर्माण और परीक्षण समय लगता है। और मैं पहले सभी बिल्ड स्क्रिप्ट प्रकाशित किए बिना बायनेरिज़ प्रकाशित नहीं करूंगा। Gcc-5.3.0 पर आधारित एक mingwpy लगभग तैयार है, साथ ही OpenBLAS भी। अगला कदम उसी के आधार पर सुस्त और तेज पहियों का निर्माण करना है।

इस चर्चा के साथ-साथ "मल्टी-डिस्ट्रीब्यूशन लिनक्स व्हील्स - प्लीज टेस्ट" में नवीनतम योगदान से सवाल उठता है कि ओपनबीएलएएस में वह गुण है जो ओपनबीएलएएस पर आधारित विंडोज़ के खस्ता पहियों की तैनाती की अनुमति देता है। लेकिन मुझे यकीन नहीं है कि इसके बजाय एटलस का उपयोग करना बेहतर समाधान है। हो सकता है कि पहले परीक्षण चरण के लिए दोनों प्रकारों के साथ सुन्न पहियों का निर्माण किया जाए।

मैं अनुमान लगा रहा/उम्मीद कर रहा हूं कि हम किसी तरह यह मंच प्राप्त करेंगे कि OpenBLAS स्वीकार्य गुणवत्ता का है। लेकिन, उस समय तक, मेरे लिए एटलस सुन्न पहियों के साथ शुरुआत करना उचित प्रतीत होता है, यह उम्मीद करते हुए कि समय के साथ हम ओपनबीएलएएस पहियों पर स्विच करने में सक्षम होंगे। हालांकि 32-बिट बिल्ड के लिए हमें SSE2 चेक डालना पड़ सकता है: http://mingwpy.github.io/blas_lapack.html#atlas

शीर्ष PyPI पृष्ठ पर एक प्रगति बॉक्स रखने से इस मुद्दे पर अधिक लोगों को लाया जा सकता है (उन लोगों सहित जो पहल का समर्थन करने के लिए दान कर सकते हैं)। बॉक्स वर्तमान रणनीति, स्वीकृति मानदंड (प्रदर्शन परीक्षण के लिए लिंक?), स्थिति और कार्रवाई को सूचीबद्ध कर सकता है जो अंतिम संस्करण तैयार होने पर किया जाएगा (प्रमुख संस्करण में वृद्धि?)

@ मैथ्यू-ब्रेट यह अभी भी मुझे स्पष्ट नहीं है कि कुछ फेंकने का आपका प्रस्ताव व्यवहार्य है। आप किस कंपाइलर का उपयोग करेंगे? यदि MingwPy, हमारे पास एक स्पष्ट योजना है कि किस क्रम में करना है और अब बहुत जल्दी लगता है। यदि एक और जीसीसी है, तो हम स्थिर लिंकिंग मुद्दे पर वापस आ गए हैं और डीएलएल दर्द वितरित कर रहे हैं।

मेरा विचार एमएसवीसी का उपयोग करके एटलस के साथ numpy संकलित करना था। बेशक यह scipy के लिए काम नहीं कर सका, लेकिन कम से कम लोग अपने विंडोज़ पहियों को शिपिंग के साथ शुरू करने में सक्षम होंगे, हालांकि निर्मित।

मैंने बस यही कोशिश की और unresolved external symbol __gfortran_compare_string फॉर्म की कुछ त्रुटियां मिलीं, इसलिए मुझे लगता है कि एटलस बायनेरिज़ में गॉफ़रन रन-टाइम के कुछ झूलने वाले संदर्भ हैं। @carlkl - कैसे डिबग करने के लिए कोई सुझाव?

विभिन्न कंपाइलरों से आने वाली स्टैटिक ऑब्जेक्ट फ़ाइलों को मिलाना कुछ ऐसा है जिससे आपको बचना चाहिए जैसे कि शैतान पवित्र जल से बचता है। कुछ मामलों में यह काम करता है, लेकिन संकलक के संयोजन के एक अलग सेट के लिए यह विफल हो जाएगा।
बीटीडब्लू: एमएस स्वयं अपने विजुअल स्टूडियो के विभिन्न संस्करणों से स्थिर वस्तुओं को मिलाकर आधिकारिक तौर पर समर्थन या अनुशंसा नहीं करता है।

मैंने कुछ हफ्ते पहले कुछ परीक्षण किए, क्योंकि यह प्रश्न पॉप अप होता है: क्या mingwpy द्वारा बनाई गई स्थिर लाइब्रेरी npymath.a का उपयोग एमएसवीसी कंपाइलर्स के साथ किया जा सकता है? सिद्धांत रूप में यह काम कर सकता है अगर जीसीसी रनटाइम पुस्तकालयों से कुछ चयनित वस्तुओं को इस पुस्तकालय में जोड़ा जाता है। मैं इस निष्कर्ष पर पहुंचा कि ऐसा दृष्टिकोण अस्थिर और नाजुक है।

यदि एटलस सुन्न पहियों के निर्माण के लिए एक विकल्प है तो मैं इसे डीएलएल के रूप में बनाने की कोशिश करूंगा, कोई आपत्ति?

विभिन्न कंपाइलरों से आने वाली स्टैटिक ऑब्जेक्ट फ़ाइलों को मिलाना कुछ ऐसा है जिससे आपको बचना चाहिए जैसे कि शैतान पवित्र जल से बचता है।

मुझे लगता है कि https://mingwpy.github.io/motivation.html (क्यों पेज) में डायनेमिक लोडेड मॉड्यूल के लिए समस्या की कुछ बहुत ही सरल और सीधी व्याख्या का अभाव है। मैंने सुदूर प्रबंधक लोगों के साथ बात की, जिसका फ़ाइल प्रबंधक विंडोज़ का मूल निवासी है, प्लगइन्स पर बनाया गया है, जो विभिन्न भाषाओं में लिखे गए .dll से लोड होते हैं, और उन्हें "बिल्कुल एक ही कंपाइलर" के साथ यह समस्या नहीं है। मुझे आश्चर्य है कि पाइथन के पास यह क्यों है - यह .dlls से मॉड्यूल भी लोड करता है ..

@techtonik , मेरी टिप्पणी विभिन्न कंपाइलरों द्वारा उत्पादित ऑब्जेक्ट फ़ाइलों को एक बाइनरी फ़ाइल (डीएलएल या EXE) में जोड़ने के बारे में थी। स्थिर वस्तु फाइलों को मिलाने से मेरा यही मतलब था। इस तरह का दृष्टिकोण _can_ कुछ अच्छी तरह से परीक्षण की गई स्थितियों में काम करता है अगर देखभाल के साथ संभाला जाए। लेकिन यह बायनेरिज़ बनाने का एक मजबूत तरीका होने से बहुत दूर है।

एक सामान्य प्रक्रिया स्थान में विभिन्न कंपाइलरों से डीएलएल की इंटरऑपरेबिलिटी पूरी तरह से अलग चीज है। आमतौर पर ऐसा दृष्टिकोण सामान्य नियम के रूप में ठीक काम करता है। किसी को यह सुनिश्चित करना होगा, कि ये बायनेरिज़ उसी एमएस रनटाइम डीएलएल से जुड़े हुए हैं यदि वे फ़ाइल डिस्क्रिप्टर साझा करते हैं। अन्य संभावित एबीआई मुद्दे भी हैं जिन्हें संभाला जाना है। और निश्चित रूप से उपयोग किए जा रहे कंपाइलर्स के आधार पर आपको डिबगिंग के लिए डिबगर्स के एक अलग सेट की आवश्यकता होती है।

minwgpy मानक MSVC CPython बिल्ड के अंदर उपयोग करने के लिए mingw-w64 की मदद से अजगर एक्सटेंशन के निर्माण का समर्थन करने के लिए एक परियोजना है।

ठीक है - मैं एटलस के निर्माण के खिलाफ एमएसवीसी लिंकिंग के साथ numpy बनाने में कामयाब रहा।

एटलस यहाँ बनाएँ:

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

ATLAS dll का निर्माण कैसे करें, इसमें कुछ नंगे-हड्डियों के निर्देश हैं।

सभी खस्ता परीक्षण f2py स्क्रिप्ट जांच के अलावा गुजरते हैं, मुझे लगता है कि यह एक सौम्य विफलता है।

अंतिम चरण पहिया के अंदर गतिशील पुस्तकालय भेज रहा है। @carlkl - ऐसा करने का आपका वर्तमान पसंदीदा तरीका क्या है?

सुनकर अच्छा लगा, मैं यह भी जानना चाहूंगा कि इसके साथ पहिया कैसे बनाया जाता है
बायनेरिज़ शामिल हैं - एक एमकेएल बिल्ड पोस्ट कर सकते हैं और दूसरों को ओपनब्लास का परीक्षण कर सकते हैं
एक।
11 फरवरी 2016 को दोपहर 1:28 बजे, "मैथ्यू ब्रेट" नोटिफिकेशन @github.com ने लिखा:

ठीक है - मैं एटलस के निर्माण के खिलाफ एमएसवीसी लिंकिंग के साथ numpy बनाने में कामयाब रहा।

एटलस यहाँ बनाएँ:

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

वहाँ कुछ नंगे हड्डियों के निर्देश हैं कि कैसे एटलस का निर्माण किया जाए
आदि

सभी खस्ता परीक्षण f2py स्क्रिप्ट जांच से अलग होते हैं, मुझे लगता है कि यह एक है
सौम्य विफलता।

अंतिम चरण पहिया के अंदर गतिशील पुस्तकालय भेज रहा है। @carlkl
https://github.com/carlkl - आपका वर्तमान पसंदीदा तरीका क्या है?
वह?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -183021728।

अंतिम चरण पहिया के अंदर गतिशील पुस्तकालय भेज रहा है।

और SSE2 चेक और ग्रेसफुल बेलआउट?

@mrslezak - सबसे आसान तरीका यह है कि इसे numpy/core फ़ोल्डर में रखा जाए, क्योंकि यह multiarray.pyd के आयात के दौरान प्रक्रिया स्थान में परमाणु रूप से लोड होता है।

अंतिम चरण गतिशील पुस्तकालय को पहिया के अंदर भेज रहा है

@ मैथ्यू-ब्रेट: मुझे 99% यकीन है कि ऐसा करने का "सही" तरीका एसएक्सएस असेंबली के माध्यम से है, जिसका दस्तावेज कठोर रूप से खराब है, लेकिन शायद करने योग्य है ... मुझे पता है कि आपने उन्हें समझने की कोशिश में समय बिताया है, और मैं मैं भी पढ़ रहा हूं, इसलिए यदि आप किसी बिंदु पर बैठना चाहते हैं और विवरण पर काम करना चाहते हैं तो मुझे बताएं :-)।

(अन्य सभी दृष्टिकोणों के साथ समस्या यह है कि आईआईयूसी विंडोज़ प्रक्रिया सामान्य रूप से सभी आयातित डीएलएस का एक वैश्विक नामस्थान बनाए रखती है। इसका मतलब यह है कि यदि दो एक्सटेंशन दोनों foo.dll नामक फ़ाइल को शिप करते हैं, तो जो भी एक्सटेंशन पहले लोड होता है उसका संस्करण होगा foo.dll "जीत" और अन्य एक्सटेंशन इसका उपयोग कर समाप्त हो जाएगा - क्लासिक "डीएलएल नरक" समस्या। और आईआईयूसी इस व्यवहार से बचने का एकमात्र तरीका एसएक्सएस मशीनरी के माध्यम से है, जितना बदसूरत है।)

नथानिएल - मैंने यहां एसएक्सएस असेंबली के बारे में अपनी समझ लिखी है: https://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-assemblies

मेरा अंतिम निष्कर्ष यह था कि यह निराशाजनक था, और किसी भी मामले में, कुछ अद्वितीय-प्रति-प्रक्रिया तरीके से डीएलएल का नाम बदलना एक उचित विकल्प था।

राल्फ - स्थापना प्रक्रिया में SSE2 आदि हुक जोड़ने के तरीके को औपचारिक रूप देने का सुझाव: https://github.com/numpy/numpy/pull/7231

@ मैथ्यू-ब्रेट: मैंने उन नोट्स को पढ़ा है, हाँ .... और उह आह, निराशाजनक क्यों? समान-निर्देशिका के मुद्दों के कारण? और क्या आपके पास कोई विचार है कि उस नामकरण को कैसे पूरा किया जाए? (मुझे अभी तक पीई फाइलों के लिए patchelf --replace के बराबर नहीं मिला है, और .lib फाइलों को पुन: उत्पन्न करना गैर-तुच्छ है - हालांकि मुझे लगता है कि mingw-w64 का उपयोग कर रहा है यह इतना बुरा नहीं है क्योंकि आप .dll से सीधे लिंक कर सकते हैं। कम से कम अगर आपको libgfortran या इसी तरह का नाम बदलने की आवश्यकता नहीं है ...)

(यह संभव है कि इस सूची में कहीं पर patchelf --replace के बराबर कुछ पीई हो: http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

मुझे multiarray.pyd के साथ satlas.dll (या वैकल्पिक रूप से libopenblaspy.dll ) लोड करने में कोई समस्या नहीं दिखती, क्योंकि DLL खोज के दौरान इस निर्देशिका को प्राथमिकता दी जाती है। यह दृष्टिकोण इस तथ्य के कारण काम करता है कि यह डीएलएल LoadLibraryEx के माध्यम से पाइथन से प्रक्रिया स्थान में लोड किया गया है। फ़ोल्डर numpy/core का उपयोग किया जाना है, क्योंकि आयात के दौरान ब्लास निर्भर पायथन एक्सटेंशन की पहली घटना यहां दी गई है। एक ही नाम के साथ एक डीएलएल लोड करने के किसी और प्रयास को केवल अनदेखा कर दिया जाता है क्योंकि यह डीएलएल पहले से ही प्रक्रिया स्थान में लोड हो चुका है। विंडोज़ सिर्फ डीएलएल बीटीडब्ल्यू के नाम की तलाश में है।

डीएलएल नरक प्रारंभ यदि ऐसी लाइब्रेरी _forther_ DLL पर निर्भर है, लेकिन ऐसा नहीं है क्योंकि satlas.dll और libopenblaspy.dll दोनों स्वयं निहित हैं और केवल मानक विंडोज सिस्टम डीएलएल पर निर्भर करते हैं। इसे आमतौर पर स्थिर रूप से जुड़े डीएलएल कहा जाता है - इसका मतलब है कि जीसीसी रनटाइम कोड स्थिर रूप से जुड़ा हुआ है।

_तुलना के लिए_: एमकेएल पुस्तकालयों को आयात करने के लिए दृष्टिकोण अस्थायी रूप से PATH से numpy/core तक बढ़ाना है। दुर्भाग्य से यह विफल हो जाता है अगर पुराने एमकेएल पुस्तकालय विंडोज सिस्टम फ़ोल्डर्स में रखे जाते हैं।

@ मैथ्यू-ब्रेट @ एनजेस्मिथ : डीएलएल का नाम बदलना: यह किसके लिए अच्छा है?

@carlkl : जिस मामले के बारे में हम चिंतित हैं वह यह है कि यदि numpy में atlas.dll शामिल है, और scipy में atlas.dll भी शामिल है, और कुछ बिंदु पर उपयोगकर्ता scipy को अपग्रेड करता है (और atlas.dll का एक नया संस्करण प्राप्त करता है) atlas.dll के पुराने संस्करण का उपयोग करके समाप्त होता है जो numpy पैकेज से आता है। यह बुरा है, क्योंकि scipy नए संस्करण के आधार पर हो सकता है - इसलिए चीजें बेतरतीब ढंग से टूट जाएंगी, जो इस बात पर निर्भर करता है कि कौन से पैकेज शामिल हैं, और उपयोगकर्ता किस क्रम में उन्हें आयात करता है। ऐसा इसलिए होता है क्योंकि यदि numpy में atlas.dll नाम का एक DLL शामिल है, तो वह प्रक्रिया-व्यापी DLL नाम स्थान में atlas.dll नाम का "दावा" करेगा, और यह किसी भी अन्य पैकेज को इसके साथ विभिन्न DLL का उपयोग करने से रोकेगा। नाम।

दो संभावित समाधान हैं (ए) यदि एसएक्सएस/सक्रियण-संदर्भ सामग्री को काम करने के लिए बनाया जा सकता है, तो यह प्रक्रिया-व्यापी डीएलएल नेमस्पेस को अक्षम करने का एक तरीका प्रदान करता है, या (बी) यदि numpy में numpy-atlas.dll है, और scipy इसमें scipy-atlas.dll शामिल है, तो वे बिना टकराए समान प्रक्रिया-व्यापी नामस्थान साझा कर सकते हैं।

या यदि दोनों एक अलग clib_atlas पैकेज पर निर्भर करते हैं जो डीएलएल प्रदान करता है? फिर संस्करण निर्भरता आवश्यकताओं को सामान्य रूप से पायथन पैकेज के लिए व्यक्त किया जा सकता है।

@tkelman : हमें यह पता लगाने की जरूरत है कि दोनों विक्रेता डीएलएल और अलग-अलग वितरित डीएलएल का समर्थन कैसे करें, मुझे लगता है, क्योंकि दोनों विकल्प अलग-अलग परिस्थितियों में उपयुक्त हैं। और विक्रेता का मामला शुरू करना बहुत आसान है :-)

मेरा मानना ​​​​है कि अगल-बगल समाधान के लिए विंडोज़ सिस्टम 32 में स्थापित करने के लिए व्यवस्थापक अधिकारों की आवश्यकता होगी। कृपया ऐसा न करें।

अगल-बगल 'निजी' असेंबलियां भी हैं, जहां असेंबली आपके अपने बाइनरी ट्री में बैठती हैं, लेकिन दो अप-डायरेक्टरी पथ मार्करों की एक सीमा है जिसका उपयोग आप असेंबली को इंगित करने के लिए कर सकते हैं, यानी आप ..\..\some_assembly को इंगित कर सकते हैं ..\..\..\some_assembly नहीं।

तो उदाहरण के लिए, scipy/first/second/third/something.pyd केवल third या second या first निर्देशिकाओं में अगल-बगल असेंबली को इंगित कर सकता है लेकिन scipy में नहीं (या उसके भीतर अन्य निर्देशिका।

ठीक है, मैंने यहां परीक्षण के लिए कुछ पहिये बनाए हैं:

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

हमेशा की तरह:

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

यहां बहुत क्रूड बिल्ड ऑटोमेशन: https://github.com/matthew-brett/np-wheel-builder

पहिए f2py स्क्रिप्ट (उस परीक्षण में एक बग जो मुझे विश्वास है) चलाने में एक नकली विफलता के अलावा सभी परीक्षणों को पास करता है।

राल्फ - SSE2 यहां देखें: https://github.com/matthew-brett/np-wheel-builder/blob/master/_distributor_init.py

मैंने उसी वेब पते पर पायथन 2.7, 3.4, 3.5 के लिए 64-बिट इंस्टॉलर भी बनाए।

@ मैथ्यू-ब्रेट, मुझे इन फ़ाइलों तक पहुंचने की अनुमति नहीं है।

@ मैथ्यू-ब्रेट, एसएक्सएस असेंबली तकनीक का अब उपयोग नहीं किया जाता है (वीएस -2010 के बाद से), https://en.wikipedia.org/wiki/Side-by-side_assembly देखें।

डीएलएल फ़ाइल नामों में संस्करण संख्या जोड़ने के बारे में कैसे: libopenblaspy_0.15..dll या libatlas_3.10.1.dll या समान। और उसके बाद एक _proxy DLL_ का उपयोग करें जिसका उपयोग संस्करणित डीएलएल में फॉरवर्डर डीएलएल के रूप में किया जाता है। Numpy और scipy एक्सटेंशन को _libblaslapack.dll_ नामक प्रॉक्सी DLL के विरुद्ध बनाया जाना चाहिए।

यदि एटलस का उपयोग किया जाता है तो यह सैद्धांतिक रूप से रनटाइम पर एक अनुकूलित एटलस डीएलएल को लोड करने की अनुमति देगा। (ओपनब्लास का उपयोग करते समय आवश्यक नहीं)

यह सब एक clib_openblas और/या clib_atlas पैकेज की मदद से नियंत्रित किया जा सकता है। (अब मुझे सीखना है कि फारवर्डर डीएलएल के लिए कोड कैसे उत्पन्न करें)। Numpy को या तो एटलस या ओपनब्लास से लैस किया जा सकता है। इसे लोड किया जाना चाहिए यदि न तो clib_openblas या clib_atlas उपलब्ध है।

@carlkl : मुझे लगता है कि विकिपीडिया पृष्ठ भ्रमित है, और यह कहने की कोशिश कर रहा है कि वीएस 2010 कुछ पुस्तकालयों के लिए एसएक्सएस _ का उपयोग नहीं करता है, लेकिन सामान्य रूप से एसएक्सएस निश्चित रूप से अभी भी उपयोग किया जाता है (उदाहरण के लिए बाद में उसी पृष्ठ पर: "विस्टा से आगे, ऑपरेटिंग सिस्टम अपने मुख्य घटकों के लिए भी WinSxS का उपयोग करता है।")

मेरा मानना ​​​​है कि जिस तरह से आप msvc के साथ एक फारवर्डर dll बनाते हैं, वह एक विशेष .def फ़ाइल लिखना है और फिर अपना .dll उत्पन्न करते समय इसका उपयोग करना है। लेकिन, फारवर्डर डीएल कैसे मदद करता है? (ओएसएक्स या लिनक्स पर मुझे लगता है कि यह एक उपयोगी उपकरण हो सकता है, लेकिन विंडोज़ पर आपके पास अभी भी उस कष्टप्रद वैश्विक डीएल नेमस्पेस समस्या है।)

@njsmith , हमें एक समझदार समाधान की तलाश करनी चाहिए। यह सच है कि एसएक्सएस साइटल मौजूद है। यह आमतौर पर ऑपरेटिंग सिस्टम के अलावा किसी और चीज़ के लिए उपयोग नहीं किया जाता है।

(1) सबसे आसान उपाय आईएमएचओ ब्लास लैपैक को स्थिर रूप से जोड़ना है। यह दृष्टिकोण विशाल बायनेरिज़ बनाता है और इसलिए अनुशंसित नहीं है (कम से कम मेरे द्वारा)।
(2) दूसरा सबसे आसान उपाय DLL को numpy/core में स्थापित करना है और बस इतना ही।
(3) तीसरा समाधान _force_ बाहरी Blas/Lapack पैकेज पर निर्भरता है, जिसे संस्करणित किया गया है और बस Blas Lapack DLL को प्रीलोड करता है। पाइप का उपयोग सुनिश्चित करता है कि डीएलएल का सही संस्करण उपलब्ध है।
(3) यदि इस तरह की विवश निर्भरता अवांछित है, तो इसे numpy और scipy द्वारा आपूर्ति की गई DLL के साथ बढ़ाया जा सकता है। इन डीएलएल को केवल परिस्थितियों में लोड किया जाना चाहिए, जहां एक बाहरी डीएलएल स्थापित नहीं है। इसका मतलब है कि बाहरी ब्लैस/लैपैक पैकेज को प्राथमिकता दी जाएगी लेकिन सख्ती से जरूरी नहीं है।
इस तरह के एक समाधान का बड़ा प्लस यह है कि ओपनब्लास/एटलस के नए बग-फिक्स्ड रिलीज को numpy/scipy को पुनर्स्थापित किए बिना एक्सचेंज किया जा सकता है।
(4) मैनिफ़ेस्ट और SxS का उपयोग करना। @njsmith , क्या आप इस मामले के लिए विवरण भर सकते हैं?

माफ़ करें - मैंने पहियों के लिए अनुमतियाँ तय कर दी हैं - क्या वे अब काम करती हैं?

क्षमा करें, SxS असेंबली में आपसे दोबारा संपर्क न करने के लिए। SxS पर मेरी 'निराशाजनक' टिप्पणी बहुत उपयोगी नहीं थी, मैं इसे अनपैक करने का प्रयास करूँगा।

सवाल यह है कि क्या हमें "निजी" एसएक्सएस असेंबली का उपयोग करना चाहिए, जो एसएक्सएस असेंबली हैं जिन्हें हम अपने बाइनरी पेड़ में होस्ट करते हैं। SxS असेंबलियों को "साझा" भी किया जा सकता है। साझा असेंबली आपके विंडोज सिस्टम फ़ोल्डर में जाती है, और एक एमएस इंस्टालर पैकेज द्वारा स्थापित किया जाना चाहिए । मुझे लगता है कि इसका मतलब है कि साझा असेंबली को एक पहिया के माध्यम से स्थापित नहीं किया जा सकता है, और किसी भी मामले में व्यवस्थापक अनुमतियों की आवश्यकता होगी, इसलिए मुझे लगता है कि हम साझा असेंबली को एक विकल्प के रूप में अस्वीकार कर सकते हैं।

तो - निजी एसएक्सएस असेंबली का उपयोग करने में क्या समस्याएं हैं?

पहली समस्या यह है कि अगर हम कोशिश करते हैं और ऐसा करते हैं तो हम एक बहुत ही नए निशान को धधक रहे होंगे। मैं किसी अन्य ओपन-सोर्स प्रोजेक्ट के बारे में नहीं जानता जो उनका उपयोग कर रहा है। मैंने स्टीव डावर से एसएक्सएस असेंबली के बारे में पूछा। स्टीव एमएस में काम करता है और वर्तमान में पायथन विंडोज मेंटेनर है। उन्होंने सुझाव दिया कि मैं उनसे बचता हूं। ऐसा लग रहा था कि वह जिस किसी के साथ काम कर रहा था, वह उनसे परिचित नहीं था। ऊपर लिंक किए गए मेरे नोट्स उन कुछ उदाहरणों को समझने का प्रयास थे जिन्हें वह जानता था कि कोई (जाहिरा तौर पर) उनका सफलतापूर्वक उपयोग कर रहा है। उन्हें समझाने के लिए बहुत कम अच्छे संसाधन हैं।

संबंधित अवलोकन कार्ल पहले ही ला चुका है कि एमएस स्वयं उनका उपयोग करने के बारे में द्विपक्षीय प्रतीत होता है। उदाहरण के लिए, MSVC रनटाइम के लिए, SxS असेंबली का एक स्पष्ट अनुप्रयोग, वे इसके बजाय अद्वितीय DLL नामों का उपयोग करते हैं (MSVCR90.DLL, MSVCR100.DLL, आदि)।

एसएक्सएस असेंबली का उपयोग करने के लिए, मुझे लगता है कि हमें "सक्रियण संदर्भ" बनाने के लिए प्रत्येक संकलित मॉड्यूल में प्रारंभिक बॉयलरप्लेट कोड जोड़ना होगा जिसे एक और डीएलएल लोड करने की आवश्यकता है। संपादित करें: नथानिएल ने मुझे याद दिलाया कि विंडोज़ स्वचालित रूप से एक नया सक्रियण संदर्भ ट्रिगर करेगा यदि यह डीएलएल से जुड़े साइड-बाय-साइड असेंबली "मैनिफेस्ट" का सबूत देखता है (जिसे डीएलएल में एम्बेड किया जा सकता है, लेकिन बाहरी एक्सएमएल फाइल भी हो सकती है) .

तो, निराशाजनक नहीं, बल्कि कठिन।

मुझे इस बहुत ही बुनियादी प्रश्न के लिए खेद है, लेकिन, विंडोज़ में, यदि मैं एक एक्सटेंशन मॉड्यूल में my_symbol foo.dll लोड करता हूं, तो क्या होता है यदि मैं लाइब्रेरी bar.dll लोड करता हूं, एक अन्य एक्सटेंशन मॉड्यूल में my_symbol भी शामिल है? मुझे लगता है कि वे मेरी प्रक्रिया में अलग से पहुंच योग्य हैं, इसलिए पहले एक्सटेंशन को foo: my_symbol मिलेगा और दूसरे एक्सटेंशन को bar:my_symbol मिलेगा? क्या कोई मुझे संदर्भ के लिए इंगित कर सकता है?

यदि यह सही है, तो निश्चित रूप से डीएलएल नरक से बचने के लिए हमें केवल एक डीएलएल नाम की आवश्यकता होगी जो उसी प्रक्रिया में दुर्घटना से उपयोग होने की संभावना नहीं थी (जहां उपयोगकर्ता हमारे सटीक डीएलएल का उपयोग करने का इरादा नहीं रखता था)।

प्रत्येक प्रतीक को जोड़ने के दौरान उसके नाम से पहचाने जाने वाले विशिष्ट डीएलएल से जुड़ा होता है। रनटाइम के दौरान किसी को यह सुनिश्चित करना होगा कि सही डीएलएल लोड हो गया है यदि समान नाम वाले एक से अधिक डीएलएल मिल सकते हैं। इसलिए खोज आदेश मायने रखता है।
उदाहरण मेरा anaconda.org सुन्न पहिए जूलिया द्वारा उपयोग किए जाने वाले गैर-मानक libopenblas, dll के साथ नाम टकराव से बचने के लिए libopenblas_py_.dll नाम के साथ openblas लाइब्रेरी का उपयोग करता है।

जूलिया के हाल के संस्करण अब हमारे द्वारा बनाए गए गैर मानक एबीआई को प्रतिबिंबित करने के लिए एक अलग नाम libopenblas64_ का उपयोग करते हैं। 32 बिट पर हम किसी भी प्रतीक या पुस्तकालय के नाम का नाम नहीं बदलते हैं क्योंकि वहां इंटरफ़ेस में 64 बिट इनट्स चुनने का कोई कारण नहीं है।

साझा पुस्तकालयों के भीतर प्रतीकों का नाम छायांकन वास्तव में विंडोज़ की तुलना में लिनक्स और ओएसएक्स पर एक समस्या थी, लेकिन हमने स्थिरता के लिए हर जगह एक ही काम किया।

हालांकि यह 32 बिट पर संभावना से इंकार नहीं करता है जहां एबीआई समान हैं कि हम एक दूसरे को दूसरे तरीकों से तोड़ने का प्रबंधन नहीं कर सके, जैसे कि दूसरे के लिए एक संस्करण की बहुत पुरानी या बहुत नई आवश्यकता है।

मैंने निर्माण प्रक्रिया को थोड़ा सा पॉलिश किया - https://github.com/matthew-brett/np-wheel-builder देखें

अब प्रक्रिया यथोचित रूप से स्वचालित है, मेरा मानना ​​​​है कि अगर हमें करना है तो अगले कुछ रिलीज में इन पहियों का निर्माण जारी रखना व्यावहारिक है। मैं विंडोज रिलीज मैनेजर के रूप में ऐसा करने के लिए खुश हूं जब तक कि mingwpy कल्पना तक नहीं पहुंच जाता।

मैंने 32-बिट और 64-बिट पायथन 2.7, 3.4, 3.5 पर इन पहियों का परीक्षण किया है, और कुछ अन्य लोगों ने भी परीक्षण किया है, इसलिए मुझे लगता है कि वे अच्छे आकार में हैं।

क्या कुछ और है जो मैं आपको आश्वस्त करने के लिए कर सकता हूं कि ये पीपीआई पर डालने लायक हैं, जैसा कि ओपी ने पूछा था?

हैलो सभी को! मैं सिर्फ इस चर्चा में कूदना चाहता था क्योंकि मैं कुछ समय के लिए स्रोत से numpy और scipy स्थापित करने में असमर्थता से निराश हो गया था, इसलिए मेरे लिए यह निश्चित रूप से फायदेमंद है कि क्या है इस मोर्चे पर चल रहा है।

@ मैथ्यू-ब्रेट: यह ऑटोमेशन स्क्रिप्ट कमाल की है। यहां तक ​​​​कि अगर यह इसे पीईपीआई में नहीं बनाता है, तो यह स्रोत से numpy बनाने का एक बहुत ही व्यवहार्य तरीका प्रतीत होता है (इस मुद्दे को मैंने यहां खोला)। यह scipy बनाने में सक्षम होने के बेहद करीब है, जिसमें मैं सब कुछ बना सकता हूं, लेकिन फिर परीक्षण पाइथन में कहीं सेगफॉल्ट का कारण बनते हैं।

इसके अलावा, जो कोई भी वास्तव में numpy पहियों का निर्माण कर रहा है, मैं इन पुस्तकालयों को स्रोत से बनाने के बारे में एक पॉलिश, अप-टू-डेट दस्तावेज़ीकरण को एक साथ रखने की कोशिश कर रहा हूं, जो वर्तमान में ऑनलाइन है, इसलिए मैं बहुत सराहना करूंगा उस मोर्चे पर भी लोगों का इनपुट!

फीडबैक के लिए धन्यवाद - और निर्माण के दस्तावेजीकरण पर आपका काम - यह बहुत उपयोगी होगा।

मुझे लगता है कि आपने http://mingwpy.github.io देखा है - वहां उचित मात्रा में सामान है, निश्चित रूप से, mingw-w64 प्रोजेक्ट और mingwpy टूलचेन के लिए विशिष्ट है।

धन्यवाद @ मैथ्यू-ब्रेट! यह numpy.test() पास करता है। f2py.py परीक्षण वर्चुअलएन्व्स के साथ test_scripts() में एक मुद्दा था जो numpy-SHAd3d2f8e में तय किया गया था, लेकिन मुझे 3 चेतावनियां, 2 बहिष्करण और 1 रनटाइम मिलता है।

एक आखिरी, उम्मीद से मामूली अनुरोध, क्या आपके रेपो एनपी-व्हील-बिल्डर और/या पीईपीआई पर बिल्ड बैज प्रदर्शित करना संभव है? ऐसा लगता है कि बिल्डबॉट 0.8 उनके पास है, और उन्हें अच्छा दिखने के लिए एक पायथन पैकेज/रेपो भी है, BuildbotEightStatusShields-0.1 ।

इसके अलावा, मैं उत्सुक हूं, ट्यूनिंग मापदंडों की कमी के कारण मैं एटलस विंडोज 64-बिट बिल्ड से डर गया हूं। क्या यह वास्तव में "पूरा दिन लेता है" या क्या वास्तुशिल्प चूक का एक उचित सेट है?

एफवाईआई: कॉन्टिनम ने एनाकोंडा को अनुकूलित एमकेएल numpy के साथ जारी किया। मुझे लगता है कि वे इस धागे की निगरानी कर रहे हैं।

अब scipy के लिए एक ही एटलस libs के साथ बनाता है। क्या इसे ग्फोरट्रान की आवश्यकता है?

हां। अन्यथा, आप किसी भी .f फ़ाइल को scipy में संकलित नहीं कर पाएंगे। इसके साथ शुभकामनाएँ! जैसा कि मैंने पहले कहा था, मुझे _वास्तव में करीब_ मिल गया है, लेकिन अगर आप परीक्षा पास करने में सक्षम हैं, तो यह बहुत अच्छा होगा!

हां, मुझे डर है कि एटलस बिल्ड को मशीन पर लगभग 8 घंटे लग गए और कुछ और नहीं किया। एटलस बिल्ड स्क्रिप्ट एनपी-व्हील-बिल्डर रेपो में है ।

MKL समाचार के संबंध में, यह बहुत अच्छा है यदि आप conda उपयोगकर्ता हैं, हालांकि मुझे लगता है कि numpy और scipy के साथ एक पायथन वितरण का उपयोग पूर्व-स्थापित है कुछ ऐसा जिसे कुछ समय के लिए प्रोत्साहित किया गया हो। मुझसे बात करें जब आप स्वयं एमकेएल पुस्तकालय भी निःशुल्क प्राप्त कर सकते हैं। :)

Gfortran के साथ निर्माण के लिए - मुझे लगता है कि mingwpy हमारी सबसे अच्छी आशा है।

@ मैथ्यू-ब्रेट: एटलस बनाने के लिए समय निकालने के लिए धन्यवाद! मैंने पहले आपकी स्क्रिप्ट चलाने की कोशिश की, और मैं मुद्दों में भागता रहा, शायद मशीन-विशिष्ट असंगतियों के कारण।

मुद्दों के लिए खेद है। मैंने एनपी-व्हील-बिल्डर रेपो में एटलस बायनेरिज़ का निर्माण किया था, यह विंडोज सर्वर 2012 की एक नई स्थापना पर था, और 64-बिट सिगविन, सटीक एटलस और लैपैक संस्करणों के साथ सूचीबद्ध था। मेरे द्वारा उपयोग किए जाने वाले स्रोत अभिलेखागार http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/ पर उपलब्ध हैं। यदि आपके पास एटलस का दूसरा संस्करण है, तो यह आसानी से बालों वाली हो सकती है।

हम्म...शायद यही बात है। फिर से, आप लोगों को ऐसा करने के लिए जो प्रयास करना पड़ा, उसे देखते हुए बहुत सराहना की। यदि आप लोग Windows-संगत ATLAS बिल्ड को रोल आउट करने का कोई तरीका ढूंढ़ने में सक्षम हैं, जिसके लिए अब जितना समय और संसाधनों की आवश्यकता नहीं है, तो यह बहुत अच्छा होगा!

@gfyoung

मुझसे बात करें जब आप स्वयं एमकेएल पुस्तकालय भी निःशुल्क प्राप्त कर सकते हैं। :)

देखें https://software.intel.com/sites/campaigns/nest/ और https://registrationcenter.intel.com/en/forms/?productid=2558&licensetype=2 - या आपका मतलब स्रोत था?

@tkelman , बस इसे @carlk new mingwpy प्रोजेक्ट साइट पर देखा लेकिन Intel समुदाय लाइसेंस Nest के पास कोई ifort नहीं है, और इसके बिना कितना डरावना है?

@tkelman : ओह, यकीन नहीं है कि मैं उस समुदाय लाइसेंसिंग के बारे में क्यों भूल गया था। हालाँकि, @tkelman एक वैध बिंदु लाता है।

@tkelman : आप इसे मिनीजीडब्ल्यू के साथ एक शॉट दे सकते हैं, लेकिन जो मैंने अनुभव किया है, वह दुर्भाग्य से काम नहीं करता है। संगतता समस्याओं के कारण यह आपको numpy से आगे भी नहीं ले जाएगा।

@mikofski सही, संकलक की कमी को देखते हुए scipy के लिए मदद नहीं करता है। scipy बिल्ड के लिए आज केवल विकल्प mingwpy होने जा रहे हैं, या ऑल-जीसीसी-ऑल-द-टाइम MSYS2 पायथन का निर्माण (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- अजगर-scipy)। पाठ्यक्रम का उत्तरार्द्ध एमएसवीसी-निर्मित सीपीथॉन या पीपीआई बाइनरी के साथ संगत नहीं होगा, इसलिए यह scipy से परे सभी मॉड्यूल को संबोधित नहीं करेगा।

@ मैथ्यू-ब्रेट: इन एटलस पहियों बनाम ओपनब्लास और/या एमकेएल के लिए गति घाटा क्या है?

क्या किसी ने पीजीआई फोरट्रान में देखा है। @carkl mingwpy प्रोजेक्ट साइट पर इसका उल्लेख नहीं है। मैंने इसे एक बार इस्तेमाल करने की कोशिश की, उस खरगोश के छेद से काफी नीचे चला गया लेकिन मुझे याद नहीं आया कि शो स्टॉपर क्या था। मुझे लगता है कि लाइसेंस बंद स्रोत होने के बावजूद अनुमेय है। शायद पीजीआई फोरट्रान एमएसवीसी के साथ अच्छा खेलेगा?

@mikofski : मेरे पास यह मेरे सामने नहीं है, लेकिन जब मैंने पिछले साल पीजीआई को देखा तो मुझे याद आया कि मेरा निष्कर्ष यह था कि यह इंटेल से भी बदतर था (आपको अपने लाइसेंस के लिए एफओएसएस-असंगत प्रतिबंध जोड़ने के लिए मजबूर करने के मामले में) .

ठीक है, हो सकता है कि कुछ अंक फोकस फंडों को x86 आर्किटेक्चर के लिए BLIS/FLAME समाधान पर लक्षित किया जा सकता है?

जाहिर तौर पर एनवीडिया/पीजीआई इस साल के अंत तक एलएलवीएम को ओपन सोर्स के रूप में अपने फोरट्रान फ्रंट एंड में योगदान देंगे। https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

ठीक है, हो सकता है कि कुछ अंक फोकस फंडों को x86 आर्किटेक्चर के लिए BLIS/FLAME समाधान पर लक्षित किया जा सकता है?

ऐसा मत सोचो। बीएलआईएस एक बहुत ही अस्वस्थ परियोजना की तरह दिखता है (और libflame और भी अधिक); कमिट्स, मेलिंग लिस्ट ट्रैफिक आदि के मामले में बहुत कम गतिविधि। इसके अलावा उनके पास महत्वपूर्ण फंडिंग (https://github.com/flame/blis#funding) है, इसलिए ऐसा नहीं है कि कुछ हजार डॉलर जादुई रूप से उन्हें बनाने जा रहे हैं परियोजनाओं परिपक्व।

मैं यह नहीं देखता कि यह चर्चा कहाँ से आ रही है या कहाँ जा रही है: हमारे पास एक स्टॉपगैप समाधान है जिसे मैथ्यू ने लगभग पूरा कर लिया है (एटीएलएएस का उपयोग करके), और इससे भी महत्वपूर्ण बात यह है कि हमारे पास एक दीर्घकालिक समाधान है जिस पर बहुत सक्रिय रूप से काम किया जा रहा है (MingwPy + ओपनब्लास)। इसके अलावा OpenBLAS का अधिक व्यापक रूप से उपयोग किया जाता है; Scipy स्टैक और जूलिया दोनों में उस प्रोजेक्ट का उपयोग इसे और तेज़ी से परिपक्व करना चाहिए।

@rgommers : बातचीत वहीं गई जहां वह गई क्योंकि @mikofski और मैं दोनों scipy बनाने के लिए @ मैथ्यू-ब्रेट समाधान का उपयोग करने का प्रयास कर रहे थे। हालांकि, ऐसा लगता है कि हम दोनों एक ही समस्या के खिलाफ चल रहे हैं: फोरट्रान कंपाइलर। मैंने खुद MinGW32 और MinGW64 दोनों के लिए स्थापित gfortran.exe का उपयोग करने का प्रयास किया है, बिना किसी कारण या किसी अन्य कारण से कई अनसुलझे बाहरी कारणों के कारण।

@gfyoung मैथ्यू का निर्माण एमएसवीसी का उपयोग करता है। MSVC के साथ gfortran का उपयोग करने का कोई मतलब नहीं है, यह काम नहीं करने के लिए जाना जाता है। निर्माण की स्थिति का सारांश है:

• कोई फोरट्रान नहीं, तो अब आप एमएसवीसी का उपयोग कर सकते हैं।
• फोरट्रान के साथ, आप MingwPy, MSVC + ifort, या icc + ifort में से किसी एक का उपयोग कर सकते हैं।
• Scipy स्टैक के लिए, हम एक मुफ्त समाधान चाहते हैं जो numpy, scipy, आदि के लिए पहियों का निर्माण करता है। उसके लिए, MingwPy यह है।

@rgommers बातचीत को पटरी से उतारने के लिए मुझे खेद है। आप बिल्कुल सही हैं, @ मैथ्यू-ब्रेट समाधान numpy कार्यों के लिए, और @carlk द्वारा mingwpy प्रोजेक्ट पहले से ही num फोकस द्वारा वित्त पोषित है। मैं यह देखने की कोशिश करूंगा कि क्या मैं अपनी कंपनी को इसका समर्थन करने के लिए मिल सकता हूं। मैं पहले से ही एक अंक फोकस सदस्य हूं। scipy 2829 के बारे में आधे रास्ते और मुझे लगता है कि मैं एक ही निष्कर्ष पर आया हूँ। मुझे बस उम्मीद है कि यह काम करेगा। अल्पावधि में हम @cgohlke का उपयोग करना जारी रखेंगे या एनाकोंडा पर स्विच करेंगे। एक बार फिर धन्यवाद!

पीपीआई को बनाने के अलावा, शायद @ मैथ्यू-ब्रेट के लिए एक आखिरी मुद्दा उसके एनपी बिल्ड स्क्रिप्ट रेपो पर एक बिल्डबॉट शील्ड है? धन्यवाद! तो इसे बंद किया जा सकता है?

इसे बंद करने से पहले, त्वरित प्रश्न: मैंने @ मैथ्यू-ब्रेट numpy बनाया ताकि यह एटलस को इंगित करे। हालांकि, जब मैं scipy का उपयोग करके ifort का निर्माण करने का प्रयास करता हूं, तो यह मेरी अन्य site.cfg फ़ाइल भी लेता है जो मेरे होम निर्देशिका में स्थित एमकेएल का उपयोग करता है। मैं वास्तव में numpy के खिलाफ सफलतापूर्वक निर्माण करने में सक्षम हूं, और परीक्षण मिनट राउंडिंग त्रुटियों के कारण कुछ त्रुटियों के लिए सहेजते हैं। हालांकि, मैं उत्सुक हूं, जब मैंने इसे बनाया तो scipy ने क्या किया? क्या उसने एमकेएल पुस्तकालयों का उपयोग किया था या क्या उसने पहले से निर्मित एटलस पुस्तकालयों का उपयोग करने का प्रयास किया था numpy ?

https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows में विंडोज फोरट्रान कंपाइलर्स का सारांश है

@gfyoung - बस अनुमान लगाने और दूर की स्मृति के संयोजन से जा रहा है - मेरा मानना ​​​​है कि scipy अपनी निर्देशिका में पहले site.cfg उठाएगा, और यदि वह गुम है, तो numpy बिल्ड की कॉन्फ़िगरेशन उठाएगा। यह बदले में उन पुस्तकालयों को इंगित करेगा जहां मैंने पहियों का निर्माण किया था। तो आपको np-व्हील-बिल्डर एटलस लाइब्रेरी लेने के लिए scipy के लिए site.cfg को फिर से लिखना होगा - build_numpy.py स्क्रिप्ट numpy बिल्ड के लिए ऐसा करती है।

बीएलआईएस एक बहुत ही अस्वस्थ परियोजना की तरह दिखता है (और libflame और भी अधिक); कमिट्स, मेलिंग लिस्ट ट्रैफिक आदि के संदर्भ में बहुत कम गतिविधि।

मुझे यकीन नहीं है कि मैं उन्हें अस्वस्थ कहूंगा, क्योंकि वे समुदाय द्वारा संचालित FOSS प्रोजेक्ट बनने की कोशिश नहीं कर रहे हैं; वे अनिवार्य रूप से एक व्यक्ति के शो हैं, और वे इसे इस तरह से पसंद करते हैं (अभी के लिए कम से कम)। मैं पिछले ~ वर्ष के लिए उनके साथ संपर्क में रहा हूं, और अच्छी खबर यह है कि उनके प्रयासों का वर्तमान फोकस बिल्कुल उन चीजों पर है जो हमें चाहिए (रनटाइम कर्नेल चयन और रनटाइम थ्रेडिंग कॉन्फ़िगरेशन); बुरी खबर यह है कि एक वास्तुकार द्वारा अपनी पसंद के अनुसार चीजों को पुनर्व्यवस्थित करने के लिए प्रतीक्षा करने के अलावा और कुछ नहीं है। शायद 6 महीने में कुछ परिणाम दिखाई देंगे?

ऐसा लगता है कि इस बिंदु पर बीएलआईएस आदि काफी दूर का विकल्प है, और हमें उस मामले की योजना बनानी होगी जहां यह काम नहीं करता है।

नथानिएल - अच्छे बेंचमार्क कहां से लाएं इस पर कोई सुझाव? मुझे नहीं लगता कि numpy.bench() अब और कुछ करता है। मैंने asv चलाने की कोशिश की, लेकिन कई परीक्षण विफल हो गए क्योंकि Windows numpy में complex256 नहीं है।

मुझे लगता है कि काम करने वाले asv के हिस्से उपयोगी हैं? या यहां तक ​​​​कि %timeit np.dot(big_array, other_big_array) कम से कम कुछ कच्चे विचार प्राप्त करने के लिए उपयोगी होगा जहां हम खड़े हैं :-)

इसके अलावा BTW, यहाँ Windows DLL वैश्विक नाम स्थान समस्या का एक सामान्य समाधान है, जो हमें Windows delocate लिखने की अनुमति देता है: https://github.com/njsmith/redll

दुर्भाग्य से एएसवी कॉम्प्लेक्स256 विफलता सभी प्रकार के परीक्षणों के पूरे अनुक्रम को तोड़ देती है। मुझे लगता है कि हालांकि इसे ठीक करना बहुत मुश्किल नहीं होगा।

इसके साथ सरल परीक्षण:

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)

सुझाव देता है कि, जैसा कि क्लिंट व्हेली ने पहले चेतावनी दी थी - 64 बिट एटलस विंडोज़ पर अच्छी तरह से अनुकूलित नहीं है। क्रिस्टोफ़ गोहल्के के पहियों के माध्यम से 64-बिट एमकेएल के साथ:

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

मेरे पहियों के साथ, 64-बिट एटलस के साथ निर्मित:

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

32-बिट पहियों (एक अलग, 32-बिट मशीन पर) के साथ अंतर बहुत कम है। एमकेएल:

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

बनाम एटलस:

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

@rcwhaley - यदि आप यहां कुछ विचार रखते हैं, तो आपको इसमें शामिल कर रहे हैं। यह एटलस 3.10.1 है ...

यहाँ एक और आधुनिक प्रोसेसर के साथ एक और विंडोज 64-बिट मशीन है - ~ 3x मंदी भी दिखाती है।

एमकेएल:

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

एटलस:

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

हाँ, जटिल 256 समस्या को ठीक करना कठिन नहीं है: https://github.com/numpy/numpy/pull/7251

3x बहुत है, लेकिन लगभग उतना नाटकीय नहीं है जितना कि lapack_lite सही है? मुझे लगता है कि यह एक अल्पकालिक समाधान के लिए ठीक है। और ऐसा नहीं है कि पुराने 32-बिट .exe इंस्टालर कोई बेहतर थे।

इसके अलावा BTW, यहाँ Windows DLL वैश्विक नाम स्थान समस्या का एक सामान्य समाधान है, जो हमें एक Windows delocate लिखने की अनुमति देता है: https://github.com/njsmith/redll

अच्छा लाइसेंस स्टेटमेंट :)

@gfyoung 'site.cfg' की तलाश में है:

1) मुख्य setup.py फ़ाइल की निर्देशिका चलाई जा रही है।
2) ~/.numpy-site.cfg . के रूप में setup.py फ़ाइल चलाने वाले उपयोगकर्ता की होम निर्देशिका
3) सिस्टम वाइड डायरेक्टरी (इस फाइल का स्थान...)

@rgommers बातचीत को पटरी से उतारने के लिए मुझे खेद है।

कोई चिंता नहीं, कुछ भी पटरी से नहीं उतरा।

आप बिल्कुल सही हैं, @ मैथ्यू-ब्रेट समाधान numpy कार्यों के लिए, और @carlk द्वारा mingwpy प्रोजेक्ट पहले से ही num फोकस द्वारा वित्त पोषित है। मैं यह देखने की कोशिश करूंगा कि क्या मैं अपनी कंपनी को इसका समर्थन करने के लिए मिल सकता हूं। मैं पहले से ही एक अंक फोकस सदस्य हूं। scipy 2829 के बारे में आधे रास्ते और मुझे लगता है कि मैं एक ही निष्कर्ष पर आया हूँ। मुझे बस उम्मीद है कि यह काम करेगा। अल्पावधि में हम @cgohlke का उपयोग करना जारी रखेंगे या एनाकोंडा पर स्विच करेंगे। एक बार फिर धन्यवाद!

ठंडा। और यह देखकर अच्छा लगा कि आप MingwPy में रुचि रखते हैं। ध्यान दें कि अब इसका अपना एमएल है, जो रुचि का हो सकता है: https://groups.google.com/forum/#!forum/mingwpy

@rgommers , @ मैथ्यू-ब्रेट: आह, हाँ, ऐसा लगता है कि यह पहले से एमकेएल के साथ निर्माण कर रहा था। मैंने सीधे अपने site.cfg को एटलस बिल्ड की ओर इशारा किया, और scipy बनाता है लेकिन परीक्षणों के दौरान segfaults। बहुत करीब!

@rgommers - हाँ - एटलस के बिना प्रदर्शन बहुत खराब है (lapack_lite के साथ):

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

मुझे लगता है कि यहां शेष प्रश्न यह है कि क्या यह ओपनबीएलएएस numpy (सभी numpy परीक्षणों पास करने के साथ) के मानकीकरण के लायक है, इस जोखिम को स्वीकार करते हुए कि यह numpy का उपयोग कर परियोजनाओं में संख्यात्मक त्रुटियों का कारण बनने की अधिक संभावना होगी।

ऐसा करने के लिए एक तर्क यह होगा कि ऐसा लगता है कि हमें इस दिशा में लघु/मध्यम अवधि में जाना होगा, और यह बेहतर होगा कि अभी शुरू करें और खुद को दयनीय बग शिकार के लिए प्रतिबद्ध करें जो कि आवश्यक होगा। कम से कम हम जूलिया अनुरक्षकों की अच्छी संगति में रहेंगे।

जूलिया की तुलना में Numpy के पास जोखिम सहनशीलता बनाम प्रदर्शन ट्रेडऑफ़ और डेवलपर्स के उपयोगकर्ताओं के अनुपात का एक काफी अलग सेट है। इसलिए मुझे लगता है कि numpy के लिए अधिक रूढ़िवादी दृष्टिकोण लेने और डिफ़ॉल्ट के रूप में धीमी लेकिन भरोसेमंद के साथ जाने के लिए यह बहुत मायने रखता है, ओपनब्लास को गैर-डिफ़ॉल्ट विकल्प के रूप में चुनने की अनुमति देने की दिशा में काम कर रहा है। हालांकि वे 8 घंटे का निर्माण समय मजेदार नहीं लगता, कोई आश्चर्य नहीं कि कोई भी हमसे जूलिया के साथ एटलस का उपयोग करने के बारे में नहीं पूछ रहा है।

ओपनब्लास को गैर-डिफ़ॉल्ट विकल्प के रूप में अनुमति देने की दिशा में काम करना

समस्या यह है कि मुझे सच में यकीन नहीं है कि यह प्रक्रिया कैसे काम कर सकती है: - /। हमारे पास उपयोगकर्ताओं को वैकल्पिक बिल्ड वितरित करने का कोई अच्छा तरीका नहीं है (लंबे समय में मुझे उम्मीद है कि हम pypi पर numpy[openblas] आदि के रूप में बिल्ड वेरिएंट प्राप्त कर सकते हैं, लेकिन यह जल्द ही कभी भी नहीं होगा) , हमारे पास उन्हें वितरित करने और बग रिपोर्ट की प्रतीक्षा करने के अलावा ओपनब्लास बिल्ड में सुधार करने का कोई तरीका नहीं है, और एटलस बिल्ड का मुख्य विकल्प उन लोगों के लिए है जो एक की तलाश करने के लिए प्रेरित हैं, ओपनब्लास बिल्ड नहीं होंगे, यह एमकेएल होगा किसी तीसरे पक्ष से बनाता है: - /।

मुझे लगता है कि टेबल पर रखने का एक और विकल्प बीएलआईएस बिल्ड को उनके संदर्भ/एसएसई 2 कर्नेल का उपयोग करके वितरित करना होगा। क्योंकि BLIS में अभी भी केवल बिल्ड टाइम कॉन्फ़िगरेशन है, यह ओपनब्लास के साथ प्रतिस्पर्धी नहीं होगा, लेकिन यह ATLAS के साथ प्रतिस्पर्धी हो सकता है, और ATLAS बनाम लाभ यह है कि निर्माण समय _much_ तेज है, और इसके एक अच्छा दीर्घकालिक समाधान होने की संभावना है अनुमान लगाना कठिन है, लेकिन निश्चित रूप से एटलस की तुलना में एक अच्छा दीर्घकालिक समाधान है (जिसे मैं शून्य पर रखूंगा)। अगर हम वैसे भी कुछ क्यूएइंग करने जा रहे हैं तो कम से कम हम उस ऊर्जा को किसी ऐसी चीज पर निर्देशित कर रहे होंगे जिसका भविष्य हो।

इस विकल्प पर गंभीरता से विचार करने से पहले कुछ सवालों के जवाब देने होंगे:

(1) मुझे यकीन नहीं है कि BLIS का मल्टीथ्रेडिंग समर्थन ATLAS के साथ प्रतिस्पर्धी है या नहीं (मुझे पता है कि स्रोत में कुछ मल्टी-थ्रेडिंग विकल्प हैं, और मुझे पता है कि मुख्य डेवलपर इसे अभी तक "किया" नहीं मानता है , यानी एमकेएल के साथ प्रतिस्पर्धी, लेकिन एटलस और एमकेएल के बीच बहुत जगह है।)

(2) उस मामले के लिए, मुझे यह भी पता नहीं है कि एक अनट्यून मोड में BLIS उन बेंचमार्क पर कैसे किराया करता है।

(3) मैंने वास्तव में विंडोज़ पर बीएलआईएस बनाने की कोशिश नहीं की है, और इससे निपटने में समस्या है कि यह सिर्फ एक बीएलएएस है, लैपैक नहीं - यह सुनिश्चित नहीं है कि यह कितनी समस्या है।

बग रिपोर्ट के प्रति BLIS कितना उत्तरदायी है? ओपनब्लास बहुत अच्छा लगता है
इस बारे में।

सोम पर, फरवरी 15, 2016 अपराह्न 3:48, नथानिएल जे. स्मिथ <
सूचनाएं@github.com> ने लिखा:

ओपनब्लास को गैर-डिफ़ॉल्ट विकल्प के रूप में अनुमति देने की दिशा में काम करना

समस्या यह है कि मुझे सच में यकीन नहीं है कि यह प्रक्रिया कैसे काम कर सकती है: - /।
हमारे पास उपयोगकर्ताओं को वैकल्पिक बिल्ड वितरित करने का कोई अच्छा तरीका नहीं है (में
लंबे समय तक मैं उम्मीद कर रहा हूं कि हम पीपीआई पर numpy [openblas] के रूप में बिल्ड वेरिएंट प्राप्त कर सकते हैं
और बहुत कुछ, लेकिन यह जल्द ही कभी नहीं होगा), हमारे पास ऐसा करने का कोई तरीका नहीं है
ओपनब्लास बिल्ड को वितरित करने और बग की प्रतीक्षा करने के अलावा सुधारें
रिपोर्ट, और एटलस का मुख्य विकल्प उन लोगों के लिए बनाता है जो
ओपनब्लास बिल्ड नहीं होगा, यह एमकेएल बिल्ड होगा
किसी तीसरे पक्ष से :-/.

मुझे लगता है कि टेबल पर रखने का एक और विकल्प BLIS को वितरित करना होगा
उनके संदर्भ/SSE2 कर्नेल का उपयोग करके बनाता है। क्योंकि BLIS में अभी भी केवल बिल्ड है
समय विन्यास यह ओपनब्लास के साथ प्रतिस्पर्धी नहीं होगा, लेकिन यह हो सकता है
एटलस के साथ प्रतिस्पर्धी, और एटलस बनाम लाभ यह है कि बिल्ड
समय _बहुत_ तेज है, और इसके एक अच्छा दीर्घकालिक होने की संभावना
समाधान का अनुमान लगाना कठिन है लेकिन निश्चित रूप से एटलस के अच्छे होने से बेहतर है
दीर्घकालिक समाधान (जिसे मैं शून्य पर रखूंगा)। अगर हम QAing होने जा रहे हैं
वैसे भी कुछ तो कम से कम हम उस ऊर्जा को किसी चीज़ पर निर्देशित कर रहे होंगे
कि _शायद_ का भविष्य हो।

इस पर गंभीरता से विचार करने से पहले कुछ प्रश्न जिनका उत्तर देने की आवश्यकता होगी
विकल्प:

(1) मुझे यकीन नहीं है कि BLIS का मल्टीथ्रेडिंग समर्थन है या नहीं
एटलस के साथ प्रतिस्पर्धी (मुझे पता है कि इसमें कुछ बहु-थ्रेडिंग विकल्प हैं
स्रोत, और मुझे पता है कि मुख्य डेवलपर इसे नहीं मानता है
"किया" अभी तक, यानी एमकेएल के साथ प्रतिस्पर्धी, लेकिन बीच में बहुत जगह है
एटलस और एमकेएल।)

(2) उस मामले के लिए, मुझे यह भी पता नहीं है कि BLIS एक अनट्यून मोड में कैसे किराया करता है
उन बेंचमार्क पर ऊपर।

(3) मैंने वास्तव में विंडोज़ पर बीएलआईएस बनाने की कोशिश नहीं की है, और वहां है
इससे निपटने में समस्या यह सिर्फ एक बीएलएएस है, लैपैक नहीं - सुनिश्चित नहीं है कि कैसे
एक मुद्दा यह numpy के लिए है।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -184387401।

मेरा मानना ​​है कि लिबफ्लेम ब्लिस के बराबर लैपैक है। संदर्भ डॉक्स में वर्णित एक लैपैक2फ्लेम संगतता इंटरफ़ेस है।

बग रिपोर्ट के प्रति BLIS कितना उत्तरदायी है?

हम अभी नहीं जानते।

बीएलआईएस की कोशिश किए बिना, मुझे लगता है कि यह पागलपन की तरह लगता है और मूल रूप से एक कम गतिविधि वाली एक-व्यक्ति परियोजना के खिलाफ बनाई गई numpy बाइनरी शिप करने के लिए पागलपन की तरह लगता है कि बहुत कम लोग उपयोग करते हैं।

मैंने अभी तक इस सूत्र में MingwPy + OpenBLAS योजना से विचलित होने का कोई अच्छा कारण नहीं देखा है। No-scipy-ATLAS-MSVC-बायनेरिज़ स्टॉपगैप के लिए अच्छा है, लेकिन मध्यम/दीर्घकालिक MingwPy समाधान से कम महत्वपूर्ण है और यदि स्टॉपगैप अपने आप में एक बड़े प्रयास में बदल जाता है, तो मैं कहूंगा कि यह प्रयास के लायक नहीं है .

BLIS / libflame दस्तावेज़ सुझाव देते हैं कि, यदि मैं विंडोज़ पर एक पूर्ण BLAS / LAPACK लाइब्रेरी बनाने की कोशिश करने जा रहा था, तो यह एक अकेला रास्ता होगा।

मुझे यह करने में खुशी हो रही है कि एक बार जब डेवलपर्स सहमत हो जाते हैं कि यह काम करना चाहिए और समर्थित है।

ATLAS लंबे समय से Linux पर डिफ़ॉल्ट लाइब्रेरी रही है। यह कल्पना करना अनुचित नहीं लगता कि विंडोज़ बीएसडी-संगत बिल्ड के मामले में कुछ समय के लिए ऐसा हो सकता है।

@tkelman - आपके विश्लेषण के लिए धन्यवाद - मुझे लगता है कि आप सही हैं, उस numpy को शुद्धता पर ध्यान देना चाहिए। लेकिन, कुछ अधिक थकाऊ OpenBLAS बगों पर भरोसा करने और अधिक व्यापक परीक्षण विकसित करने के लिए बलों में शामिल होना अच्छा होगा। यह OpenBLAS बग दिमाग में आता है - कुछ अस्पष्ट, डीबग करना बहुत कठिन।

मैं इस विशेष मुद्दे के लिए विश्वास करता हूं, कि पीपीआई पर खस्ता पहिये प्रदान करना ताकि पैकेज "x" का एक आकस्मिक उपयोगकर्ता जो "y" (जैसे: matplotlib) पर निर्भर करता है, जो कि numpy पर निर्भर करता है, पाइप का उपयोग करके स्थापित करेगा, जिससे आकस्मिक उपयोगकर्ता को फेंकना नहीं पड़ेगा। अपनी बाहों को ऊपर उठाएं और ऐसा कुछ कहें, "पायथन बहुत मुश्किल है।" और MATLAB पर वापस जाएं। अजगर के ज़ेन का कहना है कि ऐसा करने का एक स्पष्ट तरीका होना चाहिए। उस ने कहा, विशेष रूप से numpy द्वारा pypi पर कुछ भी एक निश्चित भार वहन करता है कि यह _is_ स्थिर है, या यादृच्छिक साइड प्रोजेक्ट से कहीं अधिक है, cgohlke के अपवाद के साथ। स्पष्ट रूप से उत्साही और एनाकोंडा को कम से कम उद्योग में अधिक स्थिर माना जाता है।

मुझे लगता है कि अल्पावधि में एटलस बिल्ड को चेतावनी संदेश के साथ जाना चाहिए कि इसे सिप्पी के साथ बनाना संभव नहीं है। अगर इस बिल्डबॉट को स्वचालित किया जा सकता है तो यह हो गया है, है ना? भविष्य के 8hr ATLAS बिल्ड उम्मीद के मुताबिक दुर्लभ होने चाहिए। शायद एक दिन विंडोज़ 64 बिट की समस्या हल हो जाएगी। SSE2 अपवाद समस्या एक उबाऊ है, इसलिए pypi पर एक और चेतावनी संदेश। इसके अलावा एटलस पहले से ही लिनक्स पर मानक है और पिछले सुपरपैक bdist_winst पैकेज में मानक था जो इस पथ को और भी अधिक समर्थन देता है।

फिर निकट भविष्य के लिए, आपने पहले ही मिंगवपी पर फैसला कर लिया है। यहां कई विकल्प हैं जिन्हें अभी हल करने की आवश्यकता नहीं है।

लंबी अवधि में मैं उत्साहित हूं कि आनंद/लौ ही भविष्य है। यह थोड़ा डरावना है कि हमारे कई गणितीय उपकरण 70 के दशक के फोरट्रान कोड पर निर्भर हैं। एसी ओनली सॉल्यूशन एक बड़ा ब्रेक थ्रू है और उत्साह से समर्थन करने के लिए कुछ है।

लेकिन अनुभवी डेवलपर्स के लिए हमेशा बेहतर होता है इसलिए गैर मानक विकल्पों के लिए दस्तावेज़ीकरण को जीवित रखना भी अच्छा है यदि ऐसे अनुभवी डेवलपर्स के पास निर्माण और परीक्षण करने का समय और झुकाव है।

यदि आप ब्लिस में अनुकूलित कर्नेल में से किसी एक का उपयोग करने का प्रयास नहीं करते हैं, तो आप शायद इस मुद्दे को हिट नहीं करेंगे (संपादित करें: एकवचन) मैंने 2014 से वहां खोला है। मुझे लगता है कि बिल्ड सिस्टम केवल अनुकूलित के लिए सिम्लिंक का उपयोग करता है कर्नेल, इसलिए आप msys2 के git को भ्रमित नहीं करेंगे यदि आप वहां केवल संदर्भ कॉन्फ़िगरेशन बनाने का प्रयास करते हैं। साइगविन से बिल्डिंग ने आखिरी बार काम किया, मैंने कोशिश की, हालांकि यह कुछ समय पहले था और मुझे याद नहीं आया कि मुझे स्थानीय रूप से संशोधित करने की क्या आवश्यकता हो सकती है। यदि विकल्प एटलस है, तो यह निर्माण, परीक्षण और बेंचमार्किंग के लायक है, लेकिन जब तक आप ऐसा नहीं करते हैं, तब तक इसे अप्रमाणित और अपने तरीके से उच्च जोखिम पर विचार करें।

@mikofski निष्पक्ष होने के लिए लैपैक 90 के दशक से है, यह वास्तव में कमरे में फोरट्रान हाथी है।

@tkelman : स्पष्ट होने के लिए, आपके द्वारा दायर किए गए मुद्दे विशेष रूप से विंडोज़-देशी निर्माण प्रणाली के साथ थे, है ना? जिज्ञासा से बाहर मैंने लिनक्स से विंडोज़ के लिए क्रॉस-कंपाइलिंग ब्लिस की कोशिश की (डेबियन पैकेज से स्थापित mingw-w64 क्रॉस-कंपाइलर का उपयोग करके), और मुझे यह जानकर आश्चर्य हुआ कि इसमें केवल ~ 2 मिनट लगे। मैंने "./configure संदर्भ; -j4 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-ar CPICFLAGS=" किया और सब कुछ बस काम किया। ( CPICFLAGS= केवल " -fPIC अनदेखा करने के बारे में चेतावनियों के एक समूह को दबाने के लिए है, क्योंकि यह डिफ़ॉल्ट है", और शायद मुझे AR को ओवरराइड करने की भी आवश्यकता नहीं थी, लेकिन हे क्यों नहीं।) bli_pool.c और bli_fprintm.c में प्रिंटफ्स के बारे में कुछ चेतावनियां मिलीं, जो $ intptr पूर्णांकों को प्रिंट करने के लिए %ld का उपयोग करते हैं, इसलिए शायद कुछ एलएलपी 64 किंक हैं कसरत करना।

@rgommers :

बीएलआईएस की कोशिश किए बिना, मुझे लगता है कि यह पागलपन की तरह लगता है और मूल रूप से एक कम गतिविधि वाली एक-व्यक्ति परियोजना के खिलाफ बनाई गई numpy बाइनरी शिप करने के लिए पागलपन की तरह लगता है कि बहुत कम लोग उपयोग करते हैं।

आप बिल्कुल सही कह रहे है! समस्या यह है कि हमारे सभी विकल्प भयानक हैं :-(।

तो जाहिर है कि एमकेएल के पास निश्चित रूप से खराब लाइसेंस है।

एटलस का निश्चित रूप से खराब प्रदर्शन है जो कभी नहीं सुधरेगा।

और ओपनब्लास, मुझे लगता है कि हमारे पास इस बिंदु पर कहने के लिए सबूत हैं, बस रखरखाव योग्य नहीं है और इतनी जल्दी बनने की संभावना नहीं है :-(। परियोजना पांच साल पुरानी है, इसमें अभी भी मौलिक रूप से टूटी हुई चीजें हैं जैसे जूलियन के यादृच्छिक volatile का उदाहरण

इसलिए मेरे द्वारा BLIS लाने का कारण यह नहीं है कि मुझे लगता है कि BLIS निश्चित रूप से समाधान है, लेकिन एक तरह की गणना की गई आशावाद के रूप में: BLIS _might_ MKL/OpenBLAS जितना तेज़ हो, ATLAS/MKL जितना विश्वसनीय हो, और समुदाय के लिए खुला हो- OpenBLAS के रूप में योगदान; या फिर, यह नहीं हो सकता है। लेकिन ऐसा कोई अन्य प्रोजेक्ट नहीं लगता है जिसमें उन सभी मानदंडों को पूरा करने की वास्तविक आशा हो। [और यह अन्य लाभों का भी उल्लेख नहीं कर रहा है, इस तथ्य की तरह कि यह मूल रूप से स्ट्राइडेड सरणी का समर्थन कर सकता है; यह अकल्पनीय नहीं है कि हम अपने सभी भयानक विशेष-केस बीएलएएस प्रेषण कोड को हटाने में सक्षम हो सकते हैं।]

आईआईयूसी, गोटोब्लास को यूटी ऑस्टिन में पीआई के रूप में रॉबर्ट वैन डी गीजन के साथ काम कर रहे एक पूर्णकालिक डेवलपर (काज़ुशिगे गोटो) द्वारा बनाए रखा गया था। BLIS का रखरखाव एक एकल पूर्णकालिक डेवलपर (फ़ील्ड G. Van-Zee) द्वारा किया जाता है, जो UT ऑस्टिन में रॉबर्ट वैन डे गीजन के साथ PI के रूप में काम करता है। तो ऐसा नहीं है कि यह काम नहीं कर सकता :-) लेकिन हाँ, अगर हम प्रतीक्षा करते हैं तो यह सिर्फ जादुई रूप से नहीं होने वाला है - अगर इसके आसपास डेवलपर्स का एक समुदाय होने जा रहा है तो ऐसा होने जा रहा है क्योंकि कुछ समुदाय ने अपना दिखाया तंबू के साथ सामने का लॉन जैसे "अरे, हम यहाँ हैं, हम अंदर जा रहे हैं और हमारे लिए यह काम कर रहे हैं, आशा है कि आपको कोई आपत्ति नहीं है"। और इसकी दीर्घकालिक व्यवहार्यता को निर्धारित करने के लिए हमें वास्तव में क्या जानना चाहिए, जैसे, "यह वास्तव में कितना विश्वसनीय है" और "वे पैच के लिए कितने अनुकूल हैं" और सामान, जिसे हम तब तक नहीं जान सकते जब तक हम इसका परीक्षण और सबमिट करना शुरू नहीं करते पैच और इतने पर।

अंत में: मुझे गंभीरता से पता नहीं है कि हमारा सबसे अच्छा विकल्प क्या है, लेकिन हमारे पैर की उंगलियों को बीएलआईएस पानी में चिपकाना एक अच्छा विचार है; अगर हम तय कर लें कि हम इंतजार करना चाहते हैं तो हम कम से कम कुछ तो सीखेंगे।

मैंने कई मुद्दे और एक या दो पीआर दायर किए। तथ्य यह है कि भंडार में सिम्लिंक हैं इसका मतलब है कि msys2 से निर्माण टूटा हुआ है (या केवल तभी काम करता है जब आप msys2 विकल्पों को एक विशिष्ट तरीके से सेट करते हैं)। साइगविन या लिनक्स से क्रॉस बिल्डिंग (हालांकि मैं परीक्षण चलाने के लिए शराब पर भरोसा नहीं करता) काम करना चाहिए, लेकिन 2014 में गठबंधन मॉलोक के साथ समस्याएं थीं, और रेतीले पुल कर्नेल एक परीक्षण में सेगफॉल्ट थे। मैंने सिग्विन क्रॉस (एक नए स्काईलेक लैपटॉप पर) के साथ ब्लिस के नवीनतम मास्टर पर रेतीले पुल कर्नेल को फिर से बनाया और सेगफॉल्ट अब चला जा सकता है। कौन जानता है कि इसे कब या किसने तय किया, इसे द्विभाजित करना होगा।

मुझे लगता है कि इसका उल्लेख पहले किया जा चुका है, लेकिन हम SSE2, SSE3, AVX के लिए एटलस बायनेरिज़ बना सकते हैं, और उन्हें एक निर्देशिका संरचना में डाल सकते हैं जैसे:

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

फिर हम वर्तमान सीपीयू की जांच करने और मेल खाने वाली लाइब्रेरी को प्री-लोड करने के लिए numpy/_distributor_init.py का उपयोग कर सकते हैं।

मैंने मूल रूप से वही काम करने का सुझाव दिया, लेकिन एटलस के बजाय आनंद के लिए, @njsmith को। यह तुलना करने लायक भी है कि एटलस बनाम ब्लिस वर्क्स में थ्रेडिंग कितनी अच्छी है। ब्लिस संदर्भ कॉन्फ़िगरेशन डिफ़ॉल्ट रूप से थ्रेडिंग को सक्षम नहीं करता है, हालांकि हेडर फ़ाइल में परिभाषित करने के लिए इसे स्विच करने के लिए आवश्यक सभी होना चाहिए।

मैंने बायनेरिज़ बनाने के लिए Appveyor की स्थापना की। बिल्ड की वर्तमान पुनरावृत्ति यहां दूर हो रही है: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

निर्मित पहिए यहां पहुंचे: https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

Appveyor बिल्ड में किसी भी और किंक को बाहर निकालना आसान होना चाहिए, इसलिए मुझे लगता है कि ये पहिए pypi पर अपलोड होने के लिए तैयार हैं, जब यह किया जाता है, संभवतः कल कुछ समय के लिए।

@rgommers , @matthew-brett: site.cfg के संबंध में, ऐसा लगता है कि आपकी प्रतिक्रिया केवल numpy पर लागू होती है। ऐसा लगता है कि scipy उसी निर्देशिका में site.cfg की खोज नहीं करता है क्योंकि setup.py केवल site.cfg की खोज शुरू करता है numpy को डिफ़ॉल्ट करने से पहले आपकी होम निर्देशिका में पहले

ठीक - बिना त्रुटि के चलने वाली स्क्रिप्ट का निर्माण करें, जिसमें स्थापित व्हील के परीक्षण शामिल हैं: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

यहां पहिए: http://58688808cd85529d4031-38dee5dca2544308e91131f21428d924.r12.cf2.rackcdn.com/

मैंने उन्हें एक और 64 बिट मशीन और दूसरी 32-बिट मशीन पर स्थापित और परीक्षण किया है।

इसलिए, मुझे लगता है कि ये जाने के लिए तैयार हैं। मुझे इन्हें pypi पर अपलोड करने में कोई आपत्ति है?

यह एक अच्छा विचार हो सकता है कि पीपीआई पर इन पहियों और गोहलके (एमकेएल) के बीच अंतर के स्पष्टीकरण के लिए स्पष्टीकरण/लिंकिंग पर लोगों द्वारा भ्रम को दूर करने के लिए एक अच्छा विचार हो सकता है कि पहिए अब पीपीआई पर क्यों दिखाई देते हैं और क्या अंतर है उनके बीच हैं।

एक साइड प्रश्न, क्षमा करें, लेकिन मैं सोच रहा था कि क्या

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

appveyor लिपि में मतलब है?

स्पष्टीकरण के बारे में अच्छा सुझाव - मैं इस मौजूदा रिलीज के लिए इसे जोड़ने का प्रयास करने का प्रयास करूंगा।

व्हील> 0.26 विंडोज व्हील में एक अतिरिक्त एबीआई टैग जोड़ता है। व्हील == 0.26 इस तरह से एक पहिया नाम देता है:

numpy-1.10.4-cp27-none-win32.whl

व्हील> 0.26 के साथ, आपको एक अतिरिक्त ABI टैग मिलता है, जैसे:

numpy-1.10.4-cp27-cp27m-win32.whl

(मुझे लगता है) - जो विंडोज एबीआई को निर्दिष्ट करता है। यह कष्टप्रद है क्योंकि पहले पाइप इन लोगों को स्थापित नहीं करेगा, इसलिए मुझे ऐसा लगता है कि अब के लिए नो-एबीआई नाम बेहतर है।

ठीक है - मैं इस पाठ को वर्तमान pypi पृष्ठ में जोड़ने का प्रस्ताव करता हूं:

पीपीआई से वितरित सभी सुपीरियर पहिये बीएसडी लाइसेंस प्राप्त हैं।

विंडोज़ के पहिये एटलस बीएलएएस / लैपैक लाइब्रेरी से जुड़े हुए हैं, जो एसएसई 2 निर्देशों तक सीमित है, इसलिए आपकी मशीन के लिए इष्टतम रैखिक बीजगणित प्रदर्शन नहीं दे सकता है। विकल्पों के लिए http://docs.scipy.org/doc/numpy/user/install.html देखें।

मैं अलग तरह से कहूंगा:

इन विंडोज पहियों में उप-इष्टतम रैखिक बीजगणित प्रदर्शन (http://speed.python.org जैसे बेंचमार्क से लिंक) है, क्योंकि वे एटलस बीएलएएस / लैपैक लाइब्रेरी के खिलाफ जुड़े हुए हैं, जो एसएसई 2 निर्देशों तक सीमित हैं (और कौन से गैर-प्रतिबंधित निर्देश चाहिए वहाँ होना?)। यदि आपको प्रदर्शन की आवश्यकता है, तो आप mingwpy प्रोजेक्ट का समर्थन कर सकते हैं जिसका उद्देश्य इस प्लेटफॉर्म पर संकलित पायथन एक्सटेंशन में अधिक प्रदर्शन लाना है। देखो ??? विवरण के लिए और विकल्पों के लिए http://docs.scipy.org/doc/numpy/user/install.html ।

खैर - mingwpy के वर्तमान numpy/scipy संस्करण openblas का उपयोग करते हैं, लेकिन मुझे लगता है कि यह एक कंपाइलर के रूप में mingwpy बनाम एमएसवीसी से असंबंधित है। हम इन पहियों के साथ ओपनब्लास भी भेज सकते थे, लेकिन मुझे चिंता थी कि ओपनब्लास अभी तक एक मानक पहिया में उपयोग करने के लिए पर्याप्त विश्वसनीय नहीं था जिसका हम समर्थन करते हैं।

ओपनब्लास काफी स्थिर लगता है, मुझे पता है कि एनाकोंडा अपने लिनक्स के लिए इसका इस्तेमाल करता है
अब बनाता है। कोई अद्यतन Windows Python 3.5 x64 बिल्ड आउट नहीं है
वहां, बेंचमार्क दिखाते हैं कि यह एमकेएल के बराबर है। मैं निश्चित रूप से कोशिश करूँगा अगर
कोई एक साथ पहिया लगा सकता है।
16 फरवरी 2016 को रात 10:36 बजे, "मैथ्यू ब्रेट" नोटिफिकेशन @github.com ने लिखा:

अच्छी तरह से - मिंगवपी के वर्तमान numpy/scipy संस्करण ओपनब्लास का उपयोग करते हैं, लेकिन I
सोचें कि यह एक कंपाइलर के रूप में mingwpy बनाम MSVC से असंबंधित है। हम जहाज भी कर सकते हैं
इन पहियों के साथ ओपनब्लास, लेकिन मुझे चिंता थी कि ओपनब्लास अभी तक नहीं था
एक मानक पहिया में उपयोग करने के लिए पर्याप्त विश्वसनीय है जिसका हम समर्थन करते हैं।

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -185017546।

ठीक। मैं केवल उप-प्रदर्शन के स्रोत के बारे में उलझन में हूं - मैं उन बीएलएएस पुस्तकालयों का उपयोग नहीं करता हूं और नहीं जानता कि वे क्या करते हैं और क्या अंतर है, इसलिए नश्वर लोगों के लिए इन विकल्पों की व्याख्या करने से .. एर्म, अधिक वैज्ञानिक बनने में मदद मिलती है, आप जानते हैं . =) मैंने सोचा कि इष्टतम प्रदर्शन के साथ ओपन कंपाइलर की अनुपस्थिति समस्या है।

@mrslezak : ओपनबीएलएएस के संबंध में, मैं निश्चित रूप से सहमत हो सकता हूं। सिग्विन पर प्रदान किया गया ओपनबीएलएएस पैकेज, लैपैक पैकेज के साथ, बिना किसी समस्या के NumPy और SciPy दोनों के निर्माण में सक्षम प्रतीत होता है।

@mrslezak : मुझे बेंचमार्क के बारे में जानकारी कहां मिल सकती है? मैं scipy.org के लिए विंडोज़ से स्रोत के निर्माण पर दस्तावेज़ लिखने की कोशिश कर रहा हूं, और यह किसी भी व्यक्ति के लिए एक अच्छा संदर्भ होगा जिसे इन पुस्तकालयों के साथ प्रदर्शन की आवश्यकता है।

शायद बन्दूक का दृष्टिकोण सही विचार है? कुछ इस तरह:

• स्थिर: प्रदर्शन के साथ एटलस, sse2 चेतावनी
• देव: OpenBLAS मिंगवपी और बिनस्टार देखें
• Alt: MKL @cgohlke , MKL @continuum और @enthinkt
  चेतावनी: बायनेरिज़ संगत नहीं हैं।
  scipy और Matthew Brett's github numpy wiki पर अधिक जानकारी के लिए लिंक्स

@techtonik मैं उम्मीद करता हूं कि जीसीसी एमएसवीसी या आईसीसी से समकक्ष कोड पर कुछ हद तक खराब प्रदर्शन करेगी कि उन सभी कंपाइलर्स निर्माण करने में सक्षम हैं। मुद्दा एक मुफ्त (python.org-cpython-संगत) संकलक की कमी है जो लैपैक का एक प्रतिस्पर्धी संस्करण बना सकता है, जो कि फोरट्रान में है (SciPy में अन्य फोरट्रान घटक भी हैं)। ओपनबीएलएएस (और शायद एटलस भी) का शुद्ध बीएलएएस हिस्सा वास्तव में एमएसवीसी के साथ बनाया जा सकता है, लेकिन एमएसवीसी इनलाइन असेंबली की आवश्यकता वाले किसी भी टुकड़े का निर्माण नहीं कर सकता है, इसलिए यह प्रतिस्पर्धी नहीं होगा।

मेरे पास 64 बिट एमकेएल काम नहीं है (अगर मैं खुदाई करता हूं तो मेरे पास कोंडा से 32 बिट एक हो सकता है), लेकिन यहां कुछ बेंचमार्क हैं जो जूलिया में एटलस डीएल की तुलना करते हैं जो @ मैथ्यू-ब्रेट संदर्भ और रेतीले के खिलाफ बनाया गया है- BLIS के ब्रिज कॉन्फ़िगरेशन, और OpenBLAS बिल्ड जो जूलिया के साथ आता है https://gist.github.com/54da587b01b7fb163103

सारांश: ओपनब्लास (स्काइलेक पर, नवीनतम ओपनब्लास कर्नेल हैवेल है) एटलस से 23 गुना तेज, रेफरेंस ब्लिस से 44 गुना तेज और सैंडीब्रिज ब्लिस से 5.5 गुना तेज है। मैं यह देखने के लिए हैसवेल ब्लिस की कोशिश कर सकता हूं कि यह कितना करीब है।

हम - मुझे नहीं लगता कि आपने अपने बीएलआईएस संकलनों के लिए स्क्रिप्ट बनाई है?

क्या आपको लगता है कि बीएलआईएस को कई प्रकार के प्रोसेसर के लिए बनाना और रन-टाइम पर एक का चयन करना उचित होगा? क्या प्रोसेसर का एक छोटा उपसमुच्चय है जो अधिकांश प्रोसेसर के लिए अधिकांश प्रदर्शन को कैप्चर करेगा?

यह टिप्पणियों में है, लेकिन यहां (साइगविन 64 में चलाएं)

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

यहाँ वे उपलब्ध हैं: https://github.com/flame/blis/tree/master/config

इंटेल x86 के संदर्भ में, संदर्भ, डनिंगटन, सैंडीब्रिज और हैसवेल एक बहुत अच्छी रेंज को कवर करेंगे। एएमडी के लिए बुलडोजर, पाइलड्राइवर और कैरिज़ो भी (जिसने हाल ही में बीएलआईएस के पक्ष में एसीएमएल विकसित करना बंद कर दिया है, इसलिए यह कम से कम पक्ष में एक वोट है)।

https://github.com/ फ्लेम/ब्लिस/ट्री/मास्टर/बिल्ड/ऑटो-डिटेक्ट में कुछ ऑटो-डिटेक्शन कोड है जो पुन: प्रयोज्य हो सकता है (यह वर्तमान में केवल बीएलआईएस में कॉन्फ़िगर समय पर चलता है, लेकिन इसका मतलब यह नहीं है अन्य उद्देश्यों के लिए पुन: उपयोग नहीं किया जा सकता है), इस पर निर्भर करता है कि पाइथन में पहले से ही सीपीयू परिवार पहचान कोड का एक टुकड़ा है जिसका आप उपयोग करना चाहते हैं।

इस पर निर्भर करता है कि क्या पाइथन में पहले से ही सीपीयू परिवार पहचान कोड का एक टुकड़ा पड़ा हुआ है

क्या यह मदद करता है? http://stackoverflow.com/a/35154827/239247

आप ज्यादातर प्रोसेसर परिवार चाहते हैं जो उससे प्राप्त होता है, लेकिन https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c बिल्कुल लंबा या जटिल नहीं है। SO से जुड़ा numexpr स्रोत स्ट्रिंग आउटपुट (कम से कम लिनक्स पर) पर रेगेक्स मिलान कर रहा है, और ऐसा नहीं लगता है कि इसमें कई हालिया आर्किटेक्चर सूचीबद्ध हैं।

ओपनब्लास हैसवेल ब्लिस की तुलना में 3.4x तेज है, और डनिंगटन से 17x तेज है (मूल रूप से नेहलेम पेन्रीन जैसा मुझे लगता है) ब्लिस। दिलचस्प बात यह है कि मुझे नहीं लगता कि मल्टीथ्रेडिंग इन रनों पर आनंद में काम कर रही है। डिफ़ॉल्ट सेटअप सैंडीब्रिज और हैसवेल के लिए ओपनएमपी सक्षम करता है, शायद मिंगव पर्थ्रेड बेहतर काम करेगा। OMP_NUM_THREADS सेट करने से कोई खास फर्क नहीं पड़ा।

मेरा मानना ​​है कि एटलस 3.11 को 3.10 संस्करण की तुलना में 64 बिट पर बहुत बेहतर करना चाहिए, लेकिन मैं इस समय इसे नहीं बना सकता, क्लिंट व्हेल से कुछ मदद की उम्मीद कर रहा हूं।

टोनी - मुझे नहीं लगता कि आपके पास 32-बिट एटलस व्हील का परीक्षण करने के लिए समय/ऊर्जा है? इसे अपेक्षाकृत बहुत बेहतर करना चाहिए।

मेरी अपनी प्राथमिकता इन एटलस पहियों के साथ आगे बढ़ना है, इसलिए अन्य पैकेजर हम पर निर्भर हो सकते हैं कि हम किसी प्रकार के पहिये की शिपिंग कर रहे हैं। यदि हम प्रदर्शन को बेहतर बनाने का एक अच्छा तरीका निकालते हैं, तो हमारे पास जल्द ही एक नई अच्छी रिलीज आ रही है, और यहां तक ​​कि 1.10.4 के लिए भी हम पहियों को अपडेट करने के लिए हमेशा रखरखाव रिलीज कर सकते हैं।

@ मैथ्यू-ब्रेट: त्वरित प्रश्न, numpy साइगविन पर ATLAS बिल्ड का पता लगाने में सक्षम क्यों नहीं हो सकता है? मैं मूल विंडोज वातावरण में उन्हें पूरी तरह से ठीक करने में सक्षम था, लेकिन जब मैंने सिगविन में आपकी स्क्रिप्ट चलाने की कोशिश की, तो numpy ATLAS के साथ संकलित नहीं हुआ।

यदि आप सिग्विन के अजगर का उपयोग कर रहे हैं, तो आपको चीजों के अनुकूल होने के लिए एटलस के साइबरविन-निर्मित संस्करण की आवश्यकता होगी।

ऐसा लगता है कि 32 बिट जूलिया 32 बिट एटलस डीएल को खोलने में विफल रही है। निश्चित नहीं क्यों, शायद इसलिए कि हमारे पास पहले से ही 32 बिट ओपनब्लास हैं और प्रतीक नाम परस्पर विरोधी हैं?

लेकिन @ मैथ्यू-ब्रेट संस्करण सिगविन के साथ बनाया गया है, और इसलिए मैं उलझन में हूं।

सिग्विन पर्यावरण का निर्माण करता है, एक मिंगव लाइब्रेरी में क्रॉस-संकलित होता है। देखें कि यह cygwin1.dll के बजाय msvcrt.dll से कैसे जुड़ा है?

जैसे ही मैंने टिप्पणी पोस्ट की, मुझे अचानक संदेह हुआ कि यह मामला हो सकता है। काश, ऐसा लगता है कि मुझे इसे बिल्कुल नए सिरे से बनाना होगा। धन्यवाद @tkelman !

dlopen समस्या का पता चला (संदर्भ https://github.com/matthew-brett/np-wheel-builder/pull/1, और https://github.com/JuliaLang/julia/issues/15117 के उपयोगी संस्करण को छिपा रहा था त्रुटि संदेश)।

32 बिट पर, एटलस ओपनब्लास की तुलना में 3.6 गुना धीमा है। 32 बिट ओपनब्लास समान आकार की समस्या के लिए 64 बिट ओपनब्लास की तुलना में 3x धीमा है। नवीनतम कुछ कर्नेल परिवार 32 बिट सिस्टम पर openblas में सक्षम नहीं हैं।

...
अंत में: मुझे गंभीरता से पता नहीं है कि हमारा सबसे अच्छा विकल्प क्या है, लेकिन हमारे पैर की उंगलियों को बीएलआईएस पानी में चिपकाना एक अच्छा विचार है; अगर हम तय कर लें कि हम इंतजार करना चाहते हैं तो हम कम से कम कुछ तो सीखेंगे।

यह शायद उपयोगी है, कम से कम कुछ परीक्षण/बेंचमार्किंग। लेकिन इस समय यह हमारे _Windows_ मुद्दों से काफी हद तक असंबंधित है। BLIS इस समय केवल Linux है; ओएसएक्स बिल्ड समर्थन के लिए एक खुला पीआर है, और विंडोज़ बहुत दूर है। और इससे भी बदतर, मैंने कल 32-बिट लिनक्स पर कोशिश की और यहां तक ​​​​कि यह भी काम नहीं करता है। ./configure auto && make कुछ असेंबलर कोड ( sandybridge ) पर बुरी तरह दुर्घटनाग्रस्त हो जाता है। मैं केवल reference बना सकता हूं।

तो मुझे लगता है कि चरण 0 numpy.distutils में BLIS के लिए समर्थन जोड़ना है (जो कि ज्यादातर पहले से ही काम कर रहा है), चरण 1 लिनक्स पर परीक्षण करने के लिए यह देखने के लिए कि कम से कम reference काम करता है, चरण 2 कुछ बेंचमार्किंग, ..., कदमविंडोज़ पर कुछ।

@ मैथ्यू-ब्रेट ने पीईपीआई के लिए आपका प्रस्तावित पाठ मुझे ठीक लगता है। कौन से pip संस्करण ABI टैग वाले नाम को अनदेखा करते हैं? पिप आपको इन दिनों खुद को अपग्रेड करने के लिए बहुत परेशान करता है, इसलिए मुझे उम्मीद है कि बहुत से लोगों के पास नवीनतम संस्करण होगा। और संस्करण> 1 (.5) साल पुराने ने भी डिफ़ॉल्ट रूप से पहियों को स्थापित नहीं किया था।

@rgommers ऊपर मेरे परीक्षण विंडोज़ पर थे। एमएसवीसी नहीं, लेकिन मिंगवपी या ओपनब्लास वहां बहुत अलग नहीं करेंगे - क्लैंग शायद काम करेगा लेकिन सिम्लिंक से बचने के लिए ब्लिस में रेपो पुनर्गठन की जरूरत है।

मैंने जूलिया या numpy के परीक्षण ब्लिस के खिलाफ नहीं चलाए, लेकिन ब्लिस अपने स्वयं के यूनिट परीक्षण पास कर रहा था। 2014 से मेरे अनुभव की तुलना में चीजें बहुत बेहतर हुईं, मुझे यह सोचने के लिए प्रेरित किया कि वे करेंगे। अभी भी यह पता लगाने की जरूरत है कि मल्टीथ्रेडिंग को ठीक से काम करने के लिए कैसे प्राप्त किया जाए, लेकिन इसके साथ ही आपके पास ब्लिस पहले से ही प्रतिस्पर्धी प्रदर्शन हो सकता है।

ऐसा प्रतीत होता है कि संदर्भ कॉन्फिगरेशन ब्लिस में एकमात्र चीज है जो अभी 32 बिट x86 के लिए काम करती है। इसके लिए नए असेंबली माइक्रोकर्नेल लिखने की आवश्यकता होगी, मुझे विश्वास है कि शायद नहीं, नीचे एनजेस्मिथ की टिप्पणियां देखें।

@tkelman , 32 बिट के लिए OpenBLAS कर्नेल के विषय में https://github.com/numpy/numpy/issues/5479#issuecomment -185096062: एक priv. संदेश मुझे कुछ समय पहले वर्नर सार से मिला था, नए आर्किटेक्चर के लिए इंटेल 32 बिट कर्नेल पर कोई भी काम नहीं कर रहा है। तो यह एक ऐसा तथ्य है जिसके भविष्य में बदलने की संभावना नहीं है। फोकस इंटेल 64 बिट और एआरएम प्रोसेसर पर है।

@tkelman , सी-रनटाइम से संबंधित https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: IMHO यह महत्वपूर्ण नहीं है क्योंकि ATLAS और OpenBLAS C-रनटाइम (फ़ाइल डिस्क्रिप्टर और हीप) के संसाधनों को साझा नहीं करते हैं ) _उम्मीद है कि मैं सही हूँ_। यह एटलस बिल्ड के लिए स्टैकसाइज बढ़ाने के लिए उपयोगी हो सकता है। इसे जोड़ने के दौरान ध्वज के रूप में दिया जा सकता है, अर्थात:

-Wl,--stack,16777216

ATLAS बनाम OpenBLAS चर्चाओं के संबंध में: @matthew-brett के लिए धन्यवाद अब SSE2 आधारित ATLAS DLL उपलब्ध हैं। इस एटलस बिल्ड की तुलना सीपीयू रनटाइम डिटेक्शन को अक्षम करने के लिए SSE2 सक्षम लक्ष्य (या बस OPENBLAS_CORETYPE=NORTHWOOD - मूल रूप से PENTIUM4) के विरुद्ध OpenBLAS बिल्ड से की जानी चाहिए। बेशक एक सामान्य OpenBLAS बिल्ड CPU रनटाइम डिटेक्शन के लिए बहुत अधिक CPU वेरिएंट का फायदा उठा सकता है। यह एक कारण है कि OpenBLAS ATLAS की तुलना में अधिक प्रदर्शनकारी है। एक अन्य प्रश्न OpenBLAS की विश्वसनीयता का है। हो सकता है कि एकत्रित बीएलएएस, लैपैक परीक्षणों के साथ एक भंडार मदद कर सके।

बीएलआईएस/लौ से संबंधित: दिलचस्प, लेकिन कम से कम आज के लिए एक उच्च लटका हुआ फल।

हालांकि मेरे लिए एटलस और ओपनब्लास के बीच चयन करने का निर्णय लेना स्पष्ट नहीं है।

राल्फ - पाइप 8 नए विंडोज एबीआई टैग के साथ पहियों को स्थापित करेगा, पाइप 7 नहीं करेगा। पिप 7 और पिप 8 बिना किसी चेतावनी के, बिना एबीआई टैग के पहियों को स्थापित करेंगे।

वहाँ अभी भी बहुत सारे पाइप 7 हैं, इसे अगस्त 2015 में जारी किया गया था - इसलिए मैं कम से कम थोड़ी देर के लिए अधिक संगत नाम से चिपकना पसंद करूंगा।

बीएलआईएस की जांच पर +1। यह एक अच्छा दीर्घकालिक समाधान प्रतीत होता है। क्या हमने ईजिन पर बिल्कुल भी विचार किया है? वे आंशिक LAPACK इंटरफ़ेस के निर्माण का समर्थन करते हैं, और अधिकांश कोड के लिए लाइसेंस MPL2 है। यह NumPy के लिए काफी अच्छा हो सकता है।

मैंने बीएलआईएस सीपीयू डिटेक्शन कोड से देखा है कि यह अक्सर संदर्भ कार्यान्वयन पर वापस आ जाता है अगर इसे एवीएक्स निर्देश नहीं मिलते हैं, जो अभी भी हाल ही में हैं।

इयान: यह एक साल या उससे भी पहले ईजिन के लिए राज्य है: http://mingwpy.github.io/blas_lapack.html#eigen - तो मेरा मानना ​​​​है कि यह numpy के लिए उपयोग करने योग्य पुस्तकालय बनाने के लिए कुछ काम होगा।

और इससे भी बदतर, मैंने कल 32-बिट लिनक्स पर कोशिश की और यहां तक ​​​​कि यह भी काम नहीं करता है। ./configure auto && make कुछ कोडांतरक कोड (सैंडीब्रिज के लिए) पर बुरी तरह दुर्घटनाग्रस्त हो जाता है। मैं केवल संदर्भ बना सकता हूं।

यदि आप config/ की सामग्री को देखते हैं - विभिन्न नामित "कॉन्फ़िगरेशन" (जैसे "सैंडीब्रिज", "हैसवेल") वास्तव में पहले से पैक किए गए "स्टार्टर" कॉन्फ़िगरेशन हैं जिनमें पूर्व-निर्दिष्ट सेटिंग्स का एक समूह शामिल है (न केवल सीपीयू-ट्यूनिंग-संबंधित सेटिंग्स, लेकिन थ्रेडिंग मोड सेटिंग्स, कंपाइलर सेटिंग्स, आदि)। और "सैंडीब्रिज" नामक कॉन्फ़िगरेशन एक x86-64 कॉन्फ़िगरेशन है। एक बग की तरह लगता है कि ऑटो-कॉन्फ़िगरेशन ने इसे चुना है, लेकिन हाँ यह x86-32 :-) पर काम नहीं करेगा। BLIS 32-बिट x86 कर्नेल के साथ शिप करता प्रतीत होता है (देखें kernels/x86 ), हालांकि ऐसा लगता है कि इस समय कोई भी प्रीपैक्ड कॉन्फ़िगरेशन उनका उपयोग नहीं करता है। नए विन्यास बनाना ज्यादातर तुच्छ है; जादू का एक टुकड़ा bli_kernel.h फ़ाइल में है जो नाम देता है जो आंतरिक कर्नेल + कुछ बफर आकार। यदि उनके पास x86-32 के लिए कोई सुझाव है तो हम अपस्ट्रीम से पूछताछ कर सकते हैं।

भी:

BLIS इस समय केवल Linux है; OSX बिल्ड सपोर्ट के लिए एक खुला पीआर है, और विंडोज़ बहुत दूर है

ऊपर कुछ टिप्पणियां, @tkelman विंडोज़ पर बीएलआईएस का निर्माण और बेंचमार्किंग कर रही है :-)

OpenBLAS 0.2.12 के साथ पिछला कच्चा तेल test_dot बेंचमार्क:

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

(पिछले परिणाम से) एमकेएल की तुलना में

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

64-बिट एटलस:

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

तो जब मैं सीरियल में ओपनब्लास और एमकेएल (धन्यवाद, कोंडा) की तुलना हैसवेल बीएलआईएस कॉन्फ़िगरेशन से करता हूं, तो वे सभी डीजीएमएम पर एक-दूसरे के अधिकतम 10-20% के भीतर होते हैं। यहां एक डॉकरफाइल है जो प्रत्येक कॉन्फ़िगरेशन के विंडोज डीएल को क्रॉस-कंपाइल करने के लिए डॉकर हब पर सफलतापूर्वक बनाया गया है (बुलडोजर को छोड़कर जो ठीक से लिंक नहीं करता है https://github.com/flame/blis/pull/37#issuecomment-185480513, ओह वेल) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

आप ट्रैविस के services: docker कॉन्फ़िगरेशन के समान कुछ जोड़ने की कोशिश कर सकते हैं और जीथब रिलीज/बिंट्रे/जो कुछ भी करने के लिए बाइनरी कलाकृतियों को तैनात करने के साथ खेलते हैं।

मैं बीएलआईएस सीपीयू डिटेक्शन -> टेम्प्लेट कोड देख रहा था: https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

यहां एक पायथन पुनर्लेखन है, जो उन्नत टेम्पलेट्स में से एक को स्वीकार करने में थोड़ा अधिक उदार होना चाहिए (यह विश्वास करने की अधिक संभावना है कि ओएस सी कोड की तुलना में एवीएक्स का उपयोग कर सकता है): https://gist.github.com/matthew-brett /ए53778एफ99बी7062सीसी332डी

मेरे द्वारा परीक्षण की गई सभी मशीनों पर, यह एल्गोरिदम 'संदर्भ' देता है - शायद इसलिए कि मेरे पास पुरानी मशीनें हैं जिन्हें कोई और उपयोग नहीं करना चाहता था, मेरे बिल्डबॉट फार्म के बचाव के लिए।

संदर्भ बीएलआईएस के खिलाफ numpy संकलन, बिना किसी लैपैक के, मेरे कच्चे बेंचमार्क पर निम्नलिखित देता है:

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

बस दो (1000, 1000) सरणियों का डॉट उत्पाद 12 सेकंड है। इसलिए, जैसा कि टोनी ने भी पाया, संदर्भ बीएलआईएस हमारे विकल्पों में से सबसे खराब है, लैपैक_लाइट के साथ एक ही numpy के नो-लाइब्रेरी डिफ़ॉल्ट बिल्ड के आसपास।

इसलिए, मुझे लगता है कि हमें या तो पुरानी मशीनों को कवर करने वाले अधिक टेम्प्लेट की आवश्यकता होगी या अधिक उदार सीपीयू डिटेक्शन -> टेम्प्लेट मैपिंग की आवश्यकता होगी ताकि मशीनों की एक विस्तृत श्रृंखला पर उचित प्रदर्शन दिया जा सके।

@ मैथ्यू-ब्रेट हम कब उम्मीद कर सकते हैं कि नए एटलस 64-बिट विंडोज़ व्हील ऊपर होंगे? कौन सा संस्करण? v1.10.2? क्या वे केवल पीपीआई या सोर्स फोर्ज में होंगे? क्या आप किसी प्रकार की घोषणा करने जा रहे हैं? बहुत बहुत धन्यवाद!

@ मैथ्यू-ब्रेट एक ही मशीन पर आपके लिए एटलस और संदर्भ ब्लिस के बीच का अनुपात क्या था? मैं देख रहा था कि लगभग 2 के कारक की तुलना में? मुझे ब्लिस में काम करने के लिए मल्टीथ्रेडिंग मिली, मैंने अभी ठीक से आरटीएफएम नहीं किया (https://github.com/flame/blis/wiki/Multithreading), यह स्वचालित रूप से सक्षम नहीं है, और खेलने के लिए 4 अलग-अलग एनवी वर्र्स हैं . इस पैच के साथ https://gist.github.com/0fc9497a75411fcc0ec5 सभी कॉन्फ़िगरेशन के लिए pthreads-आधारित समानांतर ब्लिस को सक्षम करने और BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 सेट करने के लिए, हैसवेल ब्लिस मूल रूप से मेरी मशीन पर एमकेएल और ओपनब्लास से जुड़ा हुआ है। अगर मैं केवल BLIS_JR_NT से 2 सेट करता हूं तो समांतर संदर्भ आनंद एटलस तक पकड़ा जाने वाला अधिकांश तरीका है, और यह 3 धागे के साथ तेज़ है।

@tkelman IMO यह उपयोगी होगा यदि आप NumPy GitHub विकी पृष्ठों में BLIS पर अपनी प्रगति का दस्तावेजीकरण कर सकते हैं। मुझे यह भी लगता है कि NumPy-BLIS-FLAME व्हील (और यदि संभव हो तो SciPy-BLIS-FLAME व्हील) बनाने के लिए mingwpy जैसी योजना का प्रस्ताव करना दिलचस्प हो सकता है।

@tkelman : यह सुनिश्चित करने के लिए कि मैं स्पष्ट हूं - आपका एटलस थ्रेडेड है, है ना?
एक और बात पर विचार करना है -msse2 या reference बिल्ड सेटिंग्स के समान - ऐसा लगता है कि डिफ़ॉल्ट रूप से यह अधिकतम संगत है और संकलक को एसएसई का उपयोग करने की अनुमति नहीं देता है, लेकिन कम से कम में numpy-land मुझे पता है कि हम अन्य कारणों से वैसे भी न्यूनतम समर्थित कॉन्फ़िगरेशन के रूप में SSE2 तक बढ़ रहे हैं ...

मुझे नहीं पता कि फ्लेम अभी प्रासंगिक है या नहीं बनाम रेगुलर लैपैक -- हम पूछना चाहेंगे।

संभावित रूप से हमें इसे अव्यवस्थित करने के बजाय बीएलआईएस सामान के लिए एक नया मुद्दा खोलना चाहिए :-)

इस धागे के लिए - मुझे लगता है कि हम पहले से ही रन-टाइम पर चुने गए विभिन्न बीएलआईएस कर्नेल के साथ एक पहिया भेज सकते हैं जैसे बीएलआईएस बिल्ड-टाइम पर उपयोग करता है, लेकिन मुझे लगता है कि इसके परिणामस्वरूप बीएलआईएस संदर्भ वाली कई मशीनें होंगी, और इसलिए बदतर हो रही है 64-बिट एटलस की तुलना में प्रदर्शन, भले ही विंडोज़ पर 64-बिट एटलस विशेष रूप से खराब है (एटीएलएएस के लिए)।

लेकिन - यदि संदर्भ निर्माण 64-बिट एटलस से तेज है - -msse2 के साथ कहें - यह एक वास्तविक विकल्प होगा।

SSE2 64-बिट के लिए न्यूनतम कॉन्फ़िगरेशन है इसलिए संदर्भ संकलन के लिए -mfpmath=sse -msse2 जैसी किसी चीज़ का उपयोग करना सुरक्षित है।

संभावित रूप से हमें इसे अव्यवस्थित करने के बजाय बीएलआईएस सामान के लिए एक नया मुद्दा खोलना चाहिए :-)

यह एक अच्छा विचार होगा (संपादित करें: क्या मैं सुझाव दे सकता हूं कि इसे "ऑक्यूपाई बीएलआईएस" शीर्षक दिया जाए, जो कि https://github.com/numpy/numpy/issues/5479#issuecomment-184472378 में लॉन के बारे में @njsmith की भावना को देखते हुए है?) . मुझे लगता है कि @ मैथ्यू-ब्रेट अपने मौजूदा एटलस पहियों को अपलोड करने के साथ आगे बढ़ने के लिए इसे अभी के लिए बंद करने के लिए पर्याप्त होगा, भविष्य के काम को नए मुद्दों पर छोड़ दिया जाएगा।

यह सुनिश्चित करने के लिए कि मैं स्पष्ट हूं -- आपका एटलस थ्रेडेड है, है ना?

मेरा एटलस https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds से dll है, लेकिन मैंने अभी तक इसे सफलतापूर्वक 1 से अधिक थ्रेड का उपयोग करते हुए नहीं देखा है। क्या मुझे एक पर्यावरण चर याद आ रहा है?

एक और बात पर विचार करना है -msse2 या reference बिल्ड सेटिंग्स के समान - ऐसा लगता है कि डिफ़ॉल्ट रूप से यह अधिकतम संगत है और संकलक को एसएसई का उपयोग करने की अनुमति नहीं देता है

SSE2 x86_64 युक्ति का हिस्सा है, इसलिए यह केवल 32 बिट पर प्रासंगिक होगा। जूलिया में हम अपने 32 बिट बिल्ड के लिए -march=pentium4 जोड़ते हैं।

मुझे नहीं पता कि फ्लेम अभी प्रासंगिक है या नहीं बनाम रेगुलर लैपैक -- हम पूछना चाहेंगे।

अभी तक लौ को नहीं छुआ है, लेकिन यह खेलने लायक है। अंततः आप mingwpy के विकल्प के रूप में विन्डोज़ क्लैंग का उपयोग बैकअप योजना के रूप में करने में सक्षम हो सकते हैं। (संपादित करें: वास्तव में यह scipy में फोरट्रान को ठीक नहीं करता है, तो शायद नहीं)

@ मैथ्यू-ब्रेट: मुझे लगता है (गलत हो सकता है) dunnington कर्नेल को केवल SSE3 की आवश्यकता होती है, जो कि स्टीम हार्डवेयर सर्वेक्षण का दावा 99.94% मशीनों (SSE2 के लिए 99.99% बनाम) पर मौजूद है। तो यह गलत लगता है यदि आप पाते हैं कि अधिकांश सिस्टम इसे संभाल नहीं सकते हैं - यह नहीं पता कि यह उनके सीपीयू कोड में एक बग है, आपके किसी भी तरह परीक्षण मशीनों का वास्तव में गैर-प्रतिनिधित्वपूर्ण सेट है, या मेरी समझ में उस कर्नेल की क्या आवश्यकता है।

मैंने ऊपर दिए गए सार में सीपीयू डिटेक्शन कोड का एक पायथन रीराइट पोस्ट किया है। मैं अनुमान लगा रहा हूं कि टेम्पलेट चयन रूढ़िवादी है, संदर्भ के लिए डिफ़ॉल्ट जहां एक और टेम्पलेट काम कर सकता है।

खुद को याद दिलाने के लिए, BLIS से लिंक करने के लिए, मुझे एक site.cfg की आवश्यकता है जैसे:

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

मैंने यह भी किया, मुझे लगता है कि यह आवश्यक है (सुन्न 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):

सीपीयू के रन-टाइम डिटेक्शन की अनुमति देने के लिए उपयोगिता: https://github.com/matthew-brett/x86cpu

मुझे लगता है कि यह numpy में शामिल करने के लिए एक उम्मीदवार हो सकता है, लेकिन हम एकल संकलित cpuinfo मॉड्यूल को विंडोज व्हील के लिए numpy पेड़ में भी कॉपी कर सकते हैं।

नमस्ते। एक विचार: यदि आप विभिन्न वेक्टर पुस्तकालयों के साथ निर्मित कई अलग-अलग खस्ता पहियों को प्रकाशित करना चाहते हैं, तो आप विभिन्न PyPI पैकेज नामों का उपयोग कर सकते हैं

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

मैंने गोहलके के पहियों को अपलोड करने का प्रयास करने के लिए 2 पंजीकृत किए, लेकिन पीईपीआई ने उन्हें अस्वीकार कर दिया। यूआरएल में आपका स्वागत है।

gh-7294 numpy.distutils में BLIS समर्थन जोड़ता है। बहुत अच्छा होगा अगर कोई यह सत्यापित कर सके कि यह अपेक्षा के अनुरूप काम करता है।

वहाँ अभी भी बहुत सारे पाइप 7 हैं, इसे अगस्त 2015 में जारी किया गया था - इसलिए मैं कम से कम थोड़ी देर के लिए अधिक संगत नाम से चिपकना पसंद करूंगा।

पिप 7.0 अभी पुराना नहीं है, इसलिए समझ में आता है।

... बीएलआईएस 32-बिट x86 कर्नेल (कर्नेल/x86 देखें) के साथ शिप करता प्रतीत होता है, हालांकि ऐसा लगता है कि इस समय कोई भी प्रीपैकेज्ड कॉन्फ़िगरेशन उनका उपयोग नहीं करता है

यह इसे समझाता है, धन्यवाद।

धन्यवाद राल्फ - मैं परीक्षण करूँगा।

मुझे एहसास है कि इसे एक नए धागे की आवश्यकता हो सकती है, लेकिन अब हम रिलीज के लिए बीएलआईएस बिल्ड का उपयोग करने में सक्षम होने के बहुत करीब हैं।

मुझे लगता है कि अब हम सभी की जरूरत है एक मशीन के लिए अनुशंसित टेम्पलेट्स जिसमें एसएसई 2 है, और एक मशीन जो एसएसई 3 है, जो एटलस 64-बिट विंडोज बिल्ड से कुछ हद तक तेज काम करती है।

मुझे एहसास है कि इसे एक नए धागे की आवश्यकता हो सकती है, लेकिन अब हम रिलीज के लिए बीएलआईएस बिल्ड का उपयोग करने में सक्षम होने के बहुत करीब हैं।

एह, तकनीकी रूप से इसे काम करना संभव हो सकता है, लेकिन इस तरह की दीवार पर निर्माण फेंकने की अभी भी एक अच्छी योजना नहीं है। हमने अभी तक Linux या OS X पर BLIS का गंभीर परीक्षण भी नहीं किया है। तो विंडोज़ पर, जहां बीएलआईएस एफएक्यू कहता है :

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.

, यह निश्चित रूप से बहुत जल्दी है। परीक्षण के अलावा, कुछ बेंचमार्किंग भी एक अच्छा विचार है जो मुझे लगता है।

ज़रूर - लेकिन जैसा कि टोनी ने दिखाया है, क्रॉस-कंपाइलिंग का उपयोग करके विंडोज़ के लिए बीएलआईएस बनाना वास्तव में मुश्किल नहीं है। प्रयोगात्मक चीज - मेरा मानना ​​है - उनकी एमएसवीसी बिल्ड सिस्टम है, जिसका हम उपयोग नहीं कर रहे हैं।

अभी के लिए, मैं केवल विंडोज व्हील के लिए बीएलआईएस का उपयोग करने का सुझाव दे रहा हूं, लेकिन निश्चित रूप से यह बहुत अच्छा होगा कि यह कई लिनक्स बिल्ड के लिए भी काम करे।

मैं इस बात से पूरी तरह सहमत हूं कि, अगर हमें एक महत्वपूर्ण औसत प्रदर्शन बढ़ावा नहीं मिल रहा है, तो हमें बीएलआईएस का उपयोग नहीं करना चाहिए, और फिलहाल, मुझे नहीं लगता कि हम बहुत नए प्रोसेसर को छोड़कर हैं। यह कुछ नए टेम्पलेट्स के साथ मामूली रूप से ठीक करने योग्य हो सकता है, मुझे यह जानना अच्छा लगेगा कि क्या ऐसा था।

शुद्धता के लिए, मैं भी सहमत हूं। कैसा रहेगा अगर हम उसे दिखाएँ

ए) सभी सुन्न परीक्षण विंडोज के सभी संस्करणों पर पास होते हैं;
बी) सभी सुन्न और तीखे परीक्षण कई लिनक्स सिस्टम पर पास होते हैं?

हम रन-टाइम पर BLIS टेम्पलेट को चयन योग्य बना सकते हैं, और एक आधुनिक मशीन पर सभी कर्नेल का परीक्षण कर सकते हैं। मैं कुछ पुरानी खराब मशीनों पर भी परीक्षण कर सकता हूं।

अभी के लिए, मैं केवल विंडोज व्हील के लिए बीएलआईएस का उपयोग करने का सुझाव दे रहा हूं, लेकिन निश्चित रूप से यह बहुत अच्छा होगा कि यह कई लिनक्स बिल्ड के लिए भी काम करे।

मुझे लगता है कि manylinux कम महत्वपूर्ण है, क्योंकि हमारे पास एक पूर्ण स्टैक के साथ पैकेज मैनेजर हैं और साथ ही ऐसे उपयोगकर्ता भी हैं जो चीजों को आसानी से संकलित कर सकते हैं। इससे पहले कि हम इस numpy + BLAS/LAPACK संदर्भ में इसके बारे में चिंता करें, आइए पहले पूरी कई लिनक्स अवधारणा को देखें :)

विंडोज़ के लिए, मुझे लगता है कि हमारे प्रिय हैं:

1) एक पूर्ण-स्टैक समाधान (ओपनब्लास/एटीएलएएस/बीएलआईएस में से एक के साथ मिंगवपी की जरूरत है)
2) स्टॉपगैप बाइनरी व्हील्स (हमारे पास आपके एटलस बिल्ड के साथ ऊपर जाने वाला है)
3) (1) के प्रदर्शन में वृद्धि। यहीं पर बीएलआईएस आ सकता है।

तो इम्हो विंडोज़ पर बीएलआईएस के साथ बड़ी भीड़ में होने की जरूरत नहीं है।

मैं इस बात से पूरी तरह सहमत हूं कि, अगर हमें एक महत्वपूर्ण औसत प्रदर्शन बढ़ावा नहीं मिल रहा है, तो हमें बीएलआईएस का उपयोग नहीं करना चाहिए, और फिलहाल, मुझे नहीं लगता कि हम बहुत नए प्रोसेसर को छोड़कर हैं। यह कुछ नए टेम्पलेट्स के साथ मामूली रूप से ठीक करने योग्य हो सकता है, मुझे यह जानना अच्छा लगेगा कि क्या ऐसा था।

सहमत हूं, इसे समझने के लिए एक महत्वपूर्ण लाभ होना चाहिए। यह देखना थोड़ा कठिन है कि वास्तव में कितना काम करने की आवश्यकता है।

शुद्धता के लिए, मैं भी सहमत हूं। कैसा रहेगा अगर हम उसे दिखाएँ

ए) सभी सुन्न परीक्षण विंडोज के सभी संस्करणों पर पास होते हैं;
बी) सभी सुन्न और तीखे परीक्षण कई लिनक्स सिस्टम पर पास होते हैं?

यह अच्छा रहेगा। scikit-learn को भी शामिल करना समझदारी होगी, यह एक बहुत ही महत्वपूर्ण linalg उपयोगकर्ता है।

मुझे नहीं पता था कि ब्लिस और लिबफ्लेम एसीएमएल कोडबेस का हिस्सा रहे हैं, जिसे कुछ समय पहले ओपन सोर्स किया गया है:

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/

फिर भी: कई सीपीयू आर्किटेक्चर पर परीक्षण करने के लिए एमएसवीसी या मिंगवपी के साथ numpy/scipy निर्माण के लिए 4 अलग-अलग त्वरित बीएलएएस/लैपैक कार्यान्वयन की तुलना करने के लिए समस्या को कैसे हल करें: पेंटियम 4 स्काईलेक तक?

अच्छा लगा @carlk , मैंने उन्हें acml छोड़ने और acl को खोलने की घोषणा करते हुए देखा, लेकिन मुझे उन्हें blis/libflame अपनाने की याद नहीं आई। बीएसडी लाइसेंस बहुत अच्छी खबर है! क्या सुन्न और जूलिया को लक्षित करने के लिए ऑस्टिन में एएमडी और एसपीसी के साथ काम करने के लिए कोई रास्ता है?

मैं बॉक्स के बाहर msys2 और हैसवेल कॉन्फिगरेशन का उपयोग करके libblis.a को संकलित करने में सक्षम था और कर्नेल सिम्लिंक को पैच करके सभी परीक्षण पास कर रहा था, लेकिन मैं libflame नहीं बना सका - मुझे वही "तर्क सूची लंबी" त्रुटि मिली मेरी परमानंद-चर्चा मेलिंग सूची पोस्ट। इसके अलावा, मैं व्यक्तिगत रूप से यह नहीं समझ सका कि लैपैक से libblis.a से कैसे लिंक किया जाए, लेकिन मैंने बहुत मेहनत नहीं की।

एमकेएल के सामुदायिक लाइसेंस के साथ, क्या पीपीआई पर एमकेएल व्हील प्रदान करना संभव नहीं है, क्या लाइसेंस वास्तव में असंगत हैं? या इफोर्ट के बिना सिप्पी बनाना संभव नहीं है?

एक मुद्दा, और यह शायद scipy से संबंधित है, जिसका उल्लेख नहीं किया गया है scipy में शेष फोरट्रान फ़ाइलें हैं। नोब प्रश्न के लिए खेद है, लेकिन हमें उनका उपयोग क्यों करना चाहिए? मेरे लिए ऐसा लगता है कि फोरट्रान, और एक मुफ्त मल्टीप्लाफ्फ़्ट कंपाइलर की कमी, यहां असली मुद्दा है। क्या मिंगवपी का उद्देश्य हल करना नहीं है। या तो मुफ्त एमकेएल या कुछ भविष्य के जादू एसीएल ब्लिस/लौ को देखते हुए सी-कंपाइलर वाला कोई भी व्यक्ति * .f फाइलों के लिए नहीं था।

@mikofski , सुनकर बहुत अच्छा लगा, कि आनंद को msys2 के साथ संकलित किया जा सकता है। क्या यह लिबफ्लेम के लिए भी सही है? मुझे लगता है कि हमें लैपैक एपीआई के लिए libflame की आवश्यकता है।
व्यक्तिगत रूप से _यह संभव है कि एक एमएसवीसी संकलित numpy हो और इसे एक मिंगवपी संकलित scipy के साथ एक साथ उपयोग करें। लंबे डबल्स == डबल को सुनिश्चित करने के लिए आपको जीसीसी झंडे में -mlong-double-64 जोड़ना होगा।

इस व्यवहार को जीसीसी पर डिफ़ॉल्ट बनाना मुश्किल है, मैं एक सप्ताह से इस समस्या पर खेल रहा हूं :(

मैं कल scipy पहियों के साथ आऊंगा। ये @matthew-brett के सुन्न पहियों द्वारा प्रदान किए गए एटलस पर आधारित होंगे।

फिर भी, मैं अभी OpenBLAS का उपयोग करने के पक्ष में हूं।

एक मुद्दा, और यह शायद scipy से संबंधित है, जिसका उल्लेख नहीं किया गया है scipy में शेष फोरट्रान फ़ाइलें हैं। नोब प्रश्न के लिए खेद है, लेकिन हमें उनका उपयोग क्यों करना चाहिए?

क्योंकि यह बहुत उपयोगी और उच्च-प्रदर्शन कोड है। और यह सिर्फ BLAS/LAPACK नहीं है - बहुत सारे scipy.sparse.linalg , scipy.linalg , scipy.special और scipy.interpolate उदाहरण के लिए फोरट्रान है। इसके अलावा, फोरट्रान कोड के साथ Scipy एकमात्र परियोजना नहीं है, bvp_solver जैसे अन्य पैकेज के साथ-साथ लोगों के अपने फोरट्रान कोड भी हैं जिन्हें उन्होंने f2py के साथ लपेटा है।

वास्तव में, कार्ल को अच्छा लगा।

फिर भी: कई सीपीयू आर्किटेक्चर पर परीक्षण करने के लिए एमएसवीसी या मिंगवपी के साथ numpy/scipy निर्माण के लिए 4 अलग-अलग त्वरित बीएलएएस/लैपैक कार्यान्वयन की तुलना करने के लिए समस्या को कैसे हल करें: पेंटियम 4 स्काईलेक तक?

इसके लिए वास्तव में एक सभ्य स्वचालित निर्माण/परीक्षण/बेंचमार्क ढांचे की आवश्यकता होती है। हमें बहुत पुराने सीपीयू आर्किटेक्चर से परेशान होने की ज़रूरत नहीं है (जब तक चीजें वहां काम करती हैं तो यह ठीक है) और एमएसवीसी के साथ भी मुझे नहीं लगता। लेकिन फिर भी इसे ठीक से सेट करने के लिए कुछ काम होगा।

@rgommers धन्यवाद!

नमस्ते। एक विचार: यदि आप विभिन्न वेक्टर पुस्तकालयों के साथ निर्मित कई अलग-अलग खस्ता पहियों को प्रकाशित करना चाहते हैं, तो आप विभिन्न PyPI पैकेज नामों का उपयोग कर सकते हैं

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

मैंने गोहलके के पहियों को अपलोड करने का प्रयास करने के लिए 2 पंजीकृत किए, लेकिन पीईपीआई ने उन्हें अस्वीकार कर दिया। यूआरएल में आपका स्वागत है।

@hickford कृपया ऐसा मत करो। यह इस तरह के बायनेरिज़ को पुनर्वितरित करने के लिए एमकेएल लाइसेंस को तोड़ रहा है (जब तक कि आपके पास व्यक्तिगत लाइसेंस न हो), और ऐसा करने का यह सही तरीका नहीं है। भविष्य में हम अतिरिक्त ( numpy[atlas] , numpy[openblas] आदि) के माध्यम से कुछ स्वाद वितरित करना चाह सकते हैं।

साथ ही, पीपीपीआई पर किसी और के पहियों को बिना पूछे पुनर्वितरित करना शायद ऐसा करने की बात नहीं है ....

Mingwpy और कोई भी फोरट्रान मुद्दे जो cpython के समान c रनटाइम से लिंक करने पर निर्भर हैं, @carlkl पर सीमित हैं, BLIS के साथ प्रयोग करने से कम समस्याएं हल होती हैं लेकिन किसी के द्वारा स्वतंत्र रूप से किया जा सकता है। दुर्भाग्य से मैंने अभी BLIS को देखने के लिए अपना व्यक्तिगत समय समाप्त कर दिया है, लेकिन #7294 देखें।

टोनी - आपकी सभी मदद के लिए बहुत बहुत धन्यवाद, यह अमूल्य रहा है।

मैंने 64-बिट्स पर बाद में एटलस (3.11.38) का निर्माण जोड़ा

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

विंडोज़ पर 3.11.38 को संकलित करने में समस्याओं के कारण यह एक धारावाहिक (बिना पढ़े) निर्माण है, लेकिन यह 3.10.1 से थोड़ा तेज होना चाहिए, और यह मेरे साधारण बेंचमार्क पर है:

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

पहले के 3.10.1 बिल्ड की तुलना में (ऊपर देखें):

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

@tkelman - क्या आप इस बिल्ड को जूलिया पर बेंचमार्क कर सकते हैं?

एमकेएल बायनेरिज़ पर एक पूर्व नोट के साथ यहां कूदने के लिए खेद है - इंटेल प्रदान करता है
सामुदायिक संस्करण जिसे पुनर्वितरण की अनुमति देनी चाहिए क्योंकि यह सभी के लिए मुफ़्त है ...
2 मार्च 2016 को अपराह्न 3:08 बजे, "मैथ्यू ब्रेट" नोटिफिकेशन @github.com ने लिखा:

मैंने 64-बिट्स पर बाद में एटलस (3.11.38) का निर्माण जोड़ा

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

3.11.38 . को संकलित करने में समस्या के कारण यह एक धारावाहिक (बिना पिरोया हुआ) निर्माण है
विंडोज़ पर, लेकिन यह 3.10.1 से थोड़ा तेज होना चाहिए, और यह मेरे सरल पर है
तल चिह्न:

में [2]: %timeit test_dot()
1 लूप, सर्वोत्तम 3: 1.65 सेकेंड प्रति लूप

पहले के 3.10.1 बिल्ड की तुलना में (ऊपर देखें):

[10] में: %timeit test_dot()
1 लूप, सर्वोत्तम 3: 2.41 s प्रति लूप

@tkelman https://github.com/tkelman - क्या आप इस बिल्ड को बेंचमार्क कर सकते हैं
जूलिया?

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -191431331।

@mrslezak - लाइसेंस पुनर्वितरण की अनुमति देता है, लेकिन अगर सॉफ़्टवेयर का उपयोग करने के परिणामस्वरूप इंटेल पर मुकदमा चलाया जाता है तो पुनर्वितरणकर्ता को किसी भी कानूनी शुल्क के लिए उत्तरदायी बनाता है। साथ ही, परिणामी बाइनरी बीएसडी लाइसेंस प्राप्त नहीं हो सकती है। देखें: http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

क्या इसे 'बशर्ते जैसा है, बिना किसी दायित्व के' जोड़कर टाला जा सकता है
मौद्रिक नुकसान जो इसके उपयोग से हो सकता है' या इससे प्रभावित होने वाली कोई चीज?
2 मार्च 2016 को शाम 6:22 बजे, "मैथ्यू ब्रेट" नोटिफिकेशन @github.com ने लिखा:

@mrslezak https://github.com/mrslezak - लाइसेंस अनुमति देता है
पुनर्वितरण, लेकिन पुनर्वितरणकर्ता को किसी भी कानूनी शुल्क के लिए उत्तरदायी बनाता है यदि
सॉफ्टवेयर का उपयोग करने के परिणामस्वरूप इंटेल पर मुकदमा चलाया जाता है। इसके अलावा, परिणामी
बाइनरी बीएसडी लाइसेंस प्राप्त नहीं हो सकता। देखो:
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -191505500।

मुझे नहीं लगता कि यह काम करेगा, क्योंकि हमें इंटेल के लाइसेंस के लिए सहमत होना होगा, और इंटेल का लाइसेंस कहता है कि अगर वे मुकदमा करते हैं तो हम उनकी कानूनी फीस के लिए उत्तरदायी हैं। मुझे लगता है कि हमें अपने लाइसेंस समझौते में उपयोगकर्ताओं को इंटेल पर मुकदमा नहीं करने की आवश्यकता हो सकती है, और इसलिए हो सकता है, अगर वे इंटेल पर मुकदमा करते हैं, और इंटेल हमसे पैसे मांगता है, तो हम उन शुल्कों के लिए उपयोगकर्ता पर मुकदमा कर सकते हैं, लेकिन फिर भी - इसे हमारे ऊपर डालते हुए लाइसेंस हमें बीएसडी से और भी आगे ले जाएगा, और हमें उपयोगकर्ता से स्पष्ट रूप से सहमत होने की आवश्यकता होगी, जो कि पाइप द्वारा स्थापित पहियों के मामले में व्यावहारिक नहीं है।

SSE3 के लिए ATLAS का निर्माण SSE2 ATLAS की तुलना में केवल 5% प्रदर्शन लाभ देता है, लेकिन निर्माण मुश्किल था और मुझे SSE3 के लिए सबसे स्पष्ट सक्षम फ़्लैग को अक्षम करना पड़ा और बस -msse3 का उपयोग करना पड़ा।

मैंने इन पहियों को तैनात करने का प्रस्ताव करते हुए खस्ता मेलिंग सूची को एक मेल लिखा: https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@ मैथ्यू-ब्रेट किसी ऐसे व्यक्ति के रूप में जो पाइथन अनुप्रयोगों के साथ विंडोज़ का समर्थन करता है, धन्यवाद।

@ मैथ्यू-ब्रेट, मैंने आपके एटलस-बिल्ड-स्क्रिप्ट रिपॉजिटरी में 2 मुद्दे जोड़े हैं।
देखें https://github.com/matthew-brett/atlas-build-scripts/issues

पहला https://github.com/matthew-brett/atlas-build-scripts/issues/1 महत्वपूर्ण है, क्योंकि numpy-atlas.dll अधिक प्रतीकों को निर्यात करता है और इस प्रकार आयात की हैकिंग के बिना mingwpy के साथ आगे के उपयोग को रोकता है। पुस्तकालय।

@ मैथ्यू-ब्रेट क्षमा करें, मैं और अधिक बेंचमार्किंग करने में थोड़ा व्यस्त हूं। क्या पहले का कोई एटलस बिल्ड मल्टीथ्रेडेड था? मैं कई कोर पर चलने वाला पहला निर्माण नहीं कर पा रहा था। यदि आप जूलिया से बहुत परिचित नहीं हैं, तो भी चलाने के लिए सार बहुत सीधा होना चाहिए। या आपकी पहुंच से अधिक नए हार्डवेयर में आपकी रुचि थी?

चिंता न करें - आपसे यह उम्मीद नहीं थी कि आप सब कुछ छोड़ देंगे और बेंचमार्क चलाएंगे।

असल में मेरा नवीनतम एटलस बिल्ड मल्टीथ्रेडेड नहीं था - एटलस 3.11 को विंडोज़ पर थ्रेडिंग को स्पष्ट रूप से काम करने के लिए कुछ और काम करने की ज़रूरत है।

बेंचमार्क के लिए, मैं सोच रहा था कि आपके द्वारा चलाए गए अन्य बेंचमार्क की तुलना में तुलना करना आसान होगा, और मेरे पास केवल विंडोज़ के साथ पुराना हार्डवेयर है - मुझे लगता है कि मेरी तुलना में आपकी मशीन पर हिट बहुत अधिक है।

विंडोज़ व्हील अब पीपीआई पर हैं: https://pypi.python.org/pypi/numpy/1.10.4

क्षमा करें टोनी - हाँ पिछले 3.10 एटलस बिल्ड (या प्रतीत होते हैं) मल्टीथ्रेडेड थे।

मुझे लगता है कि अब हम इस मुद्दे को बंद कर सकते हैं। हो सकता है कि @ मैथ्यू-ब्रेट आपको अपने https://github.com/matthew-brett/np-wheel-builder को numpy org के तहत स्थानांतरित करना चाहिए या हो सकता है कि इसे टूल फ़ोल्डर के तहत numpy रेपो में पीआर के रूप में योगदान दें।

राल्फ - np-wheel-builder कहां जाना चाहिए इसके बारे में कोई सुझाव? सुन्न/विक्रेता शायद?

मुझे लगता है कि numpy org के तहत मैं एक अलग नया रेपो ( numpy-wheel-builder ?) पसंद करूंगा। उद्देश्य में numpy-vendor के साथ ओवरलैप है, लेकिन कोड में बहुत कुछ नहीं है। वह रेपो काफी बड़ा है, वास्तव में वाइन के तहत चलने के लिए है, और इसमें जीसीसी टूलचेन अप्रचलित है।

मेरे साथ ठीक है - ठीक है कि आप आगे बढ़ें और इसे बनाएं?

मेरे साथ ठीक है, हालांकि अगर यह विंडोज़-विशिष्ट है (अभी यह AFAICT है?) तो रेपो नाम में "विंडोज़" होना चाहिए :-)। या फिर यह हो सकता है कि हम अन्य पहियों के लिए भी समान आधारभूत संरचना डालते हैं। मैं इसे सीधे numpy रेपो में कहीं भी डालने के साथ ठीक हूं अगर यह समझने के लिए काफी छोटा है। जो कुछ भी काम करता है :-)

रेपो में काफी बड़ी एटलस बायनेरिज़ हैं, मुझे लगता है कि अच्छे उद्देश्य के लिए numpy रेपो बड़ा नहीं होगा।

कैसे के बारे में win-wheel-builder ?

कैसे के बारे में windows-wheel-builder । मैं win का प्रशंसक नहीं हूं;)

इसे विंडोज़ विशिष्ट न बनाने और macosx और भविष्य के कई linux1 व्हील बिल्ड कॉन्फ़िग को एक ही स्थान पर रखने के बारे में क्या?

अन्यथा "जीत" पर "विंडोज़" के लिए +1।

इसे विंडोज़ विशिष्ट न बनाने और macosx और भविष्य के कई linux1 व्हील बिल्ड कॉन्फ़िग को एक ही स्थान पर रखने के बारे में क्या?

सभी प्लेटफॉर्म पर चीजों को बदलना आसान होगा। लेकिन मैं उम्मीद करता हूं कि ओएस एक्स और लिनक्स को केवल स्क्रिप्ट बनाने की आवश्यकता होगी, जबकि विंडोज़ के लिए हमारे पास विशाल एटलस बाइनरी हैं। यदि यह सब एक रेपो में जा रहा है, तो क्या एटलस बायनेरिज़ को किसी तरह अलग किया जा सकता है (शायद गिट-एलएफएस के साथ)?

बायनेरिज़ के लिए जीथब पर बड़ी फ़ाइल संग्रहण (एलएफएस) का प्रयोग करें

@rgommers : मुझे लगता है कि हम जल्द ही लिनक्स के लिए एटलस-या-कुछ-अन्य-ब्लास बायनेरिज़ भी ले जाएंगे, और संभवतः ओएसएक्स भी (उदाहरण के लिए यदि हम तय करते हैं कि हम मल्टीप्रोसेसिंग को तोड़ने में तेजी लाने के थक गए हैं)।

जीथब रिलीज या बिंट्रे या कुछ का उपयोग शुरू करने के बजाय उन्हें चेक करना शुरू कर सकता है ... ऐसा नहीं है कि वे सभी बड़े हैं, हालांकि जब तक आप DYNAMIC_ARCH सक्षम ओपनब्लास बिल्ड या एकाधिक ब्लिस कॉन्फ़िगरेशन के समकक्ष संयोजन में शामिल नहीं हो जाते हैं

रेपो को अभी के लिए windows-wheel-builder के रूप में कैसे रखा जाए, और जब यह अधिक स्पष्ट हो कि हम लिनक्स/ओएसएक्स के साथ क्या करने जा रहे हैं तो रिफैक्टरिंग/नाम बदलना?

मुझे अच्छा लगता है।

मेरे साथ भी ठीक है

मुझे लगता है कि मुझे सुन्न संगठन के लिए व्यवस्थापकीय अधिकार चाहिए - या मैं दे सकता हूं
मुझे लगता है कि कोई व्यक्ति रेपो का अधिकार रखता है, और वे इसे कर सकते हैं।​

@ मैथ्यू-ब्रेट: मैं जीथब के अनुमति पृष्ठ से बहुत उलझन में हूं (और विशेष रूप से numpy एक गड़बड़ है), लेकिन अगर आप मुझे रेपो पर एक व्यवस्थापक बनाना चाहते हैं या रेपो को मेरे पास स्थानांतरित करना चाहते हैं तो मैं इसे numpy/

मैंने रेपो को @njsmith में स्थानांतरित कर दिया ...

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

क्या कोई सुन्न ऐपवेयर खाता है? क्या कोई इस रेपो के लिए Appveyor बिल्ड को सक्षम कर सकता है?

मुझे लगता है कि हम @charris के Appveyor खाते का उपयोग कर रहे हैं...

हाँ, यहाँ देखें https://ci.appveyor.com/project/charris/numpy/history

बुध, मार्च 16, 2016 पूर्वाह्न 12:15 बजे, नथानिएल जे. स्मिथ <
सूचनाएं@github.com> ने लिखा:

मुझे लगता है कि हम @charris https://github.com/charris के Appveyor का उपयोग कर रहे हैं
कारण...

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

असल में, मैंने ऐपवेयर पर numpy के लिए अभी एक नया समूह खाता बनाया है (वैसे भी ऐसा करने का अर्थ है, और इसने मुझे वास्तव में ऐसा करने के लिए प्रेरित किया :-)), और इसे वहां सक्षम किया:
https://ci.appveyor.com/project/numpy/windows-wheel-builder

@njsmith आपने इसे कैसे प्रबंधित किया? अंत में मैंने देखा कि किसी को व्यवस्थापकों से प्रोजेक्ट खाते बनाने के लिए कहने की आवश्यकता है और दूसरों को इसमें जोड़ने का तरीका पूरी तरह से पारदर्शी नहीं था।

यदि खाता काम करता है, तो मैं सुन्न परीक्षण के लिए जिम्मेदारी हस्तांतरित करना चाहता हूं।

@charris : अपना ईमेल जांचें :-)। मैंने अभी-अभी numpy-steering-council @googlegroups.com पर एक व्यक्ति के रूप में एक व्यक्तिगत खाता बनाया है। मुझे नहीं पता था कि प्रोजेक्ट खाते मौजूद थे... क्या हमें एक चाहिए?

कतार के लिए आप शायद अलग-अलग खातों पर अलग-अलग प्रोजेक्ट फैलाना चाहते हैं

सुन्न-स्टीयरिंग-काउंसिल मेल का उपयोग करने का नकारात्मक पक्ष यह है कि मर्ज परीक्षण विफल होने पर ऐप्वेयर सूचनाएं भेजता है। अगर ऐपवेयर लोगों के पास इन दिनों कुछ बेहतर है तो इसका इस्तेमाल करना अच्छा होगा, लेकिन गड़बड़ी को देखते हुए उनका इंटरफ़ेस अतीत में रहा है, मैं उस पर शर्त नहीं लगाऊंगा।

@tkelman अच्छा बिंदु। इसके अलावा, अगर हम तेजी से कतार पाने के लिए पैसा खर्च करने जा रहे हैं तो हम शायद कुछ और आधिकारिक चाहते हैं।

@charris : मैंने अभी नए appveyor खाते में numpy/numpy के परीक्षण को सक्षम करने का प्रयास किया है, और सभी सूचनाओं को अक्षम करने के लिए, और खाते पर व्यवस्थापन के रूप में सभी प्रासंगिक numpy github टीमों को भी जोड़ने का प्रयास किया है - आइए देखें कि क्या होता है I अनुमान...

@ मैथ्यू-ब्रेट: यह मेरे लिए होता है कि बीएलएएस को कहीं भी numpy/windows-build-tools की तरह छिपाने के लिए सबसे सुंदर दृष्टिकोण हो सकता है, लेकिन वास्तविक व्हील बिल्ड टूल्स को वास्तविक numpy/numpy रिपॉजिटरी से बाहर चलाने के लिए एपवियर बिल्ड का हिस्सा - वे मांग पर बीएलएएस बायनेरिज़ को नीचे खींच सकते हैं।

सभी महान कार्यों के लिए धन्यवाद! क्या numpy 1.11.0 विंडो व्हील जल्द ही pypi में जोड़े जाएंगे? https://pypi.python.org/pypi/numpy

ओह हाँ, हमें संभवतः यह पता लगाने की आवश्यकता है कि हमारी रिलीज़ प्रक्रियाओं को यहाँ कैसे अपडेट किया जाए... IIUC का अभी उपयोगकर्ता अनुभव यह है कि जैसे ही 1.11 स्रोत रिलीज़ को अपलोड किया गया, वहाँ की सभी विंडोज़ मशीनें अचानक डाउनलोडिंग व्हील्स से स्विच हो गईं (याय) ) स्रोत (बू) को डाउनलोड करने और बनाने का प्रयास करने के लिए। मुझे लगता है कि ऐसा करने का "सही" तरीका यह है कि एक बार अंतिम रिलीज को टैग करने के बाद, हम sdist को अपलोड करने से पहले _before_ सभी बाइनरी व्हील्स का निर्माण और अपलोड करते हैं। उतना ही परेशान करने वाला...

@njsmith जो अच्छा होगा, लेकिन कुछ मिनट अंतराल (या यहां तक ​​​​कि कुछ घंटे) अंतराल मेरे साथ ठीक रहेगा।

एटलस के खिलाफ 1.11.0 रिलीज बिल्ड के लिए पीईपीआई पर मौजूदा विंडोज़ डब्ल्यूएलएल फाइलें स्पष्ट करने के लिए बस स्पष्ट हैं? क्या कोई बिल्ड स्क्रिप्ट है जिसे साझा किया जा सकता है?

हां, पहियों को एटलस के खिलाफ बनाया गया है, लेकिन जब हम परिणामों के बारे में आश्वस्त होते हैं तो हम ओपनबीएलएएस में जाने की सोच रहे हैं।

बिल्ड को Appveyor के माध्यम से स्वचालित किया गया है: https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day । =)

hidden रिलीज बनाना संभव हो सकता है - कम से कम पीपीपीआई फॉर्म https://pypi.python.org/pypi?%3Aaction=submit_form पर एक विकल्प है और सभी फाइलें तैयार होने पर इसे अनहाइड करें।

अफसोस की बात है कि छिपी हुई रिलीज़ सुविधा लोगों को कमांड लाइन के माध्यम से उस रिलीज़ को प्राप्त करने से रोकती है, यह केवल उन्हें pypi GUI के माध्यम से रिलीज़ को देखना बंद कर देती है:

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

मैंने 64-बिट विंडोज़ स्थापित करने की कोशिश की है और यह बहुत अच्छा काम करता है, इसलिए उन सभी को धन्यवाद जिन्होंने इस पर काम किया है।

मैं क्या सोच रहा हूं कि क्या अभी भी वही काम करने की योजना है जो कि scipy व्हील्स के साथ है? क्या यह OpenBLAS में जाने के निर्णय की प्रतीक्षा कर रहा है?

https://bitbucket.org/carlkl/mingw-w64-for-python/downloads पर scipy-0.17.0 के कुछ परीक्षण पहिए हैं। इन पहियों को mingwpy के साथ @matthew-brett के बिल्ड ऑफ numpy https://pypi.python.org/pypi/numpy/1.10.4 के खिलाफ बनाया गया है।

गुरु, 28 अप्रैल, 2016 को दोपहर 12:48 बजे, carlkl [email protected] ने लिखा:

https://bitbucket.org/carlkl/mingw-w64-for-python/downloads पर हैं
scipy-0.17.0 के कुछ परीक्षण पहिए। इन पहियों का निर्माण किया गया है
@ मैथ्यू-ब्रेट के खिलाफ mingwpy https://github.com/matthew-brett 's
खस्ता बनाता है https://pypi.python.org/pypi/numpy/1.10.4

क्षमा करें यदि आपने पहले ही कहा था, और मैंने इसे याद किया - लेकिन क्या आपको कोई परीक्षण मिलता है?
इन पहियों के लिए विफलताएं?

क्या आप नुकीले पहियों के अंदर भेजे गए एटलस से लिंक कर रहे हैं?

@ मैथ्यू-ब्रेट, मैंने एक महीने पहले इन बिल्डों की घोषणा की थी, लेकिन मुझे याद नहीं है कि कहां है। वैसे भी, ये आपके सुन्न पहियों द्वारा आपूर्ति किए गए numpy-atlas के खिलाफ लिंक बनाता है।

scipy-0.17.0-cp35-cp35m-win##.whl _wrong_ C-runtime msvcrt.dll से जुड़े हुए हैं। scipy के लिए यह ठीक लगता है। परीक्षण लॉग यहाँ हैं: https://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

क्या यह सही लॉग है? इसके अंत में NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy है।

मैं सोच रहा था कि क्या हम एक डरावना पहिया प्रदान करने में सक्षम होने के करीब हैं, भले ही यह गलत एमएसवीसी रनटाइम के खिलाफ खतरनाक रूप से लिंक हो, लेकिन ऐसा लगता है कि इस निर्माण के लिए बहुत अधिक त्रुटियां हैं।

क्या आपको 64-बिट बिल्ड के लिए कम त्रुटियां मिलती हैं? ओपनब्लास 0.2.18 के खिलाफ वर्तमान सर्वश्रेष्ठ निर्माण के लिए?

64 बिट में केवल 6 विफलताएँ हैं:

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

मुझे पता है: यह OpenBLAS के साथ तुलना के लिए रोता है। हालाँकि, मैं पिछले 4 सप्ताह से कई कारणों से अटका हुआ हूँ जैसा कि आपने देखा होगा। उम्मीद है कि स्थिति में सुधार जारी रहेगा।

@ मैथ्यू-ब्रेट, मैं ओपनबीएलएएस के साथ numpy MSVC बिल्ड का उपयोग करने की सराहना करता हूं। मेरे नवीनतम निर्माण यहां हैं:

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

जैसे कि मिंगवपी, कोंडा-फोर्ज, एनाकोंडा और कैनोपी पर्याप्त नहीं थे, यहाँ पायथन के लिए इंटेल डिस्ट्रीब्यूशन आता है और यह डाउनलोड करने के लिए मुफ़्त है । इसमें केवल संख्यात्मक उपकरण (SciPy, NumPy, Numba, Scikit-Learn) और कुछ अतिरिक्त (mpi4py Intel mp इंटरफ़ेस और pyDAAL डेटा एनालिटिक्स) शामिल हैं और conda का उपयोग करता है।

कोई चिंता नहीं है कि लाइसेंस 10/29/16 को समाप्त हो रहा है, इसलिए ये इंटेल बिल्ड सिर्फ एक हैं
बीटा परीक्षण के बाद शायद MKL+ आदि लाइसेंस शुल्क। ओपनब्लास बनाता है
खुला स्रोत समाधान रहेगा इसलिए इन्हें उपलब्ध कराने के लिए धन्यवाद
बनाता है।
28 अप्रैल 2016 को शाम 7:21 बजे, "मार्क मिकोफ़्स्की" नोटिफिकेशन @github.com ने लिखा:

मानो मिंगवपी, कोंडा-फोर्ज, एनाकोंडा और कैनोपी यहाँ पर्याप्त नहीं थे
पायथन के लिए इंटेल वितरण
https://software.intel.com/en-us/python-distribution और यह मुफ़्त है
डाउनलोड
https://software.intel.com/en-us/articles/intel-distribution-for-python-support-and-documentation।
इसमें केवल संख्यात्मक उपकरण शामिल हैं (SciPy, NumPy, Numba, Scikit-Learn)
साथ ही कुछ अतिरिक्त (mpi4py Intel mp इंटरफ़ेस और pyDAAL डेटा एनालिटिक्स) और
कोंडा का उपयोग करता है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/numpy/numpy/issues/5479#issuecomment -215600103

1.11.1 के लिए, ऐसा लगता है कि Python 3.5 amd64 के लिए PyPi पर एक गायब विंडोज व्हील है।

क्या इसकी कोई खास वजह है? अगर मैं 1.11.0 (https://pypi.python.org/pypi/numpy/1.11.0) पर जाता हूं, तो पहिया वहां है।

रिपोर्ट के लिए धन्यवाद - मुझे लगता है कि हमने बहुत जल्द अपलोड कर दिया होगा, और इसलिए सभी पहियों के बनने से पहले। मैंने लापता पहिया अपलोड कर दिया है। ऐसा लगता है कि ऐसा दोबारा न हो यह सुनिश्चित करने के लिए हमें एक परीक्षण की आवश्यकता है।

मैंने लापता पहिया अपलोड कर दिया है।

मैंने अभी इसका परीक्षण किया है, और यह बहुत अच्छा काम करता है!

विंडोज़ पहियों को उपलब्ध कराने के लिए किए गए सभी कार्यों के लिए बहुत-बहुत धन्यवाद।

मुद्दे को समाप्त करना - पिछले कुछ रिलीज के लिए पहिए उपलब्ध हैं।

मैं समझता हूं कि यह मुद्दा बंद हो गया है लेकिन मेरा मानना ​​है कि हमें इसे फिर से खोलने पर विचार करना चाहिए।

यह विंडोज़ उपयोगकर्ताओं के लिए एक समस्या बनी हुई है, जो कोंडा का सहारा लिए बिना अपने वैज्ञानिक स्टैक को चलाने की कोशिश कर रहे हैं। मुझे अभी भी @cgohlke 'MKL' बिल्ड का उपयोग करने की आवश्यकता है यह संबंधित scipy समस्या देखें जो खुला रहता है। हालांकि पहियों का निर्माण किया जा रहा है, स्किप के साथ संगत किए बिना, वे कई लोगों के लिए उपयोग करने योग्य नहीं हैं।

@wayneilsen आपके पास मेलिंग सूची थ्रेड में नए पहियों को स्थापित करने के निर्देश हैं जो आपके द्वारा अभी बताए गए मुद्दे से जुड़े हुए हैं:

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

तो अगर आप करते हैं

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

यह आपके लिए काम करना चाहिए।

Numpy के लिए करने के लिए कुछ नहीं बचा है, इसलिए समस्या समाप्त हो गई है।
Scipy समस्या अभी भी खुली है, और संभवत: इसे अगले में हल किया जाएगा
रिहाई।

यह मेरे लिए बहुत अच्छा काम करता है @ जुआनलु001 मैं वास्तव में आगे देख रहा हूं कि यह पीपीआई पर कब होगा!