Numpy: إصدار Tracker لدعم BLIS في NumPy

أرى أنه تم تضمين BLIS في site.cfg .
هل يمكن دعم libFLAME أيضًا؟

قد يحتاج الوصف الموجود على https://www.cs.utexas.edu/٪7Eflame/web/libFLAME.html إلى الإصلاح ، ولكن من غير الواضح بالنسبة لي أن libFLAME يقوم بالفعل بتنفيذ LAPACK API.

يوفرrgommers libflame بالفعل واجهات برمجة تطبيقات netlib LAPACK وتطبيقات لكل شيء لا يوفره libflame محليًا.

FWIW ، خطت BLIS خطوات كبيرة منذ فتح هذه المشكلة. على سبيل المثال ، تقوم BLIS الآن بتنفيذ تكوين وقت التشغيل ، وتم إعادة تنفيذ تكوين وقت التكوين من حيث البنية الأساسية لوقت التشغيل. تقدم BLIS الآن برامج تشغيل اختبار BLAS مدمجة بالإضافة إلى مجموعة الاختبارات الأكثر شمولاً. يتم أيضًا التهيئة الذاتية للمكتبة ، وكذلك إنشاء رأس متجانسة (blis.h واحد بدلاً من 500+ رأس تطوير) ، مما يجعل إدارة المنتج المثبت أسهل. كما أنه يتبع اصطلاحًا معياريًا لتسمية المكتبات من أجل تصميمات المكتبة الثابتة والمشتركة ، بما في ذلك soname . أخيرًا ، يعد نظام البناء الخاص به أكثر ذكاءً من حيث التحقق من توافق المحول والمجمع. وهذا ما يمكنني التفكير فيه من فوق رأسي.

fgvanzee شكرا. في هذه الحالة سأقوم بإجراء +1 لإضافة دعم له في numpy.distutils .

أنا حقًا في وقت قصير في الوقت الحالي ، لذا لا يمكنني العمل على هذا حتى سبتمبر على الأقل. إذا أراد شخص آخر معالجة هذا ، فيجب أن يكون الأمر بسيطًا نسبيًا (على غرار gh-7294). يسعدنا المساعدة في استكشاف الأخطاء وإصلاحها / المراجعة.

هذا يبدو وكأنه تقدم كبير. إلى أي مدى تعتقد أنك بعيدًا عن أن تكون بديلاً قابلاً للتطبيق لـ OpenBLAS لـ numpy / scipy (من حيث الأداء والاستقرار)؟

