Lapack: लैपैक के लिए प्रोसेसर आवश्यकताएँ

अंडरफ्लो ही असली समस्या नहीं है। अंडरफ्लो के बाद, एल्गोरिथम CABS1 पर स्विच हो जाता है, जिसमें अंडरफ्लो होने की संभावना कम होती है। जो समस्या पैदा होती है वह यह है कि टीईएमपी बिल्कुल एकात्मक नहीं होगा, जिससे जेड में राउंडऑफ हो जाएगा।

एक संभावित समाधान 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

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

शुक्रिया! यह बहुत मददगार है।
हमने 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

... यह पुनरावृति सफलतापूर्वक पूर्ण होती है (यहां तक ​​कि एबीएस के लिए एसएसई रजिस्टरों का उपयोग करते समय भी ())।

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

परीक्षण सूट बहुत मददगार है! मेरा अनुमान है कि 1% से भी कम परीक्षण इस या इसी तरह के अतिप्रवाह मुद्दों (हमारे कंपाइलर का उपयोग करते समय) से प्रभावित होते हैं। अंडर-ओवरफ्लो के खिलाफ परीक्षणों को और अधिक मजबूत बनाने से LAPACK को और अधिक प्लेटफॉर्म पर लाने में मदद मिल सकती है। ऊपर दिया गया हमारा (असफल) प्रयास सिर्फ एक उदाहरण है, जो स्पष्ट रूप से दिखाता है कि हम शायद ही अपनी तरफ से सुधार कर पाएंगे। कई संबंधित मुद्दों को खोलने से पहले मैं एक चर्चा शुरू करना चाहता हूं कि इस तरह की यात्रा में रुचि है या नहीं और एक अच्छा तरीका क्या होगा।

@hokb और @thijssteel में सुधार के लिए धन्यवाद! क्या मुझे संशोधनों के साथ एक पीआर लिखना चाहिए या क्या आप ऐसा करने को तैयार हैं, @hokb?

परियोजना के साथ अपने सीमित अनुभव को देखते हुए मैं आपके प्रयास और आपके पीआर को पॉट के लिए दिशानिर्देश के रूप में लेने का मौका की सराहना करता हूं। हमारी ओर से भावी पीआर... (यदि यह ठीक है?)

हाय @ होकब ,

मैंने कुछ विनिर्देश की तलाश की लेकिन अभी तक इसे नहीं मिला। किसी भी लिंक की भी सराहना की जाएगी। अग्रिम में धन्यवाद!

मुझे यकीन नहीं है कि कहीं भी कुछ भी निर्दिष्ट है।

हमारा कंपाइलर .NET CLR को लक्षित करता है। इसका जेआईटी एबीएस (टीईएमपी) के लिए एसएसई रजिस्टरों का उपयोग करने का फैसला करता है, जो परिमाण की मध्यवर्ती गणना में अंडरफ्लो की ओर जाता है। इफोर्ट (एक अन्य उदाहरण के रूप में) इस स्थिति में फ्लोटिंग पॉइंट रजिस्टरों का उपयोग करता है, इसलिए अंडरफ्लो नहीं होता है (इसकी बड़ी लंबाई के कारण: 80 बिट्स)। मैं LAPACK से क्या उम्मीद कर सकता हूं, इसकी एक स्पष्ट (एर) तस्वीर प्राप्त करने की कोशिश कर रहा हूं, जिसके बारे में रनटाइम पर कंपाइलर/प्रोसेसर से सटीक/संख्या सीमा की आवश्यकता होती है।

बोल्ड स्टेटमेंट: यदि सभी गणना IEEE 64-बिट अंकगणित का उपयोग करके की जाती है, तो LAPACK को काम करना चाहिए।

LAPACK किसी भी समय इसकी गणना में मदद करने के लिए 80-बिट रजिस्टर के आने की उम्मीद नहीं करता है। एल्गोरिदम को 64-बिट अंकगणित को ध्यान में रखकर बनाया गया है। अब, जैसा कि @thijssteel द्वारा उल्लेख किया गया है, LAPACK का परीक्षण विभिन्न कंपाइलर्स/आर्किटेक्चर के साथ किया जाता है, और ये कंपाइलर/आर्किटेक्चर कभी-कभी 80-बिट रजिस्टरों का उपयोग करते हैं, और हम सोच सकते हैं कि हमारे एल्गोरिदम को केवल 64-बिट की आवश्यकता है, लेकिन वे नहीं करते हैं, और वास्तव में, उन्हें 80-बिट की आवश्यकता होती है।

