Numpy: حزمة Windows wheel (.whl) على Pypi

حسنًا - وفي الواقع هناك الكثير من العمل الذي قام به carlkl يجري وراء الكواليس لتحقيق ذلك. أعتقد أننا على وشك الوصول إلى هناك الآن -carlkl - متى ستظهر للجمهور ، هل تعتقد؟

للسياق: السبب في أن هذا ليس تافهاً هو أن الثنائيات التي ربطتها
للاعتماد على مكتبة وقت التشغيل والرياضيات الخاصة بشركة Intel ، والتي
يعقّد إعادة توزيعها.

لقد قمت بنشر عجلات numpy و scipy المستندة إلى OpenBLAS على binstar. يمكنك تثبيتها بواسطة:

تثبيت pip -i https://pypi.binstar.org/carlkl/simple numpy
تثبيت pip -i https://pypi.binstar.org/carlkl/simple scipy

يعمل هذا مع python-2.7 و python-3.4. تم تمييز العجلات على أنها "تجريبية". نرحب بالتعليقات.

إذا كنت تريد اختبارًا واسع النطاق ، فعليك إرسال هذا إلى القائمة :-)

في الخميس ، 22 كانون الثاني (يناير) 2015 الساعة 8:54 مساءً ، كتب carlkl [email protected] :

لقد قمت بنشر عجلات numpy و scipy المستندة إلى OpenBLAS على binstar.
يمكنك تثبيتها بواسطة:

تثبيت pip -i https://pypi.binstar.org/carlkl/simple numpy
تثبيت pip -i https://pypi.binstar.org/carlkl/simple scipy

يعمل هذا مع python-2.7 و python-3.4. تم وضع علامة على العجلات كـ
'تجريبي'. نرحب بالتعليقات.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -71096693.

ناثانيال ج. سميث
باحث ما بعد الدكتوراه - المعلوماتية - جامعة ادنبره
http://vorpus.org

fwiw أنا شخصياً أرغب في تغيير حجم العدد الصحيح الافتراضي في win64 قبل أن نقدم بالفعل ثنائيات رسمية ، على الرغم من وجود بعض المقاومة أيضًا عندما اقترحته آخر مرة ، وربما أيضًا مع الأناكوندا وثنائيات الطرف الثالث الأخرى ربما فات الأوان: (

نتحدث أيضًا عن openblas ، شخص ما يتوهم بعض التصحيح ، لقد سئمت منه (يبدو أنه نفس الفشل الذي يكسر scipy مع openblas):

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

إصدار OpenBLAS المستخدم هو 0.2.12. لم أواجه مشاكل كبيرة مع هذا الإصدار حتى الآن.

يتم نسخ حالات الفشل scipy إلى https://gist.github.com/carlkl/b05dc6055fd42eba8cc7.

32 بت فقط حالات فشل غير دقيقة بسبب http://sourceforge.net/p/mingw-w64/bugs/367

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

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

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

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

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

لا أختلف بشأن تغيير حجم الأعداد الصحيحة لـ win64 ، لكنني أعتقد أن هذا
قضية منفصلة يجب فصلها عن العجلات. إذا كان هذا هو
لأول مرة أصبحت إصدارات win64 numpy متاحة على نطاق واسع ، ثم أصبحت
من المنطقي ربطهم ، ولكن في هذه المرحلة يوجد بالفعل عدد كبير من المستخدمين
لسنوات ، كانوا يستخدمون cgholke أو الأناكوندا أو أي شيء آخر. لذلك دعونا
التعامل مع ذلك على أنه مناقشة مستقلة؟

(بالمعنى الدقيق للكلمة ، إنها استراحة backcompat ، ولكن رغم ذلك يبدو معقولًا
أننا قد نكون قادرين على تنفيذه ، لأنه يقلل في الواقع
عدم التوافق بين الأنظمة الأساسية - يجب أن تتعامل جميع التعليمات البرمجية المحمولة مع 64 بت
نوع dtype = int بالفعل.)

يوم الخميس ، 22 كانون الثاني (يناير) 2015 الساعة 8:59 مساءً ، Julian Taylor [email protected]
كتب:

fwiw أود شخصياً تغيير حجم العدد الصحيح الافتراضي به
win64 قبل أن نقدم بالفعل ثنائيات رسمية ، على الرغم من وجود بعض
مقاومة أيضًا عندما اقترحته آخر مرة ، ربما أيضًا مع أناكوندا و
ثنائيات الطرف الثالث الأخرى ربما تكون قد فات الأوان بالفعل :(

تحدث أيضًا عن openblas ، شخص ما يتوهم بعض التصحيح ، لقد سئمت منه
(يبدو وكأنه نفس الفشل الذي كسر scipy مع openblas):

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 بت في blas فكرة رهيبة. توقف قبل أن تذهب بعيدًا جدًا في هذا الطريق. ماتلاب وجوليا قبل أن أذهب وأصلحها ، فعلوا ذلك ، وكسر أي مكتبة تابعة لجهة خارجية تفترض أعدادًا صحيحة 32 بت تقليدية في blas.

ما كنا نفعله في Julia على مدار الخمسة أشهر الماضية تقريبًا هو إعادة تسمية جميع الرموز في openblas لإضافة لاحقة _64 لهم لإصدار 64 بت int ، وبهذه الطريقة يمكنك إجراء الجبر الخطي على المصفوفات الضخمة حقًا إذا كنت تريد ذلك ، ولكن تحميل المكتبات الخارجية في نفس العملية لن يخطئ من خلال تظليل الأسماء ومحاولة استدعاء dgemm باستخدام ABI الخطأ.

مرحبًا يا رفاق ، هل هناك أي تحديث على ملفات العجلات التي يتم توفيرها لـ Numpy؟

ليس هذا ما أدركه الآن.
في 25 حزيران (يونيو) 2015 ، الساعة 4:27 صباحًا ، كتب "guyverthree" [email protected] :

مرحبًا يا رفاق ، هل هناك أي تحديث على ملفات العجلات التي يتم توفيرها من أجلها
نومبي؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -115215236.

guyverthree ، أطلق كريستوف جولك NumPy باستخدام MKL من Intel كعجلات منذ فترة حتى الآن.

أيضًا ، راجع منشور مدونتي على عجلات NumPy . لقد صنعت بعض عجلات NumPy في Dropbox الخاص بي باستخدام سلسلة أدوات mingw-w64 المعدلة من Carl Kleffner ومنفذ Zhang Xianyi OpenBLAS في GotoBLAS . كان Olivier Grisel يبحث عن مساعدة في تعديل NumPy buildbot لتكرار نفس الخطوات المستخدمة في سلسلة مجموعات Google OpenBLAS التي أنشرها.

يتوفر أحدث إصدار لدي على binstar.org على الرغم من أنني لست متأكدًا مما إذا كان anaconda.org هو الاسم المفضل الجديد الآن.
يبلغ عمر عجلات py-2.6 .. 3.4 (32/64 بت) حوالي شهرين:

• numpy-1.9.2
• scipy-0.15.1
• scikit-image-0.11.2.0 تحديث

البناء باستخدام 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

+ 1carlkl وأتمنى أن تضاف هذه إلى بناء NumPy في Cheese Factory أيضًا.

+1 أحب أن أرى هذا يحدث أيضًا.

IMHO: هناك ثلاث مشاكل على الأقل يجب حلها قبل قبول هذه البنيات:

• يجب إعادة إنشاء بقع mingwpy للمستودع الخالي من الورق
• لا توجد آلية بناء جانبا البناء يدويا حتى الآن
• تعتمد العديد من حزم Windows ثلاثية الأطراف (التي تم إلغاء تغطيتها بواسطة C. Gohlke) بشكل صريح على numpy-MKL ، لأن الثنائيات مرتبطة بشدة بملفات DLLs MKL. قد يتغير هذا في المستقبل ، حيث يوفر scipy الآن آلية للاعتماد الضمني على تنفيذ scipy BLAS / Lapack. لذا فإن تثبيت (numpy-MKL & scipy-MKL) أو (numpy-OpenBLAS & scipy-OpenBLAS) يجب أن يكون كافياً لجميع الحزم الأخرى في المستقبل.

carlkl : FWIW ، لست قلقًا حقًا بشأن حزم cgohlke - التي ستحل محلها (تمامًا مثلما لا توجد مشكلات كبيرة الآن بسبب الأشخاص الذين يحاولون الجمع بين scipy-MKL و anaconda numpy). وأنا لست قلقًا حقًا من وجود آلية بناء رائعة - فالبناء اليدوي جيد طالما أن هناك ملفًا نصيًا يوثق الخطوات.

المشكلة الرئيسية التي أشعر بالقلق بشأنها هي الاستدامة: إذا لم نتمكن من الحصول على هذه الأشياء في اتجاه المنبع ، فسنضطر إلى إعادة التحقق من صحة التصحيحات وإعادة تنفيذها في كل مرة يأتي فيها إصدار جديد من gcc / mingw-w64 / msvc وربما لن يحدث ذلك. لا نريد الوقوع في الفخ حيث نبدأ في تقديم البنيات ، ولكن بعد ذلك يصبح هذا مرهقًا أكثر فأكثر بمرور الوقت حيث يتعين علينا التعامل مع مترجم قديم غريب الأطوار للقيام بذلك.

وهذا هو السبب في أنني كنت أحاول جمع التمويل لدعم القيام بذلك في المراحل الأولية ... تعد إجراءات 1+ رائعة وكلها ، ولكن إذا كان أي شخص يريد التبرع ببعض المال أو يعرف شركة قد تكون مهتمة بجعل دول مجلس التعاون الخليجي قابلة للاستخدام بشكل عام للبايثون ملحقات على windows ، ثم أرسل لي بريدًا إلكترونيًا :-) ([email protected])

إذا لم يكن لديك $$ ولكنك لا تزال ترغب في المساعدة ، فإن إحدى طرق القيام بذلك هي إرسال تصحيحات إلى mingw-w64 لتحسين دعمها للوظائف المتعالية مثل الخطيئة وجيب التمام. (اتضح أن MSVC ABI لا يتفق مع أي شخص آخر حول كيفية تكوين وحدة x87 FPU ، لذا فإن معظم الوظائف الرياضية للبرامج المجانية لا تعمل بشكل صحيح.) لحسن الحظ ، هناك تطبيقات جيدة ومتوافقة مع الترخيص في Android " bionic "libc ، لذلك لا يتطلب هذا أي سحر رياضي أو نظرة ثاقبة حول مشكلات ABI - إنها مجرد مسألة ميكانيكية في الغالب للعثور على ملفات المصدر ذات الصلة واستخراجها ثم إسقاطها في شجرة mingw-w64 في المكان الصحيح. يمكننا تقديم مزيد من التفاصيل حول هذا أيضًا إذا كان أي شخص مهتمًا.

أليس هذا هو الشيء الذي يجب أن يموله numfocus؟ إذا لم يكن الأمر كذلك ، فربما يمكننا العودة وإعادة النظر في التقدم بطلب إلى PSF.

كم من المال نتحدث؟

+1 الرجاء نشر عجلات Windows إلى PyPI https://pypi.python.org/pypi/numpy

إذا جربت pip install numpy على تثبيت Python Windows خارج الصندوق ، فستتلقى رسالة الخطأ الشائنة "تعذر العثور على vcvarsall.bat".

+1 ستساعد مستخدمي Windows حقًا.

لا يمكن اللعب مع https://github.com/glumpy/glumpy بسبب هذا. ما هي خطوات الإنشاء اليدوية لجعل Numpy يعمل على Windows؟ يبدو أن وظيفة AppVeyor موجودة ، لذا يجب ألا تكون هناك مشكلة في تحميل القطع الأثرية على GitHub .

في الوقت الحالي ، من المستحيل فعليًا إنشاء نسخة سريعة ومرخصة من BSD من numpy على windows. نحن نعمل على إصلاح ذلك ، لكنه قيد تقني ؛ لن يكون لـ 1+ أي تأثير في كلتا الحالتين. (وظيفة appveyor مبنية على windows ، ولكنها تستخدم مكتبة الجبر الخطي غير المحسَّنة الاحتياطية التي لا تناسب حقًا العمل الحقيقي.) إلى أن يتم فرز هذا الأمر ، فإنني أوصي بتنزيل العجلات من موقع Christoph Gohlke على الويب ، أو باستخدام Anaconda أو توزيع بيثون علمي آخر .

njsmith هل يمكنك أن تكون أكثر تحديدًا؟ يفضل أن يكون ذلك بأوامر محددة لا تعمل. في الوقت الحالي هذه الأشياء غير قابلة للتنفيذ.

أعتقد أن "المستحيل" قوي للغاية - لكن بالتأكيد لا توجد طريقة عامة واضحة للمضي قدمًا. أضع صفحة wiki على الحالة الحالية هنا: 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 ، أليس كذلك؟ لماذا هو مطلوب ل numpy؟

njsmith http://mingwpy.github.io/issues.html مبادرة رائعة مع تحليل جيد. من المؤسف أن المنبع (Python) لن يدعمه أبدًا (يروج باستخدام MSVS بشكل أعمى). لكني أحاول الحصول على صورة واضحة من الوضع الحالي.

1. هل هي مشكلة "وجود سلسلة أدوات مفتوحة للعمل المفتوح" أم أن MSVS لا تستطيع حقًا تجميع جزء C من numpy؟
2. هل لا تزال هناك أعطال مع امتدادات مترجمة من mingw؟

لتضييق نطاق التركيز في الوقت الحالي ، دعنا نقول أن Python 2.7 + Win32 فقط. لا يوجد أداء ضروري (أريد فقط تشغيل التطبيق لاختباره هناك) ، ولكن هناك حاجة إلى بيانات معيارية حول هذا الأداء.

إذن ، ما هو الإجراء التالي الذي يجب القيام به لهذا التكوين لإتاحة عجلة Windows من PyPI؟

techtonik ، هناك الآن إصدارات أولية من عجلات numpy و scipy متاحة على https://anaconda.org/carlkl/numpy و https://anaconda.org/carlkl/scipy. الأداء يكاد يكون جيدًا مثل عجلات gohlke's + MKL. لم أواجه segfaults مع صندوق windows الخاص بي في المنزل.

تمت مناقشة العديد من المشكلات المتعلقة بهذا النهج وتم تلخيصها في http://mingwpy.github.io (قيد الإنشاء). إن الجمع بين سلسلة الأدوات القائمة على mingw-w64 والمسمى _mingwpy_ و OpenBLAS هو الطريقة المثلى لمنصة Windows.

يحتوي _mingwpy_ على تكوين خاص يضمن توافقًا أفضل واستخدامًا أكثر راحة مقارنة بسلاسل الأدوات الأكثر شهرة التي تستند إلى mingw-w64 ، على سبيل المثال _mingw-builds_ ، _tdm_ ...

كل هذا وأكثر موضح في https://github.com/mingwpy/mingwpy.github.io. لا تتردد في فتح القضايا أو العلاقات العامة هناك.

techtonik : أعتقد أن هذا سوء فهم / تحريف خطير لموقف موقع python.org المنبع. أود أن أقول إنهم يرفضون الترويج لانقسام دعم Windows CPython إلى العديد من ABIs غير المتوافقة (وأنا أتفق معهم في هذا). ساعدنا ستيف داور ، الذي يتولى صيانة عمليات إنشاء نوافذ المنبع الرسمية ، في معرفة كيفية جعل mingwpy متوافقًا مع هذه الإنشاءات.

إن الشرط الأساسي للمنظمة البحرية الدولية (IMO) لوضع عجلات صغيرة على pypi هو أن تكون (أ) فعالة ، (ب) قابلة للصيانة ، (ج) مرخصة بشكل مناسب. إذا كنت تريد أن يطبق المشروع مجموعة مختلفة من المعايير (أي أننا يجب أن نبذل جهدًا في توفير عجلات بأداء فظيع) ، فإن الخطوة التالية هي إرسال بريد إلكتروني إلى القائمة البريدية غير المعقدة لإثبات أن معاييرك أفضل.

يمكن أن تقوم MSVS ببناء نفسها ، لكنها لا تستطيع إنشاء أي من تطبيقات BLAS عالية الجودة والمرخصة بشكل مناسب. يمكن أن ينتج mingw-w64 المنبع numpy + BLAS (مع التصحيحات) ، لكن النتيجة ستتعطل إذا حاولت استخدامه مع CPython المنبع. يمكن لسلسلة أدوات mingwpy من Carl إنشاء numpy + BLAS (مع تصحيحات) ، وستعمل النتيجة على بعض إصدارات Python (ولكن ليس 3.5) ، لكن سلسلة الأدوات هشة وغير قابلة للاستمرار في حالتها الحالية ؛ لا يعرف أحد حرفيًا ، باستثناء كارل ، كيف تم بناؤه أو يمكنه إعادة إنشائه. لا يوجد أي شخص في المشروع الخفي على استعداد لإلزام أنفسنا بتقديم "تصميمات رسمية" باستخدام سلسلة أدوات مع هذه القيود ، لذلك نحن نركز على إصلاحها.

هناك العديد من المصادر المتاحة بشكل تافه للبنى المعقدة عالية الجودة على Windows. أنا فضولي حقًا: لماذا تصر بشدة على أننا يجب أن نرمي بعض التراكمات منخفضة الجودة فقط حتى يكونوا على PyPI؟

njsmith أردت فقط أن أذكر أن حالة الاستخدام الخاصة بي (التي أعترف أنها لن تبرر بأي حال من الأحوال استثمار موارد المطور بمفردها) هي توزيع حزمة بسيطة جدًا على PyPI تعتمد على matplotlib ، والذي بدوره يعتمد على numpy .

بالنسبة إلى حالة الاستخدام الخاصة بي ، فإن أداء حالة الاستخدام ليس مصدر قلق ، ولكن القدرة على الحصول على مستخدم Windows ببساطة pip install ____ حزمي التي تثبّت بشكل متكرر matplotlib ، numpy ، وما إلى ذلك هو أسهل بكثير شرح بدلاً من توجيههم إلى عناوين URL لتثبيتها أيضًا ، خاصة للمستخدمين الذين لا يفهمون نظام إنشاء Python. لذلك فهو في الغالب لتبسيط تعليمات التثبيت.

مرة أخرى ، لم أحاول استخدام حالتي كمبرر ، ولكن أردت فقط المشاركة كما كنت فضوليًا.

johnthagen : أوه ، بالتأكيد ، لا تقلق! أفهم تمامًا سبب كون هذا أمرًا مرغوبًا فيه بشكل عام ؛ إذا صادفتني غاضبًا في هذه التعليقات ، فهذا بالضبط لأنني أنا وآخرون قضينا وقتًا طويلاً خلال العام الماضي في محاولة لإصلاح هذا :-). كنت فقط أسأل techtonik على وجه التحديد لأنه بدا الأمر كما لو كانوا يقولون "أريد فقط تجربة تطبيق صغير واحد ، لذلك لا أهتم بالأداء" ، ولكن إذا كانوا يريدون فقط تجربة تطبيق واحد صغير ، فأنا لا اعرف سبب اهتمامهم بجزء PyPI :-)

(من المهم أن تضع في اعتبارك أن أي عجلة نضعها على pypi ستبدأ فورًا في استخدامها من قبل عشرات الآلاف من الأشخاص ، ومعظمهم لا يقرأ هذا الموضوع. لذلك أعتقد أن هناك بعض الالتزامات علينا للتأكد من أنه نحن في الواقع سيكون قابلاً للاستخدام على نطاق واسع لمجموعة واسعة من حالات الاستخدام.)

