Lapack: متطلبات المعالج لـ LAPACK

التدفق السفلي في حد ذاته ليس هو المشكلة الحقيقية. بعد التدفق السفلي ، تتحول الخوارزمية إلى CABS1 ، وهي أقل عرضة للتدفق. المشكلة التي تخلق هي أن TEMP لن تكون وحدوية تمامًا ، مما يؤدي إلى تقريب في Z.

الحل المحتمل هو التدرج المسبق باستخدام CABS1 ثم التصحيح باستخدام ABS (بسبب القياس الأول ، يجب ألا يفيض نظام ABS بعد الآن). (لا أحصل على التدفق السفلي على جهازي ، لذلك لا يمكنني اختباره لك)

IF (RTEMP .EQ. RZERO) THEN
    RTEMP = CABS1(TEMP)
    H( I, I-1 ) = RTEMP
    TEMP = TEMP / RTEMP
    RTEMP = ABS( TEMP)
    H( I, I-1 ) = H( I, I-1 )*RTEMP
    TEMP = TEMP / RTEMP
END IF

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

شكرا لك! هذا مفيد جدا.
لقد حاولنا التعافي من التدفق السفلي باستخدام CABS1. لكن محاولتنا لم تكن كافية. يبدو أن اقتراحك يعمل بشكل أفضل. استخدام ...

*
*        Ensure that H(I,I-1) is real.
*
         TEMP = H( I, I-1 )
         IF( DIMAG( TEMP ).NE.RZERO ) THEN
            RTEMP = ABS( TEMP)
            IF (RTEMP .EQ. RZERO) THEN 
                RTEMP = CABS1(TEMP)
                H( I, I-1 ) = RTEMP
                TEMP = TEMP / RTEMP
                RTEMP = ABS( TEMP)
                H( I, I-1 ) = H( I, I-1 )*RTEMP
            ELSE 
                H( I, I-1 ) = RTEMP
            END IF
            TEMP = TEMP / RTEMP
            IF( I2.GT.I )
     $         CALL ZSCAL( I2-I, DCONJG( TEMP ), H( I, I+1 ), LDH )
            CALL ZSCAL( I-I1, TEMP, H( I1, I ), 1 )
            IF( WANTZ ) THEN
               CALL ZSCAL( NZ, TEMP, Z( ILOZ, I ), 1 )
            END IF
         END IF
*
  130 CONTINUE

... اكتمل هذا التكرار بنجاح (حتى عند استخدام سجلات SSE لـ ABS ()).

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

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

شكرا على التحسين hokb و @ thijssteel! هل يجب أن أكتب إعلانًا عامًا مع التعديلات أم أنك على استعداد للقيام بذلك ،hokb؟

نظرًا لتجربتي المحدودة في المشروع ، سأكون ممتنًا لجهودك وفرصة اتخاذ العلاقات العامة الخاصة بك كمبدأ توجيهي. العلاقات العامة المستقبلية منا ... (إذا كان هذا جيدًا؟)

مرحبا hokb ،

لقد بحثت عن بعض المواصفات ولكن لم أجدها بعد. سيكون موضع تقدير أيضا أي ارتباط. شكرا لك مقدما!

لست متأكدًا من تحديد أي شيء في أي مكان.

يستهدف المترجم الخاص بنا .NET CLR. يقرر JIT الخاص به استخدام سجلات SSE لـ ABS (TEMP) ، مما يؤدي إلى التدفق السفلي في الحساب الوسيط للحجم. يستخدم Ifort (كمثال آخر) سجلات الفاصلة العائمة في هذه الحالة ، وبالتالي لا يتدفق (بسبب طوله الأكبر: 80 بت). أحاول الحصول على صورة واضحة (er) لما يمكن توقعه من LAPACK فيما يتعلق بنطاق الدقة / الرقم الذي يتطلبه من المترجم / المعالج في وقت التشغيل.