(لاحظ أننا ما زلنا لا نملك ملف scipy-openblas على نظام Windows مقابل conda بسبب فوضى Fortran: https://github.com/conda-forge/scipy-feedstock/blob/master/recipe/ meta.yaml # L14)

إذا كنت تريد BLAS و LAPACK متوافقين مع MSVC ABI ، فلا تزال هناك خيارات سهلة ومفتوحة المصدر بالكامل. على الرغم من وجود clang-cl و flang في الوقت الحاضر ، إلا أن المشكلة لا تتعلق بتوافر المترجم كما كانت عليه من قبل ، والآن يتم بناء مرونة النظام ومحاولة استخدام مجموعات لم يقم مؤلفو المكتبة بتقييمها أو دعمها من قبل. راجع https://github.com/flame/blis/issues/57#issuecomment -284614032

rgommers أود أن أقول إن BLIS هي حاليًا بديل قابل للتطبيق تمامًا لـ OpenBLAS. من الممكن أن تكون AMD قد تخلت عن ACML وتبنت BLIS بالكامل كأساس لحل مكتبة الرياضيات مفتوحة المصدر الجديدة. (لدينا رعاة من الشركات ، وقد تمت رعايتنا من قبل مؤسسة العلوم الوطنية لسنوات عديدة في الماضي).

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

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

أيضًا ، ضع في اعتبارك أن BLIS قدمت (بدءًا من اليوم صفر) مجموعة شاملة من الوظائف المشابهة لـ BLAS ، وتم ذلك عبر واجهتي API جديدتين منفصلتين وبصرف النظر عن طبقة توافق BLAS:

• واجهة برمجة تطبيقات تشبه BLAS
• واجهة برمجة تطبيقات قائمة على الكائن مكتوبة ضمنيًا

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

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

آه شكرا tkelman. Cygwin :( :(

سيكون من المثير للاهتمام سماع بعض التجارب من أشخاص يستخدمون numpy تم تجميعها ضد BLIS على Linux / macOS.

شكرا على السياق fgvanzee. سيكون من المثير للاهتمام بالنسبة لنا إضافة دعم libFLAME وتجربته على مجموعة معايير SciPy.

rgommers رد: libflame: شكرا على اهتمامك. فقط كن على علم بأن libflame يمكن أن يستخدم بعض TLC ؛ إنه ليس في حالة جيدة تمامًا مثل BLIS. (ليس لدينا الوقت / الموارد لدعمها كما نرغب ، وما يقرب من 100٪ من اهتمامنا على مدار السنوات الست الماضية قد ركز على نقل BLIS إلى مكان يمكن أن يصبح فيه بديلًا عمليًا وتنافسيًا لـ OpenBLAS وآخرون.)

في مرحلة ما ، بمجرد نضوج BLIS واستنفاد سبل البحث لدينا ، من المحتمل أن نعيد انتباهنا مرة أخرى إلى وظائف مستوى libflame / LAPACK (Cholesky ، LU ، QR Factorizations ، على سبيل المثال). قد يأخذ هذا شكل إضافة هذه التطبيقات بشكل تدريجي إلى BLIS ، أو قد يتضمن مشروعًا جديدًا تمامًا ليحل محل libflame في النهاية. إذا كان هذا هو الأخير ، فسيتم تصميمه للاستفادة من واجهات برمجة التطبيقات ذات المستوى الأدنى في BLIS ، وبالتالي تجنب بعض استدعاء الوظائف ونسخ الذاكرة التي لا يمكن تجنبها حاليًا عبر BLAS. هذا مجرد واحد من العديد من الموضوعات التي نتطلع إلى التحقيق فيها.

لقد قمت بتشغيل المعيار من هذه المقالة باستخدام NumPy 1.15 و BLIS 0.3.2 على Intel Skylake بدون تعدد مؤشرات الترابط (كان لدي خطأ في تعليمات الجهاز مع HT):

Dotted two 4096x4096 matrices in 4.29 s.
Dotted two vectors of length 524288 in 0.39 ms.
SVD of a 2048x1024 matrix in 13.60 s.
Cholesky decomposition of a 2048x2048 matrix in 2.21 s.
Eigendecomposition of a 2048x2048 matrix in 67.65 s.

إنتل MKL 2018.3:

Dotted two 4096x4096 matrices in 2.09 s.
Dotted two vectors of length 524288 in 0.23 ms.
SVD of a 2048x1024 matrix in 1.11 s.
Cholesky decomposition of a 2048x2048 matrix in 0.19 s.
Eigendecomposition of a 2048x2048 matrix in 7.83 s.

منقط مصفوفتين 4096x4096 في 4.29 ثانية.

homocomputeris معذرةً ، لم أسمع فعل "النقطة" المستخدم لوصف عملية على مصفوفتين من قبل. هل هذا ضرب مصفوفة؟

fgvanzee ما حالة دعم Windows في BLIS هذه الأيام؟ أتذكر أن إنشاءه على Windows كان في الغالب غير مدعوم ...

fgvanzee ونعم ، numpy.dot هي الطريقة التقليدية لاستدعاء GEMM في Python. (نوع من الاسم الفردي ، ولكنه لأنه يتعامل مع المتجهات ، والمتجهات ، والمصفوفة ، والمصفوفة ، جميعها في نفس واجهة برمجة التطبيقات.)

njsmith لم تتغير حالة دعم Windows "الأصلي" في الغالب. ما زلنا نفتقر إلى الخبرة والاهتمام في تحقيق مثل هذا الدعم ، للأسف. ومع ذلك ، منذ إصدار Windows 10 ، يبدو أن هناك بيئة توافق "Ubuntu for Windows" أو بيئة توافق bash من نوع ما متاحة. ربما يكون هذا وسيلة واعدة أكثر لتحقيق دعم Windows. (ولكن مرة أخرى ، لا أحد في مجموعتنا يتطور على Windows أو يستخدمه ، لذلك لم ننظر حتى في هذا الخيار أيضًا.)

حسنًا ، آخر مشاركة في الوقت الحالي ...

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

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

fgvanzee "bash for Windows" يكافئ بشكل فعال تشغيل Linux VM على Windows - جهاز

njsmith نتائجي هي نفسها إلى حد ما كما في المقالة.
أحدث MKL ، على سبيل المثال:

Dotted two 4096x4096 matrices in 2.09 s.
Dotted two vectors of length 524288 in 0.23 ms.
SVD of a 2048x1024 matrix in 1.11 s.
Cholesky decomposition of a 2048x2048 matrix in 0.19 s.
Eigendecomposition of a 2048x2048 matrix in 7.83 s.

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

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

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

njsmith محاذاة؟ رقم إيجابي؟ أعتقد أننا رفعنا هذا القيد ، لكن لم يتم اختباره بدقة. المضاعفات الدقيقة لنوع البيانات؟ نعم لا تزال.

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

homocomputeris هل تمانع في إعادة تشغيل المعيار بقيمة مختلفة لـ size ؟ أتساءل عما إذا كانت القيمة التي استخدمها المؤلف (4096) كونها قوة اثنين هي حالة استخدام سيئة بشكل خاص لـ BLIS ، وليست واقعية بشكل خاص لمعظم التطبيقات على أي حال. أقترح تجربة 4000 (أو 3000 أو 2000) بدلاً من ذلك.

homocomputeris وهل قلت أن نتائج BLIS أحادية الترابط ، في حين أن نتائج MKL متعددة الخيوط؟

FWIW ، لقد بحثت في بناء BLIS على Windows منذ بعض الوقت. نقطة الألم الأساسية في الوقت الحالي هي نظام البناء. قد يكون من الممكن جعل mingw تستخدم clang لإنتاج ثنائي متوافق مع MSVC. لم أحصل على هذا الجري مطلقًا مع الوقت الذي كنت قادرًا على إنفاقه فيه ، لكن يبدو أنه ممكن.

داخل شفرة المصدر الفعلية ، الوضع ليس سيئًا للغاية. لقد انتقلوا مؤخرًا إلى استخدام وحدات الماكرو لنواة التجميع الخاصة بهم ، لذلك تم التخلص من حاجز آخر أمام دعم Windows. راجع https://github.com/flame/blis/issues/220#issuecomment -397842370 و https://github.com/flame/blis/pull/224. يبدو أن ملفات المصدر نفسها هي عبارة عن عدد قليل من وحدات الماكرو / ifdefs بعيدًا عن البناء على MSVC ، ولكن هذا هو وجهة نظري كطرف خارجي. ليس لدي أي فكرة أيضًا عن كيفية جعل ملفات BLIS makefiles الحالية تعمل مع MSVC.

insertinterestingnamehere شكرًا على يتم تصميم نظام البناء لدينا بالتأكيد مع وضع دعم Windows في الاعتبار. علاوة على ذلك ، هل يدعم MSVC C99 حتى الآن؟ إذا لم يكن كذلك ، فهذه عقبة أخرى. (يتطلب BLIS C99.)

حسنًا ، لقد قدمت المثال أعلاه فقط لإظهار أن BLIS يمكن مقارنته بالآخرين ، ولهذا السبب لم أقم بتضمين أي شيء أكثر تحديدًا.

لكن كما تسأل: مبتسم:

• معالج Intel Core i5-6260U مع أحدث BIOS وأي تصحيحات لـ Specter / Meltdown
• Linux 4.17.3-1-ARCH
• تم تجميع كل شيء مع دول مجلس التعاون الخليجي 8.1.1 20180531
• NumPy 1.15.0rc1
• لقد اخترت رئيسًا لأبعاد المصفوفة

يقتصر Intel MKL 2018.3 على خيطين (أي ، نوى وحدة المعالجة المركزية الخاصة بي):

Dotted two 3851x3851 matrices in 1.62 s.
Dotted two vectors of length 492928 in 0.18 ms.
SVD of a 1925x962 matrix in 0.54 s.
Cholesky decomposition of a 1925x1925 matrix in 0.10 s.
Eigendecomposition of a 1925x1925 matrix in 4.38 s.

تم تجميع BLIS 0.3.2 مع
CFLAGS+=" -fPIC" ./configure --enable-cblas --enable-threading=openmp --enable-shared x86_64

Dotted two 3851x3851 matrices in 3.82 s.
Dotted two vectors of length 492928 in 0.39 ms.
SVD of a 1925x962 matrix in 12.82 s.
Cholesky decomposition of a 1925x1925 matrix in 2.02 s.
Eigendecomposition of a 1925x1925 matrix in 67.80 s.

لذلك ، يبدو أنه يجب دعم BLIS بالتأكيد بواسطة NumPy على الأقل في أنظمة Unix / POSIX / أيًا كان ما شابه ، كما أتخيل أن حالة استخدام Windows "لا تلمسه إذا كان يعمل"
الشيء الوحيد الذي لا أعرفه هو العلاقة بين MKL / BLIS و LAPACK / libFLAME. تدعي Intel أن لديها العديد من الأشياء المحسّنة إلى جانب BLAS ، مثل LAPACK و FFT وما إلى ذلك.

fgvanzee لماذا تعتبر قوة 2 سيئة بالنسبة إلى BLIS؟ من الشائع جدًا بالنسبة لطرق التجميع إذا كان المرء يريد أسرع FFT.

لآل آخرون نمباي، سيكون كافيا لإدارة المبنى في مينغو / MSYS2 --- وهذا ما نقوم به حاليا مع openblas على ويندوز (على الرغم من أن هذا النوع من الإختراق في حد ذاته). سيحصر الاستخدام على واجهات برمجة التطبيقات "التقليدية" التي لا تتضمن تمرير موارد CRT عبر ، ولكن هذا جيد لـ BLAS / LAPACK.

fgvanzee نقطة جيدة حول C99. من المدهش أن WRT المعالج C99 المسبق ، حتى المعالج الأولي MSVC 2017 لم يتم اكتشافه بالكامل هناك. من المفترض أنهم يعملون حاليًا على إصلاح ذلك (https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance#note_D).

fgvanzeenjsmith هنا هو ما كنا بحاجة إلى القيام به لدعم خطوات بايت التعسفية:

1) تعديل الواجهة. الشيء الأكثر ملاءمة الذي يحدث لي هو إضافة شيء مثل علامة stride_units في واجهة الكائن.
2) أعد تشكيل كافة العناصر الداخلية لاستخدام خطوات البايت فقط. قد لا تكون هذه فكرة سيئة على أي حال.
3) عند التعبئة ، تحقق من محاذاة نوع البيانات وإذا لم يكن الأمر كذلك ، فاستخدم نواة التعبئة العامة.
أ) يجب أيضًا تحديث نواة التعبئة العامة لاستخدام memcpy . إذا تمكنا من التحايل عليها لاستخدام معلمة حجم حرفية ، فلا ينبغي أن تمتص بشكل رهيب.
4) عندما يكون C غير محاذي ، استخدم أيضًا microkernel الافتراضية التي تصل إلى C باستخدام memcpy .

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

Homocomputeris :