हमने इन मुद्दों पर ध्यान देने के लिए अपनी यात्रा में कुछ भी व्यवस्थित नहीं किया है। सामान्य तौर पर, हम काफी खुश होते हैं जब एल्गोरिदम टेस्ट सूट पास करते हैं, और, अगर 80-बिट रजिस्टर से कुछ मदद मिलती है, तो ऐसा ही हो।

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

मेरा अनुमान है कि 1% से भी कम परीक्षण इस या इसी तरह के अतिप्रवाह मुद्दों (हमारे कंपाइलर का उपयोग करते समय) से प्रभावित होते हैं।

अरे मेरा। 1%? यह एक डरावनी बड़ी संख्या है।

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

अंडर-ओवरफ्लो के खिलाफ परीक्षणों को और अधिक मजबूत बनाने से LAPACK को और अधिक प्लेटफॉर्म पर लाने में मदद मिल सकती है।

अधिक प्लेटफार्मों के लिए पोर्टेबिलिटी वास्तव में एक रुचि है। एक और रुचि जीएमपी जैसे पैकेज के साथ विस्तारित सटीकता है, जहां, जैसा कि मैं समझता हूं, सटीकता पूरे गणना में तय की जाती है। (इसलिए उदाहरण के लिए आप 256-बिट विचार हैं, और आपकी सहायता के लिए 300-बिट रजिस्टर नहीं है।)

ऊपर दिया गया हमारा (असफल) प्रयास सिर्फ एक उदाहरण है, जो स्पष्ट रूप से दिखाता है कि हम शायद ही अपनी तरफ से सुधार कर पाएंगे। कई संबंधित मुद्दों को खोलने से पहले मैं एक चर्चा शुरू करना चाहता हूं कि इस तरह की यात्रा में रुचि है या नहीं और एक अच्छा तरीका क्या होगा।

हां। हमे रूचि है। हालांकि हम इतना ही कर सकते हैं। और हमारी प्लेटों पर बहुत कुछ है। तो हो सकता है कि हम इस एक मुद्दे को एक बार में लें, और हम देखें कि हम कितनी दूर जाते हैं।

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

मुझे खुशी है कि हम इस रास्ते से नीचे जा रहे हैं, लेकिन मैं इसे आसान बनाने की सलाह दूंगा।

हो सकता है, gfortran के लिए, हमें परीक्षण उद्देश्य के लिए झंडे -mfpmath=sse -msse2 के साथ संकलित करना चाहिए। मुझे लगता है कि यह सभी गणनाओं को 64-बिट अंकगणित के साथ करने के लिए मजबूर करेगा। हालांकि मुझे यकीन नहीं है।

परियोजना के साथ अपने सीमित अनुभव को देखते हुए मैं आपके प्रयास और आपके पीआर को पॉट के लिए दिशानिर्देश के रूप में लेने का मौका की सराहना करता हूं। हमारी ओर से भावी पीआर... (यदि यह ठीक है?)

ज़रूर! कृपया, #577 देखें।

@weslleyspereira बहुत बढ़िया! मैं अभी भी जाँच कर रहा हूँ, अगर यह CLAHQR पर भी लागू होता है। अपना परिणाम ASAP (कल) पोस्ट करूंगा

नमस्ते @langou !

बोल्ड स्टेटमेंट: यदि सभी गणना IEEE 64-बिट अंकगणित का उपयोग करके की जाती है, तो LAPACK को काम करना चाहिए।

अच्छा! मुझे लगता है, 'काम' से हमारा मतलब है: जब 'एक निश्चित सीमा में' डेटा के साथ खिलाया जाता है तो यह किसी दिए गए रजिस्टर आकार के कारण अतिप्रवाह नहीं होगा?