أعتقد أنه سيكون من السهل بشكل أساسي البدء في شحن عجلات فارغة 32 بت لـ Python 2.7 ، باستخدام ATLAS. من المحتمل أن تكون SSE2 ، لذلك تتعطل بدون تعليمات SSE ، لكن هذا لن يؤثر إلا على نسبة صغيرة جدًا من المستخدمين. يمكننا استخدام سلسلة أدوات الإصدار الحالي الخاصة بنا من أجل ذلك. ضع في اعتبارك أن هذا قد يعني أن النقطة ستعطي عجلة ثنائية لـ 32 بت ، لكنها ترجع إلى تثبيت المصدر لـ 64 بت. هل سيكون ذلك مفيدا؟

njsmith شكرا للمعلومات! نقدر كل عملك الشاق :)

أعتقد أنه سيكون من السهل بشكل أساسي البدء في شحن عجلات فارغة 32 بت لـ Python 2.7 ، باستخدام ATLAS. من المحتمل أن تكون SSE2 ، لذلك تتعطل بدون تعليمات SSE ، لكن هذا لن يؤثر إلا على نسبة صغيرة جدًا من المستخدمين. يمكننا استخدام سلسلة أدوات الإصدار الحالي الخاصة بنا من أجل ذلك. ضع في اعتبارك أن هذا قد يعني أن النقطة ستعطي عجلة ثنائية لـ 32 بت ، لكنها ترجع إلى تثبيت المصدر لـ 64 بت. هل سيكون ذلك مفيدا؟

@ Matthew-brett الإعداد الحالي لمورد numpy معطل ، وهناك خطأ segfault في fromfile . تم إفساد معالجة مقبض الملف بطريقة ما ، ولسنا متأكدين مما إذا كان ذلك بسبب تغيير في إصدار Wine أو إصدار Ubuntu أو (من غير المحتمل) تغيير في numpy نفسه. أود أن أقول إن قضاء المزيد من الوقت في ذلك هو مضيعة للوقت - إن تخصيص هذا الوقت في mingwpy يعد طريقة أكثر إنتاجية.

لدي NumPy 1.10.4 مجمّع مع كل من OpenBLAS (Int32 Windows 64 ، v0.2.15 ثنائي مترجم مسبقًا) و MKL (باستخدام ترخيص مجتمع على MKL ، أي التوزيع المجاني). لكن ... لا يمكنني ترجمة SciPy - يبدو أن جزءًا صغيرًا يبحث عن مترجم gfortran "لم يتم العثور على مترجم fortan" إذا كان لدى أي شخص فكرة عن كيفية إصلاح هذه المشكلة. أنا أستخدم ifort.exe لأن Ananconda يدعم هذه البنيات كمكونات إضافية مباشرة. تم تجميعه لـ Python 3.5 مع Microsoft Visual Studio Community 2015 إذا كان بإمكان أي شخص مساعدتي في معرفة كيفية حزم هذا للتوزيع ... ثم سأقوم بالتحميل إلى موقع github أو anaconda's website. نقدر ذلك.

mrslezak : ربما يكون أفضل ما يمكنك فعله هو النشر في القائمة البريدية لمطوري scipy ، أو فتح خطأ جديد على scipy ، بدلاً من النشر على أخطاء موجودة عشوائية :-)

أنا فضولي حقًا: لماذا تصر بشدة على أننا يجب أن نرمي بعض التراكمات منخفضة الجودة فقط حتى يكونوا على PyPI؟

فقط لأنني تعبت من حلق الياك. أعلم أن الناس يريدون الأداء ، ومن الجيد أن يكون لدى شخص ما الموارد اللازمة للقيام بذلك ، ولكن بالنسبة لي شخصيًا ، فإن التعقيد في إنجاز هذه المهمة هائل ، لذلك يمكنني فقط أن أتمنى أن تتمكن من القيام بذلك ، ولكن بالنسبة لي قد لا يحدث أبدًا ، أو قد يحدث في غضون عامين أو ثلاثة أعوام ، يستمر خلالها الأشخاص في ضرب الجدران وإضاعة الوقت في ساعات متناسبة مع تنزيلات جميع ثنائيات النوافذ من PyPI التي تتطلب تثبيت NumPy باعتباره تبعية مباشرة غير مباشرة.

عجينة. ربما تكون أطول جملة باللغة الإنجليزية كتبتها في حياتي كلها. =)

techtonik - أشاركك إحباطك ، وأعتقد أن الكثير منا يشعر بالإحباط حيال ذلك.

carlkl - أود الحصول على ملاحظاتك هنا.

من الواضح أن هناك ضغطًا قويًا علينا لوضع عجلة نوافذ ممتلئة. فيما يلي قائمة بالعجلات الأكثر تنزيلًا لأي منصة منذ أسبوعين: https://gist.github.com/dstufft/1dda9a9f87ee7121e0ee . تأتي عجلات matplotlib و scikit-Learn و pandas windows في المواضع 3 و 4 و 5. سيكون هناك سوق كبير لعجلات النوافذ الصغيرة.

أعتقد أن الأسئلة المطروحة على الطاولة هي:

1) هل يمكننا أن نلزم أنفسنا بالحصول على عجلة صلبة تعمل وشبه مثالية على pypi على المدى القصير إلى المتوسط ​​(على سبيل المثال ، 6 أشهر). أود أن أقول إن الجواب على هذا هو نعم (سعيد لسماع الخلاف) ؛
2) هل يستحق وضع عجلة غير مثالية في هذه الأثناء ليبني الآخرون ضدها؟

السؤال 2 هو الأصعب. قد تعني كلمة "ليس الأمثل" بطيئًا (لا توجد فجوة / فجوة محسّنة) أو يصعب دعمها (لا يوجد ضمان أننا يمكن أن نكرر البناء في غضون 6 أشهر).

أستطيع أن أرى الحجج ضد "بطيء". نحن بحاجة إلى توخي الحذر ، عندما تبدأ العجلات في العمل مع Windows ، فإنها لا تؤدي على الفور إلى طرح أسئلة حول نظام stackoverflow مع إجابات "على أي حساب ، قم بتنزيل العجلات الصغيرة من pypi". أعتقد أن هذه الإجابات ستكون معقولة وستستمر لفترة طويلة بما يكفي لإيذاءنا.

ليس المعنى الأمثل ، من الصعب دعم عملية البناء ، أعتقد أنه يمكننا التعايش معه ، إذا كنا ملتزمين حقًا بإيجاد حل طويل الأجل قريبًا إلى حد ما.

منذ فترة ، صممت ثنائيات ATLAS لنظام التشغيل Windows: http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/

هل أنا محق في التفكير في أنه يمكننا بالفعل بناء ثنائيات غير معقدة تجتاز جميع الاختبارات باستخدام ثنائيات ATLAS هذه؟

في هذه الحالة ، لماذا لا نضع هؤلاء؟

1) هل يمكننا أن نلزم أنفسنا بالحصول على عجلة صلبة تعمل وشبه مثالية على pypi على المدى القصير إلى المتوسط ​​(على سبيل المثال ، 6 أشهر). أود أن أقول إن الجواب على هذا هو نعم (سعيد لسماع الخلاف) ؛

أتمنى ذلك ، وإلا فهذا يعني أنه بحلول ذلك الوقت سنواجه مشكلة غير متوقعة مع اقتراح mingwpy أو لم نقم بالتخزين المؤقت لما يتيحه :)

2) هل يستحق وضع عجلة غير مثالية في هذه الأثناء ليبني الآخرون ضدها؟

يبدو أن تصميمات ATLAS الخاصة بك قد تم إنجازها باستخدام Cygwin؟ أم أن هذا مجرد تسمية دليل وقمت باستخدام بعض إصدارات MingwPy؟

أعتقد أن تصميمات ATLAS الخاصة بي قد تم إجراؤها باستخدام Cygwin ، لكنها لا ترتبط بـ Cygwin.dll ، لذلك أعتقد أنها ستكون آمنة للبناء باستخدام MSVC.

mingwpy ليست في مأزق ولكنها تحتاج إلى وقتها. يستغرق بناء سلسلة أدوات دول مجلس التعاون الخليجي و OpenBLAS ثم numpy / scipy باستخدام متغيرات مختلفة وقتًا في البناء والاختبار. ولن أنشر ثنائيات بدون نشر جميع نصوص البناء أولاً. يكاد يكون mingwpy المعتمد على مجلس التعاون الخليجي 5.3.0 جاهزًا ، بالإضافة إلى OpenBLAS. والخطوة التالية هي بناء عجلات متكتلة وخفيفة بناءً على ذلك.

هذه المناقشة بالإضافة إلى أحدث المساهمات في الموضوع الخيطي "عجلات Linux متعددة التوزيع - يرجى الاختبار" تؤدي إلى السؤال ، حيث أن OpenBLAS تتمتع بالجودة التي تسمح بنشر عجلات Windows numpy على أساس OpenBLAS. لكنني لست متأكدًا من أن استخدام الأطلس بدلاً من ذلك هو الحل الأفضل. ربما يجب بناء العجلات غير المتساقطة مع كلا المتغيرين لمرحلة الاختبار أولاً.

أظن / آمل أن نصل بطريقة ما إلى مرحلة أن OpenBLAS ذات جودة مقبولة. ولكن ، حتى ذلك الوقت ، يبدو من المعقول بالنسبة لي أن أبدأ بعجلات ATLAS الممتلئة ، وتوقع أنه في الوقت المناسب سنكون قادرين على التحول إلى عجلات OpenBLAS. قد نضطر إلى إجراء فحص SSE2 لإصدارات 32 بت على الرغم من: http://mingwpy.github.io/blas_lapack.html#atlas

قد يؤدي وضع مربع تقدم في أعلى صفحة PyPI إلى جذب المزيد من الأشخاص إلى المشكلة (بما في ذلك أولئك الذين قد يتبرعون لدعم المبادرة). قد يسرد المربع الاستراتيجية الحالية ومعايير القبول (رابط إلى اختبار الأداء؟) والحالة والإجراء الذي سيتم تنفيذه عندما يكون الإصدار النهائي جاهزًا (هل تريد زيادة الإصدار الرئيسي؟).

@ Matthew-brett لا يزال من غير الواضح بالنسبة لي أن اقتراحك بإلقاء شيء ما قابل للتطبيق. ما المترجم الذي ستستخدمه؟ إذا كان MingwPy ، فلدينا خطة واضحة بشأن الترتيب الذي يجب القيام به ويبدو الآن مبكرًا جدًا. إذا كانت دول مجلس التعاون الخليجي أخرى ، فإننا نعود إلى مشكلة الربط الثابتة وتوزيع DLL.

كانت فكرتي هي تجميع numpy باستخدام ATLAS باستخدام MSVC. بالطبع هذا لا يمكن أن ينجح مع scipy ، ولكن على الأقل سيكون الناس قادرين على البدء في شحن عجلات النوافذ الخاصة بهم ، مهما كانت مصنوعة.

لقد جربت ذلك للتو وحصلت على بعض الأخطاء من النموذج unresolved external symbol __gfortran_compare_string لذا أفترض أن ثنائيات ATLAS تحتوي على بعض الإشارات المتدلية إلى وقت تشغيل gfortran. carlkl - أي اقتراحات حول كيفية التصحيح؟

يجب تجنب خلط ملفات الكائنات الثابتة القادمة من مترجمين مختلفين مثل الشيطان الذي يتجنب الماء المقدس. في بعض الحالات ، ستنجح هذه الطريقة ، لكنها ستفشل في مجموعة مختلفة من المجمّعين.
راجع للشغل: MS نفسها لا تدعم رسميًا أو توصي بخلط كائنات ثابتة من إصدارات مختلفة من Visual Studio الخاص بهم.

لقد أجريت بعض الاختبارات منذ بضعة أسابيع ، حيث ظهر هذا السؤال: هل يمكن استخدام المكتبة الثابتة npymath.a التي أنشأتها mingwpy مع مترجمي MSVC؟ من حيث المبدأ ، قد ينجح الأمر إذا تمت إضافة بعض الكائنات المحددة من مكتبات وقت تشغيل دول مجلس التعاون الخليجي إلى هذه المكتبة. لقد توصلت إلى استنتاج مفاده أن مثل هذا النهج غير مستقر وهش.

إذا كان الأطلس خيارًا لبناء عجلات فارغة ، فسأحاول بنائه كـ DLL ، هل هناك أي اعتراضات؟

يجب تجنب خلط ملفات الكائنات الثابتة القادمة من مترجمين مختلفين مثل الشيطان الذي يتجنب الماء المقدس.

أشعر أن https://mingwpy.github.io/motivation.html (لماذا الصفحة) يفتقر إلى بعض الشرح البسيط والمباشر لمشكلة الوحدات الديناميكية المحملة . لقد تحدثت مع رفاق Far Manager ، الذين يعتبر مدير ملفاتهم أصليًا لنظام Windows ، ومبنيًا على المكونات الإضافية ، والتي يتم تحميلها من dlls المكتوبة بلغات مختلفة ، وليس لديهم هذه المشكلة مع "نفس المترجم تمامًا". أتساءل لماذا تمتلك Python ذلك - فهي تحمل أيضًا وحدات من dlls ..

techtonik ، كان تعليقي حول ربط ملفات الكائنات التي تم إنتاجها بواسطة مجمعين مختلفين في ملف ثنائي واحد (DLL أو EXE). هذا ما قصدته بخلط ملفات الكائنات الثابتة. يمكن أن يعمل مثل هذا النهج في بعض المواقف التي تم اختبارها جيدًا إذا تم التعامل معها بحذر. لكنها أبعد ما تكون عن كونها وسيلة قوية لبناء ثنائيات.

تعد إمكانية التشغيل التفاعلي لملفات DLL من مترجمين مختلفين في مساحة عملية مشتركة أمرًا مختلفًا تمامًا. عادة مثل هذا النهج يعمل بشكل جيد كقاعدة عامة. على المرء أن يتأكد من أن هذه الثنائيات مرتبطة بنفس وقت تشغيل MS DLL إذا كانت تشترك في واصفات الملفات. هناك مشكلات أخرى محتملة تتعلق بـ ABI يجب التعامل معها أيضًا. وبالطبع تحتاج إلى مجموعة مختلفة من مصححات الأخطاء لتصحيح الأخطاء اعتمادًا على المجمعات المستخدمة.

minwgpy هو مشروع لدعم ملحقات بناء بايثون بمساعدة mingw-w64 للاستخدام داخل بنى MSVC CPython القياسية.

حسنًا - تمكنت من إنشاء numpy باستخدام ربط MSVC مقابل إصدار ATLAS.

أطلس يبني هنا:

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

توجد بعض الإرشادات الأساسية حول كيفية إنشاء ملف ATLAS dll.

تمر جميع الاختبارات المعقدة بصرف النظر عن اختبار البرنامج النصي f2py ، أعتقد أن هذا فشل حميد.

الخطوة الأخيرة هي شحن المكتبة الديناميكية داخل العجلة. carlkl - ما هي طريقتك المفضلة حاليًا للقيام بذلك؟

من الجيد أن أسمع ، أود أيضًا معرفة كيفية إنشاء عجلة باستخدام
تم تضمين الثنائيات - يمكن نشر بناء MKL وجعل الآخرين يختبرون OpenBlas
واحد.
في 11 فبراير 2016 1:28 مساءً ، كتب "ماثيو بريت" [email protected] :

حسنًا - تمكنت من إنشاء numpy باستخدام ربط MSVC مقابل إصدار ATLAS.

أطلس يبني هنا:

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

توجد بعض الإرشادات الأساسية حول كيفية بناء أطلس
dll.

تمر جميع الاختبارات المعقدة بصرف النظر عن فحص البرنامج النصي f2py ، وأعتقد أن هذا هو ملف
فشل حميد.

الخطوة الأخيرة هي شحن المكتبة الديناميكية داخل العجلة. تضمين التغريدة
https://github.com/carlkl - ما هي طريقتك المفضلة الحالية في العمل
الذي - التي؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -183021728.

الخطوة الأخيرة هي شحن المكتبة الديناميكية داخل العجلة.

وفحص SSE2 وخطة الإنقاذ الرائعة؟

mrslezak - أسهل طريقة هي وضعه في المجلد numpy / core ، حيث يتم تحميله تلقائيًا في مساحة العملية أثناء استيراد multiarray.pyd.

الخطوة الأخيرة هي شحن المكتبة الديناميكية داخل العجلة

@ Matthew-brett: أنا متأكد بنسبة 99٪ من أن الطريقة "الصحيحة" للقيام بذلك تتم عبر تجميعات SxS ، التي تكون وثائقها سيئة للغاية ، ولكن من المحتمل أن تكون قابلة للتنفيذ ... أعلم أنك قضيت وقتًا في محاولة فهمها ، وأنا لقد كنت تقرأ أيضًا ، لذا إذا كنت تريد الجلوس في وقت ما ومحاولة العمل على التفاصيل ، فأخبرني :-).

(تكمن المشكلة في جميع الأساليب الأخرى في أن عمليات نوافذ IIUC تحتفظ عادةً بمساحة اسم عالمية واحدة لجميع ملفات dll التي تم استيرادها. ما يعنيه هذا هو أنه إذا قام كل من الامتدادين بشحن ملف باسم foo.dll ، فإن أي ملحق يتم تحميله أولاً سيكون له نسخته لـ foo.dll "win" وسينتهي الامتداد الآخر باستخدامه - مشكلة "dll hell" الكلاسيكية. و IIUC الطريقة الوحيدة لتجنب هذا السلوك هي من خلال آلية SxS ، كما هي قبيحة.)

Nathaniel - لقد كتبت فهمي لتجمعات SxS هنا: https://github.com/numpy/numpy/wiki/windows-dll-notes#side -by-side-التجميعات

كان استنتاجي النهائي أنه كان ميؤوسًا منه ، وأنه على أي حال ، فإن إعادة تسمية DLL بطريقة فريدة لكل عملية كانت بديلاً معقولاً.

رالف - اقتراح لإضفاء الطابع الرسمي على طريقة إضافة خطافات SSE2 وما إلى ذلك لعملية التثبيت: https://github.com/numpy/numpy/pull/7231

@ ماثيو بريت: لقد قرأت تلك الملاحظات ، نعم .... وتنهد آخ ، ميؤوس منه لماذا؟ بسبب قضايا نفس الدليل؟ وهل لديك أي أفكار حول كيفية إنجاز إعادة التسمية؟ (لم أجد حتى الآن أي ما يعادل patchelf --replace لملفات PE ، وإعادة إنشاء ملفات .lib ليس بالأمر السهل - على الرغم من أنني أعتقد أن استخدام mingw-w64 ليس سيئًا للغاية لأن يمكنك الارتباط بـ .dll مباشرة. على الأقل إذا لم تكن بحاجة إلى إعادة تسمية libgfortran أو ما شابه ذلك ...)