1. لم أقصد أن أشير إلى أن قوى اثنين لا تنشأ أبدًا "في البرية" ، فقط لأنها ممثلة تمثيلا زائدا في المعايير ، على الأرجح لأننا نحن البشر الموجهون للكمبيوتر نحب أن نحسب في قوى اثنين. :)
2. هذه النتائج المعيارية متشابهة حقًا . سأحبها إذا كانت الإجابة على هذا السؤال التالي "لا" ، ولكن هل من الممكن أن تكون قد نفذت عن طريق الخطأ كلا المعيارين مع MKL (أو BLIS) المرتبطة؟
3. أوافق تمامًا على أن قوى اثنين تنشأ في التطبيقات ذات الصلة بـ FFT. كنت أعمل في معالجة الإشارات ، لذلك فهمت. :)
4. قلقي من عدم أداء BLIS بشكل جيد مع صلاحيات اثنين هو في الواقع مصدر قلق لا يقتصر على BLIS. ومع ذلك ، قد تكون الظاهرة التي نلاحظها أكثر وضوحًا مع BLIS ، وبالتالي "عقوبة" صافية لـ BLIS بالنسبة إلى حل مُحسَّن بشكل يبعث على السخرية مثل MKL. القلق هو كما يلي: عندما تكون المصفوفات ذات بعد يمثل قوة اثنين ، فمن المحتمل أن يكون "البعد الرائد" أيضًا قوة من اثنين. (يتوافق البعد البادئ مع خطوة العمود عندما تكون المصفوفة مخزنة في العمود ، أو خطوة الصف عند تخزين الصف.) لنفترض تخزين صف لحظة. عندما يكون البعد البادئ قوة اثنين ، فإن سطر ذاكرة التخزين المؤقت الذي يوجد فيه العنصر (i ، j) يعيش في نفس الارتباط المعين مثل سطر ذاكرة التخزين المؤقت حيث العناصر (i + 1 ، j) ، (i + 2 ، j) ، (i + 3 ، j) إلخ مباشرة - أي نفس عناصر الصفوف اللاحقة. هذا يعني أنه عند تحديث العملية gemm ، على سبيل المثال ، ملف دقيق حقيقي مزدوج الدقة 6 × 8 من C ، فإن هذه الصفوف الستة جميعها تعين نفس الارتباط المحدد في ذاكرة التخزين المؤقت L1 ، وحتمًا يتم طرد بعض هذه الصفوف قبل أن يتم معاد استخدامها. ستظهر هذه الأخطاء المزعومة في التعارض في الرسوم البيانية للأداء لدينا مع حدوث طفرات عرضية في الأداء. على حد علمي ، لا توجد طريقة سهلة للتغلب على هذا الأداء. لقد قمنا بالفعل بتعبئة / نسخ المصفوفات A و B ، لذلك لا يؤثر ذلك عليهم كثيرًا ، لكن لا يمكننا حزم المصفوفة C لبعض الأبعاد الرائدة الأكثر ملاءمة دون أخذ نسخة ضخمة من الذاكرة. (سيكون العلاج أسوأ من المرض.) الآن ، ربما يكون لدى MKL طريقة للتخفيف من هذا ، ربما التحول إلى نواة صغيرة ذات شكل مختلف تقلل من عدد أخطاء الصراع. أو ربما لا يفعلون ذلك ، لكنني أعلم أن BLIS لا تحاول فعل أي شيء للتخفيف من ذلك. نأمل أن يجيب هذا على سؤالك.
5. أنت محق في أن MKL هي أكثر من مجرد وظيفة BLAS + LAPACK. ومع ذلك ، ضع في اعتبارك أن MKL هو حل تجاري مغلق المصدر. في حين أنه متاح لأغراض غير تجارية "مجانًا" ، إلا أنه لا يوجد ضمان بأن Intel لن تجعل MKL غير متاح للجمهور في المستقبل ، أو تبدأ في فرض رسوم عليه مرة أخرى. بالإضافة إلى ذلك ، ليس الأمر رائعًا حقًا بالنسبة لنا نحن علماء الكمبيوتر الذين يرغبون في فهم التنفيذ ، أو تعديل أو تعديل التطبيق ، أو بناء بحثنا على لبنات بناء مفهومة جيدًا. ومع ذلك ، إذا كان كل ما تريد فعله هو حل مشكلتك والمضي قدمًا في يومك ، وأنت بخير في التعبير عنها عبر BLAS ، فهذا رائع. :)

fgvanzee محدث. سيئتي ، لسبب ما تم تجميعها باستخدام MKL ، على الرغم من أنني وضعت BLIS في config.
هل يتم تنفيذ SVD و EVD في LAPACK؟

homocomputeris نعم ، تطبق LAPACK SVD و EVD. وأتوقع أن تكون تطبيقات MKL سريعة للغاية.

ومع ذلك ، فإن مرض EVD غامض بعض الشيء: فهناك مشكلة القيمة الذاتية المعممة و EVD الهرمي (أو المتماثل). هناك أيضًا مرض فيروس الإيبولا ثلاثي الأضلاع ، ولكن عادةً ما يهتم به عدد قليل جدًا من الأشخاص ، باستثناء الأشخاص الذين ينفذون مرض فيروس الإيبولا في هيرميت.

ستقوم NumPy بإسقاط دعم Python 2.7 و 3.4 في نهاية عام 2018 ، مما سيسمح باستخدام أحدث برامج التحويل البرمجي MSVC المتوافقة مع C99 ، وهذا أحد أسباب قيامنا بهذه الخطوة قبل نفاد الدعم الرسمي 2.7. راجع http://tinyurl.com/yazmczel لمزيد من المعلومات حول دعم C99 في مترجمي MSVC الحديثين. الدعم ليس كاملاً (هل أحد مكتمل؟) ولكنه قد يكون كافياً. سننقل NumPy نفسها إلى C99 في مرحلة ما ، حيث طلب بعض (Intel) ذلك للحصول على دعم رقمي محسن.

@ تشارلز شكرا على هذه المعلومات ، تشارلز. من المحتمل أن كل ما سيتم تنفيذه سيكون كافياً ، لكننا لن نعرف على وجه اليقين حتى نجربه.

على أي حال ، لا تحتاج BLIS إلى التغلب على MKL لبدء التبني على نطاق واسع ؛ منافسها المباشر هو OpenBLAS.

لا يحتاج BLIS إلى التغلب على MKL لبدء التبني على نطاق واسع ؛ منافسها المباشر هو OpenBLAS.

لا يمكن أن نتفق أكثر. MKL هي في جامعة خاصة بها.

njsmith مجرد فضول: ما مدى اهتمام المجتمع غير المتراكم بواجهات برمجة التطبيقات / الوظائف الجديدة التي تسمح لأحد بأداء ، على سبيل المثال ، gemm بدقة مختلطة و / أو مجال مختلط؟ بمعنى ، يمكن أن يكون كل معامل من نوع بيانات مختلف ، مع إجراء الحساب (من المحتمل) بدقة مختلفة عن واحد أو كليهما من A و B؟

fgvanzee مهتم ، نعم ، على الرغم من أن العدد المحتمل

وهناك دائمًا تعويم 16. قد يكون الأشخاص ML أكثر اهتمامًا بهذه الوظائف. GaelVaroquaux أفكار؟

charris نعم ، يمكن أن يكون عدد الحالات مخيفًا. هناك 128 تركيبة نوع مقابل gemm ، بافتراض أنواع البيانات العائمة الأربعة التقليدية ، ويستثني هذا الرقم أي تضخم اندماجي من معلمات التحويل / الاقتران بالإضافة إلى إمكانيات تخزين المصفوفة (وفي هذه الحالة قد ترتفع إلى 55296).

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

إذا كان هذا يثير اهتمامك ، فيرجى مشاهدة مشروعنا في الأيام / الأسابيع القادمة. :)

هل شوكة BLIS آمنة؟

على أي حال ، لا تحتاج BLIS إلى التغلب على MKL لبدء التبني على نطاق واسع ؛ منافسها المباشر هو OpenBLAS.

في الواقع. لأكون صادقًا ، لم أستطع جعل NumPy + BLAS يعمل على نظامي ، لكن يبدو أنهما يتمتعان بأداء مشابه جدًا ، بناءً على المقالة التي ذكرتها من قبل.
من المحتمل أن libFLAME يمكنه تسريع عمليات LAPACK إذا تم ربطه بـ NumPy.

سؤال آخر مثير للاهتمام هو اختبار شوكة BLIS / libFLAME من AMD على أحدث وحدات المعالجة المركزية Zen لمعرفة ما إذا كانت قد حصلت على أي تحسن. يصبح الأمر أكثر إثارة للاهتمام في ضوء معالجات Intel ذات المشكلات.

في نظامي Linux و Windows ، تتضمن العجلات الرسمية لـ Numpy حاليًا نسخة مسبقة الصنع من OpenBLAS ، لذا فإن أسرع طريقة للحصول على نسخة على هذه الأنظمة الأساسية هي pip install numpy . (بالطبع هذا ليس عادلاً تمامًا لأنه على سبيل المثال ، تم إنشاء هذا الإصدار باستخدام مترجم مختلف عن الذي تم استخدامه لبناء BLIS محليًا ، ولكنه يمكن أن يعطي فكرة ما.)

هل شوكة BLIS آمنة؟

jakirkham لقد تحدثت إلى devinamatthews حول هذا الأمر ، ويبدو أنه يعتقد أن الإجابة هي نعم. يولد BLIS سلاسل الرسائل عند الطلب ، (على سبيل المثال ، عند استدعاء gemm ) بدلاً من الاحتفاظ بمجموعة مؤشرات الترابط كما يفعل OpenBLAS.