LAPACK किसी भी समय इसकी गणना में मदद करने के लिए 80-बिट रजिस्टर के आने की उम्मीद नहीं करता है। एल्गोरिदम को 64-बिट अंकगणित को ध्यान में रखकर बनाया गया है। अब, जैसा कि @thijssteel द्वारा उल्लेख किया गया है, LAPACK का परीक्षण विभिन्न कंपाइलर्स/आर्किटेक्चर के साथ किया जाता है, और ये कंपाइलर/आर्किटेक्चर कभी-कभी 80-बिट रजिस्टरों का उपयोग करते हैं, और हम सोच सकते हैं कि हमारे एल्गोरिदम को केवल 64-बिट की आवश्यकता है, लेकिन वे नहीं करते हैं, और वास्तव में, उन्हें 80-बिट की आवश्यकता होती है।

हमने इन मुद्दों पर ध्यान देने के लिए अपनी यात्रा में कुछ भी व्यवस्थित नहीं किया है। सामान्य तौर पर, हम काफी खुश होते हैं जब एल्गोरिदम टेस्ट सूट पास करते हैं, और, अगर 80-बिट रजिस्टर से कुछ मदद मिलती है, तो ऐसा ही हो।

बहुत उचित लगता है!

मेरा अनुमान है कि 1% से भी कम परीक्षण इस या इसी तरह के अतिप्रवाह मुद्दों (हमारे कंपाइलर का उपयोग करते समय) से प्रभावित होते हैं।

अरे मेरा। 1%? यह एक डरावनी बड़ी संख्या है।

खैर, संभावना है कि यह उससे 'बहुत कम' है;)

अधिक प्लेटफार्मों के लिए पोर्टेबिलिटी वास्तव में एक रुचि है। एक और रुचि जीएमपी जैसे पैकेज के साथ विस्तारित सटीकता है, जहां, जैसा कि मैं समझता हूं, सटीकता पूरे गणना में तय की जाती है। (इसलिए उदाहरण के लिए आप 256-बिट विचार हैं, और आपकी सहायता के लिए 300-बिट रजिस्टर नहीं है।)

दिलचस्प लगता है, लेकिन मैं इस पर टिप्पणी नहीं कर सकता, क्योंकि मेरे पास इस तरह के निश्चित सटीक प्रयासों के अनुभव की कमी है।

हां। हमे रूचि है। हालांकि हम इतना ही कर सकते हैं। और हमारी प्लेटों पर बहुत कुछ है। तो हो सकता है कि हम इस एक मुद्दे को एक बार में लें, और हम देखें कि हम कितनी दूर जाते हैं।

मैं अभी भी अनिश्चित हूं कि एक अच्छा सामान्य दृष्टिकोण क्या होगा। मेरे साथ नंगे, अगर मेरी समझ बहुत भोली है। लेकिन इनपुट डेटा और एल्गोरिथम दोनों के आधार पर हमेशा ओवर-/अंडरफ्लो नहीं होता है? तो नए सशर्त परीक्षण के साथ कोड को भरने के बजाय और उनसे पुनर्प्राप्त करने के लिए नए कोड के बजाय हम इनपुट डेटा के लिए 'अनुमत सीमा' को कम कर सकते हैं? हालाँकि, मेरे पास किसी भी दृष्टिकोण के लिए आवश्यक प्रयास में आवश्यक अंतर्दृष्टि नहीं है। इसलिए मैं न्याय नहीं कर सकता कि क्या अधिक व्यवहार्य होगा।

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

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

मुझे खुशी है कि हम इस रास्ते से नीचे जा रहे हैं, लेकिन मैं इसे आसान बनाने की सलाह दूंगा।

इधर भी ऐसा ही है! :)