(من الممكن أن يكون هناك بعض PE ما يعادل patchelf --replace في مكان ما في هذه القائمة: http://www.woodmannsfortress.com/collaborative/tools/index.php/Category:Import_Editors)

لا أرى مشكلة في تحميل satlas.dll (أو بدلاً من ذلك libopenblaspy.dll ) جنبًا إلى جنب مع multiarray.pyd ، حيث يُفضل هذا الدليل أثناء بحث DLL. يعمل هذا الأسلوب نظرًا لأنه يتم تحميل DLL هذا عبر LoadLibraryEx من python إلى مساحة العملية. يجب استخدام المجلد numpy/core ، حيث يوجد هنا أول ظهور لامتداد Python المعتمد على blas أثناء الاستيراد. يتم ببساطة تجاهل أي محاولات أخرى لتحميل DLL بنفس الاسم لأن DLL هذا قد تم تحميله بالفعل في مساحة العملية. يبحث Windows فقط عن اسم DLL BTW.

بدء جحيم DLL إذا كانت هذه المكتبة تعتمد على مكتبات DLL _fMore_ ، ولكن هذا ليس هو الحال لأن كلاً من satlas.dll و libopenblaspy.dll مستقلان ولا يعتمدان إلا على مكتبات DLL القياسية لنظام Windows. هذا ما يسمى عادةً بـ DLL المرتبطة بشكل ثابت - وهذا يعني أن كود وقت تشغيل دول مجلس التعاون الخليجي مرتبط بشكل ثابت.

_ للمقارنة _: لاستيراد مكتبات MKL ، يتمثل الأسلوب في تمديد PATH مؤقتًا إلى numpy/core . لسوء الحظ ، يفشل هذا إذا تم وضع مكتبات MKL الأقدم في مجلدات نظام Windows.

@ ماثيو بريت njsmith : إعادة تسمية DLL: ما هو جيد؟

carlkl : الحالة التي نشعر بالقلق بشأنها هي إذا كان numpy يتضمن atlas.dll ، وأيضًا يتضمن scipy atlas.dll ، وفي مرحلة ما يقوم المستخدم بترقية scipy (ويحصل على إصدار أحدث atlas.dll ) ، ولكن بعد ذلك ينتهي الأمر باستخدام scipy باستخدام الإصدار القديم من atlas.dll الذي يأتي من الحزمة الصغيرة. هذا أمر سيء ، لأن scipy قد يعتمد على وجود الإصدار الأحدث - لذلك ستتعطل الأشياء بشكل عشوائي اعتمادًا على ما يُبنى بالضبط من الحزم المتضمنة ، والترتيب الذي يستورده المستخدم. يحدث هذا لأنه إذا اشتمل numpy على ملف DLL باسم atlas.dll فسوف "يطالب" بالاسم atlas.dll في مساحة اسم DLL على مستوى العملية ، وسيحظر أي حزم أخرى من استخدام مكتبات DLL مختلفة مع ذلك اسم.

هناك حلان محتملان هما (أ) إذا كان من الممكن تشغيل عناصر SxS / سياقات التنشيط ، فإنها توفر طريقة لتعطيل مساحة اسم DLL على مستوى العملية ، أو (ب) إذا كان numpy يحتوي على numpy-atlas.dll ، و scipy يحتوي على scipy-atlas.dll ، ثم يمكنهم مشاركة نفس مساحة الاسم على مستوى العملية دون الاصطدام.

أو إذا كان كلاهما يعتمد على حزمة منفصلة clib_atlas التي توفر dll؟ ثم يمكن التعبير عن متطلبات تبعية الإصدار كالمعتاد لحزم بايثون.

tkelman : نحن بحاجة إلى معرفة كيفية دعم كل من مكتبات DLL المباعة وملفات DLL الموزعة بشكل منفصل ، على ما أعتقد ، لأن كلا الخيارين مناسبان في المواقف المختلفة. ومن السهل جدًا البدء في الحالة الموردة بـ :-)

أعتقد أن الحل جنبًا إلى جنب سيتطلب حقوق المسؤول للتثبيت في windows system32. من فضلك لا تفعل هذا.

هناك أيضًا تجميعات "خاصة" جنبًا إلى جنب ، حيث توجد التجميعات في الشجرة الثنائية الخاصة بك ، ولكن هناك حدًا لاثنين من علامات مسار الدليل العلوي التي يمكنك استخدامها للإشارة إلى التجميع ، أي يمكنك الإشارة إلى ..\..\some_assembly لكن ليس ..\..\..\some_assembly .

على سبيل المثال ، يمكن أن يشير scipy/first/second/third/something.pyd فقط إلى التجميع جنبًا إلى جنب في الدلائل third أو second أو first لكن ليس في scipy (أو أدلة أخرى ضمن ذلك.

حسنًا ، لقد صنعت بعض العجلات للاختبار ، هنا:

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

كل عادة:

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

أتمتة بناء خام للغاية هنا: https://github.com/matthew-brett/np-wheel-builder

اجتازت العجلات جميع الاختبارات بصرف النظر عن فشل زائف في تشغيل البرنامج النصي f2py (أعتقد أنه خطأ في هذا الاختبار).

تحقق من رالف - SSE2 هنا: https://github.com/matthew-brett/np-wheel-builder/blob/master/_distributor_init.py

لقد قمت أيضًا بإنشاء مثبتات 64 بت لـ Pythons 2.7 و 3.4 و 3.5 على نفس عنوان الويب.

@ ماثيو بريت ، ليس لدي إذن للوصول إلى هذه الملفات.

@ Matthew-brett ، لم تعد تقنية التجميع SxS مستخدمة بعد الآن (منذ VS2010) ، راجع https://en.wikipedia.org/wiki/Side-by-side_assembly.

ماذا عن إضافة أرقام الإصدارات إلى أسماء ملفات DLL: libopenblaspy_0.15..dll أو libatlas_3.10.1.dll أو ما شابه. ثم استخدم _proxy DLL_ الذي يتم استخدامه كمرجع DLL إلى إصدارات DLLs. يجب إنشاء ملحقات Numpy و scipy مقابل وكيل DLL يسمى ie _libblaslapack.dll_.

إذا تم استخدام الأطلس ، فسيسمح هذا من حيث المبدأ بتحميل ملف DLL أطلس محسن في وقت التشغيل. (ليس ضروريًا إذا كنت تستخدم openblas)

يمكن معالجة كل هذا بمساعدة حزمة clib_openblas و / أو clib_atlas. (الآن يجب أن أتعلم كيفية إنشاء رمز لمرجع DLL). يمكن تجهيز Numpy نفسها إما بأطلس أو openblas. يجب تحميل هذا في حالة عدم توفر clib_openblas أو clib_atlas.

carlkl : أعتقد أن صفحة ويكيبيديا محيرة ، وأحاول أن أقول إن VS 2010 لا يستخدم SxS _ لبعض المكتبات_ ، ولكن SxS بشكل عام لا يزال مستخدماً بالتأكيد (على سبيل المثال في نفس الصفحة لاحقًا: "من Vista فصاعدًا ، يستخدم نظام التشغيل أيضًا WinSxS لمكوناته الأساسية. ")

أعتقد أن الطريقة التي تبني بها ملف dll معيد التوجيه باستخدام msvc هي كتابة ملف .def خاص ثم استخدامه عند إنشاء ملف dll الخاص بك. ولكن ، كيف يساعد معيد التوجيه dll؟ (في نظام التشغيل OSX أو Linux ، أعتقد أنه يمكن أن يكون أداة مفيدة ، ولكن على نظام التشغيل windows ، لا يزال لديك مشكلة مساحة اسم dll العالمية المزعجة.)

njsmith ، يجب أن نبحث عن حل مفهوم. صحيح أن موقع SxS موجود. لا يتم استخدامه عادةً لأي شيء آخر غير نظام التشغيل نفسه.

(1) أسهل حل IMHO هو ربط Blas Lapack بشكل ثابت. ينشئ هذا الأسلوب ثنائيات ضخمة ولذلك لا أوصي به (على الأقل من قبلي).
(2) الحل الثاني الأسهل هو تثبيت DLL في numpy/core وهذا كل شيء.
(3) الحل الثالث هو فرض تبعية لحزمة Blas / Lapack خارجية ، والتي تم إصدارها وتحميل مكتبة Blas Lapack DLL مسبقًا. يضمن استخدام النقطة توفر الإصدار الصحيح من DLL.
(3) إذا كانت مثل هذه التبعية المقيدة غير مرحب بها ، فيمكن إضافتها إلى DLL الموفر من قبل numpy و scipy نفسها. يجب تحميل مكتبات DLL هذه _ فقط في الحالات_ ، حيث لا يتم تثبيت DLL خارجي ، وهذا يعني أنه من المفضل استخدام حزمة Blas / Lapack خارجية ولكنها ليست ضرورية تمامًا.
الإضافة الكبيرة لمثل هذا الحل هي أنه يمكن استبدال الإصدارات الأحدث التي تم إصلاح الأخطاء فيها من openblas / الأطلس دون إعادة تثبيت numpy / scipy.
(4) استخدام المانيفست و SxS. njsmith ، هل يمكنك ملء تفاصيل هذه الحالة؟

عذرًا - لقد أصلحت أذونات العجلات - هل تعمل الآن؟

آسف لعدم العودة إليك على تجميعات SxS. لم يكن تعليقي "اليائس" على SxS مفيدًا للغاية ، وسأحاول تفريغه.

السؤال هو ما إذا كان يجب علينا استخدام تجميعات SxS "الخاصة" ، وهي تجميعات SxS نستضيفها في الشجرة الثنائية الخاصة بنا. يمكن أيضًا مشاركة تجميعات SxS. تنتقل التجميعات المشتركة إلى مجلد نظام Windows الخاص بك ، ويجب تثبيتها بواسطة حزمة مثبّت MS . أعتقد أن هذا يعني أنه لا يمكن تثبيت التجميعات المشتركة عبر عجلة ، وعلى أي حال ستحتاج إلى أذونات المسؤول ، لذلك أعتقد أنه يمكننا رفض التجميعات المشتركة كخيار.

إذن - ما هي مشكلات استخدام تجميعات SxS الخاصة؟

المشكلة الأولى هي أننا سنشعل مسارًا جديدًا جدًا إذا حاولنا فعل ذلك. لا أعرف أي مشروع آخر مفتوح المصدر يستخدمهم. سألت ستيف داور عن تجميعات SxS. يعمل ستيف في MS وهو مشرف صيانة Python Windows الحالي. اقترح أن أتجنبهم. يبدو أنه لم يكن هناك من كان يعمل معه يعرفهم. كانت ملاحظاتي المرتبطة أعلاه محاولة لفهم الحالات القليلة التي يعرفها عن شخص ما (على ما يبدو) يستخدمها بنجاح. هناك عدد قليل جدًا من الموارد الجيدة لشرحها.

ذات صلة هي الملاحظة التي ذكرها كارل بالفعل أن MS نفسها تبدو متناقضة بشأن استخدامها. على سبيل المثال ، بالنسبة لوقت تشغيل MSVC ، وهو تطبيق واضح لتجميعات SxS ، يستخدمون أسماء DLL الفريدة بدلاً من ذلك (MSVCR90.DLL ، MSVCR100.DLL ، إلخ).

لاستخدام تجميعات SxS ، أعتقد أنه سيتعين علينا إضافة رمز التهيئة المعياري لكل وحدة نمطية مترجمة تحتاج إلى تحميل DLL آخر ، من أجل إنشاء "سياق تنشيط". تحرير: ذكرني Nathaniel أن Windows سيقوم تلقائيًا بتشغيل سياق تنشيط جديد إذا رأى دليلًا على "بيان" التجميع جنبًا إلى جنب المرتبط بـ DLL (والذي يمكن تضمينه في DLL ، ولكنه أيضًا ملف XML خارجي) .

لذا ، ليس ميؤوسًا منه ، ولكنه صعب.

أنا آسف لهذا السؤال الأساسي للغاية ، ولكن ، في نظام التشغيل Windows ، إذا قمت بتحميل مكتبة foo.dll تحتوي على my_symbol في وحدة امتداد واحدة ، فماذا يحدث إذا قمت بتحميل مكتبة bar.dll ، تحتوي أيضًا على my_symbol ، في وحدة امتداد أخرى؟ أفترض أنهما يمكن الوصول إليهما بشكل منفصل في عملي ، لذا فإن الامتداد الأول سيحصل على foo: my_symbol وسيحصل الملحق الثاني على bar:my_symbol ؟ يمكن لأي شخص أن يشير لي إلى مرجع؟

إذا كان هذا صحيحًا ، فمن المؤكد أن كل ما نحتاجه ، لتجنب جحيم DLL ، هو الحصول على اسم DLL الذي كان من غير المحتمل أن يتم استخدامه عن طريق الصدفة في نفس العملية (حيث لم يكن المستخدم ينوي استخدام DLL الخاص بنا بالضبط).

أثناء ربط كل رمز مرتبط بمكتبة DLL محددة تم تحديدها من خلال اسمها. أثناء وقت التشغيل ، يتعين على المرء التأكد من تحميل DLL الصحيح إذا كان من الممكن العثور على أكثر من DLL بالاسم نفسه. لذلك فإن ترتيب البحث مهم.
مثال تستخدم عجلات anaconda.org numpy مكتبة openblas بالاسم libopenblas_py_.dll لتجنب تعارض الاسم مع libopenblas غير القياسي ، dll الذي تستخدمه Julia.

تستخدم الإصدارات الأخيرة من julia الآن اسمًا مختلفًا libopenblas64_ لتعكس ABI غير القياسي الذي قمنا ببنائه. في 32 بت ، لا نعيد تسمية أي رموز أو اسم مكتبة نظرًا لعدم وجود سبب كبير لاختيار ints 64 بت في الواجهة هناك.

كان تظليل الأسماء للرموز داخل المكتبات المشتركة في الواقع مشكلة في نظام التشغيل Linux و OSX أكثر من النوافذ ، لكننا فعلنا نفس الشيء في كل مكان من أجل الاتساق.

على الرغم من أن هذا لا يستبعد الاحتمال في 32 بت حيث تكون ABI هي نفسها التي لم نتمكن من تحطيم بعضها البعض بطرق أخرى ، مثل الحاجة إلى إصدار قديم جدًا أو جديد جدًا للآخر.

لقد قمت بصقل عملية البناء قليلاً - راجع https://github.com/matthew-brett/np-wheel-builder

الآن العملية مؤتمتة بشكل معقول ، أعتقد أنه من العملي الاستمرار في بناء هذه العجلات خلال الإصدارات القليلة القادمة إذا كان علينا ذلك. يسعدني القيام بذلك بصفتي مدير إصدارات Windows حتى يصل mingwpy إلى المواصفات.

لقد اختبرت هذه العجلات على 32 بت و 64 بت Python 2.7 و 3.4 و 3.5 ، واختبرها عدد قليل من الآخرين أيضًا ، لذلك أعتقد أنها في حالة جيدة.

هل هناك أي شيء آخر يمكنني القيام به لطمأنتكم جميعًا بأن هذه الأشياء تستحق طرحها على pypi ، كما طلب OP؟

اهلا جميعا! أردت فقط الانتقال إلى هذه المناقشة لأنني شعرت بالإحباط بسبب عدم قدرتي على تثبيت numpy و scipy من المصدر لبعض الوقت ، لذلك من المفيد بالتأكيد أن أقرأ ما هو يجري على هذه الجبهة.

@ ماثيو بريت: هذا البرنامج النصي للأتمتة رائع . حتى لو لم يصل إلى PyPI تمامًا ، يبدو أن هذه طريقة قابلة للتطبيق جدًا لإنشاء numpy من المصدر (انظر هذه المشكلة التي فتحتها هنا ). إنه قريب جدًا أيضًا من القدرة على إنشاء scipy حيث يمكنني بناء كل شيء ، ولكن يبدو أن الاختبارات تتسبب في حدوث تعطل في مكان ما في Python.

أيضًا ، بالنسبة لأي شخص قام بالفعل ببناء عجلات numpy ، كنت أحاول تجميع وثائق مصقولة ومحدثة حول إنشاء هذه المكتبات من المصدر لتحل محل ما هو موجود حاليًا على الإنترنت ، لذلك سأكون ممتنًا للغاية مدخلات الناس على تلك الجبهة أيضًا!

شكرًا لك على التعليقات - وعملك على توثيق التصميم - الذي سيكون مفيدًا للغاية.

أعتقد أنك رأيت http://mingwpy.github.io - هناك قدر لا بأس به من الأشياء هناك ، بالطبع ، خاصة بمشروع mingw-w64 وسلسلة أدوات mingwpy.

شكرا لك @ ماثيو بريت! يمر numpy.test() . كان الاختبار f2py.py مشكلة في test_scripts() مع virtualenvs التي تم إصلاحها في numpy-SHAd3d2f8e ، لكنني أتلقى 3 تحذيرات ، 2 إهمال ووقت تشغيل واحد.

طلب أخير ، آمل أن يكون بسيطًا ، هل من الممكن عرض شارة بناء على repo np-wheel-builder و / أو PyPI؟ يبدو أن buildbot 0.8 يمتلكها ، وهناك حزمة / ريبو بيثون لجعلها تبدو جميلة ، BuildbotEightStatusShields-0.1 .

أيضًا ، لدي فضول ، لقد كنت خائفًا من إصدار ATLAS Windows 64 بت بسبب نقص معلمات الضبط. هل في الواقع "استغرق الأمر طوال اليوم" أم أن هناك مجموعة مناسبة من الافتراضات المعمارية؟

لمعلوماتك: أصدرت Continuum للتو Anaconda مع numpy محسّن من mkl. أعتقد أنهم كانوا يراقبون هذا الموضوع.

الآن ل scipy يبني مع نفس أطلس libs. هل يتطلب gfortran؟

نعم. وإلا فلن تتمكن من تجميع أي من ملفات .f في scipy . حظا سعيدا مع هذا! كما قلت سابقًا ، لقد اقتربت حقًا ، ولكن إذا تمكنت من اجتياز الاختبارات بنجاح ، فسيكون ذلك رائعًا!

نعم ، أخشى أن بناء أطلس استغرق حوالي 8 ساعات على آلة لا تفعل شيئًا آخر. البرنامج النصي لبناء ATLAS موجود في مستودع np-wheel-builder .

فيما يتعلق بالأخبار MKL ، فهذا رائع إذا كنت مستخدمًا conda ، على الرغم من أنني أعتقد أن استخدام توزيع Python مع numpy و scipy مثبت مسبقًا شيء تم تشجيعه لبعض الوقت. تحدث معي عندما يمكنك الحصول على مكتبات MKL نفسها مجانًا أيضًا. :)

للبناء مع gfortran - أعتقد أن mingwpy هو أفضل أمل لنا.

@ ماثيو بريت: نشكرك على الوقت الذي قضيته في بناء أطلس! لقد حاولت تشغيل البرنامج النصي الخاص بك من قبل ، وظلت أواجه مشكلات ، ربما بسبب عدم التوافق الخاص بالجهاز.

آسف على القضايا. لقد قمت للتو ببناء ثنائيات ATLAS في np-wheel-builder repo ، وكان ذلك مثبتًا حديثًا من Windows Server 2012 و 64 بت Cygwin ، مع إدراج إصدارات ATLAS و lapack الدقيقة. أرشيفات المصدر التي استخدمتها موجودة في http://nipy.bic.berkeley.edu/scipy_installers/atlas_builds/. إذا كان لديك نسخة أخرى من نظام أطلس ، يمكن أن تصبح مشعرة بسهولة.

هممم ... ربما هذا هو الحال. مرة أخرى ، أقدر ذلك كثيرًا نظرًا للجهود التي بذلتموها يا رفاق للقيام بذلك. إذا كنتم قادرون على إيجاد طريقة لطرح إصدارات ATLAS المتوافقة مع Windows والتي لا تتطلب الكثير من الوقت والموارد كما هو الحال الآن ، فسيكون ذلك رائعًا!

تضمين التغريدة

تحدث معي عندما يمكنك الحصول على مكتبات MKL نفسها مجانًا أيضًا. :)