نحن فضوليون على الرغم من ذلك: ما هو نوع نموذج الخيط الذي يتوقعه / يفضل / يعتمد عليه numpy ، إن وجد؟ هل تحتاج إلى مجموعة خيوط لتقليل النفقات العامة في حالة استخدام استدعاء العديد من المشكلات الصغيرة جدًا على التوالي؟ (خيوط BLIS عند الطلب ليست مناسبة تمامًا لهذا النوع من الاستخدام.)

تحرير: في سياق مماثل ، هل تحتاج إلى pthreads ، أو هل أنت قادر على OpenMP؟

شكرا للمعلومة.

فهل يستخدم pthreads ، OpenMP ، كلاهما؟ FWIW هناك مشكلات معروفة مع OpenMP لدول مجلس التعاون الخليجي والتشعب الذي لم يتم حل AFAIK ( multiprocessing في Python أحد أكثر استراتيجيات التوازي شيوعًا ، فالقدرة على استخدام الخيوط (ويفضل أن تكون pthreads للسبب أعلاه) بطريقة آمنة للتشعب أمر مهم جدًا في Python بشكل عام. على الرغم من وجود المزيد من الخيارات هذه الأيام مع أشياء مثل loky على سبيل المثال التي تستخدم fork-exec.

من المسلم به أن ناثانييل يعرف الكثير عن هذا أكثر مما أعرفه ، ولكن منذ أن بدأت بالفعل في كتابة هذا التعليق ، فإن IIUC NumPy لا تستخدم خيوط المعالجة نفسها إلا من خلال مكتبات خارجية (مثل BLAS). على الرغم من أن NumPy تطلق GIL في كثير من الأحيان بشكل كافٍ ، مما يسمح للخيوط في Python أن تكون فعالة إلى حد ما. تستفيد أشياء مثل Joblib و Dask وما إلى ذلك من هذه الاستراتيجية.

بالنسبة لمجموعات الخيوط ، من المثير للاهتمام أن تسأل عن هذا لأنني كنت فقط أقوم بتوصيف تقنية ML لتعظيم الأداء في اليوم الآخر الذي يقوم بسلسلة من إجراءات BLAS في Python باستخدام NumPy / SciPy. باستخدام OpenBLAS وعدد معقول من النوى ، فإن هذا الروتين قادر على تشبع النوى لطول الروتين على الرغم من عدم وجود خيوط صريحة مستخدمة في Python (بما في ذلك NumPy و SciPy) لمجرد أن OpenBLAS استخدم مجموعة خيوط لطول نمط. لذا ، نعم ، تعتبر حمامات الخيوط ذات قيمة لا تصدق.

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

jakirkham شكرا لتعليقاتكم. أفترض أن التكلفة الملحوظة لعدم وجود مجموعة مؤشرات ترابط ستعتمد على حجم معاملات المصفوفة التي تقوم بتمريرها والعملية التي تقوم بها. أفترض أن gemm هي عملية نموذجية تستهدفها (يرجى التصحيح إذا كنت مخطئًا) ، ولكن ما حجم المشكلة الذي تعتبره نموذجيًا؟ أتخيل أن تكلفة نموذج الإنشاء / الانضمام الخاص بـ BLIS ستظهر إذا كنت تقوم بضرب المصفوفة بشكل متكرر حيث كانت A و B و C 40x40 ، ولكن ربما ليس بنفس القدر 400x400 أو أكبر. (TBH ، ربما لا يجب أن تتوقع تسريعًا كبيرًا من موازاة مشاكل 40x40 لتبدأ.)

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

نعم. تم تنفيذ هذه الميزة منذ وقت ليس ببعيد ، في النصف الأخير من عام 2017. يمكن لـ BLIS الآن استهداف ما يسمى بـ "مجموعات التكوين" ، مع تكوين فرعي محدد يتم اختياره في وقت التشغيل من خلال بعض الأساليب التجريبية (على سبيل المثال cpuid تعليمات intel64 ، amd64 ، x86_64 .

fgvanzee أعتقد بالفعل أن الأداء على المصفوفات الصغيرة هو أحد نقاط الضعف في OpenBLAS ، لذلك من المقلق بعض الشيء إذا كان BLIS أبطأ مرة أخرى ... الناس بالتأكيد يستخدمون numpy في جميع أنواع المواقف ، لذلك نحن نقدر حقًا المكتبات التي "العمل فقط" دون الحاجة إلى ضبط لحالات معينة. (أعتقد أن هذا يختلف قليلاً عن الإعداد الكلاسيكي للجبر الخطي الكثيف ، حيث إن أهم حالتين هما مؤلف الخوارزمية الذي يقوم بإجراء المعايير ، والخبراء الذين يديرون وظائف الكمبيوتر العملاق لمدة أسبوع مع مدراء نظام متخصصين.) على سبيل المثال ، غالبًا ما يستخدم الأشخاص numpy مع مصفوفات 3x3.

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

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

في الواقع هذا يذكرني: كنت أتحدث مع شخص الأسبوع الماضي الذي كان يعلم أنه في مكتبته أراد استدعاء الأحجار الكريمة ذات الخيط الواحد ، لأنه كان يدير الترابط على مستوى أعلى ، وكان محبطًا من أن مكتبات blas القياسية هي الطريقة الوحيدة التحكم في هذا عبر الإعدادات العالمية التي يسهل الاتصال بها من داخل مكتبة عشوائية. هل تسمح واجهة برمجة تطبيقات BLIS الأصلية للمستخدم بالتحكم في تكوين مؤشر الترابط على أساس كل اتصال على حدة؟ أظن نعم ، لأن IIRC ليس لديك أي تكوين عام على الإطلاق ، خارج طبقة التوافق BLAS؟

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

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

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

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

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

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

نعم.

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

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

هل تسمح واجهة برمجة تطبيقات BLIS الأصلية للمستخدم بالتحكم في تكوين مؤشر الترابط على أساس كل اتصال على حدة؟ أظن نعم ، لأن IIRC ليس لديك أي تكوين عام على الإطلاق ، خارج طبقة التوافق BLAS؟

حتى إذا قمت بتكوين BLIS مع تمكين تعدد مؤشرات الترابط ، يتم تعطيل التوازي (مؤشر ترابط واحد) افتراضيًا. هذه طريقة ثانية لحل مشكلته.

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

devinamatthews أي فرصة لإضافة TBLIS على طول نفس المسار؟

إذا كانت لديك مشكلة 3x3 ، والأداء مهم حقًا بالنسبة لك ، فمن المحتمل ألا تستخدم BLIS. أنا لا أقول أن BLIS سيعمل أبطأ بمقدار 10 مرات من الحلقة الثلاثية الساذجة لـ 3x3 ، فقط هذا ليس حجم المشكلة الذي تتفوق فيه تطبيقات BLIS.

لست قلقًا بشأن الحصول على الأداء الأمثل لمشاكل 3x3 (على الرغم من أنه من الواضح أنه من الجيد أن نحصل عليه!). ولكن لإعطاء مثال متطرف: إذا تم تجميع numpy باستخدام BLIS كمكتبة الجبر الخطي الأساسية ، وكتب بعض المستخدمين a @ b في الكود الخاص بهم باستخدام numpy ، آمل بالتأكيد ألا ينتهي الأمر بتشغيل أبطأ 10x من تطبيق ساذج. إن توقع قيام المستخدمين بإعادة بناء numpy قبل ضرب المصفوفات 3x3 يعد أمرًا أكثر من اللازم :-). خاصة وأن نفس البرنامج الذي يضاعف المصفوفات 3 × 3 في مكان واحد قد يضاعف أيضًا 1000 × 1000 مصفوفة في مكان آخر.

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

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

آمل بالتأكيد ألا ينتهي الأمر بتشغيل أبطأ 10x من تطبيق ساذج.

الآن بعد أن فكرت في الأمر ، لن أتفاجأ إذا كانت أبطأ عدة مرات من السذاجة للمشكلات الصغيرة جدًا (3 × 3) ، لكن نقطة التقاطع ستكون منخفضة ، ربما صغيرة مثل 16 × 16. وهذه مشكلة يسهل وضع ضمادة عليها

إنه يشحن مكتبة بايثون. يتوقع أن يأخذ المستخدمون مكتبته ، ويجمعونها مع مكتبات أخرى وكودهم الخاص ، وكلها تعمل معًا في نفس العملية. تستخدم مكتبته برنامج GEMM ، ومن المحتمل أن بعض الرموز الأخرى التي لا يتحكم فيها - أو حتى يعرف عنها - سيرغب أيضًا في استخدام GEMM. إنه يريد أن يكون قادرًا على التحكم في سلسلة مكالماته مع GEMM ، دون التأثير بطريق الخطأ على المكالمات الأخرى غير ذات الصلة بـ GEMM والتي قد تحدث في نفس العملية. ومن الناحية المثالية ، سيكون قادرًا على القيام بذلك دون الحاجة إلى شحن نسخته الخاصة من GEMM ، نظرًا لأن هذا أمر مزعج جدًا للقيام به بشكل صحيح ، كما أنه من المثير للهجوم من الناحية المفاهيمية أن يتضمن البرنامج نسختين من مكتبة كبيرة فقط لذلك يمكنك الحصول على نسختين من متغير عدد صحيح واحد number_of_threads. هل هذا أكثر منطقية؟

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

هل تمانع في إبلاغه أن هذا بالتأكيد على رادارنا؟ سوف اجتمع مع روبرت. قد يكون مهتمًا بما يكفي للموافقة على قضاء وقتي في هذا عاجلاً وليس آجلاً. (واجهة برمجة تطبيقات الترابط موجودة في قائمة أمنياته منذ فترة.)

من الممكن بالتأكيد بناء BLIS على النوافذ باستخدام clang.exe التي تستهدف MSVC ABI. قضيت بضع ساعات وإليكم التغييرات. كان عدد التغييرات المطلوبة منخفضًا بشكل مدهش مقارنة بـ OpenBLAS.
السجل هنا . اجتازت جميع اختبارات BLIS و BLAS.

isuruf شكرًا لك على الوقت الذي

بالنسبة لطلب السحب ، لدي بعض التعليقات / الطلبات (كلها بسيطة جدًا) ، لكنني سأبدأ محادثة حول طلب السحب نفسه.

ملاحظة: يسعدني أنك تمكنت من اكتشاف أخطاء f2c . لقد قمت باستيراد أجزاء كافية من libf2c إلى مصدر برنامج تشغيل اختبار BLAS (تم تجميعه كـ libf2c.a ) بحيث يتم ربط الأشياء ، على الرغم من أنها تتطلب بعض القرصنة في ملفات الرأس. (لا أحب الحفاظ على كود Fortran - لدرجة أنني أفضل أن أنظر إلى f2c'ed C بدلاً من Fortran - في حال لم تستطع معرفة ذلك).

إنتل MKL 2018.3:

Dotted two 4096x4096 matrices in 2.09 s.
Dotted two vectors of length 524288 in 0.23 ms.
SVD of a 2048x1024 matrix in 1.11 s.
Cholesky decomposition of a 2048x2048 matrix in 0.19 s.
Eigendecomposition of a 2048x2048 matrix in 7.83 s.

كلمة عن المعيار المستخدم أعلاه. ذكّرني روبرت أنه ما لم نعرف كيف يطبق هذا المعيار (أو numpy؟) Cholesky و EVD و SVD ، فإن نتائج هذه العمليات لن تكون ذات معنى. على سبيل المثال ، إذا تم استخدام كود netlib LAPACK لعامل Cholesky ، فسيكون حجم الكتل الحسابية خاطئًا (بعيدًا عن المثالية). علاوة على ذلك ، اعتمادًا على كيفية الروابط غير المستقرة إلى MKL ، قد يؤدي ذلك إلى تشويه الأشياء بشكل أكبر لأن MKL لديها تنفيذها الخاص لعامل Cholesky بالإضافة إلى fast gemm ، لذلك قد لا يكون من التفاح إلى التفاح عند المقارنة MKL.

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

بشكل عام ، يقوم numpy بتأجيل العمليات مثل تلك إلى أي مكتبة LAPACK أو LAPACK على حد سواء متاحة. من شبه المؤكد أن تصميمات MKL تستخدم الشوكة المضبوطة لـ LAPACK التي تشحنها Intel داخل MKL. ربما تستخدم تصميمات BLIS المرجع LAPACK أو شيء من هذا القبيل.

هذا أمر عادل إلى حد ما: إذا كنت تحاول اختيار تكوين بسيط للقيام بـ SVD سريع ، فمن المناسب أن يكون لدى MKL إصدارًا مضبوطًا متاحًا وأن BLIS لا يفعل ذلك. (أعتقد أن OpenBLAS يقع بينهما: يشحنون نسخة معدلة من LAPACK مع المكتبة ، لكنه أقرب بكثير إلى التطبيق المرجعي من إصدار MKL.) ولكن نعم بالتأكيد إذا كنت تحاول فهم ماهية BLIS ولماذا النتائج تبدو على هذا النحو ، من المهم أن تتذكر أن هناك الكثير من الأشياء التي تدخل في SVD / إلخ أكثر من مجرد كفاءة GEMM الخالصة.

هذا عادل بمعنى ما:

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

njsmithinsertinterestingnameherergommerscharris بفضل العمل Isuru وسريع، كنا قادرين على صقل ودمج له على أساس appveyor دعم ويندوز إلى المعايير الأساسية ل master فرع. يرجى إلقاء نظرة وإخبارنا ما إذا كان هذا يعالج مشكلة دعم Windows لـ numpy وإلى أي درجة.

fgvanzee هل يمكنك الارتباط

هل يمكنك الارتباط بالعلاقات العامة؟

بالتأكيد ، ها هو.

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

هناك شيء واحد يجب ملاحظته حول التبعيات المستخدمة في هذه الحالة: pthreads-win32 هو LGPL. اعرف ما الذي يجب فعله حيال ذلك ، إن وجد.

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

نحن لا نضيفه إلى قاعدة الشفرة هنا. لا يمثل شحن أحد مكونات LGPL في عجلات مشكلة. نقوم الآن بشحن ملف gfortran dll الذي يمثل GPL مع استثناء وقت التشغيل. انظر gh-8689

في الواقع. إلى جانب ذلك ، لن يتفاجأ إذا كانت هذه الشركات تفضل أيضًا MKL.

نحتاج فقط للتأكد من أن مكون LGPL ليس مرتبطًا بشكل ثابت ، على الأرجح.

jakirkham شكرا لتعليقاتكم. أفترض أن التكلفة الملحوظة لعدم وجود مجموعة مؤشرات ترابط ستعتمد على حجم معاملات المصفوفة التي تقوم بتمريرها والعملية التي تقوم بها. أفترض أن الأحجار الكريمة هي عملية نموذجية تستهدفها (يرجى تصحيح ما إذا كنت مخطئًا) ، ولكن ما حجم المشكلة الذي تعتبره نموذجيًا؟ أتخيل أن تكلفة نموذج الإنشاء / الانضمام الخاص بـ BLIS ستظهر إذا كنت تقوم بضرب المصفوفة بشكل متكرر حيث كانت A و B و C 40x40 ، ولكن ربما ليس بنفس القدر 400x400 أو أكبر. (TBH ، ربما لا يجب أن تتوقع تسريعًا كبيرًا من موازاة مشاكل 40x40 لتبدأ.)

بشكل رئيسي GEMM و SYRK نموذجيان. يظهر GEMV في بعض الأحيان ، ولكن غالبًا ما يتم تحويله إلى عملية GEMM كبيرة إذا أمكن ذلك.

ليس من غير المعتاد بالنسبة لنا أن يكون لدينا بُعد واحد على الأقل بترتيب 10 ^ 6 عناصر. يمكن أن يكون الآخر في أي مكان من 10 ^ 3 إلى 10 ^ 6. لذلك فإن الأمر يختلف قليلاً. هل هناك أي شيء نحتاج إلى القيام به للاستفادة من مجموعة threadpool أم أن ذلك يحدث تلقائيًا؟ أيضا كيف يتصرف Threadpool إذا كانت العملية متشعبة؟

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

نعم. تم تنفيذ هذه الميزة منذ وقت ليس ببعيد ، في النصف الأخير من عام 2017. يمكن لـ BLIS الآن استهداف ما يسمى بـ "مجموعات التكوين" ، مع تكوين فرعي محدد يتم اختياره في وقت التشغيل من خلال بعض الأساليب التجريبية (مثل تعليمات وحدة المعالجة المركزية). من أمثلة العائلات المدعومة intel64 و amd64 و x86_64.

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

تحصل على بناء التكوين x86_64 :

• Penryn (بما في ذلك Nehalem وأي شريحة Intel SSSE3 64 بت أخرى)
• جسر ساندي (بما في ذلك جسر آيفي)
• هاسويل (+ Broadwell و Skylake و Kaby Lake و Coffee Lake ، على الرغم من أنها قد لا تكون مثالية تمامًا لآخر ثلاثة)
• Xeon Phi (الجيل الأول والثاني ، يمكننا عمل الجيل الثالث أيضًا إذا لزم الأمر)
• Skylake SP / X / W (من المحتمل أن تكون قريبة جدًا من المستوى الأمثل في بحيرة كانون أيضًا)
• جرافة / Piledriver / عربة بخارية / حفارة
• Ryzen / EPYC

لاحظ أن بعضها يتطلب مترجمًا جديدًا و / أو إصدارًا من binutils جديدًا بدرجة كافية ، ولكن فقط على آلة الإنشاء.

لا يحتوي AFAIK libflame على نواة متخصصة لأي هندسة ، كل هذا متروك لـ BLIS.

jakirkham علينا إضافة تطبيق threadpool. في الوقت الحالي ، يعد تنفيذًا أساسيًا لربط الشوكة والذي يجب أن يكون آمنًا من حيث التشعب.

لا يحتوي AFAIK libflame على نواة متخصصة لأي هندسة ، كل هذا متروك لـ BLIS.

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

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

jakirkham لست متأكدًا مما

إذا استبدلت "Flame" نصيًا بـ "BLIS" ، فإن الإجابة هي "نعم ، في الغالب".

إلى أي مدى تحصل على حبيبات؟

لست متأكدًا مما تقصده ، لكن دعم kernel في BLIS ليس واسع النطاق كما هو الحال في OpenBLAS. على سبيل المثال ، في كثير من الأحيان لا نقوم بتحسين المجال المعقد trsm . يتم استخدام النوى ، في بعض التركيبات ، عن طريق التكوينات الفرعية. يتم اختيار التكوينات الفرعية عبر cpuid . تحصل بالضبط على النواة "مسجلة" بواسطة التكوين الفرعي. يرجى الاطلاع على ويكي التكوين للحصول على تفاصيل حول الصواميل والمسامير.

هل هناك أي شيء نحتاج إلى القيام به أثناء الإنشاء لضمان وجود هذه النوى؟

إذا كنت بحاجة إلى اكتشاف أجهزة وقت التشغيل ، فأنت تستهدف عائلة تكوين (على سبيل المثال ، intel64 ، x86_64 ) في وقت التكوين بدلاً من تكوين فرعي محدد (أو auto ، والذي يحدد تكوين فرعي محدد). هذا هو.

هل هناك أي شيء نحتاج إلى القيام به للاستفادة من مجموعة threadpool أم أن ذلك يحدث تلقائيًا؟ أيضا كيف يتصرف Threadpool إذا كانت العملية متشعبة؟

كما قلت سابقًا في هذا الموضوع ، لا يستخدم BLIS تجمع مؤشرات الترابط. وأنا أتفق مع Devin بشأن سلامة الشوكة (ويبدو أنه يعتقد أن التفرع لن يكون مشكلة).

تتوفر حزم FYI و BLIS conda لنظام التشغيل Linux و osx و windows على conda-forge. (حاليا بناء فرع ديف ، في انتظار الإصدار). تم إنشاء الحزم مع تمكين pthreads وتكوين x86_64.

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

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

jakirkham يخبرنا أحد جهات اتصالنا في Intel ، مؤشرات الترابط داخليًا. وبالتالي ، فهو يثنينا عن تنفيذ مجموعات الخيوط بشكل متكرر داخل BLIS.

الآن ، قد يكون الأمر كذلك ، كما تقترح ، تلك الاحتياجات / يفضل pthreads ، وفي هذه الحالة ربما نعود إلى الانقسام الفعلي / الانضمام الذي يحدث أسفل واجهة برمجة تطبيقات pthreads بنمط fork / connect

فهل يستخدم pthreads ، OpenMP ، كلاهما؟

كما أدركت أنني نسيت الإجابة على هذا السؤال. التوازي متعدد مؤشرات الترابط الخاص بـ BLIS قابل للتكوين: يمكنه استخدام pthreads أو OpenMP. (ومع ذلك ، لا ينبغي الخلط بين هذا وبين اعتماد BLIS غير المشروط لوقت التشغيل على pthreads نظرًا لاعتمادنا على pthread_once() ، والذي يستخدم لتهيئة المكتبة.)

لسوء الحظ ، ما لم تصبح تطبيقات OpenMP (مثل GOMP) بشكل عام أكثر قوة للتشعب ، فهي ليست خيارًا آمنًا حقًا في Python. لا سيما في شيء منخفض في المكدس مثل NumPy.

لسوء الحظ ، ما لم تصبح تطبيقات OpenMP (مثل GOMP) بشكل عام أكثر قوة للتشعب ، فهي ليست خيارًا آمنًا حقًا في Python. لا سيما في شيء منخفض في المكدس مثل NumPy.

عادل بما يكفي. لذلك يبدو أن numpy سيعتمد على خيار التكوين --enable-threading=pthreads لتعدد مؤشرات الترابط عبر BLIS.

عند التحويل البرمجي باستخدام pthreads ، هل هناك بعض واجهات برمجة التطبيقات العامة للحصول على بعض التحكم البرمجي لتجنب مشكلات زيادة الاشتراك عند القيام بالتوازي المتداخل مع عمليات Python / مجموعات الخيوط التي تستدعي numpy؟

بشكل أكثر تحديدًا ، إليك أنواع الرموز العامة التي سأبحث عنها:

https://github.com/tomMoral/loky/pull/135/files#diff -e49a2eb30dd7db1ee9023b8f7306b9deR111

مشابه لما يتم في https://github.com/IntelPython/smp لـ MKL & OpenMP.

عند التحويل البرمجي باستخدام pthreads ، هل هناك بعض واجهات برمجة التطبيقات العامة للحصول على بعض التحكم البرمجي لتجنب مشكلات زيادة الاشتراك عند القيام بالتوازي المتداخل مع عمليات Python / مجموعات الخيوط التي تستدعي numpy؟

ogrisel سؤال عظيم gemm أو أيًا كان) فإنه يتغذى من خلال متغيرات البيئة.

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

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

ملاحظة: لقد ألقيت نظرة على الرابط المحبب الذي قدمته. تم إعداد جميع هذه الرموز لإعداد شامل للخيوط. لن يمنع الحل الذي أقترحه وضع الأشياء على مستوى عالمي ، ولكنه مصمم بحيث لا يكون هذا هو الخيار الوحيد . لذلك يمكن للشخص الذي يريد استخدام 8 مراكز / خيوط كحد أقصى أن يكون لديه تطبيق يفرز خيوط 2 ، ويستدعي كل منهما مثيل gemm يحصل على توازي رباعي الاتجاهات. أو 3 سلاسل تطبيقات حيث يستدعي اثنان منهم gemm بتوازي ثنائي الاتجاه بينما الثالث يستخدم التوازي رباعي الاتجاهات. (انت وجدت الفكرة.)

يتغذى من خلال متغيرات البيئة.

ماذا يعنى ذلك؟ هل من الممكن استخدام ctypes من Python لإعادة تكوين حجم تجمع خيوط BLIS الافتراضي / العام بمجرد تهيئته بالفعل في عملية Python معينة؟

يتغذى من خلال متغيرات البيئة.

ماذا يعنى ذلك؟

ogrisel ما أعنيه بهذا هو أن لدينا واجهة برمجة تطبيقات صغيرة في BLIS لتعيين أو الحصول على عدد الخيوط ، على غرار omp_get_num_threads() و omp_set_num_threads() في OpenMP. ومع ذلك ، يتم تنفيذ وظائف BLIS API هذه كمكالمات إلى getenv() و setenv() . هذه مجرد قطعة أثرية تاريخية لحقيقة أن إحدى حالات الاستخدام الأصلية لـ BLIS كانت تعيين واحد أو أكثر من متغيرات البيئة في الصدفة (على سبيل المثال bash ) ثم تنفيذ تطبيق مرتبط بنظام BLIS ، لذلك في الوقت المناسب للبناء ببساطة على نهج متغير البيئة هذا ؛ لم يكن من المفترض أن تكون الطريقة النهائية والمثالية لتحديد عدد خيوط التوازي.

هل من الممكن استخدام ctypes من Python لإعادة تكوين حجم تجمع مؤشرات الترابط BLIS بمجرد تهيئته بالفعل في عملية Python محددة؟

لا يستخدم BLIS بشكل صريح تجمع مؤشرات الترابط. بدلاً من ذلك ، نستخدم نموذج إنشاء / انضمام لاستخراج التوازي عبر pthreads. لكن نعم ، بعد تهيئة BLIS ، يمكن للتطبيق (أو مكتبة الاستدعاء) تغيير عدد سلاسل الرسائل في وقت التشغيل عبر استدعاء دالة ، على الأقل من حيث المبدأ. (لا أعرف ما إذا كان هذا سيعمل عمليًا ، لأنني لا أعرف كيف ستتعامل Python مع محاولة BLIS لتعيين / الحصول على متغيرات البيئة.) ولكن كما ذكرت سابقًا ، بمجرد إكمال بعض التعديلات ، فإن التطبيق / سوف تكون المكتبة قادرة على تحديد مخطط موازٍ مخصص على أساس كل مكالمة في الوقت الذي يتم فيه استدعاء عملية المستوى 3. يمكن القيام بذلك أولاً عن طريق تهيئة نوع بيانات صغير struct ثم تمرير هذا struct إلى إصدار "خبير" ممتد من BLIS API مقابل gemm ، على سبيل المثال.) هذا من شأنه أن يجعل متغيرات البيئة غير ضرورية لمن لا يحتاجونها / يريدونها. نأمل أن هذا يجيب عن سؤالك.