#577 का एक परिणाम यह है कि LAPACK यथोचित रूप से मजबूत (अंडर- / ओवरफ्लो) जटिल विभाजन और ABS () को लागू करने के लिए फोरट्रान कंपाइलर पर निर्भर करता है। मुझे आश्चर्य है कि क्या हमें इस तरह की और इसी तरह की आवश्यकताओं को इकट्ठा करने के लिए एक दस्तावेज बनाए रखना शुरू कर देना चाहिए? वे अन्य / नए कंपाइलरों के साथ LAPACK का उपयोग करने के इच्छुक लोगों के लिए समान रूप से महत्वपूर्ण और उपयोगी होंगे, कंपाइलर बिल्डरों के लिए और भागों या सभी LAPACK एल्गोरिदम को अन्य भाषाओं में स्थानांतरित करने के लिए?

ज़रूर! इस जानकारी को अच्छी तरह से प्रलेखित करना अच्छा होगा।

शुरू करने के लिए, मैंने फॉर्म के LAPACK/SRC/z*.f (COMPLEX*16 एल्गोरिदम) फाइलों में सभी डिवीजनों को ट्रैक करने (शायद) में कुछ समय बिताया

 REAL / COMPLEX   or   COMPLEX / COMPLEX

मुझे कुल 53 फाइलें मिलीं। संलग्न फ़ाइल देखें: complexDivisionFound.code-search

• उसके लिए, मैंने विजुअल स्टूडियो कोड में REGEX एक्सप्रेशन का उपयोग किया:

  \n .*/ ^0-9 (?!DBLE)(?!असली)(?!मिन)(?!MAX)[^0-9]

हो सकता है, gfortran के लिए, हमें परीक्षण उद्देश्य के लिए झंडे -mfpmath=sse -msse2 के साथ संकलित करना चाहिए। मुझे लगता है कि यह सभी गणनाओं को 64-बिट अंकगणित के साथ करने के लिए मजबूर करेगा। हालांकि मुझे यकीन नहीं है।

हाँ, यह GCC का उपयोग करते समय होना चाहिए लेकिन यह ध्वज भी डिफ़ॉल्ट रूप से x86-64 पर सेट होना चाहिए। नीचे दिया गया दस्तावेज़ीकरण अंश GCC 11 के लिए है, लेकिन बहुत पुराने GCC संस्करणों में समान व्यवहार प्रदर्शित होना चाहिए। जीएनयू कंपाइलर संग्रह (जीसीसी) का उपयोग करना: 3.19.59 x86 विकल्प

sse

SSE निर्देश सेट में मौजूद अदिश फ़्लोटिंग-पॉइंट निर्देशों का उपयोग करें। यह निर्देश सेट पेंटियम III और नए चिप्स द्वारा समर्थित है, और एएमडी लाइन में एथलॉन -4, एथलॉन एक्सपी और एथलॉन एमपी चिप्स द्वारा समर्थित है। एसएसई निर्देश सेट का पुराना संस्करण केवल एकल-सटीक अंकगणित का समर्थन करता है, इस प्रकार डबल और विस्तारित-सटीक अंकगणित अभी भी 387 का उपयोग करके किया जाता है। बाद का संस्करण, केवल पेंटियम 4 और एएमडी x86-64 चिप्स में मौजूद है, डबल-सटीक अंकगणित का समर्थन करता है बहुत।

x86-32 कंपाइलर के लिए, आपको SSE एक्सटेंशन को सक्षम करने और इस विकल्प को प्रभावी बनाने के लिए -march=cpu-type , -msse या -msse2 स्विच का उपयोग करना चाहिए। x86-64 कंपाइलर के लिए, ये एक्सटेंशन डिफ़ॉल्ट रूप से सक्षम होते हैं।

परिणामी कोड अधिकांश मामलों में काफी तेज होना चाहिए और 387 कोड की संख्यात्मक अस्थिरता की समस्याओं से बचना चाहिए, लेकिन कुछ मौजूदा कोड को तोड़ सकता है जो अस्थायी रूप से 80 बिट होने की अपेक्षा करता है।

यह x86-64 कंपाइलर, डार्विन x86-32 लक्ष्य, और -ffast-math सक्षम होने पर SSE2 निर्देश सेट के साथ x86-32 लक्ष्यों के लिए डिफ़ॉल्ट विकल्प है।