راجع https://software.intel.com/sites/campaigns/nest/ و https://registrationcenter.intel.com/en/forms/؟productid=2558&licensetype=2 - أو هل تقصد المصدر؟

tkelman ، شاهدته للتو على موقع مشروع mingwpy @ carlk الجديد لكن ترخيص مجتمع Intel ليس لدى Nest أي ifort ، وبدون ذلك كيف scipy؟

tkelman : عفوًا ، لست متأكدًا من سبب نسيتي لترخيص المجتمع هذا. ومع ذلك ، يقوم tkelman بإحضار نقطة صحيحة.

tkelman : يمكنك إعطائها فرصة مع MinGW ، ولكن مما جربته ، هذا لا يعمل لسوء الحظ. لن يتجاوزك حتى numpy بسبب مشاكل التوافق.

mikofski صحيح ، لا يساعد scipy نظرًا لقلة المترجمين. الخيارات المتاحة اليوم فقط لإصدارات scipy ستكون mingwpy ، أو إصدار MSYS2 الشامل لجميع دول مجلس التعاون الخليجي في جميع الأوقات من Python (https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64- بيثون سكيبي). لن يكون الأخير بالطبع متوافقًا مع ثنائيات pypi أو cpython المبنية من msvc ، لذلك لن يعالج جميع الوحدات التي تتجاوز scipy.

@ Matthew-brett: ما هو العجز في السرعة لعجلات ATLAS مقابل openblas و / أو MKL؟

هل نظر أي شخص إلى PGI Fortran. لم يتم ذكره في موقع مشروعcarkl mingwpy . حاولت استخدامه مرة واحدة ، وذهبت بعيدًا إلى أسفل حفرة الأرانب تلك ، لكن لا يمكنني تذكر ماهية سدادة العرض. أعتقد أن الترخيص مسموح به رغم أنه مغلق المصدر. ربما ستلعب PGI Fortran بشكل أفضل مع MSVC؟

mikofski : ليس لدي ذلك أمامي ، لكن عندما نظرت إلى PGI العام الماضي ، أتذكر أن استنتاجي كان أنه أسوأ من Intel (من حيث إجبارك على إضافة قيود غير متوافقة مع البرمجيات الحرة والمفتوحة المصدر إلى ترخيصك) .

حسنًا ، ربما يمكن استهداف بعض صناديق التركيز الرقمية في حل BLIS / FLAME لبنى x86؟

من الواضح أن Nvidia / PGI ستساهم بواجهة Fortran الأمامية كمصدر مفتوح لـ LLVM بحلول نهاية هذا العام. https://www.llnl.gov/news/nnsa-national-labs-team-nvidia-develop-open-source-fortran-compiler-technology

حسنًا ، ربما يمكن استهداف بعض صناديق التركيز الرقمية في حل BLIS / FLAME لبنى x86؟

لا أعتقد ذلك. يبدو BLIS كمشروع غير صحي للغاية (والأكثر من ذلك هو libflame) ؛ القليل من النشاط من حيث الالتزامات ، وحركة مرور القوائم البريدية ، وما إلى ذلك. بالإضافة إلى أن لديهم تمويلًا كبيرًا (https://github.com/flame/blis#funding) ، لذلك ليس الأمر وكأن بضعة آلاف من الدولارات ستجعل هؤلاء بطريقة سحرية تنضج المشاريع.

لا أرى تمامًا من أين تأتي هذه المناقشة أو ستذهب إليها: لدينا حل مؤقت أكمله ماثيو تقريبًا (باستخدام ATLAS) ، والأهم من ذلك أن لدينا حل طويل الأجل يتم العمل عليه بنشاط كبير (MingwPy + OpenBLAS). علاوة على ذلك ، يتم استخدام OpenBLAS على نطاق واسع ؛ استخدام هذا المشروع في كل من Scipy stack و Julia يجب أن ينضج بشكل أسرع.

rgommers : ذهبت المحادثة إلى حيث ذهبت لأن mikofski وأنا كنا نحاول استخدام حل @ Matthew-brett لإنشاء scipy . ومع ذلك ، يبدو أن كلا منا يواجه نفس المشكلة: مترجم فورتران. لقد حاولت بنفسي استخدام gfortran.exe المثبت لكل من MinGW32 و MinGW64 دون نجاح كبير بسبب الكثير من العناصر الخارجية التي لم يتم حلها لسبب أو لآخر.

يستخدم بناء gfyoung Matthew MSVC. ليس هناك فائدة من محاولة استخدام gfortran مع MSVC ، فمن المعروف أنه لا يعمل. ملخص حالة البناء هو:

• لا فورتران ، إذًا يمكنك استخدام MSVC الآن.
• مع Fortran ، يمكنك استخدام MingwPy أو MSVC + ifort أو icc + ifort.
• بالنسبة إلى مكدس Scipy ، نريد حلاً مجانيًا يبني عجلات لـ numpy و scipy وما إلى ذلك ، لذلك ، MingwPy هو كذلك.

rgommers أنا آسف لعرقلة المحادثة. أنت محق تمامًا ، حل @ Matthew-brett للأعمال المعقدة ، ومشروع mingwpy من carlk ممول بالفعل من خلال num focus. سأحاول معرفة ما إذا كان بإمكاني إقناع شركتي بدعمها. أنا بالفعل عضو تركيز رقمي. في منتصف الطريق تقريبًا من خلال scipy 2829 وأعتقد أنني توصلت إلى نفس النتيجة. أتمنى فقط أن يعمل. على المدى القصير ، سنستمر في استخدام cgohlke أو التبديل إلى أناكوندا. شكرا لك مرة أخرى!

بخلاف دفع البنيات إلى pypi ، ربما تكون إحدى المشكلات الأخيرة لـ @ matthew-brett عبارة عن درع buildbot في إعادة إنشاء البرامج النصية الخاصة به؟ شكرا! ثم يمكن إغلاق هذا؟

قبل إغلاق هذا السؤال السريع: لقد قمت ببناء @ Matthew-brett numpy بحيث يشير إلى ATLAS. ومع ذلك ، عندما أحاول إنشاء scipy باستخدام ifort ، فإنه يلتقط أيضًا ملف site.cfg الآخر الذي يستخدم MKL الموجود في دليلي الرئيسي. أنا قادر بالفعل على البناء بنجاح مقابل numpy ، وتجتاز الاختبارات حفظًا لخطأين بسبب أخطاء التقريب الدقيقة. ومع ذلك ، لدي فضول ، ما الذي فعله scipy عندما قمت بإنشائه؟ هل استخدمت مكتبات MKL أم أنها حاولت استخدام مكتبات ATLAS التي تم إنشاؤها بالفعل باستخدام numpy ؟

يوجد ملخص لمجمعات Windows Fortran في https://github.com/numpy/numpy/wiki/Numerical-software-on-Windows

gfyoung - فقط من خلال مزيج من التخمين والذاكرة البعيدة - أعتقد أن scipy ستلتقط أولاً site.cfg في دليلها الخاص ، وإذا كان ذلك مفقودًا ، فسوف تلتقط تكوين البنية الخفية. وهذا بدوره سوف يشير إلى المكان الذي توجد فيه المكتبات ، وعندما قمت ببناء العجلات. لذلك ستحتاج إلى إعادة كتابة site.cfg لـ scipy لالتقاط مكتبات أطلس np-wheel-builder - يقوم البرنامج النصي build_numpy.py بعمل ذلك من أجل البناء الخشن.

يبدو BLIS كمشروع غير صحي للغاية (والأكثر من ذلك هو libflame) ؛ نشاط قليل من حيث الالتزامات وحركة مرور القائمة البريدية وما إلى ذلك.

لست متأكدًا من أنني سأسميهم غير صحيين ، لأنهم لا يحاولون أن يكونوا مشروعات مجتمعية تديرها البرمجيات الحرة والمفتوحة المصدر ؛ هم في الأساس عرض فردي ، وهم يحبونه بهذه الطريقة (في الوقت الحالي على الأقل). لقد كنت على اتصال معهم بشكل متقطع خلال العام الماضي ، والخبر السار هو أن التركيز الحالي لجهودهم ينصب بالضبط على الأشياء التي نحتاجها (اختيار نواة وقت التشغيل وتكوين خيوط وقت التشغيل) ؛ النبأ السيئ هو أنه ليس هناك الكثير للقيام به سوى الانتظار حتى يقوم المهندس المعماري بإعادة ترتيب الأشياء حسب رغبته. ربما ستشهد 6 أشهر بعض النتائج؟

يبدو أن BLIS وما إلى ذلك يعد خيارًا بعيدًا إلى حد ما في هذه المرحلة ، وأنه سيتعين علينا التخطيط للحالة التي لا ينجح فيها ذلك.

ناثانيال - أي اقتراحات حول مكان الحصول على معايير جيدة؟ لا أعتقد أن numpy.bench() يفعل أي شيء بعد الآن. حاولت تشغيل asv ، لكن العديد من الاختبارات فشلت لأن Windows numpy لا يحتوي على complex256 .

أعتقد أن asv هذا العمل مفيدة؟ أو حتى %timeit np.dot(big_array, other_big_array) سيكون مفيدًا للحصول على الأقل على فكرة بسيطة عن المكان الذي نقف فيه :-)

راجع أيضًا ، إليك حل عام لمشكلة مساحة الاسم العالمية لـ Windows DLL ، مما يسمح لنا بكتابة Windows delocate : https://github.com/njsmith/redll

لسوء الحظ ، يكسر فشل مجمع ASV256 تسلسلًا كاملاً من الاختبارات عبر أنواع dtypes. أعتقد أنه لن يكون من الصعب جدًا إصلاحه.

اختبار بسيط مع هذا:

def test_dot():
    """
    Test the dot product
    """
    i = 1000
    a = random((i, i))
    b = numpy.linalg.inv(a)
    result = numpy.dot(a, b) - numpy.eye(i)

يشير إلى أنه ، كما حذر كلينت والي من قبل - 64 بت ATLAS ليس محسنًا بشكل جيد على Windows. مع MKL 64 بت عبر عجلات كريستوف جولكه:

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

مع عجلاتي المصممة باستخدام ATLAS 64 بت:

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

الفرق أقل بكثير مع عجلات 32 بت (على آلة مختلفة 32 بت). MKL:

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

مقابل أطلس:

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

rcwhaley - نسخة لك ، في حال كان لديك بعض الأفكار هنا. هذا هو ATLAS 3.10.1 ...

إليك جهاز آخر يعمل بنظام Windows 64 بت مزود بمعالج أكثر حداثة - يعرض أيضًا تباطؤًا بمقدار 3 أضعاف.

MKL:

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

أطلس:

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

نعم ، مشكلة 256 المعقدة ليست صعبة الإصلاح: https://github.com/numpy/numpy/pull/7251

3x عدد كبير ، ولكن ليس بنفس الدرجة من الدراما كما هو الحال مع lapack_lite أليس كذلك؟ أعتقد أنه لا بأس من حل قصير المدى. وهذا ليس مثل مثبِّتات exe 32 بت القديمة التي كانت أفضل.

راجع أيضًا ، إليك حل عام لمشكلة مساحة الاسم العالمية لـ Windows DLL ، مما يسمح لنا بكتابة حذف Windows: https://github.com/njsmith/redll

بيان رخصة لطيف :)

تم البحث عنgfyoung 'site.cfg' في:

1) دليل ملف setup.py الرئيسي قيد التشغيل.
2) الدليل الرئيسي للمستخدم الذي يقوم بتشغيل ملف setup.py كـ ~/.numpy-site.cfg
3) دليل على مستوى النظام (موقع هذا الملف ...)

rgommers أنا آسف لعرقلة المحادثة.

لا تقلق ، لا شيء خرج عن مساره.

أنت محق تمامًا ، حل @ Matthew-brett للأعمال المعقدة ، ومشروع mingwpy من carlk ممول بالفعل من خلال num focus. سأحاول معرفة ما إذا كان بإمكاني إقناع شركتي بدعمها. أنا بالفعل عضو تركيز رقمي. في منتصف الطريق تقريبًا من خلال scipy 2829 وأعتقد أنني توصلت إلى نفس النتيجة. أتمنى فقط أن يعمل. على المدى القصير ، سنستمر في استخدام cgohlke أو التبديل إلى أناكوندا. شكرا لك مرة أخرى!

رائع. ومن الجيد أن ترى أنك مهتم بـ MingwPy. لاحظ أنه يحتوي على ML الخاص به الآن ، والذي قد يكون مهمًا: https://groups.google.com/forum/#!forum/mingwpy

rgommers ، @ Matthew-brett: آه ، نعم ، يبدو أنه تم البناء باستخدام MKL مسبقًا. لقد وجهت مباشرة site.cfg إلى إصدار ATLAS ، و scipy يبني لكن segfaults أثناء الاختبارات. قريب جدا!

rgommers - نعم - الأداء أسوأ بكثير بدون ATLAS (مع lapack_lite):

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

أعتقد أن السؤال المتبقي هنا هو ما إذا كان الأمر يستحق التوحيد القياسي لـ OpenBLAS numpy (مع اجتياز جميع الاختبارات المعقدة) ، مع قبول المخاطرة بأن هذا سيكون أكثر احتمالًا للتسبب في أخطاء رقمية في المشاريع التي تستخدم numpy.

قد تكون إحدى الحجج للقيام بذلك أنه يبدو أننا سنضطر إلى السير في هذا الاتجاه على المدى القصير / المتوسط ​​، وقد يكون من الأفضل أن نبدأ الآن ونلزم أنفسنا بمطاردات الأخطاء البائسة التي ستترتب على ذلك. على الأقل سنكون بصحبة مشرفين جوليا.

لدى Numpy أيضًا مجموعة مختلفة إلى حد ما من تحمل المخاطر مقابل مقايضات الأداء ، ونسبة المستخدمين إلى المطورين ، عن Julia. لذلك أعتقد أنه قد يكون من المنطقي للغاية بالنسبة لـ numpy اتباع نهج أكثر تحفظًا والتعامل ببطء ولكن يمكن الاعتماد عليه كإعداد افتراضي ، والعمل على السماح لـ openblas كخيار غير افتراضي في الاختيار. على الرغم من أن أوقات الإنشاء التي تبلغ 8 ساعات لا تبدو ممتعة ، فلا عجب أنه لم يسألنا أحد عن استخدام Atlas مع Julia.

العمل على السماح لـ openblas كخيار غير افتراضي

المشكلة هي أنني لست متأكدًا حقًا من كيفية عمل هذه العملية: - /. ليس لدينا أي طريقة جيدة لتوزيع إصدارات بديلة على المستخدمين (على المدى الطويل ، آمل أن نتمكن من الحصول على متغيرات بناء على pypi مثل numpy[openblas] وما إلى ذلك ، لكن هذا لن يحدث في أي وقت قريبًا) ، ليس لدينا أي طريقة لتحسين تصميمات openblas باستثناء توزيعها وانتظار تقارير الأخطاء ، والبديل الرئيسي لبناء ATLAS للأشخاص الذين لديهم الدافع للبحث عن أحدهم لن يكون إصدار openblas ، بل سيكون MKL يبني من طرف ثالث: - /.

أعتقد أن هناك خيارًا آخر يمكن وضعه على الطاولة وهو توزيع إصدارات BLIS باستخدام مرجعها / نواة SSE2. نظرًا لأن BLIS لا يزال لديه تكوين وقت الإنشاء فقط ، فلن يكون هذا منافسًا لـ openblas ، ولكنه قد يكون منافسًا لـ ATLAS ، وتتمثل الفوائد مقابل ATLAS في أن وقت الإنشاء أسرع بكثير ، وفرصة أن يكون حلاً جيدًا على المدى الطويل يصعب تقديرها ولكن بالتأكيد أفضل من كون أطلس حلاً جيدًا طويل الأجل (والذي سأضعه عند الصفر). إذا كنا سنقوم بمهمة ضمان الجودة على أي حال ، فسنقوم على الأقل بتوجيه تلك الطاقة إلى شيء قد يكون له مستقبل.

بعض الأسئلة التي قد تحتاج إلى إجابة قبل التفكير بجدية في هذا الخيار:

(1) لست متأكدًا مما إذا كان دعم BLIS متعدد مؤشرات الترابط منافسًا لـ ATLAS (أعرف أن هناك بعض خيارات خيوط المعالجة المتعددة في المصدر ، وأنا أعلم أن المطور الرئيسي لا يعتبره "تم" حتى الآن ، أي منافسة لـ MKL ، ولكن هناك متسع كبير بين ATLAS و MKL.)

(2) لهذه المسألة ، ليس لدي أي فكرة أيضًا عن كيفية تسعير BLIS في وضع غير مضبوط على تلك المعايير المذكورة أعلاه.

(3) لم أحاول في الواقع إنشاء BLIS على النوافذ ، وهناك مشكلة للتعامل معها أنها مجرد BLAS ، وليست LAPACK - لست متأكدًا من حجم المشكلة التي تخص numpy.

ما مدى استجابة BLIS لتقارير الأخطاء؟ يبدو أن Openblas جيد جدًا
عن هذا.

يوم الإثنين 15 فبراير 2016 الساعة 3:48 مساءً ، ناثانيال ج. سميث <
[email protected]> كتب:

العمل على السماح لـ openblas كخيار غير افتراضي

المشكلة هي أنني لست متأكدًا حقًا من كيفية عمل هذه العملية: - /.
ليس لدينا أي طريقة جيدة لتوزيع إصدارات بديلة على المستخدمين (في ملف
على المدى الطويل ، آمل أن نتمكن من إنشاء متغيرات بناء على pypi مثل numpy [openblas]
وهكذا دواليك ، لكن هذا لن يحدث في أي وقت قريب) ، ليس لدينا أي طريقة لذلك
تحسين تصميمات openblas باستثناء توزيعها وانتظار الخطأ
التقارير ، والبديل الرئيسي لأطلس يبني للأشخاص الذين هم
الدافع للبحث عن واحد لن يكون بناء openblas ، بل سيكون MKL يبني
من طرف ثالث: - /.

أعتقد أن هناك خيارًا آخر يمكن طرحه على الطاولة وهو توزيع BLIS
يبني باستخدام مرجعهم / نواة SSE2. لأن BLIS لا يزال لديه بناء فقط
تكوين الوقت لن يكون هذا منافسًا لـ openblas ، ولكنه قد يكون كذلك
منافسة مع ATLAS ، والمزايا مقابل ATLAS هي أن البناء
الوقت أسرع بكثير ، وفرصة أن يكون على المدى الطويل
يصعب تقدير الحل ولكنه بالتأكيد أفضل من كون أطلس حسنًا
حل طويل الأمد (والذي سأضعه عند الصفر). إذا كنا سنكون QAing
شيء على أي حال ، على الأقل سنوجه تلك الطاقة إلى شيء ما
قد يكون له مستقبل.

بعض الأسئلة التي قد تحتاج إلى إجابة قبل التفكير بجدية في ذلك
اختيار:

(1) لست متأكدًا مما إذا كان دعم BLIS متعدد مؤشرات الترابط مناسبًا أم لا
تنافسيًا مع ATLAS (أعلم أن هناك بعض خيارات خيوط المعالجة المتعددة في
المصدر ، وأنا أعلم أن المطور الرئيسي لا يعتبره كذلك
"تم" حتى الآن ، أي التنافس مع MKL ، ولكن هناك متسع كبير بينهما
ATLAS و MKL.)

(2) في هذا الصدد ، ليس لدي أي فكرة أيضًا عن كيفية تسعير BLIS في وضع غير مضبوط
على تلك المعايير أعلاه.