شكرا جزيلا على التوضيحات لك. تعد واجهة برمجة التطبيقات (API) الخبيرة لكل مكالمة مثيرة للاهتمام ولكنها تتطلب numpy للحفاظ على واجهة برمجة تطبيقات محددة لكشف ذلك للمتصلين على مستوى Python. لست متأكدا من أننا نريد ذلك. أعتقد أنه بالنسبة للمستخدمين العُدد الذين لديهم طريقة لتغيير القيمة الحالية لمستوى التوازي العالمي (مستوى العملية) كافٍ. أنا شخصياً لا أمانع إذا تم تحقيق ذلك عن طريق تغيير القيمة الحالية لمتغير env طالما أن هذا التغيير يأخذ في الاعتبار لمكالمات BLAS-3 اللاحقة.

قد يكون charris float16

أعتقد أنه بالنسبة للمستخدمين العُدد الذين لديهم طريقة لتغيير القيمة الحالية لمستوى التوازي العالمي (مستوى العملية) كافٍ. أنا شخصياً لا أمانع إذا تم تحقيق ذلك عن طريق تغيير القيمة الحالية لمتغير env طالما أن هذا التغيير يأخذ في الاعتبار لمكالمات BLAS-3 اللاحقة.

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

ربما من الأفضل عدم الاعتماد على متغيرات البيئة التي يتم إعادة فحصها في كل مكالمة ، لأن getenv ليس سريعًا للغاية ، لذلك قد يكون من المنطقي إزالته لاحقًا. (أيضًا ، لا أعتقد أنه من المضمون حتى أن تكون آمنة في مؤشر الترابط؟) ولكن يجب أن تكون مكالمات API bli_thread_set_num_threads جيدة ، لأنه حتى لو توقف BLIS عن استدعاء getenv طوال الوقت ، فإن API يستدعي يمكن تعديلها لمواصلة العمل بغض النظر.