بيان جريء: إذا تم إجراء جميع العمليات الحسابية باستخدام حساب IEEE 64 بت ، فيجب أن يعمل LAPACK.

لا يتوقع LAPACK أن يأتي تسجيل 80 بت للمساعدة في حسابه في أي وقت. تم تصميم الخوارزميات مع مراعاة العمليات الحسابية 64 بت. الآن ، كما ذكر thijssteel ، يتم اختبار LAPACK باستخدام

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

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

تقديري التقريبي هو أن أقل بكثير من 1٪ من الاختبارات تتأثر بهذا أو مشاكل تجاوز مماثلة (عند استخدام المترجم لدينا).

يا بلادي. 1٪؟ هذا رقم كبير مخيف.

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

يمكن أن يساعد جعل الاختبارات أكثر قوة ضد التدفق الزائد / الناقص في جلب LAPACK إلى المزيد من الأنظمة الأساسية.

إمكانية النقل إلى المزيد من المنصات هي أحد الاهتمامات بالفعل. هناك فائدة أخرى تتمثل في الدقة الموسعة مع حزمة مثل GMP حيث ، كما أفهم ، يتم إصلاح الدقة في جميع أنحاء الحساب. (على سبيل المثال ، تفكر في 256 بت ، ولا يوجد سجل 300 بت ليساعدك.)

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

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

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

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

ربما ، بالنسبة إلى gfortran ، يجب علينا تجميع الأعلام -mfpmath=sse -msse2 لغرض الاختبار. أعتقد أن هذا سيجبر كل العمليات الحسابية على أن تتم بحساب 64 بت. أنا لست متأكدا بالرغم من ذلك.

نظرًا لتجربتي المحدودة في المشروع ، سأكون ممتنًا لجهودك وفرصة اتخاذ العلاقات العامة الخاصة بك كمبدأ توجيهي. العلاقات العامة المستقبلية منا ... (إذا كان هذا جيدًا؟)

بالتأكيد! من فضلك انظر # 577.

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

مرحبا langou !

بيان جريء: إذا تم إجراء جميع العمليات الحسابية باستخدام حساب IEEE 64 بت ، فيجب أن يعمل LAPACK.

لطيف - جيد! أفترض أننا نعني بكلمة "عمل": عند تغذيتها بالبيانات "في نطاق معين" ، فلن يتم تجاوزها نظرًا لحجم تسجيل معين؟

لا يتوقع LAPACK أن يأتي تسجيل 80 بت للمساعدة في حسابه في أي وقت. تم تصميم الخوارزميات مع مراعاة العمليات الحسابية 64 بت. الآن ، كما ذكر thijssteel ، يتم اختبار LAPACK باستخدام

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

تبدو معقولة جدا!

تقديري التقريبي هو أن أقل بكثير من 1٪ من الاختبارات تتأثر بهذا أو مشاكل تجاوز مماثلة (عند استخدام المترجم لدينا).

يا بلادي. 1٪؟ هذا رقم كبير مخيف.

حسنًا ، من المحتمل أنه "أقل بكثير" من ذلك ؛)

إمكانية النقل إلى المزيد من المنصات هي أحد الاهتمامات بالفعل. هناك فائدة أخرى تتمثل في الدقة الموسعة مع حزمة مثل GMP حيث ، كما أفهم ، يتم إصلاح الدقة في جميع أنحاء الحساب. (على سبيل المثال ، تفكر في 256 بت ، ولا يوجد سجل 300 بت ليساعدك.)

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

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

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

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

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

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

نفس الشيء هنا! :)

إحدى نتائج # 577 هي أن LAPACK يعتمد على مترجم FORTRAN لتنفيذ تقسيم معقد قوي (تحت / تجاوز) و ABS (). أتساءل عما إذا كان يجب أن نبدأ في الاحتفاظ بوثيقة ما ، وجمع مثل هذه المتطلبات وما شابهها؟ ستكون مهمة ومفيدة بنفس القدر لأي شخص يرغب في استخدام LAPACK مع مترجمين آخرين / جدد ، لمنشئي المترجمين ومن أجل نقل أجزاء أو كل خوارزميات LAPACK إلى لغات أخرى؟