(3) لم أحاول بالفعل إنشاء BLIS على النوافذ ، وهناك
مشكلة للتعامل معها ، إنها مجرد BLAS ، وليست LAPACK - لست متأكدًا من كيفية القيام بذلك
الكثير من هذه المشكلة هو numpy.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -184387401.

أعتقد أن libflame هو مكافئ lapack في blis. توجد واجهة توافق lapack2flame موصوفة في المستندات المرجعية .

ما مدى استجابة BLIS لتقارير الأخطاء؟

لا نعرف بعد.

بدون تجربة BLIS ، أعتقد أنه من الجنون الذهاب وشحن ثنائيات غير معقدة مبنية على ما هو أساسًا مشروع رجل واحد منخفض النشاط يستخدمه عدد قليل جدًا من الناس.

لم أر سببًا وجيهًا في هذا الموضوع بعد للانحراف عن خطة MingwPy + OpenBLAS. تعد ثنائيات No-scipy-ATLAS-MSVC طريقة جيدة للحصول على فجوة مؤقتة ، ولكنها أقل أهمية من حل MingwPy على المدى المتوسط ​​/ الطويل ، وإذا تحولت الفجوة المؤقتة إلى جهد كبير في حد ذاتها ، فأنا أقول إنها لا تستحق الجهد المبذول .

تشير مستندات BLIS / libflame إلى أنه إذا كنت سأحاول إنشاء مكتبة BLAS / LAPACK كاملة على Windows ، فسيكون ذلك مسارًا وحيدًا.

يسعدني القيام بذلك بمجرد موافقة المطورين على أن ذلك يجب أن يعمل ويتم دعمه.

لطالما كانت ATLAS هي المكتبة الافتراضية على نظام Linux. لا يبدو من غير المعقول تخيل أن هذا قد يكون هو الحال بالنسبة للبنيات المتوافقة مع Windows BSD لفترة من الوقت.

tkelman - شكرًا على تحليلك - أعتقد أنك على حق ، يجب أن يركز هذا الشخص الحزين على الصواب. ولكن ، سيكون من الجيد توحيد الجهود للاعتماد على بعض أخطاء OpenBLAS الأكثر إرهاقًا وتطوير اختبارات أكثر شمولاً. يتبادر إلى الذهن خطأ OpenBLAS - غامض إلى حد ما ، ويصعب تصحيحه.

أعتقد بالنسبة لهذه المشكلة تحديدًا ، توفير عجلات غير مربعة على pypi بحيث يتم تثبيت مستخدم غير رسمي للحزمة "x" التي تعتمد على "y" (على سبيل المثال: matplotlib) التي تعتمد على numpy باستخدام pip ، دون التسبب في قيام المستخدم العادي برمي يرفعون أيديهم ويقولون شيئًا مثل ، "بايثون صعبة للغاية." والعودة إلى MATLAB. يقول Zen of Python أنه يجب أن تكون هناك طريقة واحدة واضحة للقيام بذلك. ومع ذلك ، فإن أي شيء على pypi بواسطة numpy على وجه الخصوص يحمل وزنًا معينًا أنه مستقر ، أو أكثر من مشروع جانبي عشوائي ، مع إمكانية استثناء cgohlke. من الواضح أن الفكر والأناكوندا يُنظر إليهما على الأقل في الصناعة على أنهما أكثر استقرارًا.

أعتقد على المدى القصير أن بناء ATLAS يجب أن يتماشى مع الرسالة التحذيرية التي مفادها أنه لا يمكن البناء باستخدام scipy. إذا كان بالإمكان أتمتة هذا buildbot ، فسيتم ذلك ، أليس كذلك؟ نأمل أن تكون إصدارات ATLAS المستقبلية التي تبلغ مدتها 8 ساعات نادرة. ربما في يوم من الأيام سيتم حل مشكلة windows 64bit. مشكلة استثناء SSE2 هي المشكلة ، لذا هناك رسالة تحذير أخرى على pypi. كما أن ATLAS هو المعيار الموجود بالفعل في نظام التشغيل Linux وكان هو المعيار في حزم superpack السابقة bdist_winst التي تضفي مزيدًا من الدعم على هذا المسار للأمام.

ثم في المستقبل القريب ، كنت قد قررت بالفعل على mingwpy. يوجد هنا العديد من الخيارات التي لا يلزم حلها الآن.

على المدى الطويل أنا متحمس لأن اللهب هو المستقبل. إنه لأمر مخيف بعض الشيء أن تعتمد العديد من أدواتنا الرياضية على كود FORTRAN من السبعينيات. حل التيار المتردد فقط هو اختراق رئيسي و IMO شيء لدعمه بحماس.

ولكن دائمًا ما يكون المزيد أفضل للمطورين ذوي الخبرة ، لذا فإن الاحتفاظ بالوثائق حيًا للخيارات غير القياسية يعد أمرًا جيدًا أيضًا إذا كان لدى هؤلاء المطورين ذوي الخبرة الوقت والميل للبناء والاختبار في ذلك الوقت.

إذا لم تحاول استخدام أحد النوى المحسّنة في blis ، فمن المحتمل ألا تواجه المشكلة (تحرير: مفرد) التي فتحتها هناك منذ عام 2014. أعتقد أن نظام الإنشاء لا يستخدم سوى الارتباطات الرمزية لـ kernels ، لذلك لن تخلط بين git msys2 إذا كنت ستحاول إنشاء التكوين المرجعي فقط هناك. عمل البناء من cygwin آخر مرة حاولت فيه ، على الرغم من أنه كان منذ بعض الوقت ولا يمكنني تذكر ما قد أحتاجه لتعديله محليًا. الأمر يستحق البناء والاختبار والقياس إذا كان البديل هو أطلس ، لكن اعتبره غير مثبت ، وبالتالي فهو يمثل مخاطرة كبيرة بطريقته الخاصة حتى تقوم بذلك.

mikofski لكي نكون منصفين ، Lapack من التسعينيات ، إنه حقًا فيل فورتران في الغرفة.

tkelman : لكي أكون واضحًا ، كانت المشكلات التي قدمتها خاصة بنظام إنشاء Windows الأصلي ، أليس كذلك؟ بدافع الفضول ، جربت للتو التحويل المتقاطع blis للنوافذ من لينكس (باستخدام المترجم المتقاطع mingw-w64 المثبت من حزم دبيان) ، وفوجئت بأن الأمر استغرق دقيقتين فقط. لقد قمت بعمل "./ تكوين المرجع ؛ make -j4 CC = x86_64-w64-mingw32-gcc AR = x86_64-w64-mingw32-ar CPICFLAGS =" وعمل كل شيء للتو. (الغرض من CPICFLAGS= هو فقط منع مجموعة من التحذيرات حول "تجاهل -fPIC ، لأن هذا هو الخيار الافتراضي" ، وربما لم أكن بحاجة حتى إلى تجاوز AR ، ولكن مهلاً لماذا لا.) تلقيت بعض التحذيرات حول printfs في bli_pool.c و bli_fprintm.c التي تستخدم %ld لطباعة intptr الأعداد الصحيحة ، لذلك من المحتمل أن يكون هناك عدد قليل من مكامن الخلل في LLP64 للعمل بها.

rgommers :

بدون تجربة BLIS ، أعتقد أنه من الجنون الذهاب وشحن ثنائيات غير معقدة مبنية على ما هو أساسًا مشروع رجل واحد منخفض النشاط يستخدمه عدد قليل جدًا من الناس.