على المدى الطويل ، أعتقد أنه سيكون من المنطقي البدء في الكشف عن بعض واجهات برمجة التطبيقات (APIs) التي تجاوزت العارية BLAS في numpy. أحد الأشياء التي تجعل BLIS جذابة في المقام الأول هو بالضبط أنها توفر ميزات لا توفرها مكتبات BLAS الأخرى ، مثل القدرة على مضاعفة المصفوفات المتتالية ، وهناك عمل جاري لتوسيع واجهات برمجة تطبيقات BLAS بعدة طرق .

لا نرغب في ترميز التفاصيل الخاصة بالمكتبة في واجهة برمجة تطبيقات numpy's (على سبيل المثال ، لا نريد أن يبدأ np.matmul في أخذ الحجج المقابلة لمعلمات BLIS's JC و IC و JR و IR ) ، ولكنه قد يكون من المنطقي تقديم حجة عامة حول "عدد سلاسل الرسائل لهذه المكالمة" التي تعمل فقط على الخلفيات التي توفر تلك الوظيفة.

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

charris حجم العدد الصحيح في BLIS قابل للتكوين في وقت التكوين: 32 أو 64 بت. علاوة على ذلك ، يمكنك تكوين حجم العدد الصحيح المستخدم في BLAS API بشكل مستقل عن حجم العدد الصحيح الداخلي.

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