उदाहरण:
XEIGTSTZ < zec.in - ZLAHQR में कम प्रवाह के कारण विफल रहता है।
पुन: पेश करने के लिए कदम: ZGET37 -> knt == 31, ZHSEQR -> ZLAHQR -> दूसरे क्यूआर चरण के अंत में (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 को लक्षित करता है। इसका जेआईटी एबीएस (टीईएमपी) के लिए एसएसई रजिस्टरों का उपयोग करने का फैसला करता है, जो परिमाण की मध्यवर्ती गणना में अंडरफ्लो की ओर जाता है। इफोर्ट (एक अन्य उदाहरण के रूप में) इस स्थिति में फ्लोटिंग पॉइंट रजिस्टरों का उपयोग करता है, इसलिए अंडरफ्लो नहीं होता है (इसकी बड़ी लंबाई के कारण: 80 बिट्स)। मैं LAPACK से क्या उम्मीद कर सकता हूं, इसकी एक स्पष्ट (एर) तस्वीर प्राप्त करने की कोशिश कर रहा हूं, जिसके बारे में रनटाइम पर कंपाइलर/प्रोसेसर से सटीक/संख्या सीमा की आवश्यकता होती है।

संक्षेप में दुहराना:

• आपने फोरट्रान 77 की आधा मिलियन लाइनों को सी # में स्थानांतरित कर दिया है।
• .NET जस्ट-इन-टाइम कंपाइलर का उपयोग करते समय पारदर्शी कोड का परीक्षण विफल हो जाता है।
• इंटेल फोरट्रान कंपाइलर (आईफोर्ट) का उपयोग करते समय वेनिला लैपैक कोड का परीक्षण सफल होता है।
• दो मामलों के बीच देखा गया अंतर आईफोर्ट द्वारा 80-बिट इंटरमीडिएट का उपयोग है जो एक अंडरफ्लो से बचा जाता है।

सही?

डिफ़ॉल्ट रूप से जीसीसी x86-64 पर 64-बिट फ्लोट रजिस्टरों के लिए केवल कोड उत्पन्न करता है और मेरी मशीनों पर आमतौर पर सभी LAPACK परीक्षण एक या दो को छोड़कर पास होते हैं।

क्या जीसीसी के साथ संकलन करते समय नेटलिब लैपैक टेस्ट सूट पास होता है?

संपादित करें: हल किया गया https://github.com/Reference-LAPACK/lapack/pull/577#issuecomment -859496175

हो सकता है, gfortran के लिए, हमें परीक्षण उद्देश्य के लिए झंडे -mfpmath=sse -msse2 के साथ संकलित करना चाहिए। मुझे लगता है कि यह सभी गणनाओं को 64-बिट अंकगणित के साथ करने के लिए मजबूर करेगा। हालांकि मुझे यकीन नहीं है।

मैंने मैकोज़ और लिनक्स दोनों पर जीसीसी 11 के साथ -mfpmath=sse -msse2 की कोशिश की: 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 झंडे का उपयोग करके GCC के साथ पुन: पेश कर सकते हैं? क्या उसके लिए आपके द्वारा मेरी मदद की जाएगी?

@weslleyspereira मैंने जीसीसी की कोशिश भी नहीं की है। विंडोज़ पर आईफोर्ट के लिए मेरे पास केवल/एक रनिंग सेटअप तक पहुंच है। मुझे जीसीसी को स्थापित करने और साइबरविन के माध्यम से परीक्षण करने में कुछ दिन लगेंगे (विशेषकर मेरे वर्तमान हॉलिडे होटल के कमरे से ...:|) मुझे बताएं कि क्या आपको यह चुनौती लेने के लिए मेरी आवश्यकता है, हालांकि!
कम से कम और https://godbolt.org/z/YYv5oPxe9 के अनुसार झंडे का उपयोग करने से gfortran द्वारा उत्पन्न कोड प्रभावित नहीं होता है। लेकिन निश्चित रूप से केवल एक टेस्ट रन ही निश्चित रूप से बताएगा ...

मैं विंडोज़ का उपयोग नहीं करता, लेकिन मेरे पास यह यहाँ है। मैं अपने उबंटू पर आईफोर्ट के साथ लैपैक का परीक्षण करके शुरू करूंगा और देखें कि क्या होता है। छुट्टी का आनंद लें!