أنت محق تماما! المشكلة هي أن كل خياراتنا رهيبة :-(.

لذلك من الواضح أن MKL لديها ترخيص سيء بالتأكيد.

يتمتع ATLAS بأداء سيئ بالتأكيد لن يتحسن أبدًا.

و OpenBLAS ، أعتقد أن لدينا الدليل لنقوله في هذه المرحلة ، إنه ليس قابلاً للصيانة ومن غير المحتمل أن يصبح قريبًا :- (. المشروع عمره خمس سنوات ، ولا يزال يحتوي على أشياء محطمة بشكل أساسي مثل مثال جوليان العشوائي volatile s ورمز الترابط الذي لا يستخدم كائنات المزامنة ، لا يوجد اهتمام واضح في المراحل الأولى لإصلاح هذه الأشياء ، ولا يزال الأمر كذلك بمجرد نشر الثنائيات إلى مجموعة صغيرة (مناقشة معقدة) للاختبار ، نعود فورًا إلى 2-3 أعطال غامضة تمامًا أو يصعب إعادة إنتاجها وأخطاء نتائج غير صحيحة. وتقدم ورقة BLIS حالة مقنعة إلى حد معقول تتعلق بحدود بنية GotoBLAS الأساسية ، بدلاً من شيء يمكن إصلاحه بسهولة عن طريق قضاء المزيد من الوقت في تلميع الأشياء. (تتطلب الطريقة التي يتم بها تجميع GotoBLAS الكثير من التعليمات البرمجية ASM الصعبة الجديدة في كل مرة يتم فيها إصدار بنية دقيقة جديدة ، وبالتالي فإن نسبة الوقت المستغرق في إضافة كود جديد هش / أمضى الوقت ستابليزي إن التعليمات البرمجية القديمة الهشة لا تعمل لصالحك. لاحظ أن الخطأ الأكثر استنساخًا في قائمة المناقشة المعقدة هو الخطأ الذي نشك في أنه يكمن في نواة Core2 الخاصة بـ OpenBLAS ، وهي بنية معمارية دقيقة تم إيقافها منذ 5 سنوات.)

لذا فإن السبب الذي يجعلني أستمر في طرح BLIS ليس أنني أعتقد أن BLIS هو الحل بالتأكيد ، ولكن كنوع من التفاؤل المحسوب: تصبح BLIS _might_ بنفس سرعة MKL / OpenBLAS ، وموثوقة مثل ATLAS / MKL ، ومنفتحة على المجتمع- المساهمات مثل OpenBLAS ؛ أو مرة أخرى ، قد لا يكون كذلك. ولكن لا يبدو أن هناك أي مشاريع أخرى لديها أمل حقيقي في تحقيق كل هذه المعايير. [وهذا لا يشير حتى إلى المزايا الأخرى ، مثل حقيقة أنه يمكن أن يدعم المصفوفات المتتالية محليًا ؛ إنه ليس بعيدًا عن التصور ، فقد نتمكن من حذف جميع أكواد إرسال BLAS الفظيعة الخاصة بنا.]

تم صيانة IIUC ، GotoBLAS بواسطة مطور واحد بدوام كامل (Kazushige Goto) يعمل في UT Austin مع Robert van de Geijn في دور الباحث الرئيسي. تتم صيانة BLIS بواسطة مطور واحد يعمل بدوام كامل (Field G. Van-Zee) يعمل في UT Austin مع روبرت فان دي جيجن في دور الباحث الرئيسي. لذلك ليس الأمر كما لو أن هذا لا يمكن أن يعمل :-) ولكن نعم ، لن يحدث ذلك بطريقة سحرية إذا انتظرنا - إذا كان هناك مجتمع من المطورين حوله ، فسيكون ذلك لأن بعض المجتمعات قد ظهرت الحديقة الأمامية بها خيام مثل "مرحبًا ، ها نحن ذا ، نحن نتحرك ونجعل هذا يعمل من أجلنا ، آمل ألا تمانع". وما نحتاج إلى معرفته حقًا لتحديد قابلية التطبيق على المدى الطويل هو ، مثل "مدى موثوقيتها حقًا" و "مدى قابليتها للتصحيحات" والأشياء التي لا يمكننا معرفتها ما لم نبدأ في اختبارها وإرسالها بقع وهلم جرا.

في الختام: لا أعرف بجدية ما هو أفضل خيار لدينا ، ولكن يبدو أن وضع أصابع قدمنا ​​في مياه BLIS فكرة جيدة ؛ حتى إذا قررنا أننا نريد الانتظار ، فسنتعلم شيئًا ما على الأقل.

لقد تقدمت بالعديد من القضايا وواحدة أو اثنتين من العلاقات العامة. حقيقة وجود روابط رمزية في المستودع تعني أن البناء من msys2 معطل (أو يعمل فقط إذا قمت بتعيين خيارات msys2 بطريقة معينة). يجب أن يعمل البناء المتقاطع من cygwin أو linux (لا أثق في النبيذ لإجراء الاختبارات على الرغم من ذلك) ولكن واجهت مشكلات في عام 2014 مع malloc المحاذاة ، وخطأ نواة الجسر الرملي في الاختبار. لقد أعدت للتو بناء حبات الجسر الرملي على أحدث نسخة رئيسية من blis باستخدام تقاطع cygwin (على كمبيوتر محمول جديد من نوع skylake) وقد يختفي segfault الآن. من يدري متى أو ما الذي تم إصلاحه ، يجب أن ينقسم.

أعتقد أن هذا قد تم ذكره من قبل ، ولكن يمكننا إنشاء ثنائيات ATLAS لـ 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 للتحقق من وحدة المعالجة المركزية الحالية والتحميل المسبق للمكتبة المطابقة.

اقترحت فعل الشيء نفسه بشكل أساسي ، ولكن بالنسبة إلى blis بدلاً من الأطلس ، إلىnjsmith. يجدر أيضًا مقارنة مدى جودة عمل الخيوط في blis مقابل الأطلس. تكوين مرجع blis لا يمكّن الترابط افتراضيًا ، على الرغم من أن التغيير والتبديل في تعريف في ملف الرأس يجب أن يكون كل ما هو مطلوب لتبديل ذلك.

قمت بإعداد Appveyor لبناء الثنائيات. التكرار الحالي للبناء يتلاشى هنا: https://ci.appveyor.com/project/matthew-brett/np-wheel-builder/build/1.0.10

تصل العجلات المصنعة هنا: https://84c1a9a06db6836f5a98-38dee5dca2544308e91131f21428d924.ssl.cf2.rackcdn.com

يجب أن يكون من السهل تسوية أي مكامن الخلل الأخرى في تصميم Appveyor ، لذلك أعتقد أن هذه العجلات جاهزة للتحميل إلى pypi عند الانتهاء من ذلك ، ويفترض أن يكون ذلك غدًا في وقت ما.

rgommers ، @ Matthew-brett: بخصوص site.cfg ، يبدو أن إجابتك تنطبق فقط على numpy . يبدو أن scipy لا يبحث عن 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؟

قد تكون فكرة جيدة أن يكون لديك ملاحظة ثم على pypi تشرح / تربط لشرح الفرق بين هذه العجلات وتلك من خلال gohlke (mkl) لاستباق الارتباك من قبل الأشخاص الذين يتساءلون عن سبب ظهور العجلات الآن على pypi وما الفرق بينهم.

سؤال جانبي ، آسف ، لكني كنت أتساءل ماذا

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

في النص appveyor يعني؟

اقتراح جيد حول الشرح - سأحاول العمل على كيفية إضافة ذلك لهذا الإصدار الحالي.

تضيف العجلة> 0.26 علامة ABI إضافية إلى عجلة Windows. العجلة == 0.26 تعطي اسم عجلة مثل هذا:

numpy-1.10.4-cp27-none-win32.whl

باستخدام Wheel> 0.26 ، تحصل على علامة ABI إضافية ، مثل هذا:

numpy-1.10.4-cp27-cp27m-win32.whl

(على ما أظن) - والذي يحدد Windows ABI. هذا أمر مزعج لأن النقطة السابقة لن تقوم بتثبيت هؤلاء الرجال ، لذلك يبدو لي أن اسم no-ABI أفضل في الوقت الحالي.

حسنًا - أقترح إضافة هذا النص إلى صفحة pypi الحالية:

جميع العجلات التي يتم توزيعها من pypi مرخصة من BSD.

يتم ربط عجلات Windows بمكتبة ATLAS BLAS / LAPACK ، وهي مقيدة بتعليمات SSE2 ، لذلك قد لا تقدم أداء الجبر الخطي الأمثل لجهازك. راجع http://docs.scipy.org/doc/numpy/user/install.html لمعرفة البدائل.

سأقول بشكل مختلف:

تتميز عجلات Windows هذه بأداء الجبر الخطي دون المستوى الأمثل (رابط إلى معيار مثل http://speed.python.org) ، لأنها مرتبطة بمكتبة ATLAS BLAS / LAPACK ، والتي تقتصر على تعليمات SSE2 (والتي يجب أن تكون التعليمات غير المقيدة بها) كن هناك؟). إذا كنت بحاجة إلى أداء ، فيمكنك دعم مشروع mingwpy الذي يهدف إلى تحقيق المزيد من الأداء لملحقات Python المجمعة على هذا النظام الأساسي. نرى ؟؟؟ للحصول على التفاصيل و http://docs.scipy.org/doc/numpy/user/install.html للبدائل.

حسنًا - إصدارات mingwpy / scipy الحالية تستخدم openblas ، لكنني أعتقد أن هذا لا علاقة له بـ mingwpy vs MSVC كمترجم. يمكننا أيضًا شحن openblas بهذه العجلات ، لكنني كنت قلقًا من أن openblas لم يكن موثوقًا به بدرجة كافية لاستخدامه في عجلة قياسية ندعمها.

يبدو OpenBlas مستقرًا بدرجة كافية ، وأنا أعلم أن Anaconda يستخدمه لنظام التشغيل Linux
يبني الآن. لا توجد أي إصدارات محدثة من Windows Python 3.5 x64
هناك ، تظهر المعايير أنها تساوي MKL تقريبًا. سأحاول بالتأكيد إذا
يمكن لشخص ما أن يجمع العجلة.
في 16 شباط (فبراير) 2016 ، الساعة 10:36 مساءً ، كتب "Matthew Brett" [email protected] :

حسنًا - إصدارات mingwpy الحالية numpy / scipy تستخدم openblas ، لكني
أعتقد أن هذا ليس له علاقة بـ mingwpy vs MSVC كمترجم. يمكننا أيضا الشحن
openblas بهذه العجلات ، لكنني كنت قلقًا من أن openblas لم يكن بعد
موثوقة بدرجة كافية لاستخدامها في عجلة قياسية ندعمها.

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -185017546.

موافق. أنا في حيرة من أمري بشأن مصدر الأداء دون المستوى الأمثل - فأنا لا أستخدم مكتبات BLAS هذه ولا أعرف ما الذي تفعله وما هو الفرق ، لذا فإن شرح هذه الخيارات للبشر يساعد على أن يصبحوا .. . =) اعتقدت أن عدم وجود مترجم مفتوح مع الأداء الأمثل هو المشكلة.

mrslezak : بخصوص OpenBLAS ، يمكنني أن أتفق معه بالتأكيد. يبدو أن حزمة OpenBLAS المتوفرة على Cygwin ، إلى جانب حزمة Lapack ، قادرة على بناء كل من NumPy و SciPy دون مشاكل.

mrslezak : أين يمكنني العثور على معلومات حول المعايير؟ أحاول كتابة وثائق حول إنشاء المصدر من Windows مقابل scipy.org ، وسيكون هذا مرجعًا رائعًا لأي شخص يحتاج إلى أداء مع هذه المكتبات.

ربما نهج البندقية هو الفكرة الصحيحة؟ شيء مثل:

• مستقرة: أطلس مع الأداء ، والمحاذير sse2
• ديف: OpenBLAS انظر mingwpy و binstar
• البديل: MKLcgohlke و MKLcontinuum وenthought
  تحذير: الثنائيات غير متوافقة.
  روابط لمزيد من المعلومات في scipy و Matthew Brett's Github numpy wiki

techtonik أتوقع أن يكون أداء دول مجلس التعاون الخليجي أسوأ إلى حد ما من MSVC أو ICC على كود مكافئ يمكن لجميع هؤلاء المجمعين بناءه. تكمن المشكلة في عدم وجود مترجم مجاني (متوافق مع python.org-cpython) يمكنه إنشاء نسخة تنافسية من Lapack ، الموجودة في Fortran (يحتوي SciPy أيضًا على مكونات Fortran أخرى). يمكن بالفعل بناء جزء BLAS النقي من OpenBLAS (وربما Atlas أيضًا) باستخدام MSVC ، لكن MSVC لا يمكنها بناء أي من القطع التي تتطلب تجميعًا مضمّنًا لذا لن تكون تنافسية أيضًا.

ليس لدي ملف MKL 64 بت في متناول يدي (قد يكون لدي 32 بت واحد من conda في مكان ما إذا ذهبت للحفر) ، ولكن فيما يلي بعض المعايير التي يتم تشغيلها في Julia لمقارنة Atlas dll الذي @ Matthew-brett مبني مقابل المرجع والرملية- تكوينات الجسر لـ BLIS ، وبناء OpenBLAS الذي يأتي مع Julia https://gist.github.com/54da587b01b7fb163103

الملخص: openblas (على skylake ، أحدث نواة openblas is haswell) أسرع 23 مرة من أطلس ، 44x أسرع من blis المرجعي ، و 5.5 مرة أسرع من sandybridge blis. قد أحاول haswell blis لمعرفة مدى قربه.

همهمة - لا أفترض أن لديك نصوص بناء ملقاة لتجميعات BLIS الخاصة بك؟

هل تعتقد أن الأمر يستحق إنشاء نماذج BLIS لمجموعة من المعالجات واختيار واحدة في وقت التشغيل؟ هل هناك مجموعة فرعية صغيرة من المعالجات يمكنها التقاط معظم أداء معظم المعالجات؟

إنه في التعليقات ، لكن هنا (تشغيل في cygwin 64)

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

إليك ما هو متاح لديهم: https://github.com/flame/blis/tree/master/config

من حيث Intel x86 ، فإن المرجع و dunnington و sandybridge و haswell سيغطي نطاقًا جيدًا جدًا. أيضًا جرافة وجرافة و carrizo لـ AMD (التي توقفت مؤخرًا عن تطوير ACML لصالح BLIS ، لذلك هذا تصويت مؤيد على الأقل).

يوجد بعض كود الكشف التلقائي في https://github.com/flame/blis/tree/master/build/auto-detect والذي قد يكون قابلاً لإعادة الاستخدام (يتم تشغيله حاليًا فقط في وقت التكوين في BLIS ، لكن هذا لا يعني ذلك لا يمكن إعادة استخدامها لأغراض أخرى) ، اعتمادًا على ما إذا كان هناك بالفعل جزء من رمز تعريف عائلة وحدة المعالجة المركزية في Python موجود حوله تريد استخدامه.

اعتمادًا على ما إذا كان هناك بالفعل جزء من رمز تعريف عائلة وحدة المعالجة المركزية في Python

هل هذا يساعد؟ http://stackoverflow.com/a/35154827/239247

أنت في الغالب تريد عائلة المعالج المشتقة من ذلك ، لكن https://github.com/flame/blis/blob/master/build/auto-detect/cpuid_x86.c ليست طويلة أو معقدة تمامًا. يقوم مصدر numexpr المرتبط من SO بإجراء مطابقة regex على إخراج السلسلة (على الأقل على نظام Linux) ، ولا يبدو أنه يحتوي على العديد من البنى الحديثة المدرجة.

openblas أسرع بـ 3.4 مرة من Haswell blis ، و 17x أسرع من dunnington (أساسًا مثل nehalem penryn على ما أعتقد) blis. المثير للاهتمام هو أنني لا أعتقد أن تعدد مؤشرات الترابط يعمل بشكل جيد على هذه المسارات. يمكّن الإعداد الافتراضي openmp لـ sandybridge و haswell ، وربما تعمل pthreads mingw بشكل أفضل. لا يبدو أن تعيين OMP_NUM_THREADS يحدث فرقًا كبيرًا.

أعتقد أن ATLAS 3.11 يجب أن يعمل بشكل أفضل على 64 بت من الإصدار 3.10 ، لكن لا يمكنني بنائه في الوقت الحالي ، على أمل الحصول على بعض المساعدة من Clint Whaley.

توني - لا أعتقد أن لديك الوقت / الطاقة لاختبار عجلة ATLAS 32 بت؟ يجب أن يكون أفضل بكثير ، نسبيًا.

أفضّل أن أمضي قدمًا مع عجلات أطلس هذه ، لذا يمكن لشركات التعبئة الأخرى الاعتماد علينا في شحن نوع من العجلات. إذا توصلنا إلى طريقة جيدة لتحسين الأداء ، فلدينا إصدار جديد سيأتي قريبًا ، وحتى بالنسبة لـ 1.10.4 يمكننا دائمًا إجراء إصدار صيانة لتحديث العجلات.

@ Matthew-brett: سؤال سريع ، لماذا لا يكون numpy قادرًا على اكتشاف ATLAS المبني على Cygwin؟ لقد تمكنت من اكتشافها بشكل جيد تمامًا في بيئة Windows الأصلية ، ولكن عندما حاولت تشغيل البرنامج النصي الخاص بك في Cygwin ، لم يتم تجميع numpy باستخدام ATLAS .

إذا كنت تستخدم Python من Cygwin ، فمن المحتمل أن تحتاج إلى إصدار من الأطلس مبني على cygwin لكي تكون الأشياء متوافقة.

32 بت يبدو أن جوليا فشلت في dlopen 32 بت atlas dll. لست متأكدًا من السبب ، ربما لأن لدينا بالفعل إصدار 32 بت openblas وأن أسماء الرموز متضاربة؟

لكن إصدار @ Matthew-brett مبني باستخدام Cygwin ، ولهذا السبب أنا في حيرة من أمري.

Cygwin بناء البيئة ، عبر تجميعها إلى مكتبة mingw. تعرف على كيفية ارتباطه بـ msvcrt.dll بدلاً من cygwin1.dll؟

بمجرد أن نشرت التعليق ، هذا ما كنت أظن فجأة أنه قد يكون هو الحال. للأسف ، يبدو أنني سأضطر إلى بنائه من الصفر. شكرا tkelman !

برزت مشكلة dlopen (راجع https://github.com/matthew-brett/np-wheel-builder/pull/1 ، و https://github.com/JuliaLang/julia/issues/15117 كان يخفي النسخة المفيدة من رسالة الخطأ).

في 32 بت ، يكون الأطلس 3.6 مرة أبطأ من openblas. 32 بت openblas أبطأ 3x من openblas 64 بت لمشكلة الحجم نفسه. لم يتم تمكين أحدث عدد قليل من عائلات kernel في openblas على أنظمة 32 بت.

...
في الختام: لا أعرف بجدية ما هو أفضل خيار لدينا ، ولكن يبدو أن وضع أصابع قدمنا ​​في مياه BLIS فكرة جيدة ؛ حتى إذا قررنا أننا نريد الانتظار ، فسنتعلم شيئًا ما على الأقل.

ربما يكون هذا مفيدًا ، على الأقل بعض الاختبارات / المقارنة المعيارية. ولكن في هذه المرحلة ، لا يتعلق الأمر إلى حد كبير بقضايا _Windows_ الخاصة بنا. نظام BLIS هو نظام Linux فقط في الوقت الحالي ؛ هناك علاقات عامة مفتوحة لدعم بناء OSX ، و Windows بعيد جدًا. والأسوأ من ذلك ، لقد جربته بالأمس على نظام Linux 32 بت وحتى هذا لا يعمل. تعطل ./configure auto && make بشكل فظيع في بعض أكواد المجمّع (مقابل sandybridge ). يمكنني فقط إنشاء reference .

لذلك أعتقد أن الخطوة 0 هي إضافة دعم لـ BLIS في numpy.distutils (جعل ذلك يعمل في الغالب بالفعل) ، الخطوة 1 للاختبار على Linux لمعرفة أنه على الأقل reference يعمل ، الخطوة 2 بعض المعايير ، ...، خطوةشيء ما على Windows.

@ Matthew-brett يبدو النص المقترح لـ PyPI جيدًا بالنسبة لي. أي إصدارات pip تتجاهل الاسم بعلامة ABI؟ يزعجك Pip كثيرًا لترقية نفسه هذه الأيام ، لذلك أتوقع أن يكون لدى الكثير من الأشخاص أحدث إصدار. والإصدارات التي يزيد عمرها عن 1 (.5) سنة لم تقم بتثبيت العجلات على الإطلاق افتراضيًا.

rgommers كانت اختباراتي أعلاه على windows. ليس MSVC ، لكن mingwpy أو openblas لن يكونا مختلفين كثيرًا هناك - من المحتمل أن تعمل clang ولكنها تحتاج إلى إعادة تنظيم الريبو في blis لتجنب الروابط الرمزية.

لم أجري اختبارات جوليا أو نومبي ضد بليس ، لكن بليس كان يجتاز اختبارات الوحدة الخاصة به. سارت الأمور بشكل أفضل بكثير من تجربتي في عام 2014 مما جعلني أعتقد أنها ستفعل ذلك. ما زلت بحاجة إلى معرفة كيفية جعل تعدد مؤشرات الترابط يعمل بشكل صحيح ، ولكن مع ذلك قد يكون لديك أداء تنافسي بالفعل.

لا يبدو أن التكوين المرجعي هو الشيء الوحيد في blis الذي يعمل مع 32 بت x86 في الوقت الحالي. سيتطلب ذلك كتابة نواة تجميعية جديدة أعتقد أنها ربما لا ، انظر تعليقات نجسميث أدناه.

tkelman ، بخصوص نواة OpenBLAS لـ 32 بت https://github.com/numpy/numpy/issues/5479#issuecomment -185096062: وفقًا لخاص. الرسالة التي تلقيتها من Werner Saar منذ بعض الوقت لا يوجد أحد يعمل على نواة Intel 32 بت لأحدث البنى. لذا فهذه حقيقة من غير المرجح أن تتغير في المستقبل. ينصب التركيز على معالجات Intel 64 بت و ARM.

tkelman ، بخصوص وقت تشغيل C https://github.com/numpy/numpy/issues/5479#issuecomment -185055210: IMHO هذا ليس بالغ الأهمية لأن ATLAS و OpenBLAS لا يشتركان في موارد وقت تشغيل C (واصفات الملفات وكومة الذاكرة المؤقتة) ). _ آمل أن أكون على حق_. قد يكون من المفيد لإصدارات ATLAS زيادة حجم التكديس. يمكن إعطاء هذا كعلامة أثناء الربط ، على سبيل المثال:

-Wl,--stack,16777216

بخصوص النقاشات ATLAS مقابل OpenBLAS: بفضل @ Matthew-brett ، تتوفر الآن مكتبات DLL ATLAS المستندة إلى SSE2. يجب مقارنة إصدار Atlas هذا ببناء OpenBLAS مقابل هدف ممكن لـ SSE2 (أو قم ببساطة بتعيين OPENBLAS_CORETYPE=NORTHWOOD - بشكل أساسي PENTIUM4) لتعطيل اكتشاف وقت تشغيل وحدة المعالجة المركزية. بالطبع يمكن لبناء OpenBLAS العام استغلال المزيد من متغيرات وحدة المعالجة المركزية بفضل اكتشاف وقت تشغيل وحدة المعالجة المركزية. هذا هو أحد الأسباب التي تجعل OpenBLAS أكثر أداءً مقارنةً بـ ATLAS. سؤال آخر هو موثوقية OpenBLAS. ربما يكون المستودع الذي يحتوي على BLAS ، واختبارات LAPACK المجمعة مفيدًا.

بخصوص BLIS / Flame: مثيرة للاهتمام ، لكنها فاكهة معلقة على الأقل لهذا اليوم.

ومع ذلك ، فإن اتخاذ القرار بشأن كيفية الاختيار بين ATLAS و OpenBLAS ليس واضحًا بالنسبة لي.

رالف - النقطة 8 ستثبت العجلات بعلامات Windows ABI الجديدة ، أما النقطة 7 فلن تقوم بذلك. سوف تقوم النقطة 7 والنقطة 8 بتركيب العجلات بدون علامات ABI ، دون سابق إنذار.

لا يزال هناك الكثير من النقاط 7 ، تم إصداره في أغسطس 2015 - لذلك أفضل التمسك بالاسم الأكثر توافقًا ، على الأقل لبعض الوقت.

+1 على التحقيق في BLIS. يبدو أن هذا حل جيد على المدى الطويل. هل نظرنا إلى Eigen على الإطلاق؟ أنها تدعم بناء واجهة LAPACK الجزئية ، والترخيص هو MPL2 لمعظم الكود. قد يكون ذلك جيدًا بما يكفي لـ NumPy.

لقد لاحظت من رمز الكشف عن وحدة المعالجة المركزية BLIS أنه غالبًا ما يعود إلى التطبيق المرجعي إذا لم يعثر على تعليمات AVX ، والتي لا تزال حديثة جدًا.

إيان: هذه هي حالة Eigen منذ عام أو نحو ذلك: http://mingwpy.github.io/blas_lapack.html#eigen - لذلك أعتقد أنه سيكون بعض العمل لبناء مكتبة قابلة للاستخدام من أجل numpy.

والأسوأ من ذلك ، لقد جربته بالأمس على نظام Linux 32 بت وحتى هذا لا يعمل. يتعطل ./configure auto && make بشكل مروع في بعض رموز المُجمِّع (بالنسبة إلى sandybridge). يمكنني بناء مرجع فقط.

إذا نظرت إلى محتويات config/ - فإن "التكوينات" المختلفة المسماة (مثل "sandybridge" ، "haswell") هي في الواقع تكوينات "بداية" معدة مسبقًا تتضمن مجموعة من الإعدادات المحددة مسبقًا (وليس فقط الإعدادات المتعلقة بضبط وحدة المعالجة المركزية ، ولكن أيضًا إعدادات وضع الترابط ، وإعدادات المحول البرمجي ، وما إلى ذلك). والتكوين المسمى "sandybridge" هو تكوين x86-64. يبدو وكأنه خطأ حدده التكوين التلقائي ، لكن نعم لن يعمل على x86-32 :-). يبدو أن BLIS يشحن مع نواة x86 32 بت (انظر kernels/x86 ) ، على الرغم من أنه لا يبدو في الوقت الحالي أن أيًا من التكوينات المعبأة مسبقًا لا يستخدمها. إن إجراء التكوينات الجديدة أمر تافه في الغالب ؛ قطعة واحدة من السحر موجودة في ملف bli_kernel.h الذي يسمي النواة الداخلية + بعض أحجام المخزن المؤقت. يمكننا الاستفسار عن المنبع إذا كان لديهم أي اقتراحات لـ x86-32.

ايضا:

نظام BLIS هو نظام Linux فقط في الوقت الحالي ؛ هناك علاقات عامة مفتوحة لدعم بناء OSX ، و Windows بعيد جدًا

بعض التعليقات أعلاه ، tkelman تقوم ببناء وتقييم BLIS على Windows :-)

الخام القياسي السابق test_dot مع OpenBLAS 0.2.12:

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

مقارنة بـ (النتيجة السابقة من) MKL

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

64 بت ATLAS:

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

لذلك عندما أقوم بمقارنة openblas و MKL (شكرًا ، conda) في المسلسل بتكوين Haswell BLIS ، فإنهم جميعًا في نطاق 10-20 ٪ على الأكثر من بعضهم البعض على dgemm. إليك ملف dockerfile الذي تم إنشاؤه بنجاح على لوحة Docker لتجميع ملفات Windows dll لكل تكوين (باستثناء البلدوزر الذي لم يتم ربطه بشكل صحيح https://github.com/flame/blis/pull/37#issuecomment-185480513 ، حسنًا) : https://github.com/tkelman/docker-mingw/blob/09c7cadd5d682066cea89b3b97bfe8ba783bbfd5/Dockerfile.opensuse

قد ترغب في محاولة تثبيت شيء مشابه لتكوين Travis ' services: docker واللعب بنشر القطع الأثرية الثنائية لإصدارات github / bintray / أيا كان.

كنت أبحث في اكتشاف BLIS CPU -> رمز القالب: https://raw.githubusercontent.com/flame/blis/master/build/auto-detect/cpuid_x86.c

إليك إعادة كتابة Python ، والتي يجب أن تكون أكثر ليبرالية في قبول أحد القوالب المتقدمة (من المرجح أن تعتقد أن نظام التشغيل يمكنه استخدام AVX بدلاً من كود C): https://gist.github.com/matthew-brett / a53778f99b7062cc332d

على جميع الأجهزة التي اختبرت عليها ، تُعيد هذه الخوارزمية "مرجعًا" - ربما لأن لديّ آلات قديمة لم يرغب أي شخص آخر في استخدامها ، لإنقاذ مزرعة buildbot الخاصة بي.

يعطي تجميع numpy مقابل BLIS المرجعي ، بدون فجوة ، ما يلي في معيار معياري الخام:

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

فقط حاصل الضرب القياسي لمصفوفتين (1000 ، 1000) هو 12 ثانية. لذلك ، كما وجد توني أيضًا ، مرجع BLIS هو أسوأ خياراتنا ، حول البنية الافتراضية بدون مكتبة لـ numpy مع lapack_lite.

لذلك ، أعتقد أننا سنحتاج إلى المزيد من القوالب التي تغطي الأجهزة القديمة أو اكتشاف وحدة المعالجة المركزية الأكثر ليبرالية -> تعيين القوالب من أجل تقديم أداء معقول على مجموعة واسعة من الأجهزة.

@ Matthew-brett متى نتوقع أن تكون عجلات نوافذ ATLAS 64 بت الجديدة جاهزة؟ أية نسخة؟ الإصدار 1.10.2؟ هل سيكونون فقط في pypi أم أيضًا في Source Forge؟ هل ستصدر أي نوع من الإعلانات؟ شكرا جزيلا!

@ ماثيو بريت ما هي النسبة بين الأطلس والمرجعية بالنسبة لك على نفس الجهاز؟ مقارنة بعامل 2 الذي كنت أراه؟ لقد حصلت على multithreading للعمل في blis ، لم أكن rtfm بشكل صحيح (https://github.com/flame/blis/wiki/Multithreading) ، لم يتم تمكينه تلقائيًا ، وهناك 4 متغيرات بيئة مختلفة للعب بها . باستخدام هذا التصحيح https://gist.github.com/0fc9497a75411fcc0ec5 لتمكين blis المتوازي المستند إلى pthreads لجميع التكوينات وإعداد BLIS_JC_NT=1 BLIS_IC_NT=2 BLIS_JR_NT=2 BLIS_IR_NT=2 ، يرتبط Haswell blis أساسًا بـ mkl و openblas على جهازي. إذا قمت بتعيين BLIS_JR_NT على 2 ، فإن blis المرجعي المتوازي هو في معظم الأحيان محاصر في الأطلس ، ويكون أسرع مع 3 سلاسل.

tkelman IMO سيكون مفيدًا إذا كان بإمكانك توثيق تقدمك على BLIS في صفحات NumPy GitHub Wiki. أعتقد أيضًا أنه قد يكون من المثير للاهتمام اقتراح خطة مشابهة لـ mingwpy لصنع عجلة NumPy-BLIS-FLAME (وعجلة SciPy-BLIS-FLAME إن أمكن ذلك؟).

tkelman : للتأكد من أنني واضح - أطلسك ملولب ، أليس كذلك؟
شيء آخر يجب مراعاته هو إضافة -msse2 أو ما شابه ذلك لإعدادات الإنشاء reference - يبدو أنه متوافق بشكل افتراضي إلى أقصى حد ولا يسمح للمجمع باستخدام SSE ، ولكن على الأقل في numpy-land وأنا أعلم أننا نصطدم بـ SSE2 باعتباره الحد الأدنى من التكوين المدعوم على أي حال لأسباب أخرى ...

لا أعرف ما إذا كان FLAME مناسبًا أم لا في الوقت الحالي مقابل LAPACK العادي - نريد أن نسأل.

من المحتمل أن نفتح إصدارًا جديدًا لعناصر BLIS بدلاً من الاستمرار في ازدحام هذا :-)

بالنسبة لهذا الخيط - أعتقد أنه يمكننا بالفعل شحن عجلة مع نواة BLIS مختلفة تم تحديدها في وقت التشغيل باستخدام نفس القواعد التي يستخدمها BLIS في وقت البناء ، لكنني أعتقد أن ذلك سيؤدي إلى العديد من الأجهزة ذات المرجع BLIS ، وبالتالي وجود أسوأ أداء من ATLAS 64 بت ، على الرغم من أن ATLAS 64 بت على Windows سيء بشكل خاص (لـ ATLAS).

ولكن - إذا كان الإصدار المرجعي أسرع من ATLAS 64 بت - قل مع msse2 - فسيكون ذلك خيارًا حقيقيًا.

SSE2 هو الحد الأدنى من التكوين لـ 64 بت لذا من الآمن استخدام شيء مثل -mfpmath=sse -msse2 للترجمة المرجعية.

من المحتمل أن نفتح إصدارًا جديدًا لعناصر BLIS بدلاً من الاستمرار في ازدحام هذا :-)