njsmith لقد أصلحت حالة السباق التي ذكرتها سابقًا ونفذت أيضًا واجهة برمجة التطبيقات متعددة مؤشرات الترابط الآمنة لكل مكالمة. يرجى توجيه صديقك نحو fa08e5e (أو أي سليل لهذا الالتزام). تم أيضًا تحديث التوثيق متعدد مؤشرات الترابط وإرشاد القارئ من خلال خياراته ، مع إعطاء أمثلة أساسية. الالتزام موجود في الفرع dev في الوقت الحالي ، لكنني أتوقع دمجه في master قريبًا. (لقد قمت بالفعل بوضع الشفرة في معظم خطواتها).

تحرير: تم تحديث الروابط لتعكس الالتزام بإصلاح بسيط

كإضافة محتملة للأنواع المدعومة ، ماذا عن long double ؟ ألاحظ أن بعض الأبنية بدأت في دعم الدقة الرباعية (لا تزال في البرنامج) وأتوقع أنه في مرحلة ما سيتم استبدال الدقة الممتدة بدقة رباعية على intel. لا أعتقد أن هذا أمر ملح على الفور ، لكنني أعتقد أنه بعد كل هذه السنوات بدأت الأمور تسير على هذا النحو.

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

charris وفقًا لـ https://en.wikipedia.org/wiki/Long_double ، يمكن أن يعني long double مجموعة متنوعة من الأشياء:

• نوع 80 بت مطبق في x87 ، باستخدام تخزين 12B أو 16B
• دقة مزدوجة مع MSVC
• دقة مزدوجة مزدوجة
• دقة رباعية
  نظرًا لأن المعنى غامض ولا يعتمد فقط على الأجهزة ولكن على المترجم المستخدم ، فهذه كارثة مطلقة للمكتبات ، لأن ABI غير محدد جيدًا.

من منظور الأداء ، لا أرى أي اتجاه صعودي لـ float80 (أي x87 long double) لأنه لا يوجد إصدار SIMD. إذا كان بإمكان المرء كتابة إصدار SIMD double double في BLIS ، فيجب أن يؤدي ذلك بشكل أفضل.

يعد تنفيذ float128 في البرنامج على الأقل ترتيبًا من حيث الحجم أبطأ من float64 في الأجهزة. سيكون من الحكمة كتابة تنفيذ جديد لـ float128 يتخطى جميع عمليات معالجة FPE ويكون قابلاً للتطبيق SIMD. التنفيذ في libquadmath ، على الرغم من صحته ، لا يستحق اهتمام تطبيق BLAS عالي الأداء مثل BLIS.

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

يتضمن اقتراح BLAS G2 بعض الاعتبارات للحسابات المزدوجة و "القابلة للتكرار" في BLAS. (قابل للتكرار هنا يعني حتمية عبر التطبيقات ، لكن IIUC تتضمن أيضًا استخدام قيم وسيطة عالية الدقة.)

متحمس لرؤية هذا يتحرك إلى الأمام!

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

لقد قمت ببعض الأعمال منذ حوالي عام على تغليف Blis لـ PyPi ، وإضافة روابط Cython: https://github.com/explosion/cython-blis

لقد وجدت Blis من السهل جدًا تجميعه كملحق C مثل هذا. كان العائق الرئيسي بالنسبة لي هو دعم Windows. من الذاكرة ، كانت مشكلات C99 ، لكن ربما أتذكرها بشكل خاطئ.

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