بالتأكيد! سيكون من الجيد أن تكون هذه المعلومات موثقة جيدًا.

بادئ ذي بدء ، قضيت بعض الوقت في تتبع (ربما) جميع الأقسام في الملفات LAPACK/SRC/z*.f (COMPLEX * 16 خوارزميات) للنموذج

 REAL / COMPLEX   or   COMPLEX / COMPLEX

لقد وجدت إجمالي 53 ملفًا. انظر الملف المرفق: complexDivisionFound.code-search

• لذلك ، استخدمت تعبير REGEX في رمز Visual Studio Code:

  \ n. * / ^ 0-9 (؟! DBLE) (؟! REAL) (؟! MIN) (؟! MAX) [^ 0-9]

ربما ، بالنسبة إلى gfortran ، يجب علينا تجميع الأعلام -mfpmath=sse -msse2 لغرض الاختبار. أعتقد أن هذا سيجبر كل العمليات الحسابية على أن تتم بحساب 64 بت. أنا لست متأكدا بالرغم من ذلك.

نعم ، يجب أن يتم ذلك عند استخدام GCC ولكن يجب أيضًا تعيين هذه العلامة بشكل افتراضي على x86-64. مقتطفات التوثيق أدناه خاصة بـ GCC 11 ولكن يجب أن تظهر الإصدارات الأقدم من دول مجلس التعاون الخليجي نفس السلوك. استخدام مجموعة مترجم جنو (GCC): 3.19.59 x86 Options

sse

استخدم تعليمات الفاصلة العائمة العددية الموجودة في مجموعة تعليمات SSE. يتم دعم مجموعة التعليمات هذه بواسطة Pentium III والرقائق الأحدث ، وفي خط AMD بواسطة رقائق Athlon-4 و Athlon XP و Athlon MP. يدعم الإصدار السابق من مجموعة تعليمات SSE العمليات الحسابية ذات الدقة الواحدة فقط ، وبالتالي لا يزال يتم إجراء العمليات الحسابية ذات الدقة المزدوجة والممتدة باستخدام 387. إصدار لاحق ، موجود فقط في رقائق Pentium 4 و AMD x86-64 ، يدعم الحساب مزدوج الدقة جدا.

بالنسبة لمترجم x86-32 ، يجب عليك استخدام مفاتيح التبديل -march=cpu-type أو -msse أو -msse2 لتمكين امتدادات SSE وجعل هذا الخيار فعالاً. بالنسبة للمجمع x86-64 ، يتم تمكين هذه الامتدادات افتراضيًا.

يجب أن يكون الكود الناتج أسرع بشكل كبير في معظم الحالات وأن يتجنب مشاكل عدم الاستقرار العددي في كود 387 ، ولكن قد يكسر بعض الكود الحالي الذي يتوقع أن تكون الفترات الزمنية 80 بت.

هذا هو الخيار الافتراضي للمترجم x86-64 وأهداف Darwin x86-32 والخيار الافتراضي لأهداف x86-32 مع مجموعة تعليمات SSE2 عند تمكين -ffast-math .

مثال:
XEIGTSTZ <zec.in - فشل بسبب التدفق السفلي في ZLAHQR.
خطوات إعادة الإنتاج: ZGET37 -> knt == 31، ZHSEQR -> ZLAHQR -> في نهاية خطوة QR الثانية (ITS == 2) يتسبب الكود التالي في التدفق (على بعض السجلات ، انظر أدناه)

TEMP = H( I, I-1 )
    IF( DIMAG( TEMP ).NE.RZERO ) THEN
        RTEMP = ABS( TEMP)    ! <-- underflow on TEMP = (~1e-0173, ~1e-0173)
        IF (RTEMP .EQ. RZERO) RTEMP = CABS1(TEMP)
        H( I, I-1 ) = RTEMP
        TEMP = TEMP / RTEMP
        IF( I2.GT.I )