قد تكون هذه فكرة جيدة (تعديل: هل لي أن أقترح أن يكون بعنوان "احتل بليس" ، نظرًا لمشاعرnjsmith حول المروج في https://github.com/numpy/numpy/issues/5479#issuecomment-184472378؟) . أعتقد أن استمرار @ Matthew-brett في تحميل عجلات أطلس الحالية الخاصة به سيكون كافياً لإغلاق هذه العجلة في الوقت الحالي ، مع ترك العمل المستقبلي لقضايا جديدة.

للتأكد من أنني واضح - أطلسك ملولب ، أليس كذلك؟

أطلس الخاص بي هو dll من https://github.com/matthew-brett/np-wheel-builder/tree/d950904f19309db103e676d876ea681b6a6b882e/atlas-builds ، لكن لم أره بعد باستخدام أكثر من مؤشر ترابط واحد بنجاح. هل أفتقد متغير البيئة؟

شيء آخر يجب مراعاته هو إضافة -msse2 أو ما شابه ذلك لإعدادات الإنشاء reference - يبدو أنه متوافق بشكل افتراضي إلى أقصى حد ولا يسمح للمجمع باستخدام SSE

SSE2 هو جزء من مواصفات x86_64 لذا سيكون هذا مناسبًا فقط لـ 32 بت. في Julia نضيف -march=pentium4 لإصداراتنا ذات 32 بت.

لا أعرف ما إذا كان FLAME مناسبًا أم لا في الوقت الحالي مقابل LAPACK العادي - نريد أن نسأل.

لم تلمس اللهب بعد ، لكن الأمر يستحق اللعب به. في النهاية قد تتمكن من استخدام WIndows Clang كخطة احتياطية بديلة لـ mingwpy. (تحرير: في الواقع هذا لا يصلح فورتران في scipy ، لذلك ربما لا)

@ Matthew-brett: أعتقد (قد يكون خطأ) أن kernel dunnington يتطلب فقط SSE3 ، والذي يدعي Steam Hardware Survey أنه موجود على 99.94٪ من الأجهزة (مقابل 99.99٪ لـ SSE2). لذلك يبدو من الخطأ إذا وجدت أن غالبية الأنظمة لا يمكنها التعامل مع ذلك - لا تعرف ما إذا كان هذا خطأ في كود وحدة المعالجة المركزية الخاصة بهم ، أو في وجود مجموعة غير ممثلة حقًا من آلات الاختبار ، أو حسب فهمي لما تتطلبه تلك النواة.

لقد قمت بنشر إعادة كتابة Python لرمز اكتشاف وحدة المعالجة المركزية في الجوهر أعلاه. أعتقد أن اختيار القالب متحفظ ، افتراضيًا للإشارة إلى المكان الذي قد يعمل فيه قالب آخر.

لتذكير نفسي ، للارتباط بـ BLIS ، كنت بحاجة إلى site.cfg مثل:

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

لقد فعلت هذا أيضًا ، أفترض أنه ضروري (تصحيح متعلق بـ numpy 1.10.4):

diff --git a/numpy/distutils/system_info.py b/numpy/distutils/system_info.py
index d7eb49e..3cb7f95 100644
--- a/numpy/distutils/system_info.py
+++ b/numpy/distutils/system_info.py
@@ -1680,18 +1680,11 @@ class blas_info(system_info):
         info = self.check_libs(lib_dirs, blas_libs, [])
         if info is None:
             return
-        if platform.system() == 'Windows':
-            # The check for windows is needed because has_cblas uses the
-            # same compiler that was used to compile Python and msvc is
-            # often not installed when mingw is being used. This rough
-            # treatment is not desirable, but windows is tricky.
-            info['language'] = 'f77'  # XXX: is it generally true?
-        else:
-            lib = self.has_cblas(info)
-            if lib is not None:
-                info['language'] = 'c'
-                info['libraries'] = [lib]
-                info['define_macros'] = [('HAVE_CBLAS', None)]
+        lib = self.has_cblas(info)
+        if lib is not None:
+            info['language'] = 'c'
+            info['libraries'] = [lib]
+            info['define_macros'] = [('HAVE_CBLAS', None)]
         self.set_info(**info)

     def has_cblas(self, info):

أداة للسماح باكتشاف وقت التشغيل لوحدة المعالجة المركزية: https://github.com/matthew-brett/x86cpu

أعتقد أن هذا قد يكون مرشحًا للتضمين في numpy نفسه ، ولكن يمكننا أيضًا نسخ الوحدة المفردة المترجمة cpuinfo في الشجرة المعقدة لعجلة Windows.

أهلا بكم. فكرة: إذا كنت ترغب في نشر العديد من عجلات 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 لمحاولة تحميل عجلات Gohlke ، لكن PyPI رفضتها. اهلا وسهلا بكم في URL.

يضيف gh-7294 دعم BLIS إلى numpy.distutils . سيكون رائعًا إذا تمكن شخص ما من التحقق من أن هذا يعمل كما هو متوقع.

لا يزال هناك الكثير من النقاط 7 ، تم إصداره في أغسطس 2015 - لذلك أفضل التمسك بالاسم الأكثر توافقًا ، على الأقل لبعض الوقت.

Pip 7.0 ليس قديمًا بعد ، لذا فمن المنطقي.

... يبدو أن BLIS يأتي مع نواة x86 32 بت (انظر kernels / x86) ، على الرغم من أنه لا يبدو في الوقت الحالي أن أيًا من التكوينات المعبأة مسبقًا يستخدمها

هذا يفسر ذلك ، شكرا.

شكرا رالف - سأختبر.

أدرك أن هذا قد يحتاج إلى موضوع جديد ، لكننا الآن قريبون جدًا من أن نكون قادرين على استخدام إصدارات BLIS للإصدار.

أعتقد أن كل ما نحتاجه الآن هو قوالب موصى بها لجهاز يحتوي على SSE2 ، وجهاز SSE3 ، يعمل بشكل أسرع إلى حد ما من إصدار Windows 64 بت ATLAS.

أدرك أن هذا قد يحتاج إلى موضوع جديد ، لكننا الآن قريبون جدًا من أن نكون قادرين على استخدام إصدارات BLIS للإصدار.

إيه ، من الناحية الفنية ، قد يكون من الممكن إنجاحها ، لكنها لا تزال ليست خطة جيدة لرمي المباني على الحائط بهذا الشكل. لم نقم حتى باختبار جاد لـ BLIS على Linux أو OS X حتى الآن. لذلك في نظام Windows ، حيث تقول الأسئلة الشائعة عن 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 لنظام التشغيل Windows ، باستخدام التجميع المتقاطع. الشيء التجريبي - على ما أعتقد - هو نظام البناء MSVC ، الذي لا نستخدمه.

في الوقت الحالي ، أقترح فقط استخدام BLIS لعجلة Windows ، ولكن بالطبع سيكون من الجيد جدًا تشغيلها مع العديد من إصدارات Linux.

أوافق تمامًا على أنه إذا لم نحصل على زيادة كبيرة في الأداء في المتوسط ​​، فلا ينبغي لنا استخدام BLIS ، وفي الوقت الحالي ، لا أعتقد أننا كذلك ، باستثناء المعالجات الجديدة جدًا. قد يكون ذلك قابلاً للإصلاح بشكل تافه باستخدام نموذجين جديدين ، أود أن أعرف ما إذا كان الأمر كذلك.

من أجل الصحة ، أنا أوافق أيضًا. ماذا لو أظهرنا ذلك

أ) اجتازت جميع الاختبارات الخادعة جميع إصدارات Windows ؛
ب) جميع الاختبارات الخادعة و scipy تمر على نظام Manylinux؟

يمكننا جعل قالب BLIS قابلاً للتحديد في وقت التشغيل ، واختبار جميع النوى على جهاز حديث. يمكنني اختبار بعض الآلات القديمة السيئة أيضًا.

في الوقت الحالي ، أقترح فقط استخدام BLIS لعجلة Windows ، ولكن بالطبع سيكون من الجيد جدًا تشغيلها مع العديد من إصدارات Linux.

أعتقد أن manylinux أقل أهمية ، حيث لدينا مديرو حزم مع مجموعة كاملة بالإضافة إلى مستخدمين يمكنهم تجميع الأشياء بسهولة أكبر. دعنا نرى أولاً مفهوم Manylinux بالكامل ينطلق قبل أن نقلق بشأنه في سياق numpy + BLAS / LAPACK :)

بالنسبة لنظام التشغيل Windows ، أعتقد أن prios لدينا هي:

1) حل متكامل (يحتاج MingwPy ، مع أحد حلول OpenBLAS / ATLAS / BLIS)
2) عجلات ثنائية مؤقتة (لدينا واحدة على وشك الصعود ببناء ATLAS الخاص بك)
3) زيادة أداء (1). هذا هو المكان الذي يمكن أن يأتي فيه BLIS.

لذا لا داعي لأن تكون في عجلة من أمرك مع BLIS على Windows.

أوافق تمامًا على أنه إذا لم نحصل على زيادة كبيرة في الأداء في المتوسط ​​، فلا ينبغي لنا استخدام BLIS ، وفي الوقت الحالي ، لا أعتقد أننا كذلك ، باستثناء المعالجات الجديدة جدًا. قد يكون ذلك قابلاً للإصلاح بشكل تافه باستخدام نموذجين جديدين ، أود أن أعرف ما إذا كان الأمر كذلك.

متفق عليه ، يجب أن يكون هناك مكسب كبير حتى يصبح منطقيًا. من الصعب بعض الشيء الإشراف على حجم العمل المطلوب بالفعل.

من أجل الصحة ، أنا أوافق أيضًا. ماذا لو أظهرنا ذلك

أ) اجتازت جميع الاختبارات الخادعة جميع إصدارات Windows ؛
ب) جميع الاختبارات الخادعة و scipy تمر على نظام Manylinux؟

هذا يبدو جيدا. سيكون من المنطقي تضمين scikit-learn أيضًا ، إنه مستخدم linalg مهم جدًا.

لم أكن على علم بأن blis و libflame كانا جزءًا من قاعدة كود ACML ، التي تم فتحها منذ بعض الوقت:

http://developer.amd.com/community/blog/2015/08/07/open-source-strikes-again-accelerated-math-libraries-at-amd/
http://developer.amd.com/tools-and-sdks/opencl-zone/acl-amd-compute-libraries/

ومع ذلك: كيف يمكن حل المشكلة لمقارنة 4 تطبيقات مسرعة مختلفة من BLAS / Lapack لبناء numpy / scipy إما باستخدام MSVC أو mingwpy ليتم اختبارها على العديد من بنيات وحدة المعالجة المركزية: Pentium4 حتى skylake؟

اكتشاف لطيف carlk ، لقد رأيت أن أتذكرهم وهم يعلنون عن إسقاط acml و open sourcing acl ، لكنني لم أتذكرهم وهم يتبنون blis / libflame. رخصة BSD هي أخبار جيدة جدا! هل هناك طريقة ما للعمل مع AMD و shpc في أوستن لاستهداف Numpy و Julia؟

تمكنت من تجميع libblis.a باستخدام msys2 و haswell config خارج الصندوق واجتياز جميع الاختبارات عن طريق تصحيح روابط رموز kernel ، لكنني لم أتمكن من إنشاء libflame - حصلت على نفس خطأ "قائمة الوسيطات الطويلة" كما في مشاركة القائمة البريدية الخاصة بي. كما أنني شخصياً لم أتمكن من معرفة كيفية الارتباط بـ libblis.a من lapack ، لكنني لم أحاول جاهداً.

مع الترخيص المجتمعي لـ MKL ، هل من غير الممكن توفير عجلة MKL على pypi ، هل التراخيص غير متوافقة حقًا؟ أم أنه ليس من الممكن بناء scipy بدون ifort؟

هناك مشكلة واحدة ، وربما تنتمي إلى scipy ، لم يتم ذكرها وهي ملفات Fortran المتبقية في scipy. آسف على السؤال المستجد ولكن لماذا يجب أن نستخدمها؟ بالنسبة لي ، يبدو أن Fortran ، وعدم وجود مترجم مجاني متعدد المنصات ، هو المشكلة الحقيقية هنا. أليس هذا بعد كل ما يهدف mingwpy إلى حله. بالنظر إلى MKL المجاني أو بعض السحر المستقبلي acl blis / flame ، يمكن لأي شخص لديه مترجم c أن يبني كومة scipy لم تكن لملفات * .f.

mikofski ، من الرائع سماع ذلك ، يمكن تجميع blis باستخدام msys2. هل هذا ينطبق أيضا على libflame؟ أعتقد أننا بحاجة إلى libflame لـ Lapack API.
شخصيا _ من الممكن_ أن يكون لديك MSVC مجمعة numpy واستخدامها مع mingwpy compiled scipy. تحتاج إلى إضافة -mlong-double-64 إلى علامات دول مجلس التعاون الخليجي للتأكد من أن المضاعفات الطويلة == ضعف.