سأكون سعيدًا جدًا للحفاظ على حزمة Blis قائمة بذاتها ، والحفاظ على بناء العجلات ، والحفاظ على واجهة Cython لطيفة ، وما إلى ذلك. أعتقد أنه سيكون من الجيد جدًا الحصول عليها كحزمة منفصلة ، بدلاً من شيء مدمج داخل numpy. يمكننا بعد ذلك الكشف عن المزيد من واجهة برمجة تطبيقات Blis ، دون التقيد بما تدعمه مكتبات BLAS الأخرى.

honnibal آسف للتأخير في الرد على هذا الموضوع ، ماثيو.

شكرا على رسالتك. يسعدنا دائمًا رؤية الآخرين متحمسون بشأن BLIS. بالطبع ، يسعدنا تقديم المشورة كلما دعت الحاجة إذا قررت الاندماج بشكل أكبر في نظام Python البيئي (تطبيق ، مكتبة ، وحدة ، إلخ).

بالنسبة إلى دعم Windows ، يرجى التحقق من دعم clang / appveyor لنظام Windows ABI الذي أضافهisuruf مؤخرًا. آخر ما سمعته منه ، كان يعمل كما هو متوقع ، لكننا لا نقوم بأي تطوير على Windows هنا في UT ، لذلك لا يمكنني متابعة هذا بنفسي. (على الرغم من أن Isuru أوضح لي ذات مرة أنه يمكنني الاشتراك في appveyor بطريقة مشابهة لـ Travis CI.)

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

اعتبارًا من BLIS 0.5.2 ، لدينا مستند أداء يعرض

لذا ، إذا كان المجتمع الخفي يتساءل عن كيفية تكديس BLIS مقابل حلول BLAS الرائدة الأخرى ، فأنا أدعوك لإلقاء نظرة خاطفة سريعة!

مثير جدا للاهتمام ، شكرا fgvanzee.

اضطررت إلى البحث عن Epyc - يبدو أن هذا اسم علامة تجارية يعتمد على بنية Zen (ربما تم تحديثها إلى Zen + في مرحلة ما؟). ربما من الأفضل إعادة تسمية Zen؟ بالنسبة لقاعدة مستخدمينا ، فإن Ryzen / Threadripper هي العلامات التجارية الأكثر إثارة للاهتمام ، فقد يتعرفون على Zen ولكن ربما ليس Epyc.

Epyc هو اسم خط خادم AMD. إنه خليفة منتجات AMD Opteron في الماضي.

للأسف ، لا توجد طريقة فريدة لـ BLIS لتسمية أهدافها المعمارية ، لأن الكود يعتمد على ناقل ISA (مثل AVX2) ، والبنية الدقيقة لوحدة المعالجة المركزية (مثل Ice Lake) وتكامل SOC / النظام الأساسي (مثل معالج Intel Xeon Platinum ). يستخدم BLIS أسماء رموز معمارية دقيقة في بعض الحالات (مثل Dunnington) ولكن هذا ليس أفضل للجميع.

fgvanzee قد تفكر في إضافة الأسماء المستعارة التي تتوافق مع أسماء GCC march / mtune / mcpu ...

rgommers تم بالفعل تسمية zen ، لأنه يلتقط كلا المنتجين.

بالنسبة إلى ما إذا كانت Ryzen / Threadripper أو Epyc هي علامات تجارية أكثر إثارة للاهتمام (حتى بالنسبة للمستخدمين المبتدئين) ، فسأقول هذا: إذا كان بإمكاني فقط قياس نظام AMD Zen واحد ، فسيكون هذا هو أعلى مستوى Epyc ، لأنه يستخدم معمارية دقيقة مماثلة لتلك الخاصة بـ Ryzen ؛ (ب) يعطيني الحد الأقصى من النوى المادية 64 (وكمكافأة ، يتم ترتيب هذه النوى في تكوين جديد إلى حد ما يشبه NUMA) والتي (ج) تضع أقصى قدر من الضغط على BLIS والتطبيقات الأخرى. وهذا ما فعلناه هنا.

الآن ، لحسن الحظ ، لا توجد قاعدة تنص على أنه يمكنني فقط قياس نظام Zen واحد. :) ومع ذلك ، هناك عقبات أخرى ، لا سيما فيما يتعلق بالوصول في المقام الأول. لا يمكنني الوصول إلى أي من أنظمة Ryzen / Threadripper في الوقت الحالي. إذا / عندما أحصل على حق الوصول ، سأكون سعيدًا بتكرار التجارب ونشر النتائج وفقًا لذلك.

يشير جيف إلى بعض عيوب التسمية التي نواجهها. بشكل عام ، نقوم بتسمية التكوينات الفرعية ومجموعات النواة الخاصة بنا من حيث الهندسة المعمارية الدقيقة ، ولكن هناك المزيد من الفروق الدقيقة حتى الآن. على سبيل المثال ، نستخدم التكوين الفرعي haswell بنا في Haswell و Broadwell و Skylake و Kaby Lake و Coffee Lake. هذا لأنهم جميعًا يتشاركون أساسًا في نفس المتجه ISA ، وهو إلى حد كبير كل ما يهم رمز نواة BLIS. ولكن هذا هو أحد تفاصيل التنفيذ التي لا يحتاج المستخدمون تقريبًا إلى الاهتمام بها. إذا كنت تستخدم ./configure auto ، فستحصل دائمًا تقريبًا على أفضل تكوين فرعي ومجموعة kernel لنظامك ، سواء تم تسميتها zen أو haswell أو أيًا كان. في الوقت الحالي ، ما زلت بحاجة إلى اتباع نهج عملي أكثر عندما يتعلق الأمر باختيار مخطط الترابط على النحو الأمثل ، وهنا يأتي دور تكامل SoC / النظام الأساسي الذي يذكره Jeff.

jeffhammond شكرا على اقتراحك. لقد فكرت في إضافة تلك الأسماء المستعارة في الماضي. ومع ذلك ، لست مقتنعًا بأن الأمر يستحق ذلك. سيضيف فوضى كبيرة إلى سجل التكوين ، ومن المحتمل أن يعرف الأشخاص الذين سيبحثون فيه في المقام الأول بالفعل نظام التسمية الخاص بنا للتكوينات الفرعية ومجموعات النواة ، وبالتالي لن يتم الخلط بينه وبين عدم وجود مراجعة معمارية دقيقة معينة أسماء في هذا الملف (أو في الدليل config ). الآن ، إذا تطلب BLIS تحديدًا يدويًا للتكوين الفرعي ، عبر ./configure haswell على سبيل المثال ، إذن أعتقد أن المقاييس تميل بالتأكيد لصالح اقتراحك. لكن ./configure auto يعمل بشكل جيد ، لذلك لا أرى الحاجة في هذا الوقت. (إذا أردت ، يمكنك فتح قضية حول هذا الموضوع حتى نتمكن من بدء مناقشة أوسع بين أعضاء المجتمع. أنا دائمًا منفتح على تغيير رأيي إذا كان هناك طلب كافٍ.)

نعم ، التسمية معقدة دائمًا :) شكرًا للإجابات fgvanzee و jeffhammond

# 13132 و # 13158 مرتبطان

النقاش أخذ قليلاً. ما هي المشكلات المتبقية التي يجب حلها لدعم BLIS رسميًا في numpy؟

بسذاجة ، حاولت إجراء اختبارات غير معقدة مع BLIS من conda-Forge (راجع https://github.com/numpy/numpy/issues/14180#issuecomment-525292558) وبالنسبة لي ، على Linux ، نجحت جميع الاختبارات (ولكن ربما أنا فقدت شيئا ما).

حاول أيضًا تشغيل مجموعة اختبار scipy التجريبية في نفس البيئة وهناك عدد من الإخفاقات في scipy.linalg (راجع https://github.com/scipy/scipy/issues/10744) في حالة تعليق شخص ما على ذلك.

لاحظ أن BLIS من conda-forge تستخدم ReferenceLAPACK (netlib) كتطبيق LAPACK الذي يستخدم BLIS كتطبيق BLAS وليس libflame .

حول خيار BLIS في conda-forge ، هل أنا محق في أنه خيط واحد خارج الصندوق (على عكس خيار OpenBLAS)؟

ربما من الأفضل نقل مناقشات Conda-Forge إلى conda-forge