يستهدف المترجم الخاص بنا .NET CLR. يقرر JIT الخاص به استخدام سجلات SSE لـ ABS (TEMP) ، مما يؤدي إلى التدفق السفلي في الحساب الوسيط للحجم. يستخدم Ifort (كمثال آخر) سجلات الفاصلة العائمة في هذه الحالة ، وبالتالي لا يتدفق (بسبب طوله الأكبر: 80 بت). أحاول الحصول على صورة واضحة (er) لما يمكن توقعه من LAPACK فيما يتعلق بنطاق الدقة / الرقم الذي يتطلبه من المترجم / المعالج في وقت التشغيل.

إلى خلاصة:

• لقد قمت بتحويل نصف مليون سطر من Fortran77 إلى C #.
• فشل اختبار الشفرة المنقولة عند استخدام برنامج التحويل البرمجي في الوقت المناسب لـ .NET فقط.
• نجح اختبار كود Vanilla LAPACK عند استخدام مترجم Intel Fortran (ifort).
• يتمثل الاختلاف الملحوظ بين الحالتين في استخدام وسيطة 80 بت بواسطة ifort والتي تتجنب التدفق السفلي.

صيح؟

بشكل افتراضي ، ينشئ GCC رمزًا فقط لسجلات التعويم 64 بت على x86-64 وعلى أجهزتي عادةً ما تجتاز جميع اختبارات LAPACK باستثناء واحد أو اثنين.

هل تجتاز مجموعة اختبار Netlib LAPACK عند التحويل البرمجي مع GCC؟

تحرير: تم الحل https://github.com/Reference-LAPACK/lapack/pull/577#issuecomment -859496175

ربما ، بالنسبة إلى gfortran ، يجب أن نقوم بالتجميع باستخدام الأعلام -mfpmath = sse -msse2 لغرض الاختبار. أعتقد أن هذا سيجبر كل العمليات الحسابية على أن تتم بحساب 64 بت. أنا لست متأكدا بالرغم من ذلك.

لقد جربت -mfpmath=sse -msse2 مع GCC 11 على كل من MacOS و Linux: https://github.com/weslleyspereira/lapack/actions/runs/966071530. لم تكن هناك أخطاء إضافية عند مقارنتها بسير العمل بدون تلك العلامات: https://github.com/Reference-LAPACK/lapack/actions/runs/945060330. انظر # 591

hokb ، هل يمكنك إعادة إنتاج مشكلات الفائض التي ذكرتها في https://github.com/Reference-LAPACK/lapack/issues/575#issuecomment -855880000 مع دول مجلس التعاون الخليجي باستخدام علامات SSE؟ هل يمكنك مساعدتي مع هذا؟

weslleyspereira لم أجرب حتى دول مجلس التعاون الخليجي. كل ما لدي وصول إلى / إعداد قيد التشغيل هو ifort على Windows. سيستغرق الأمر بضعة أيام حتى أقوم بتشغيل مجلس التعاون الخليجي وتشغيله عبر cygwin للاختبار (خاصة من غرفتي الحالية في فندق العطلات ...: |) أخبرني إذا كنت بحاجة إلى خوض هذا التحدي ، رغم ذلك!
على الأقل ووفقًا لـ https://godbolt.org/z/YYv5oPxe9 ، فإن استخدام العلامات لا يؤثر على الكود الذي تم إنشاؤه بواسطة gfortran. ولكن بالطبع لن يخبرنا ذلك بالتأكيد إلا عن طريق الاختبار التجريبي ...

أنا لا أستخدم النوافذ ، لكني أمتلكها هنا. سأبدأ باختبار LAPACK مع ifort على Ubuntu الخاص بي ومعرفة ما سيحدث. استمتع بالعطلة!