من الصعب جعل هذا السلوك هو السلوك الافتراضي في دول مجلس التعاون الخليجي ، فأنا أعالج هذه المشكلة منذ أسبوع :(

سأصعد غدا مع عجلات scipy. وستستند هذه إلى نظام أطلس الذي توفره العجلات الصغيرة من @ Matthew-brett.

ومع ذلك ، فأنا أؤيد استخدام OpenBLAS في الوقت الحالي.

هناك مشكلة واحدة ، وربما تنتمي إلى scipy ، لم يتم ذكرها وهي ملفات Fortran المتبقية في scipy. آسف على السؤال المستجد ولكن لماذا يجب أن نستخدمها؟

لأنه يحتوي على الكثير من التعليمات البرمجية المفيدة للغاية وذات الأداء العالي. وهي ليست فقط BLAS / LAPACK - الكثير من scipy.sparse.linalg و scipy.linalg و scipy.special و scipy.interpolate على سبيل المثال هي Fortran. أيضًا ، Scipy ليس المشروع الوحيد الذي يحتوي على كود Fortran ، فهناك حزم أخرى مثل bvp_solver بالإضافة إلى كود Fortran الخاص بالأشخاص الذين قاموا بلفها بـ f2py.

في الواقع ، من الجميل العثور على كارل.

ومع ذلك: كيف يمكن حل المشكلة لمقارنة 4 تطبيقات مسرعة مختلفة من BLAS / Lapack لبناء numpy / scipy إما باستخدام MSVC أو mingwpy ليتم اختبارها على العديد من بنيات وحدة المعالجة المركزية: Pentium4 حتى skylake؟

يتطلب هذا بالفعل إطار عمل مؤتمتًا لائقًا للبناء / الاختبار / المعيار. لسنا مضطرين إلى الاهتمام بهياكل وحدة المعالجة المركزية القديمة جدًا (طالما أن الأشياء تعمل هناك فلا بأس) وأيضًا ليس مع MSVC على ما أعتقد. ولكن لا يزال هناك بعض العمل لإعداد هذا بشكل صحيح.

rgommers شكرا!

أهلا بكم. فكرة: إذا كنت ترغب في نشر العديد من عجلات numpy المختلفة التي تم إنشاؤها باستخدام مكتبات ناقلات مختلفة ، فيمكنك استخدام أسماء حزم PyPI مختلفة

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

لقد سجلت 2 لمحاولة تحميل عجلات Gohlke ، لكن PyPI رفضتها. اهلا وسهلا بكم في URL.

hickford من فضلك لا تفعل ذلك. إنه انتهاك لترخيص MKL لإعادة توزيع ثنائيات من هذا القبيل (ما لم يكن لديك ترخيص شخصي) ، وهي ليست الطريقة الصحيحة للقيام بذلك. في المستقبل ، قد نرغب في توزيع بعض النكهات عبر الإضافات ( numpy[atlas] ، numpy[openblas] إلخ).

أيضًا ، ربما لا يكون إعادة توزيع عجلات شخص آخر على PyPi دون طلب ذلك هو الشيء الذي يجب فعله ....

Mingwpy وأي مشكلات فورتران تعتمد على الارتباط بنفس وقت تشغيل c مثل cpython محدودة بمعدل على carlkl ، فإن تجربة BLIS تحل مشكلات أقل ولكن يمكن إجراؤها بشكل مستقل من قبل أي شخص. للأسف ، لقد استنفدت مخزوني الشخصي من الوقت للنظر في BLIS الآن ، ولكن انظر # 7294.

توني - شكرًا جزيلاً على كل ما قدمته من مساعدة ، فقد كانت لا تقدر بثمن.

أضفت بناءًا لاحقًا لـ ATLAS (3.11.38) على 64 بت

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

هذا بناء تسلسلي (غير مرتبط) ، بسبب مشاكل تجميع 3.11.38 على Windows ، ولكن يجب أن يكون أسرع قليلاً من 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 - هل يمكنك قياس هذا البناء على جوليا؟

آسف للقفز هنا مع ملاحظة مسبقة حول ثنائيات MKL - تقدم إنتل
إصدار المجتمع الذي يجب أن يسمح بإعادة التوزيع لأنه مجاني للجميع ...
في 2 آذار (مارس) 2016 ، الساعة 3:08 مساءً ، كتب "Matthew Brett" [email protected] :

أضفت بناءًا لاحقًا لـ ATLAS (3.11.38) على 64 بت

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

هذا بناء تسلسلي (غير خيوط) ، بسبب مشاكل في تجميع 3.11.38
على Windows ، ولكن يجب أن يكون أسرع قليلاً من 3.10.1 ، وهو بسيط
المعيار:

في [2]:٪ timeit test_dot ()
حلقة واحدة ، أفضل 3: 1.65 ثانية لكل حلقة

مقارنة بالبنية السابقة 3.10.1 (انظر أعلاه):

في [10]:٪ timeit test_dot ()
حلقة واحدة ، أفضل 3: 2.41 ثانية لكل حلقة

tkelman https://github.com/tkelman - هل يمكنك قياس هذا البناء على
جوليا؟

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -191431331.

mrslezak - يسمح الترخيص بإعادة التوزيع ، ولكنه يجعل الموزع مسؤولاً عن أي رسوم قانونية إذا تم رفع دعوى ضد شركة Intel نتيجة استخدام البرنامج. أيضًا ، لا يمكن أن يكون الثنائي الناتج مرخصًا لـ BSD. انظر: http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

يمكن تجنب ذلك عن طريق إضافة "المقدمة كما هي ، دون أي مسؤولية عن أي منها
الخسائر المالية التي قد تنجم عن استخدامه أو شيء من هذا القبيل؟
في 2 آذار (مارس) 2016 6:22 مساءً ، كتب "ماثيو بريت" [email protected] :

mrslezak https://github.com/mrslezak - الترخيص يسمح
إعادة التوزيع ، ولكن يجعل معيد التوزيع مسؤولاً عن أي رسوم قانونية إذا
يتم مقاضاة إنتل نتيجة لاستخدام البرنامج. أيضا ، الناتج
لا يمكن أن يكون البرنامج الثنائي مرخصًا لـ BSD. نرى:
http://mingwpy.github.io/blas_lapack.html#intel -math-kernel-library

-
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -191505500.

لا أعتقد أن هذا سينجح ، لأنه يتعين علينا الموافقة على ترخيص Intel ، وترخيص Intel ينص على أننا مسؤولون عن الرسوم القانونية إذا تمت مقاضاتهم. أعتقد أننا يمكن أن نطلب من المستخدمين عدم مقاضاة شركة Intel في اتفاقية الترخيص الخاصة بنا ، ولذا ربما ، إذا رفعوا دعوى ضد Intel ، وطلبت Intel منا المال ، فيمكننا محاولة مقاضاة المستخدم مقابل هذه الرسوم ، ولكن لا يزال - وضع ذلك على عاتقنا سيأخذنا الترخيص إلى أبعد من BSD ، ويتطلب منا إقناع المستخدم بالموافقة الصريحة ، وهو أمر غير عملي في حالة العجلات المثبتة بواسطة نقطة.

يمنحك إنشاء ATLAS لـ SSE3 فائدة أداء بنسبة 5 ٪ فقط مقارنةً بـ SSE2 ATLAS ، لكن البناء كان صعبًا واضطررت إلى تعطيل أعلام التمكين الأكثر وضوحًا لـ SSE3 ، واستخدم فقط -msse3 .

لقد كتبت بريدًا إلى القائمة البريدية غير المستقرة مقترحًا نشر هذه العجلات: https://mail.scipy.org/pipermail/numpy-discussion/2016-March/075125.html

@ Matthew-brett بصفتك شخصًا يدعم Windows مع تطبيقات Python ، شكرًا لك.

@ Matthew-brett ، أضفت مشكلتين إلى مستودع atlas-build-scripts الخاص بك.
انظر https://github.com/matthew-brett/atlas-build-scripts/issues

أول https://github.com/matthew-brett/atlas-build-scripts/issues/1 مهم ، حيث يصدر numpy-atlas.dll إلى الكثير من الرموز وبالتالي يمنع من الاستخدام الإضافي مع mingwpy دون اختراق الاستيراد مكتبة.

@ ماثيو بريت آسف لأنني كنت مشغولاً بعض الشيء للقيام بمزيد من المقارنة المعيارية. هل كانت أي من أبنية الأطلس السابقة متعددة الخيوط؟ لم أتمكن من الحصول على أول بناء يعمل على نوى متعددة. يجب أن يكون الجوهر مباشرًا جدًا للتشغيل حتى لو لم تكن معتادًا على جوليا. أو هل كنت مهتمًا في الغالب بأحدث الأجهزة التي يمكنك الوصول إليها؟

لا تقلق - لم أكن أتوقع منك التخلي عن كل شيء وتشغيل المعايير.

في الواقع ، لم يكن إصدار أطلس الأخير الخاص بي متعدد الخيوط - يحتاج ATLAS 3.11 إلى مزيد من العمل لجعل الخيوط تعمل على Windows على ما يبدو.

بالنسبة للمعايير ، كنت أفكر أنه سيكون من الأسهل مقارنتها بالمعايير الأخرى التي قمت بتشغيلها ، وليس لدي سوى أجهزة قديمة مع Windows قيد التشغيل - أعتقد أن النتيجة أكبر بكثير على جهازك مقارنة بجهازي.

عجلات Windows متوفرة الآن على pypi: https://pypi.python.org/pypi/numpy/1.10.4

عذرًا توني - نعم ، كانت إصدارات ATLAS السابقة 3.10 (أو بدا أنها) متعددة الخيوط.

أعتقد أنه يمكننا إغلاق هذه المشكلة الآن. ربما @ matthew-brett يجب عليك نقل https://github.com/matthew-brett/np-wheel-builder تحت المؤسسة غير المستقرة أو ربما المساهمة بها كعلاقات عامة في الريبو الخالي من تحت مجلد الأدوات .

رالف - أي اقتراحات حول المكان الذي يجب أن يذهب إليه np-wheel-builder ؟ numpy / بائع ربما؟

أنا أفضل الريبو الجديد المنفصل ( numpy-wheel-builder ؟) تحت المؤسسة الخاوية على ما أعتقد. يوجد تداخل مع الغرض numpy-vendor ، لكن ليس كثيرًا في الكود. هذا الريبو كبير جدًا ، وهو مخصص حقًا للعمل تحت Wine ، وسلسلة أدوات دول مجلس التعاون الخليجي فيه عفا عليها الزمن.

حسنًا معي - حسنًا معكم جميعًا للمضي قدمًا وإنشاء ذلك؟

حسنًا بالنسبة لي ، على الرغم من أنه خاص بالنوافذ (الآن هو AFAICT؟) ، فيجب أن يحتوي اسم الريبو على "windows" بداخله :-). وإلا فقد يكون المكان الذي نضع فيه البنية التحتية المماثلة للعجلات الأخرى أيضًا. سأكون على ما يرام أيضًا مع وضعه مباشرة في الريبو numpy في مكان ما إذا كان صغيرًا بما يكفي ليكون ذا معنى. أي شيء يعمل :-)

يحتوي Repo على ثنائيات ATLAS كبيرة إلى حد ما ، مما يجعل الريبو الخالي كبير الحجم وليس الغرض الجيد ، على ما أعتقد.

ماذا عن win-wheel-builder ؟

ماذا عن windows-wheel-builder . لست من محبي win ؛)

ماذا عن عدم جعلها خاصة بالنوافذ ووجود تكوين بناء عجلة macosx ومستقبل manylinux1 في مكان واحد؟

وإلا +1 لـ "windows" فوق "win".

ماذا عن عدم جعلها خاصة بالنوافذ ووجود تكوين بناء عجلة macosx ومستقبل manylinux1 في مكان واحد؟

سيكون من الأسهل تغيير الأشياء على جميع المنصات. لكنني أتوقع أن نظامي التشغيل OS X و Linux سيحتاجان فقط إلى إنشاء نصوص برمجية ، بينما لدينا لنظام التشغيل Windows ثنائيات ATLAS الضخمة. إذا كان كل شيء في ريبو واحد ، فهل يمكن فصل ثنائيات ATLAS بطريقة ما (ربما باستخدام git-lfs)؟

استخدم تخزين الملفات الكبير (LFS) على جيثب للثنائيات

rgommers : أعتقد أننا سنحمل قريبًا ثنائيات أطلس أو البعض الآخر blas لنظام Linux أيضًا ، وربما OSX أيضًا (على سبيل المثال إذا قررنا أننا سئمنا من تسريع كسر المعالجة المتعددة).

يمكن أن تبدأ في استخدام إصدارات github أو bintray أو أي شيء بدلاً من إيداعها ... ليس كما لو أنها كبيرة جدًا على الرغم من ذلك حتى تبدأ في الوصول إلى إصدارات openblas الممكّنة من DYNAMIC_ARCH أو المجموعات المكافئة لتكوينات blis المتعددة

ماذا عن طرح الريبو كـ windows-wheel-builder في الوقت الحالي ، وإعادة البناء / إعادة التسمية عندما يكون من الواضح أكثر ما الذي سنفعله مع Linux / OSX؟

يبدو أمرا جيدا لي.

بخير معي كذلك

أعتقد أنني بحاجة إلى حقوق المسؤول في المنظمة غير المفككة - أو يمكنني أن أعطيها
شخص ما لديه حقوق المسؤول في الريبو ، ويمكنه فعل ذلك ، على ما أعتقد.

@ Matthew-brett: أنا في حيرة من أمري بسبب صفحة أذونات github (و numpy's على وجه الخصوص هي فوضى) ، ولكن إذا كنت تريد أن تجعلني مسؤولاً عن الريبو أو نقل الريبو إلي ، فيمكنني نقله إلى numpy /

لقد قمت بنقل الريبو إلى njsmith ...

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

هل يوجد حساب مفصل؟ هل يمكن لشخص ما تمكين أبفيور يبني لهذا الريبو؟

أعتقد أننا نستخدم حساب Appveyor الخاص بـcharris ...

نعم ، انظر هنا https://ci.appveyor.com/project/charris/numpy/history

يوم الأربعاء ، 16 آذار (مارس) 2016 الساعة 12:15 صباحًا ، ناثانيال ج. سميث <
[email protected]> كتب:

أعتقد أننا نستخدم تطبيقcharris https://github.com/charris's Appveyor
الحساب...

-
أنت تتلقى هذا لأنه تم ذكرك.
قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub
https://github.com/numpy/numpy/issues/5479#issuecomment -197064930

في الواقع ، لقد أنشأت للتو حسابًا جماعيًا جديدًا لـ numpy في appveyor (كنت أقصد القيام بذلك على أي حال ، وهذا دفعني للقيام بذلك في الواقع :-)) ، وقمت بتمكينه هناك:
https://ci.appveyor.com/project/numpy/windows-wheel-builder

njsmith كيف تدير ذلك؟ آخر مرة بحثت فيها عن شخص يحتاج إلى مطالبة المسؤولين بإنشاء حسابات للمشروع ولم تكن طريقة إضافة آخرين إليها شفافة تمامًا.

إذا نجح الحساب ، فأنا أرغب في نقل المسؤولية عن الاختبار غير المستقر.

charris : تحقق من بريدك الإلكتروني :-). لقد أنشأت للتو حسابًا فرديًا مع numpy -eering-Council @ googlegroups.com باعتباري الفرد. لم أكن أعرف أن حسابات المشروع كانت شيئًا موجودًا ... هل نريد حسابًا؟

من أجل قائمة الانتظار ، ربما تريد نشر مشاريع مختلفة على حسابات مختلفة

الجانب السلبي لاستخدام بريد مجلس التوجيه غير المقيد هو أن التطبيق يرسل إشعارات عند فشل اختبار الدمج. إذا كان لدى مستخدمي appveyor شيئًا أفضل هذه الأيام ، فسيكون من الجيد استخدام ذلك ، ولكن نظرًا للفوضى التي كانت واجهتهم في الماضي ، فلن أراهن عليه.

tkelman نقطة جيدة. أيضًا ، إذا كنا سننفق الأموال للحصول على قائمة انتظار أسرع ، فربما نريد شيئًا أكثر رسمية.

charris : لقد حاولت للتو تمكين اختبار numpy/numpy في حساب appveyor الجديد ، وكذلك لتعطيل جميع الإشعارات ، وأيضًا إضافة جميع فرق github numpy ذات الصلة كإدارات على الحساب - دعنا نرى ما سيحدث أنا خمن...

@ Matthew-brett: يخطر ببالي أن الأسلوب الأكثر أناقة قد يتمثل في إخفاء إنشاءات BLAS في مكان ما مثل numpy/windows-build-tools ، ولكن لتشغيل أدوات بناء العجلة الفعلية من المستودع الحقيقي numpy/numpy مثل جزء من بناء appveyor - يمكنهم سحب ثنائيات BLAS لأسفل عند الطلب.

شكرا لجميع العمل العظيم! هل ستتم إضافة عجلات النافذة numpy 1.11.0 إلى pypi قريبًا؟ https://pypi.python.org/pypi/numpy

نعم ، ربما نحتاج إلى معرفة كيفية تحديث إجراءات الإصدار الخاصة بنا هنا ... تجربة المستخدم في الوقت الحالي هي أنه بمجرد تحميل الإصدار المصدر 1.11 ، تحولت جميع أجهزة Windows الموجودة هناك فجأة من تنزيل العجلات (رائع) ) لمحاولة تحميل وبناء المصدر (بوو). أعتقد أن الطريقة "الصحيحة" للقيام بذلك هي أنه بمجرد وضع علامة على الإصدار النهائي ، نقوم ببناء وتحميل جميع العجلات الثنائية قبل تحميل sdist. مزعج مثل هذا ...

njsmith سيكون ذلك رائعًا ، لكن التأخير لبضع دقائق (أو حتى بضع ساعات) سيكون جيدًا بالنسبة لي.

فقط للتوضيح هل ملفات Windows whl الحالية على PyPI للإصدار 1.11.0 بناءً على ATLAS؟ هل يوجد نص بناء يمكن مشاركته؟

نعم ، تم تصنيع العجلات ضد ATLAS ، لكننا نفكر في الانتقال إلى OpenBLAS عندما نكون واثقين من النتائج.

البناء مؤتمت عبر Appveyor: https://github.com/numpy/windows-wheel-builder

23735 downloads in the last day . =)

قد يكون من الممكن إنشاء إصدار hidden - على الأقل يوجد خيار في نموذج PyPI https://pypi.python.org/pypi؟٪3Aaction=submit_form وإظهاره عندما تكون جميع الملفات جاهزة.

للأسف ، تمنع ميزة الإصدار المخفي الأشخاص من الحصول على هذا الإصدار عبر سطر الأوامر ، بل تمنعهم فقط من رؤية الإصدار عبر واجهة المستخدم الرسومية pypi:

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

لقد جربت تثبيت Windows 64 بت لـ numpy وهذا يعمل بشكل رائع ، لذا شكرًا لجميع الذين عملوا على هذا.

ما أتساءل عنه هو ما إذا كانت لا تزال هناك خطة لفعل الشيء نفسه مع عجلات 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 ضد @ Matthew-brett https://github.com/matthew-brett 's
إصدارات numpy https://pypi.python.org/pypi/numpy/1.10.4

آسف إذا قلت بالفعل ، وقد فاتني - لكن هل تحصل على أي اختبار
فشل هذه العجلات؟

هل تقوم بالربط مع ATLAS المشحون داخل العجلات الصغيرة؟

@ ماثيو بريت ، لقد أعلنت عن هذه البنايات منذ شهر ، لكني لا أتذكر أين. على أي حال ، ترتبط هذه البنايات ضد الأطلس النامي الذي توفره عجلاتك الصغيرة.

scipy-0.17.0-cp35-cp35m-win ##. whl مرتبطة بالملف msvcrt.dll _wrong_ C-runtime. بالنسبة إلى Scipy ، يبدو أن هذا لا بأس به. سجلات الاختبار موجودة هنا: https://gist.github.com/carlkl/9e9aa45f49fedb1a1ef7

هل هذا هو السجل الصحيح؟ يحتوي على NumPy is installed in D:\devel\py\python-3.4.4\lib\site-packages\numpy في النهاية.

كنت أتساءل عما إذا كنا على وشك أن نكون قادرين على توفير عجلة scipy ، حتى لو كانت مرتبطة بشكل خطير بوقت تشغيل MSVC الخاطئ ، ولكن يبدو أن هناك عددًا كبيرًا جدًا من الأخطاء لهذا الإصدار.

هل تحصل على أخطاء أقل للإصدار 64 بت؟ لأفضل بناء حالي ضد openblas 0.2.18؟

يحتوي الإصدار 64 بت على 6 حالات فشل فقط مع كل من:

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

أعلم: هذا صرخات للمقارنة مع OpenBLAS. ومع ذلك ، أنا عالق منذ الأسابيع الأربعة الماضية لعدة أسباب ربما تكون قد لاحظت. نأمل أن يستمر الوضع في التحسن.

@ Matthew-brett ، سأكون ممتنًا لاستخدام إنشاءات MSVC الخفية مع OpenBLAS. أحدث تصميماتي هنا:

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

كما لو أن mingwpy و conda-forge و Anaconda و Canopy لم تكن كافية هنا يأتي توزيع Intel لـ Python وهو مجاني للتنزيل . يتضمن فقط الأدوات العددية (SciPy و NumPy و Numba و Scikit-Learn) بالإضافة إلى بعض الإضافات (واجهة mpi4py Intel mp وتحليلات البيانات pyDAAL) ويستخدم conda.

لا تقلق من انتهاء صلاحية الترخيص في 10/29/16 ، لذا فإن إصدارات Intel هذه مجرد ملف
اختبار تجريبي يتبعه على الأرجح رسوم ترخيص MKL + إلخ. يبني OpenBLAS
سيظل الحل مفتوح المصدر ، لذا نشكرك على توفيرها
يبني.
في 28 أبريل 2016 ، الساعة 7:21 مساءً ، كتب "مارك ميكوفسكي" [email protected] :

كما لو أن mingwpy و conda-forge و Anaconda و Canopy لم تكن كافية هنا
توزيع إنتل لبيثون
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 ، يبدو أن هناك عجلة Windows مفقودة على PyPi لـ Python 3.5 amd64.

هل هناك سبب معين لذلك؟ إذا ذهبت إلى 1.11.0 (https://pypi.python.org/pypi/numpy/1.11.0) ، فإن العجلة موجودة.

شكرًا على التقرير - أعتقد أننا يجب أن نحمله في وقت مبكر جدًا ، وبالتالي قبل بناء جميع العجلات. لقد قمت بتحميل العجلة المفقودة. يبدو أننا بحاجة إلى اختبار للتأكد من عدم حدوث ذلك مرة أخرى.

لقد قمت بتحميل العجلة المفقودة.

لقد اختبرت ذلك للتو ، وهو يعمل بشكل رائع!

شكرًا جزيلاً على كل العمل المنجز لإتاحة عجلات Windows.

إغلاق المشكلة - كانت العجلات متاحة للإصدارات القليلة الماضية.

أتفهم أن هذه المشكلة قد تم إغلاقها ولكني أعتقد أنه ينبغي علينا التفكير في إعادة فتحها.

تظل هذه مشكلة بالنسبة لمستخدمي windows الذين يحاولون تشغيل مكدسهم العلمي دون الحاجة إلى اللجوء إلى conda. ما زلت بحاجة إلى استخدام بنياتcgohlke 'MKL' لرؤية هذه المشكلة scipy ذات الصلة والتي لا تزال مفتوحة. على الرغم من إنشاء العجلات ، دون أن تكون متوافقة مع scipy ، إلا أنها غير صالحة للاستخدام بالنسبة للكثيرين.

waynenilsen لديك الإرشادات الخاصة بتثبيت العجلات الجديدة في سلسلة رسائل القائمة البريدية المرتبطة بالمشكلة التي ذكرتها للتو:

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

حتى إذا كنت تفعل

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

يجب ان تعمل لأجلك.

لم يتبق شيء لفعله لـ Numpy ، لذلك تم إغلاق المشكلة. ال
لا تزال مشكلة Scipy مفتوحة ، ومن المحتمل أن يتم حلها في اليوم التالي
إطلاق سراح.

هذا يعمل بشكل رائع بالنسبة لي @ Juanlu001 إنني أتطلع حقًا إلى عندما يكون هذا على pypi!