Lapack: मानक अनुक्रमणिका-32 पुस्तकालय के साथ-साथ अनुक्रमणिका-64 पुस्तकालय की संभावित स्थापना की अनुमति दें?

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

सबसे निश्चित रूप से, यह एक अच्छी योजना की तरह लगता है।

ओएमजी @langou
तुम बहुत तेज हो: दिल:

केवल पूर्णता के लिए, मैं वे चीज़ें लिख रहा हूँ जो हमें अभी भी करनी हैं:

• पता लगाएँ कि हेडर का नाम कैसे दिया जाए ताकि 32 बिट एपीआई 64 बिट एपीआई के साथ सह-अस्तित्व में हो सके
• Printf/fprintf स्टेटमेंट्स को ठीक करें ताकि वे प्रिंटिंग के लिए सही क्वालिफायर का उपयोग करें।

पहले बिंदु को हल करने के लिए किसी भी सुझाव का स्वागत है, दुर्भाग्य से मेरे पास "साफ" समाधान नहीं है।

कुछ प्रश्न, जो मुझे फाइलों के नामकरण को संभालने में मदद करेंगे

• ऐसा लगता है कि cblas_f77.h और cblas_test.h बीच एक टन डुप्लिकेट परिभाषाएं हैं। क्या हमें वाकई इसकी ज़रूरत है?
• क्या cblas_test.h को स्थापित करने की आवश्यकता है? इसका नाम (और जिन फ़ाइलों में इसका उपयोग किया जाता है) को देखते हुए, मैं इसे केवल परीक्षण चरण के दौरान उपयोग करने के लिए मानता हूं। शायद हमें इस फाइल को सिस्टम-वाइड स्तर पर स्थापित नहीं करना चाहिए?

हाय @ एप्सिलॉन-0,

कुछ चीजें जो मानक स्थापना के साथ सह-अस्तित्व की अनुमति देने के लिए मेरे मन में थीं - पुस्तकालयों का नाम libblas64.so, libcblas64.so, liblapack64.so, liblapacke64.so, इस तरह पुस्तकालय नामों के बीच कोई संघर्ष नहीं है ( हालांकि निश्चित रूप से, आप एक ही समय में libblas और libblas64 दोनों से लिंक नहीं कर सकते हैं)।

आप पीआर #218 की तलाश में हो सकते हैं। इस पीआर के लेखक फेडोरा प्रोजेक्ट से ब्योर्न एस्सेर हैं।

हाय @ एप्सिलॉन -0। क्या #462 ने इस समस्या का समाधान किया?

@weslleyspereira नहीं, यह अभी पूरा नहीं हुआ है।
कुछ और हेडर का नाम बदलने/हैंडलिंग करने की जरूरत है।
मैं अगले कुछ हफ़्तों के लिए व्यस्त हूं इसलिए जल्द ही ऐसा नहीं कर पाऊंगा।
मूल रूपरेखा

• शीर्षलेख फ़ाइलों को cblas.h और cblas64.h कहा जाना चाहिए, इसी तरह अन्य शीर्षलेखों के लिए
  
  
  
  • इसका मतलब है कि उचित हेडर को शामिल करने के लिए *.c फाइलों को कुछ मामूली समायोजन की आवश्यकता होगी, लेकिन यह केवल निर्माण समय के दौरान है, इसलिए इसे हैक किया जा सकता है।
  
  
• cmake फ़ाइलें lapack64 या cblas64 आदि के तहत स्थापित की जानी चाहिए।

ठीक है मैं समझा। त्वरित अनुवर्ती के लिए धन्यवाद!

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

/usr/lib/libopenblas.so
/usr/lib/libopenblas64.so
/usr/lib/libblas.so
/usr/lib/libcblas.so
/usr/lib/libblas64.so
/usr/lib/libcblas64.so
/usr/include/openblas/cblas.h
/usr/include/openblas64/cblas.h
/usr/include/netlib/cblas.h
/usr/include/netlib64/cblas.h
/usr/include/cblas.h -> netlib/cblas.h (for compatibility, having the default)

(इत्यादि)

हम बाइनरी डिस्ट्रोस की तरह रनटाइम स्विचिंग पर विचार नहीं करते हैं, इसलिए यह ठीक है यदि प्रत्येक cblas.h (और lapacke.h) इसकी मिलान वाली लाइब्रेरी के लिए विशिष्ट है, जैसे कि libopenblas के लिए अतिरिक्त नाम। बिल्ड-टाइम चयन के माध्यम से होता है

BLAS_INCLUDES=-I/prefix/include/netlib64
BLAS_LIBS=-lblas64
CBLAS_LIBS=-lcblas64

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

हालांकि, मुझे उन शीर्षकों के बारे में एक प्रश्न मिला।

मैं प्रत्येक घटक को अलग से बनाने के लिए सेमेक बिल्ड को हैक कर रहा हूं, और कुछ अन्य फिक्सअप की कोशिश कर रहा हूं (देखें https://github.com/Reference-LAPACK/lapack/pull/556)। मुझे libblas.so और libblas64.so लाइब्रेरी ठीक बनी हैं, मुझे हेडर डीआईआर कॉन्फ़िगर किए गए हैं ... लेकिन स्थापित cblas.h और lapacke.h 32 और 64 बिट इंडेक्सिंग संस्करणों के लिए समान हैं। यह ओपनब्लास के साथ बाधाओं पर है: वहां, मुझे एक महत्वपूर्ण अंतर मिला है जो मुझे नेटलिब बिल्ड के लिए नहीं दिखता है:

diff -ruN /data/pkg/include/openblas/openblas_config.h /data/pkg/include/openblas64/openblas_config.h
--- /data/pkg/include/openblas/openblas_config.h    2021-06-03 19:03:53.000000000 +0200
+++ /data/pkg/include/openblas64/openblas_config.h  2021-06-03 19:13:36.000000000 +0200
@@ -44,6 +44,7 @@
 #define OPENBLAS_DLOCAL_BUFFER_SIZE 32768
 #define OPENBLAS_CLOCAL_BUFFER_SIZE 16384
 #define OPENBLAS_ZLOCAL_BUFFER_SIZE 12288
+#define OPENBLAS_USE64BITINT 
 #define OPENBLAS_GEMM_MULTITHREAD_THRESHOLD 4
 #define OPENBLAS_VERSION " OpenBLAS 0.3.15 "
 /*This is only for "make install" target.*/

संदर्भ पुस्तकालयों के लिए, 32 और 64 बिट इंडेक्स बिल्ड के सभी शीर्षलेख समान हैं और स्पष्ट रूप से उपयोगकर्ताओं से अपेक्षा की जाती है
cblas.h और -DLAPACK_ILP64 -DHAVE_LAPACK_CONFIG_H लिए -DWeirdNEC उनके झंडे में (30 साल पहले मजाकिया हो सकता है)। चूंकि लोग उत्पादन में अनुकूलित बीएलएएस पुस्तकालयों का उपयोग करते हैं, वास्तविक मानक इसे उपयोगकर्ताओं के सामने प्रकट नहीं करना है। ये संदर्भ पर वापस फ़ीड करते हैं, IMHO, और ILP64 बिल्ड से इंस्टॉल किए गए हेडर को 64 बिट लिब से लिंक करते समय आपके ऐप को क्रैश होने से बचाने के लिए फंकी फ़्लैग की आवश्यकता नहीं होनी चाहिए।

क्या हम इस बात से सहमत हैं कि सही पूर्णांकों को परिभाषित करने के लिए निर्माण समय पर हेडर को संशोधित करना सही समाधान है?

बीटीडब्ल्यू, स्थापित cblas कॉन्फ़िगरेशन फ़ाइलें भी आवश्यक defs के किसी भी संदर्भ को याद करती हैं, इसलिए ऐसा लगता है कि 64 बिट इंडेक्स बिल्ड के लिए टूटा हुआ है। लेकिन वास्तव में, मैं इन्हें बिल्कुल भी स्थापित नहीं करने पर विचार करता हूं। वे .pc फ़ाइलों के साथ बेमानी हैं और BLAS_LIBS etal के माध्यम से पैकेजर विकल्प को स्वीकार करने के लिए cmake-निर्भर पैकेजों का उपयोग करना संभवतः कठिन बनाते हैं।

पीएस: इंटेल एमकेएल के साथ, एक केंद्रीय स्विच -DMKL_ILP64 सेट किया जाना है। मैं तुच्छ स्थापित करने की कल्पना करता हूं
include/intel-mkl64/cblas.h साथ

#ifndef MKL_ILP64
#define MKL_ILP64
#endif
#include <mkl_cblas.h>

सामान्य योजना में फिट होने के लिए। मैं परिभाषित को BLAS_INCLUDES में भी डाल सकता हूं, वही अजीब नेटलिब परिभाषित करता है। क्या बेहतर है? क्या हम इसे Intel या OpenBLAS की तरह करना चाहते हैं?

क्या हम इस बात से सहमत हैं कि सही पूर्णांकों को परिभाषित करने के लिए निर्माण समय पर हेडर को संशोधित करना सही समाधान है?

हां। मैं इससे सहमत हूं, और उस समाधान को प्राथमिकता देता हूं जो पूरे शीर्षलेख को दोहराता नहीं है। मुझे लगता है कि यह क्लीनर है।

बीटीडब्ल्यू, स्थापित cblas कॉन्फ़िगरेशन फ़ाइलें भी आवश्यक defs के किसी भी संदर्भ को याद करती हैं, इसलिए ऐसा लगता है कि 64 बिट इंडेक्स बिल्ड के लिए टूटा हुआ है।

सही। मैंने अभी-अभी 64-बिट लाइब्रेरी (BUILD_INDEX64=ON) स्थापित की है और मुझे WeirdNEC , LAPACK_ILP64 या HAVE_LAPACK_CONFIG_H का उपयोग करने के लिए कहने वाला कुछ भी नहीं देख सका। उस पर ध्यान देने के लिए धन्यवाद!

हां। मैं इससे सहमत हूं, और उस समाधान को प्राथमिकता देता हूं जो पूरे शीर्षलेख को दोहराता नहीं है। मुझे लगता है कि यह क्लीनर है।

यह मेरे लिए अस्पष्ट है। क्लीनर समाधान कौन सा है? मैं अभी जो तैयारी कर रहा हूं वह इस प्रकार है:

#if defined(WeirdNEC) || @HAVE_ILP64@
   #define CBLAS_INDEX long
   #ifndef WeirdNEC
   #define WeirdNEC
   #endif
#else
   #define CBLAS_INDEX int
#endif

CMakeFile HAVE_ILP को 1 या 0 से बदल देगा, परिणामी हेडर वर्तमान बिल्ड के लिए स्थापित किया जा रहा है।

(बीटीडब्ल्यू: विंडोज़ पर लंबे समय तक काम नहीं करेगा। यह वहां लंबा लंबा है … या int64_t stdint के साथ सभी प्लेटफॉर्म पर।)

सही। मैंने अभी-अभी 64-बिट लाइब्रेरी (BUILD_INDEX64=ON) स्थापित की है और मुझे WeirdNEC , LAPACK_ILP64 या HAVE_LAPACK_CONFIG_H का उपयोग करने के लिए कहने वाला कुछ भी नहीं देख सका। उस पर ध्यान देने के लिए धन्यवाद!

मैं एक ऐसे भविष्य की कल्पना कर रहा हूँ जहाँ आप करते हैं

cc -I/foo/include/netlib64 -o bar bar.c -L/foo/lib -lcblas64

और चीजों को foo/include/netlib64/cblas.h में नियंत्रित किया जाता है, अन्यथा foo/include/netlib/cblas.h द्वारा (संभवतः foo/include/cblas.h से जुड़ा हुआ)।

मुझे संदेह है कि यह आपका मतलब _not_ है, लेकिन मैं यह विश्वास दिलाना चाहता हूं कि यह बेहतर है ;-)

आप 'द' हेडर को /foo/include/cblas.h में रखकर हेडर को डुप्लिकेट न करने का प्रयास कर सकते हैं और इसमें /foo/include/netlib64/cblas.h शामिल है, केवल WeirdNEC को परिभाषित करके, लेकिन इसका मतलब है कि 64 बिट और 32 बिट पैकेज उस सामान्य हेडर फ़ाइल को साझा करते हैं, जो पैकेजिंग के लिए गन्दा है। यह बेहतर है यदि प्रत्येक अपनी फ़ाइल को अलग-अलग स्थानों/नामों में रखता है। नाम को cblas.h रहने की आवश्यकता है क्योंकि आप #include <cblas.h> लाइनों को बदलने के लिए इधर-उधर नहीं जाना चाहते हैं।

संपादित करें: इसके अलावा, cblas.h शामिल ../cblas.h अपने आप में गड़बड़ है। साथ ही हम cmake के लिए _one_ हेडर इंस्टॉलेशन डायरेक्टरी को परिभाषित करते हैं। डिफ़ॉल्ट रूप से यह /foo/include है, न कि /foo/netlib64/include। मैं इस डिफ़ॉल्ट को नहीं बदलने जा रहा हूं। पैकेजर्स को इस तरह उपनिर्देशिका निर्दिष्ट करनी होगी (बीएसडी मेक इन पीकेजीएसआरसी):

.if !empty(LAPACK_COMPONENT:M*64)
.  if empty(MACHINE_ARCH:M*64)
PKG_FAIL_REASON+=       "${LAPACK_COMPONENT} incompatible with non-64-bit platform"
.  endif
HEADERDIR=netlib64
.else
HEADERDIR=netlib
.endif

# Note: We patch the build to install both static and
# shared libraries.
CMAKE_ARGS=     -DBUILD_DEPRECATED=ON \
                -DBUILD_SHARED_LIBS=ON \
                -DBUILD_STATIC_LIBS=ON \
                -DCMAKE_INSTALL_INCLUDEDIR=${PREFIX}/include/${HEADERDIR} \
                ${LAPACK_COMPONENT_CMAKE_ARGS}

सामान्य स्थान पर इस संशोधन के साथ 32 बिट cblas.h को शिपिंग/इंस्टॉल करने का एक सुंदर पहलू यह है कि मूल यांत्रिकी अभी भी काम करती है। केवल 64 बिट संस्करण ही WeirdNEC को लागू करेगा। आप केवल 64 बिट एक को उपसर्ग में स्थापित करने और पारिस्थितिकी तंत्र के अन्य हिस्सों को अछूता रखने का निर्णय ले सकते हैं।

ओह, चलो... CBLAS/cmake/cblas-config-install.cmake.in भूल गया लगता है -DCMAKE_INSTALL_INCLUDEDIR, है न?

# Report lapacke header search locations.
set(CBLAS_INCLUDE_DIRS ${_CBLAS_PREFIX}/include)

(टिप्पणी शीर्ष पर चीनी है।)

मुझे लगता है कि सीएमके बिल्ड बहुत कम परिपक्व है जो कोई सोचता है। क्या यह परियोजना प्राथमिक निर्माण के रूप में होने के बारे में गंभीर है या यह सिर्फ एक ड्राइव-बाय योगदान है? मैं वास्तव में पुरानी शैली के मेकफ़ाइल को ठीक करने के लिए ललचा रहा हूं, चारों ओर कम उपद्रव। लेकिन अब मैं सीएमके सामान को ठीक करने में इतना समय लगा चुका हूं, कि मैं वैसे भी घृणा करता हूं। इसलिए मैं इसे खत्म करना चाहूंगा।

मुझे अब हार माननी होगी ... मैं cblas.h को cblas.h.in पर ले जाने में कामयाब रहा जैसा कि ऊपर बताया गया है, और जोड़ा गया

configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cblas.h.in cblas.h @ONLY)
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/cblas_f77.h.in cblas_f77.h @ONLY)

CBLAS/include/CMakeLists.txt में, साथ ही @HAVE_ILP64@ से 1 या 0 को टॉपलेवल CMakeLists.txt में परिभाषित किया है। लेकिन मैं अपने जीवन के लिए यह नहीं समझ सकता कि उच्च-स्तरीय CMakeLists.txt में स्थापित सामग्री को कैसे बनाया जाए, या ${LAPACK_BINARY_DIR}/include (वास्तव में? स्रोत पेड़ के भीतर कॉपी करें?)

मैक्रो append_subdir_files को क्या करना चाहिए? ऐसा लगता है कि उपसर्ग की एक प्रति शीर्षलेख पथों में प्रीपेड करना है। मुझे स्रोत शीर्षलेख फ़ाइलों के लिए पर्याप्त या बहुत अधिक पथ नहीं मिला। मैं सिर्फ हेडर फाइलों को यहां से वहां तक ​​स्थापित करना चाहता हूं, धिक्कार है।

क्या कोई जानकार यहाँ मदद कर सकता है? मुझे लगता है कि मैं कल इसका पता लगा सकता हूं, लेकिन मुझे यकीन नहीं है कि यह भावनात्मक राहत के लिए वास्तविक दुनिया में कुछ तोड़ दिए बिना है।

हां। मैं इससे सहमत हूं, और उस समाधान को प्राथमिकता देता हूं जो पूरे शीर्षलेख को दोहराता नहीं है। मुझे लगता है कि यह क्लीनर है।

यह मेरे लिए अस्पष्ट है। क्लीनर समाधान कौन सा है? मैं अभी जो तैयारी कर रहा हूं वह इस प्रकार है:

#if defined(WeirdNEC) || @HAVE_ILP64@
   #define CBLAS_INDEX long
   #ifndef WeirdNEC
   #define WeirdNEC
   #endif
#else
   #define CBLAS_INDEX int
#endif

CMakeFile HAVE_ILP को 1 या 0 से बदल देगा, परिणामी हेडर वर्तमान बिल्ड के लिए स्थापित किया जा रहा है।

(बीटीडब्ल्यू: विंडोज़ पर लंबे समय तक काम नहीं करेगा। यह वहां लंबा लंबा है … या int64_t stdint के साथ सभी प्लेटफॉर्म पर।)

सही। मैंने अभी-अभी 64-बिट लाइब्रेरी (BUILD_INDEX64=ON) स्थापित की है और मुझे WeirdNEC , LAPACK_ILP64 या HAVE_LAPACK_CONFIG_H का उपयोग करने के लिए कहने वाला कुछ भी नहीं देख सका। उस पर ध्यान देने के लिए धन्यवाद!

मैं एक ऐसे भविष्य की कल्पना कर रहा हूँ जहाँ आप करते हैं

cc -I/foo/include/netlib64 -o bar bar.c -L/foo/lib -lcblas64

और चीजों को foo/include/netlib64/cblas.h में नियंत्रित किया जाता है, अन्यथा foo/include/netlib/cblas.h द्वारा (संभवतः foo/include/cblas.h से जुड़ा हुआ)।

मुझे संदेह है कि यह आपका मतलब _not_ है, लेकिन मैं यह विश्वास दिलाना चाहता हूं कि यह बेहतर है ;-)

क्षमा करें, मुझे समझाएं। सबसे पहले, मुझे मूल शीर्षलेख cblas.h और include/netlib64/cblas.h और include/netlib/cblas.h को कुछ इस तरह से बनाने का विचार पसंद आया

#if defined(WeirdNEC)
   #define WeirdNEC
#endif
#include <cblas.h>

आप 'द' हेडर को /foo/include/cblas.h में रखकर हेडर को डुप्लिकेट न करने का प्रयास कर सकते हैं और इसमें /foo/include/netlib64/cblas.h शामिल है, केवल WeirdNEC को परिभाषित करके, लेकिन इसका मतलब है कि 64 बिट और 32 बिट पैकेज उस सामान्य हेडर फ़ाइल को साझा करते हैं, जो पैकेजिंग के लिए गन्दा है। यह बेहतर है यदि प्रत्येक अपनी फ़ाइल को अलग-अलग स्थानों/नामों में रखता है। नाम को cblas.h रहने की आवश्यकता है क्योंकि आप #include <cblas.h> लाइनों को बदलने के लिए इधर-उधर नहीं जाना चाहते हैं।

संपादित करें: इसके अलावा, cblas.h शामिल ../cblas.h अपने आप में गड़बड़ है। साथ ही हम cmake के लिए _one_ हेडर इंस्टॉलेशन डायरेक्टरी को परिभाषित करते हैं।

लेकिन हाँ, हमें include/netlib64 और include का उपयोग करना होगा क्योंकि इसमें dirs शामिल हैं यदि हम एक हेडर में दूसरे को शामिल करते हैं।

डिफ़ॉल्ट रूप से यह /foo/include है, न कि /foo/netlib64/include। मैं इस डिफ़ॉल्ट को नहीं बदलने जा रहा हूं। पैकेजर्स को इस तरह उपनिर्देशिका निर्दिष्ट करनी होगी (बीएसडी मेक इन पीकेजीएसआरसी):

.if !empty(LAPACK_COMPONENT:M*64)
.  if empty(MACHINE_ARCH:M*64)
PKG_FAIL_REASON+=       "${LAPACK_COMPONENT} incompatible with non-64-bit platform"
.  endif
HEADERDIR=netlib64
.else
HEADERDIR=netlib
.endif

# Note: We patch the build to install both static and
# shared libraries.
CMAKE_ARGS=     -DBUILD_DEPRECATED=ON \
                -DBUILD_SHARED_LIBS=ON \
                -DBUILD_STATIC_LIBS=ON \
                -DCMAKE_INSTALL_INCLUDEDIR=${PREFIX}/include/${HEADERDIR} \
                ${LAPACK_COMPONENT_CMAKE_ARGS}

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

(बीटीडब्ल्यू: विंडोज़ पर लंबे समय तक काम नहीं करेगा। यह वहां लंबा लंबा है … या int64_t stdint के साथ सभी प्लेटफॉर्म पर।)

जानकर अच्छा लगा। बीएलएएस ++ और लैपैक ++ लंबे समय के बजाय int64_t का उपयोग करते हैं।

@weslleyspereira तो आपको सबसे पहले यह विचार पसंद आया:

#if defined(WeirdNEC)
   #define WeirdNEC
#endif
#include "../cblas.h"

/prefix/include/cblas.h और /prefix/include/netlib64/cblas.h के साथ, बाद वाला पूर्व का पता लगा रहा है? लेकिन अब आप सहमत हैं कि 64 बिट बिल्ड के लिए इस तरह दिखने वाले हेडर को स्थापित करने के लिए यह एक अधिक मजबूत समाधान है?

#if defined(WeirdNEC) || @HAVE_ILP64@
   #define CBLAS_INDEX long
   #ifndef WeirdNEC
   #define WeirdNEC
   #endif
#else
   #define CBLAS_INDEX int
#endif

(लंबा बनाम int64 एक अलग मामला है, लेकिन मैं उस परिवर्तन को करने के लिए हूं, जैसे BLAS++)

हेक, मुझे यह भी यकीन नहीं है कि यह मान लेना सुरक्षित है कि `# शामिल ".../cblas.h" केवल अन्य इंडेंटेड हेडर ढूंढेगा। सी मानक यह कहता प्रतीत होता है कि खोज आदेश कार्यान्वयन-परिभाषित है, जरूरी नहीं कि वर्तमान शीर्षलेख के सापेक्ष हो। पैकेजर के रूप में मेरा मुख्य मुद्दा यह है कि मुझे उस सामान्य हेडर के लिए एक अलग पैकेज की आवश्यकता होगी या 64 बिट पैकेज 32 बिट पर निर्भर करेगा। यह चूसना होगा।

मैं वास्तव में pkgsrc के लिए इस तरह के बदलाव के साथ आगे बढ़ना चाहता हूं, बाद में अपस्ट्रीम कोड के लिए एक बदलाव को व्यवस्थित करने के लिए। हम 32 बिट इंडेक्स या 64 बिट इंडेक्स को स्पष्ट रूप से किसी भी शीर्षलेख ( -DNETLIB_INDEX_BITS=64 ?) के साथ मजबूर करने के लिए एक नए प्रतीक पर चर्चा कर सकते हैं, जो पुस्तकालय के साथ बनाया गया था।

क्या मुझे हमारे इच्छित समाधान के बारे में सहमति मिल सकती है?

lib/libcblas64.so
include/optional_subdir64/cblas.h

तथा

lib/libcblas.so
include/optional_subdir/cblas.h

LAPACK कोड के प्रत्येक निर्माण का परिणाम हेडर में होता है, जो कम से कम डिफ़ॉल्ट रूप से, उपयोगकर्ता द्वारा कुछ भी परिभाषित किए बिना स्थापित पुस्तकालयों से मेल खाता है। ठीक है?

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

(बस किसी भी तरह से उस अजीब सीएमके को सबमिशन में हरा करने की कोशिश करते समय मेरे गुस्से की जांच करने की आवश्यकता है, जहां यह बिल्ड निर्देशिकाओं के चारों ओर हेडर प्रतियों को घुमाता है और फिर उन्हें इंस्टॉल के लिए नहीं ढूंढ पाता है। या उन टूटी हुई .cmake फ़ाइलों के बारे में निर्णय लें जो हमारे लिए कोई उपयोग नहीं कर रहे हैं, हो सकता है कि बस उन्हें इंस्टॉल से हटा दें ... हमें pkg-config मिल गया!)

कुछ भी? मुझे यह स्वीकार करना होगा कि मुझे व्यवहार में एक अलग समाधान के लिए ज्यादा मौका नहीं दिख रहा है, क्योंकि यह ओपनब्लास द्वारा निर्धारित उदाहरण है, मुख्य कार्यान्वयन जिसका हम उपयोग करते हैं। मैं कल्पना कर सकता हूं कि इंटेल को 64 बिट/32 बिट इंडेक्स हेडर के लिए उपनिर्देशिका रखने के लिए भी, उनके mkl_cblas.h और mkl_lapacke.h पर लपेटकर। अन्यथा मैं एक साधारण पैकेज बनाता हूं जो बस उनको प्रदान करता है।

include/mkl-blas/cblas.h
include/mkl-blas64/cblas.h

वर्तमान में, मैंने pkgsrc में अजीब -DWeirdNEC -DHAVE_LAPACK_CONFIG_H -DLAPACK_ILP64 लाइन के साथ निर्माण प्रदान करने के लिए मशीनरी को जोड़ा, जिसमें cblas और cblas64 दोनों समान हेडर स्थापित कर रहे हैं। यह उस तरह से रह सकता है, लेकिन मुझे अभी भी लगता है कि एबीआई के निर्माण से मेल खाने के लिए हेडर सेट अप करना समझ में आता है।

@weslleyspereira तो आपको सबसे पहले यह विचार पसंद आया:

#if defined(WeirdNEC)
   #define WeirdNEC
#endif
#include "../cblas.h"

/prefix/include/cblas.h और /prefix/include/netlib64/cblas.h के साथ, बाद वाला पूर्व का पता लगा रहा है? लेकिन अब आप सहमत हैं कि 64 बिट बिल्ड के लिए इस तरह दिखने वाले हेडर को स्थापित करने के लिए यह एक अधिक मजबूत समाधान है?

#if defined(WeirdNEC) || @HAVE_ILP64@
   #define CBLAS_INDEX long
   #ifndef WeirdNEC
   #define WeirdNEC
   #endif
#else
   #define CBLAS_INDEX int
#endif

हाँ बस यही। मैं 32- और 64-बिट हेडर के लिए सबफ़ोल्डर रखने के आपके समाधान से सहमत हूं। मैंने @langou के साथ इस पर चर्चा की, और उन्हें यह भी विश्वास था कि यह एक अच्छा समाधान होगा।

(लंबा बनाम int64 एक अलग मामला है, लेकिन मैं उस परिवर्तन को करने के लिए हूं, जैसे BLAS++)

सही। इसे किसी अन्य मुद्दे में संबोधित किया जाना चाहिए।

मैं वास्तव में pkgsrc के लिए इस तरह के बदलाव के साथ आगे बढ़ना चाहता हूं, बाद में अपस्ट्रीम कोड के लिए एक बदलाव को व्यवस्थित करने के लिए। हम 32 बिट इंडेक्स या 64 बिट इंडेक्स को स्पष्ट रूप से किसी भी शीर्षलेख ( -DNETLIB_INDEX_BITS=64 ?) के साथ मजबूर करने के लिए एक नए प्रतीक पर चर्चा कर सकते हैं, जो पुस्तकालय के साथ बनाया गया था।

क्या मुझे हमारे इच्छित समाधान के बारे में सहमति मिल सकती है?

lib/libcblas64.so
include/optional_subdir64/cblas.h

तथा

lib/libcblas.so
include/optional_subdir/cblas.h

हां। मुझे लगता है कि आप आगे बढ़ सकते हैं और भविष्य में एक पीआर का प्रस्ताव कर सकते हैं, धन्यवाद! मुझे व्यक्तिगत रूप से लगता है कि NETLIB_INDEX_BITS जैसा एक नया प्रतीक पूरी तरह से समझ में आता है। मैं केवल यह सुनिश्चित करूंगा कि डिफ़ॉल्ट मान 32 बना रहे, और वह -DWeirdNEC का अर्थ है -DNETLIB_INDEX_BITS=64 ।

LAPACK कोड के प्रत्येक निर्माण का परिणाम हेडर में होता है, जो कम से कम डिफ़ॉल्ट रूप से, उपयोगकर्ता द्वारा कुछ भी परिभाषित किए बिना स्थापित पुस्तकालयों से मेल खाता है। ठीक है?

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

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

ठीक! हमारे पास शायद 2021 के दूसरे सेमेस्टर में LAPACK रिलीज़ होगी। और हाँ, मेकफ़ाइल को तदनुसार समायोजित किया जाना चाहिए, और मैं इसमें मदद करने के लिए तैयार हूँ।

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

https://github.com/numpy/numpy/blob/main/numpy/core/src/common/npy_cblas.h

और इस शीर्षलेख में, यह CBLAS_INDEX=size_t सेट करता है, जो सूचकांक निर्दिष्ट करने में उपयोग किए जाने वाले पूर्णांक प्रकार से भिन्न होता है। इसका उपयोग पूरी तरह से कुछ कार्यों के वापसी मूल्यों के लिए किया जाता है:

$ grep CBLAS_INDEX ./numpy/core/src/common/npy_cblas_base.h                                                                                                                                  
CBLAS_INDEX BLASNAME(cblas_isamax)(const BLASINT N, const float  *X, const BLASINT incX);
CBLAS_INDEX BLASNAME(cblas_idamax)(const BLASINT N, const double *X, const BLASINT incX);
CBLAS_INDEX BLASNAME(cblas_icamax)(const BLASINT N, const void   *X, const BLASINT incX);
CBLAS_INDEX BLASNAME(cblas_izamax)(const BLASINT N, const void   *X, const BLASINT incX);

अंतर:

$ grep cblas_isamax ./numpy/core/src/common/npy_cblas_base.h  /data/pkg/include/cblas.h                                                                                                      
./numpy/core/src/common/npy_cblas_base.h:CBLAS_INDEX BLASNAME(cblas_isamax)(const BLASINT N, const float  *X, const BLASINT incX);
/data/pkg/include/cblas.h:CBLAS_INDEX cblas_isamax(const CBLAS_INDEX N, const float  *X, const CBLAS_INDEX incX);

मुझे आश्चर्य है कि क्या यह संभवतः परेशानी पैदा कर रहा है। नेटलिब के लिए, केवल एक प्रकार का सूचकांक है, जबकि अन्य कार्यान्वयन सूचकांक कार्यों के लिए भिन्न रिटर्न मान प्रकार का उपयोग करते हैं। OpenBLAS उदाहरण सेट करता है। वे कहते हैं कि isamax अहस्ताक्षरित size_t देता है, लेकिन C आवरण वास्तव में एक फोरट्रान फ़ंक्शन को कॉल करता है जो एक हस्ताक्षरित पूर्णांक देता है (संपादित करें: एक सबरूटीन जो एक हस्ताक्षरित 32 या 64 बिट पूर्णांक मान को एक हस्ताक्षरित 64 बिट चर के संदर्भ में 64 पर लिखता है। बिट सिस्टम)।

क्या संदर्भ कार्यान्वयन की इस बारे में कोई राय है? I_guess_ कोई वास्तविक परेशानी नहीं है, क्योंकि size_t मान हमेशा isamax() से किसी भी गैर-ऋणात्मक रिटर्न को धारण करने में सक्षम होगा। लेकिन यह iffy बदबू आ रही है। (संपादित करें: आप 32 बिट सिस्टम पर 64 बिट इंडेक्स के साथ निर्माण कर सकते हैं जहां size_t 32 बिट्स है, है ना? फिर आप ओवरफ्लो हो गए। size_t * से int * कास्टिंग की बेचैनी के अलावा।)

चूंकि ऑप्टिमाइज्ड कार्यान्वयनों ने वहां size_t पर निर्णय लिया है, क्या संदर्भ को उस तथ्य को स्वीकार करना चाहिए और उसका पालन करना चाहिए?

और वास्तव में, संदर्भ cblas के साथ numpy को जोड़ना कितना खतरनाक है?

OpenBLAS उदाहरण सेट करता है। (...)
चूंकि ऑप्टिमाइज्ड कार्यान्वयनों ने वहां size_t पर निर्णय लिया है, क्या संदर्भ को उस तथ्य को स्वीकार करना चाहिए और उसका पालन करना चाहिए?

मैं निश्चित रूप से numpy (या उस मामले के लिए एमकेएल इत्यादि) के लिए बात नहीं कर सकता, लेकिन मैं ओपनबीएलएएस को किसी भी रूप में मानक होने का दावा करने में संकोच करता हूं, कम से कम सभी सापेक्ष जो (मुझे विश्वास है) आम तौर पर __the__ संदर्भ कार्यान्वयन के रूप में देखा जाता है .. .

ज़रूर। यह सिर्फ इतना है कि OpenBLAS या MKL वही हैं जो लोग व्यवहार में उपयोग करते हैं और ऐसा लगता है कि दोनों ने समझौता कर लिया है

#define CBLAS_INDEX size_t  /* this may vary between platforms */
#ifdef MKL_ILP64
#define MKL_INT MKL_INT64
#else
#define MKL_INT int
#endif
CBLAS_INDEX cblas_isamax(const MKL_INT N, const float  *X, const MKL_INT incX);

या इसी तरह

#ifdef OPENBLAS_USE64BITINT
typedef BLASLONG blasint;
#else
typedef int blasint;
#endif
#define CBLAS_INDEX size_t
CBLAS_INDEX cblas_isamax(OPENBLAS_CONST blasint n, OPENBLAS_CONST float  *x, OPENBLAS_CONST blasint incx);

बनाम संदर्भ

#ifdef WeirdNEC
   #define CBLAS_INDEX long
#else
   #define CBLAS_INDEX int
#endif
CBLAS_INDEX cblas_isamax(const CBLAS_INDEX N, const float  *X, const CBLAS_INDEX incX);

यह कैसे आया कि वे यहाँ संदर्भ से अलग हो गए हैं? क्या इसके बारे में कोई संवाद था? साथ ही ... मैं एमकेएल और ओपनबीएलएएस को ऐसे कई कार्यों को परिभाषित करता हूं जो संदर्भ सीबीएलएएस का हिस्सा भी नहीं हैं:

CBLAS_INDEX cblas_isamin(const MKL_INT N, const float  *X, const MKL_INT incX);
CBLAS_INDEX cblas_idamin(const MKL_INT N, const double *X, const MKL_INT incX);
CBLAS_INDEX cblas_icamin(const MKL_INT N, const void   *X, const MKL_INT incX);
CBLAS_INDEX cblas_izamin(const MKL_INT N, const void   *X, const MKL_INT incX);

CBLAS_INDEX cblas_isamin(OPENBLAS_CONST blasint n, OPENBLAS_CONST float  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_idamin(OPENBLAS_CONST blasint n, OPENBLAS_CONST double *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_icamin(OPENBLAS_CONST blasint n, OPENBLAS_CONST void  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_izamin(OPENBLAS_CONST blasint n, OPENBLAS_CONST void *x, OPENBLAS_CONST blasint incx);

CBLAS_INDEX cblas_ismax(OPENBLAS_CONST blasint n, OPENBLAS_CONST float  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_idmax(OPENBLAS_CONST blasint n, OPENBLAS_CONST double *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_icmax(OPENBLAS_CONST blasint n, OPENBLAS_CONST void  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_izmax(OPENBLAS_CONST blasint n, OPENBLAS_CONST void *x, OPENBLAS_CONST blasint incx);

CBLAS_INDEX cblas_ismin(OPENBLAS_CONST blasint n, OPENBLAS_CONST float  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_idmin(OPENBLAS_CONST blasint n, OPENBLAS_CONST double *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_icmin(OPENBLAS_CONST blasint n, OPENBLAS_CONST void  *x, OPENBLAS_CONST blasint incx);
CBLAS_INDEX cblas_izmin(OPENBLAS_CONST blasint n, OPENBLAS_CONST void *x, OPENBLAS_CONST blasint incx);

तो, मानक का विस्तार करना एक बात है, लेकिन size_t बनाम int 64 बिट सिस्टम पर एक गंभीर मुद्दा प्रतीत होता है। इसे किसी तरह सुलझाया जाना चाहिए। मुझे ऐसा लगता है कि नेटलिब तरीका समझदार है: उसी प्रकार जैसा कि सूचकांक के लिए उपयोग किया जाता है। जैसा कि सभी अंत में फोरट्रान रूटीन को इस तरह कहते हैं

c     isamaxsub.f
c
c     The program is a fortran wrapper for isamax.
c     Witten by Keita Teranishi.  2/11/1998
c
      subroutine isamaxsub(n,x,incx,iamax)
c
      external isamax
      integer  isamax,iamax
      integer n,incx
      real x(*)
c
      iamax=isamax(n,x,incx)
      return
      end

... iamax के लिए size_t का पता सौंपना, जो कि गलत लगता है। मुझे OpenBLAS स्रोतों में इस संदर्भ से एक और कार्यान्वयन नहीं मिला। क्या वे सिर्फ मूर्ख हैं जो बाहरी प्रकार को इस तरह बदल रहे हैं या क्या मैं कुछ बहुत ही बुनियादी देख रहा हूं? क्या कोई वास्तव में इन कार्यों का उपयोग कर रहा है?

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

कुछ संदर्भ जोड़ने के लिए, सीबीएलएएस का जन्म एक समिति (बेसिक लीनियर अलजेब्रा सबप्रोग्राम्स टेक्निकल फोरम) से हुआ था, जिसने बीएलएएस पर दोबारा गौर करने पर 1996 से 2000 तक काम किया था, इसके हिस्से के रूप में उन्होंने बीएलएएस के लिए सी इंटरफेस को परिभाषित किया था। देखो:
http://www.netlib.org/blas/blast-forum/
विशेष रूप से देखें:
http://www.netlib.org/blas/blast-forum/cinterface.pdf
मेरा मानना ​​है कि LAPACK द्वारा पेश किया गया CBLAS 25 साल पहले बेसिक लीनियर अलजेब्रा सबप्रोग्राम्स टेक्निकल फोरम द्वारा परिभाषित इंटरफ़ेस का कार्यान्वयन है।

यदि सीबीएलएएस में सुधार के लिए कोई सुझाव हैं, तो उन्हें साथ भेजें। मैं इसे विभिन्न हितधारकों तक पहुंचाने का प्रयास कर सकता हूं।

सूचक के लिए धन्यवाद। तो प्रासंगिक हिस्सा उस स्पेक में बी.2.2 प्रतीत होता है, जो कहता है कि BLAS_INDEX आमतौर पर size_t , लेकिन इसे (हस्ताक्षरित) फोरट्रान पूर्णांक प्रकार के समान होने के लिए भी चुना जा सकता है अनुक्रमण यह क्रियान्वयन पर निर्भर है।

तो ऐसा लगता है कि लोकप्रिय अनुकूलित कार्यान्वयन ने size_t चुना और नेटलिब संदर्भ ने उसी पूर्णांक को चुना जो वह फोरट्रान के लिए उपयोग करता है। मैं विभिन्न परियोजनाओं में चारों ओर cblas.h की प्रतियां देखता हूं जो उस लाइन के साथ lib (जैसे numpy, बाहरी lib के लिए शीर्षलेख शिपिंग) का उपयोग करते हैं

#define CBLAS_INDEX size_t  /* this may vary between platforms */

https://github.com/LuaDist/gsl/blob/master/cblas/gsl_cblas.h में , इसके साथ है

/* This is a copy of the CBLAS standard header.
 * We carry this around so we do not have to
 * break our model for flexible BLAS functionality.
 */

ऐसा लगता है कि यह संदर्भ कार्यान्वयन में उत्पन्न हुआ है, लेकिन तब से बदल गया है? 41779680d1f233928b67f5f66c0b239aecb42774 को देखते हुए ... मैं देखता हूं कि CBLAS_INDEX WeirdNEC के साथ स्विच 64 बिट बिल्ड से पहले रहा है। वाह, क्या यह हाल ही में प्रतिबद्ध है। अब मैं देखता हूं कि 2015 तक size_t संदर्भ cblas.h में था, 83fc0b48afd1f9a6d6f8dddb16e69ed7ed0e7242 ने इसे बदल दिया और WeirdNEC परिभाषित किया। मैंने कल्पना नहीं की थी कि यह इतना हाल का है! बेतहाशा भ्रमित।

मैं यह भी देखता हूं कि cblas.h के पुराने संस्करण ने फोरट्रान कॉल को int सौंप दिया, अब CBLAS_INDEX । यह अब सही प्रतीत होता है, पूर्णांक प्रकार के रूप में CBLAS_INDEX लगातार उपयोग और फोरट्रान भाग में 32 या 64 बिट्स के लिए स्विच के साथ।

लेकिन क्या ऐसा हो सकता है कि अनुकूलित पुस्तकालय जो cblas.h के पुराने संस्करण को size_t साथ विरासत में मिला है, लेकिन संदर्भ से वर्तमान CBLAS कोड के साथ सिंक स्रोतों में एक अच्छी बग चल रही है? क्या वे 64 बिट सिस्टम पर 32 बिट केस के लिए ऐसा कुछ नहीं कर रहे हैं?

#include <stdio.h>
#include <stdlib.h>


void ia_max(int a, void *b)
{
    int *ib = (int*)b;
    *ib = a*2;
}


int main(int argc, char **argv)
{
    int i = atoi(argv[1]);
    size_t maxi;
    ia_max(i, &maxi);
    printf("in %d out %ld\n", i, (long)maxi);
    return 0;
}

इसका परिणाम यह होगा

$ gcc -O -o t t.c
$ ./t 42
in 42 out 140724603453524

size_t मान को शून्य पर प्रारंभ करने से मदद मिलती है, लेकिन शायद केवल छोटे-एंडियन मामले में। क्या इसके लिए किसी को परेशानी नहीं होती? मुझे कुछ याद आ रहा है।

समाप्त करने के लिए:

1. संदर्भ CBLAS के पास पहले वापसी मूल्य के रूप में size_t ।
2. हालांकि, फोरट्रान को वास्तविक कॉल में यह int का उपयोग करता था।
3. डाउनस्ट्रीम (अनुकूलित बीएलएएस, सीबीएलएएस उपयोगकर्ता) हेडर के पुराने संस्करण के साथ चलते हैं।
4. संदर्भ CBLAS एक विशिष्ट प्रणाली के लिए WeirdNEC हैक का परिचय देता है, size_t को int या long से बदल देता है (फोरट्रान पक्ष से मेल खाता है ?!)
5. फोरट्रान डिफ़ॉल्ट पूर्णांक के लिए हर जगह CBLAS_INDEX का उपयोग करके 64 बिट संदर्भ सीबीएलएएस इंटरफ़ेस उसके ऊपर निर्मित हो जाता है।
6. डाउनस्ट्रीम ने 64 बिट समर्थन के साथ अपना काम किया, लेकिन इसे CBLAS_INDEX से अलग कर दिया, जो कि हमेशा size_t होता है।
7. डाउनस्ट्रीम सीबीएलएएस रैपर को इनहेरिट करते हैं जो फोरट्रान को कॉल करने के लिए CBLAS_INDEX नियोजित करते हैं जो डिफ़ॉल्ट पूर्णांक की अपेक्षा करता है।

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

ओपनब्लास कम से कम संदर्भ-लैपैक से सीबीएलएएस रैपर कोड का उपयोग नहीं करता है (और कभी नहीं किया, स्रोत वहां है लेकिन निर्मित नहीं होता है)

@ मार्टिन-एफआरबीजी जानना अच्छा है। क्या आप x86-64 के लिए एक कोड पथ इंगित कर सकते हैं जो दिखाता है कि cblas_isamax() के लिए वास्तविक गणना के लिए size_t कैसे पारित किया जाता है? मुझे कुछ विशिष्ट कर्नेल कार्यान्वयन मिला लेकिन सामान्य मामले के बारे में निश्चित नहीं हूं।

यह जानना अच्छा होगा कि कोई भी वास्तव में फोरट्रान इंटरफ़ेस के लिए (size_t*) पास नहीं करता है।

निश्चित रूप से यह अच्छा नहीं है कि परियोजनाएं केवल मान लें

size_t cblas_isamax(…)

जब वास्तविक पुस्तकालय वापसी मूल्य के रूप में एक int या long (या int64_t) प्रदान कर सकता है। अधिकांश समय 64 बिट रजिस्टरों में मूल्यों के साथ काम कर सकता है, लेकिन यह अच्छा नहीं है। क्या हम इसे कार्यान्वयन में सुधार सकते हैं? पिछले 5 वर्षों में लोगों ने CBLAS_INDEX लगातार उपयोग के बारे में नेटलिब के उदाहरण पर ध्यान नहीं दिया।

प्रासंगिक कोड OpenBLAS/इंटरफ़ेस में है, उदाहरण के लिए इंटरफ़ेस/imax.c cblas_isamax() में संकलित हो जाता है जब सीबीएलएएस परिभाषित किया जाता है, इसके कॉल ग्राफ में कोई फोरट्रान कोड शामिल नहीं होता है।

आह अच्छा। तो एक मामला जो वास्तव में समस्याग्रस्त है वह cblas.h की एक प्रति का उपयोग कर परियोजनाओं पर निर्भर करता है जो पुस्तकालय में फिट नहीं होता है।

मुझे NumPy (और SciPy) में cblas_isamax() और दोस्तों का वास्तविक उपयोग नहीं मिला, इसलिए यह केवल एक सैद्धांतिक मुद्दा हो सकता है। फिर भी इसे ठीक किया जाना चाहिए। इसलिए:

1. अन्य लोग int32_t/int64_t का उपयोग करने के नेटलिब उदाहरण का अनुसरण करते हैं (चलो उस पर स्पष्ट रहें;-) BLAS_INDEX आकार रिटर्न और अनुक्रमणिका तर्क दोनों के लिए।
2. Netlib गुफाओं में जाता है और दूसरों की तरह उन रिटर्न के लिए size_t वापस आ जाता है।

क्या यह चर्चा के लिए एक अलग मुद्दा है? हालांकि, यह 32 या 64 बिट लाइब्रेरी की पसंद से संबंधित है।

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

जितना अधिक मैं इसके बारे में सोचता हूं, उतना ही मैं विकल्प 2 की ओर झुकता हूं: हमारे पास एपीआई में बहुत लंबे समय के लिए size_t था। फिर नेटलिब ने उस size_t को int या long में बदल दिया। फोरट्रान कोड से बेहतर मेल खाने वाले या अधिक सुसंगत होने के बावजूद, size_t स्थापित एपीआई और नेटलिब संदर्भ ने इसे तोड़ दिया।

क्या मुझे चीजों को बदलने के बारे में पीआर खोलना चाहिए

size_t cblas_isamax(const CBLAS_INDEX N, const float  *X, const CBLAS_INDEX incX);
size_t cblas_idamax(const CBLAS_INDEX N, const double *X, const CBLAS_INDEX incX);
size_t cblas_icamax(const CBLAS_INDEX N, const void   *X, const CBLAS_INDEX incX);
size_t cblas_izamax(const CBLAS_INDEX N, const void   *X, const CBLAS_INDEX incX);

फिर? इस स्थिति पर अब कोई मैक्रो नहीं होना चाहिए ताकि इस बात पर जोर दिया जा सके कि यह हमेशा size_t, हर जगह, अतीत और भविष्य में होता है।

https://github.com/numpy/numpy/issues/19243 में अब हम मूल रूप से नीचे उतर गए हैं: "स्क्रू नेटलिब, size_t बाकी सभी के लिए काम करता है"।

size_t का उपयोग करने के तीन कारण हैं:

1. सभी C और C++ मानक पुस्तकालय कार्य इस मान को स्वीकार करते हैं और वापस करते हैं, उदाहरण के लिए, void* malloc(size_t) , size_t strlen() , या std::size_t std::vector<T>::size() (C++)। size_t से मूल्यों और हस्ताक्षरित/अहस्ताक्षरित रूपांतरणों को छोटा करने से बचा जाता है।
2. size_t का उपयोग अक्सर व्यक्त मात्रा के रूप में किया जाता है जो ऋणात्मक नहीं हो सकता, उदाहरण के लिए, मैट्रिक्स आयाम।
3. C और C++ मानक गारंटी देते हैं कि आप किसी भी सरणी के आकार को size_t में संग्रहीत कर सकते हैं और यह कि आप सभी तत्वों को size_t , cf के साथ अनुक्रमित कर सकते हैं। cppference.com: size_t ।

संपादित करें: आप 32 बिट सिस्टम पर 64 बिट इंडेक्स के साथ निर्माण कर सकते हैं जहां size_t 32 बिट्स है, है ना? फिर आप ओवरफ्लो हो गए।

नहीं, क्योंकि 32-बिट सिस्टम में 4 जीबी से अधिक वर्चुअल मेमोरी हो सकती है (लिनक्स इसका समर्थन करता है) लेकिन एक 32-बिट प्रक्रिया कभी भी 4 जीबी से अधिक तक नहीं पहुंच सकती है। यानी, 64-बिट इंडेक्स के ऊपरी 32-बिट का कभी भी उपयोग नहीं किया जाता है।

_स्मृति सीमा 64-बिट Linux OS पर चलने वाली 32-बिट प्रक्रिया तक_

मैं यह भी सोच रहा हूं कि size_t रखना सही काम है, क्योंकि इससे बदलना ABI ब्रेक था और बाकी दुनिया के साथ Netlib को सिंक से बाहर कर दिया।

लेकिन मुझे आपके तर्कों पर ध्यान देने के लिए मजबूर होना पड़ता है ;-)

1. All of the C and C++ standard library functions accept and return this value

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

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

लेकिन वैसे भी, अगर यह केवल मेमोरी आकार को malloc() और दोस्तों को सौंपने के बारे में है, size_t स्वाभाविक बात है, और यह सीबीएलएएस में पहले भी रहा है।

कोड की वर्तमान स्थिति के साथ संभावित मुद्दों पर, बिल्ड में विक्रेता cblas.h साथ बेमेल:

नहीं, क्योंकि 32-बिट सिस्टम में 4 जीबी से अधिक वर्चुअल मेमोरी हो सकती है (लिनक्स इसका समर्थन करता है) लेकिन एक 32-बिट प्रक्रिया कभी भी 4 जीबी से अधिक तक नहीं पहुंच सकती है। यानी, 64-बिट इंडेक्स के ऊपरी 32-बिट का कभी भी उपयोग नहीं किया जाता है।

ठीक है, size_t 32 बिट रहता है। जब आप (मूर्खतापूर्ण रूप से हो सकता है) ने cblas_isamax() को 64 बिट पूर्णांक वापस करने के लिए बनाया, बिल्ड को हैक करने के बाद long उपयोग नहीं करने के लिए, लेकिन int64_t , निश्चित रूप से, क्या होगा वास्तव में ऐसे उपयोग में होता है?

size_t cblas_isamax(); // really int64_t cblas_isamax()!
size_t value = cblas_isamax(…);

x86 कॉलिंग कन्वेंशन 64 बिट मान को EAX और EDX में डाल सकता है। या यह एक सूचक वापसी और कुछ बफर के साथ काम कर सकता है। लेकिन अन्य आर्किटेक्चर क्या करेंगे? तो हो सकता है कि आपको भ्रष्टाचार न मिले, लेकिन निश्चित रूप से एक गलत मूल्य। सबसे अच्छा मामला उच्च 32 बिट्स को अनदेखा किया जा रहा है।

अब एक बड़े-एंडियन 32 बिट सिस्टम (एआरएम का कुछ रूप) की कल्पना करें ... सुनिश्चित करें कि आपको लौटाए गए मूल्य का वांछित आधा भी मिल जाएगा?

आप वास्तव में गैर-स्पैस डेटा के साथ काम नहीं कर सके, जिसे 32 बिट प्रोग्राम में 64 बिट इंडेक्स की आवश्यकता है, निश्चित रूप से। लेकिन सिर्फ एक गैर-मिलान फ़ंक्शन कॉल करने में सक्षम होने के कारण _at_least_ गलत परिणाम देता है जो अस्वस्थ लगता है।

मैंने कुछ त्वरित परीक्षण किया ... x86 लिनक्स पर ( gcc -m32 एक x86-64 सिस्टम पर), आप बस ऊपरी 32 बिट्स को छोड़ दें।

अधिक दिलचस्प मामला … 64 बिट size_t:

size_t cblas_isamax(); // really int32_t cblas_isamax()!
size_t value = cblas_isamax(…);

फिर, x86-64 पर, 64 बिट RAX और 32 बिट EAX के बीच अजीबोगरीब संबंध चीजों को कुछ हद तक अच्छी तरह से परिभाषित करता है, साथ ही साझा रजिस्टर पर 32 बिट ऑपरेशन करने के बाद केवल चुपचाप ऊपरी 32 बिट्स को शून्य कर देता है। लेकिन थोड़ा अजीब फंक्शन डिफिनिशन के साथ मजा आता है:

$ cat ret32.c 
#include <stdint.h>

int32_t ret64(int64_t a)
{
    a += 1LL<<32;
    return a;
}
$ gcc -m64  -g -c -o ret32.o ret32.c 
$ LANG=C objdump -S ret32.o 
[…]
   8:   48 89 7d f8             mov    %rdi,-0x8(%rbp)
    a += 1LL<<32;
   c:   48 b8 00 00 00 00 01    movabs $0x100000000,%rax
  13:   00 00 00 
  16:   48 01 45 f8             add    %rax,-0x8(%rbp)
    return a;
  1a:   48 8b 45 f8             mov    -0x8(%rbp),%rax

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

$ cat call.c 
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

INDEX ret64(int64_t);

int main(int argc, char **argv)
{
    if(argc < 2)
        return 1;
    int64_t a = (int64_t)strtoll(argv[1], NULL, 10);
    INDEX  s = ret64(a);
    printf("%lld\n", (long long)s);
    return 0;
}
$ gcc -m64 -g -DINDEX=int32_t -c -o call32_64.o call.c
$ gcc -m64 -g -DINDEX=size_t -c -o call64_64.o call.c
$ ./call32_64 1
1
$ ./call64_64 1
4294967297

आनंद। एक 32 बिट रिटर्न वैल्यू जो 32 बिट्स में संभव से अधिक देता है। यह वही हो सकता है (सिद्धांत रूप में) Netlib CBLAS की वर्तमान स्थिति के साथ कोड के साथ जोड़ा जा रहा है जो size_t की अपेक्षा करता है। मुझे लगता है कि व्यवहार में वास्तविक कोड में RAX के ऊपरी 32 बिट शून्य होंगे। लेकिन कौन जानता है ... संकलक उम्मीद करता है कि कॉलर किसी भी प्लेटफॉर्म पर कम 32 बिट्स से अधिक का उपयोग नहीं करेगा ... साथ ही वहां कचरा स्टोर कर सकता है।

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

इन सभी मूल्यवान टिप्पणियों के लिए धन्यवाद!

मैंने इस विषय पर @langou के साथ थोड़ी चर्चा की। यहाँ चर्चा के आधार पर, मेरा प्रस्ताव है:

एक अलग पीआर में:

1. हम एक cblas.h वापस जाते हैं जो दो पूर्णांक परिभाषाओं का उपयोग करता है, मान लीजिए CBLAS_INDEX और CBLAS_INT। MKL (CBLAS_INDEX और MKL_INT) और OpenBLAS (CBLAS_INDEX और blasint) में यही होता है। CBLAS_INDEX का उपयोग केवल i*amax की वापसी में किया जाएगा। इसके साथ, हम एक एबीआई को पुनर्स्थापित करते हैं जो अन्य बीएलएएस के साथ संगत है।
2. इसके अतिरिक्त, हम CBLAS_INDEX का डिफ़ॉल्ट मान size_t चुनते हैं और समुदाय से राय एकत्र करते हैं।

मुझे लगता है कि इस धागे में हाल की चर्चाओं के पीछे यह गठबंधन (या शायद वही) विचार है।
जैसा कि @drhpc ने बताया,
https://github.com/Reference-LAPACK/lapack/commit/83fc0b48afd1f9a6d6f8dddb16e69ed7ed0e7242 ने CBLAS_INDEX के डिफ़ॉल्ट मान को बदल दिया, और
https://github.com/Reference-LAPACK/lapack/commit/41779680d1f233928b67f5f66c0b239aecb42774 ने CBLAS_INDEX के उपयोग को बदल दिया।

बस मजबूत करने के लिए:

• OpenBLAS, MKL, GNU साइंटिफिक लाइब्रेरी और Numpy सभी डिफ़ॉल्ट रूप से size_t उपयोग करते हैं।
• बीएलएएस के लिए सी इंटरफ़ेस (https://www.netlib.org/blas/blast-forum/cinterface.pdf) इंगित करता है कि, आमतौर पर, CBLAS_INDEX = size_t ।

क्या आप सहमत हैं? अगर आप करते हैं, तो मैं पीआर खोल सकता हूं। या शायद @drhpc ऐसा करना

मैं सहमत हूं। और कृपया पीआर के साथ आगे बढ़ें।

@mgates3 ने स्लेट Google समूह पर चर्चा का उल्लेख किया:
https://groups.google.com/a/icl.utk.edu/g/slate-user/c/f5y6gt0aoLs/m/oQyyhikwCgAJ
चर्चा इस बारे में नहीं है कि "CBLAS_INDEX" क्या होना चाहिए, बल्कि इस बारे में है कि "CBLAS_INT" क्या होना चाहिए। क्या CBLAS_INT size_t या हस्ताक्षरित पूर्णांक या आदि होना चाहिए? मुझे लगता है कि प्रतिभागी अच्छे अंक बना रहे हैं इसलिए मैं आगे बढ़ रहा हूं।

कृपया, #588 देखें।

ठीक है, size_t 32 बिट रहता है। जब आप (मूर्खतापूर्ण रूप से हो सकता है) ने cblas_isamax() को 64 बिट पूर्णांक वापस करने के लिए बनाया, बिल्ड को हैक करने के बाद long उपयोग नहीं करने के लिए, लेकिन int64_t , निश्चित रूप से, क्या होगा वास्तव में ऐसे उपयोग में होता है?

size_t cblas_isamax(); // really int64_t cblas_isamax()!
size_t value = cblas_isamax(…);

x86 कॉलिंग कन्वेंशन 64 बिट मान को EAX और EDX में डाल सकता है। या यह एक सूचक वापसी और कुछ बफर के साथ काम कर सकता है। लेकिन अन्य आर्किटेक्चर क्या करेंगे? तो हो सकता है कि आपको भ्रष्टाचार न मिले, लेकिन निश्चित रूप से एक गलत मूल्य। सबसे अच्छा मामला उच्च 32 बिट्स को अनदेखा किया जा रहा है।

अब एक बड़े-एंडियन 32 बिट सिस्टम (एआरएम का कुछ रूप) की कल्पना करें ... सुनिश्चित करें कि आपको लौटाए गए मूल्य का वांछित आधा भी मिल जाएगा?

यह खेल खत्म हो गया है। 32-बिट आर्म सीपीयू पर, चार 32-बिट मान पास किए जा सकते हैं और रजिस्टरों में वापस किए जा सकते हैं, 64-बिट मान लगातार दो रजिस्टरों पर कब्जा कर लेते हैं, आर्म आर्किटेक्चर के लिए प्रक्रिया कॉल स्टैंडर्ड में खंड 6.1.1.1 देखें। एक रजिस्टर में लिखने के बजाय, कैली अपने 64-बिट पूर्णांकों के साथ दो रजिस्टरों को अव्यवस्थित कर देगा; यह स्पष्ट रूप से एक समस्या है। जैसे ही कॉलर पैरामीटर के लिए रजिस्टरों से बाहर हो जाता है, स्टैक का उपयोग किया जाता है। स्टैक संरेखण 32 बिट है लेकिन 32 बिट पढ़ने या लिखने के बजाय, कैली 64 बिट लिखता है; फिर से, यह खेल खत्म हो गया है और यह समस्या (ढेर पढ़ने/लिखने के आकार का बेमेल) किसी बिंदु पर सभी निर्देश सेट आर्किटेक्चर पर समस्याएं पैदा करनी चाहिए।

• शाखा एबीआई दस्तावेज

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

नहीं, सी और सी ++ के पीछे मानक समितियां इस मामले में आपके कोड को स्पष्ट तरीके से व्यवहार करती हैं: यदि u एक हस्ताक्षरित मूल्य है और s एक हस्ताक्षरित मूल्य है, जहां u कम से कम s रूप में कई बिट्स हैं, तो u + s गणितीय रूप से सही परिणाम देगा जब तक कि u + s ओवर- या अंडरफ्लो न हो। यदि यह अंडर-ओवरफ्लो होता है, तो परिणाम चारों ओर लपेट जाएगा, यानी, (u + s) mod 2^b , जहां b में बिट्स की संख्या है u और s । दूसरी ओर, यदि हस्ताक्षरित प्रकार अहस्ताक्षरित प्रकार के सभी मानों का प्रतिनिधित्व कर सकता है, तो अहस्ताक्षरित मान अहस्ताक्षरित प्रकार में परिवर्तित हो जाएगा।

C11 मानक मसौदे में प्रासंगिक खंड निम्नलिखित हैं:

• 6.2.5.9: बाइनरी ऑपरेशंस केवल अहस्ताक्षरित ऑपरेंड के साथ ओवरफ्लो नहीं हो सकता है; परिणाम मॉड्यूलो MAX + 1 , जहां MAX सबसे बड़ा प्रतिनिधित्व योग्य मूल्य है।
• 6.3.1.3: एक हस्ताक्षरित मूल्य s को देखते हुए, इसे अहस्ताक्षरित मूल्य s यदि s >= 0 , अन्यथा इसे s + MAX + 1 में बदल दिया जाता है।
• 6.3.1.8: हस्ताक्षरित और अहस्ताक्षरित ऑपरेंड [समान आकार के] अहस्ताक्षरित में परिवर्तित हो जाते हैं; एक अहस्ताक्षरित ऑपरेंड को एक हस्ताक्षरित प्रकार में बदल दिया जाता है यदि हस्ताक्षरित प्रकार अहस्ताक्षरित प्रकार के सभी मूल्यों का प्रतिनिधित्व कर सकता है

इसलिए, u + s (सी सिंटैक्स) का मूल्यांकन किया जाएगा

• (u + s) mod (M + 1) अगर s >= 0 ,
• (u + s + M + 1) mod (M + 1) अन्यथा।

ओवर- या अंडरफ्लो की अनुपस्थिति में, यह अभिव्यक्ति u + s मूल्यांकन करेगी जो सहज रूप से वांछित परिणाम है।

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

कुछ C++ प्रोग्रामर हैं (C++ के आविष्कारक सहित) जो हर जगह हस्ताक्षरित पूर्णांकों का उपयोग करने का प्रस्ताव कर रहे हैं, C++ Core दिशानिर्देश देखें लेकिन मैं इसे प्रवेश नहीं कहूंगा। "हर जगह हस्ताक्षरित पूर्णांक" नीति के साथ समस्या हैं

• न्यूनतम मूल्यों की जाँच: एक अहस्ताक्षरित पूर्णांक के साथ यह कई मामलों में न्यूनतम मान की जाँच करने के लिए अनिवार्य है, एक हस्ताक्षरित पूर्णांक के साथ यह अनिवार्य है; यह त्रुटि प्रवण है और सुरक्षा समस्याओं का कारण बन सकता है, उदाहरण के लिए CWE-839 _न्यूमेरिक रेंज तुलना बिना न्यूनतम जांच के देखें ।
• अतिप्रवाह: एक अहस्ताक्षरित अतिप्रवाह का एक अच्छी तरह से परिभाषित परिणाम होता है जबकि एक हस्ताक्षरित पूर्णांक अतिप्रवाह अपरिभाषित व्यवहार का गठन करता है।

आप a + b < a अभिव्यक्ति के साथ एक हस्ताक्षरित अतिप्रवाह की जांच करने का प्रयास कर सकते हैं लेकिन संकलक इसे बिना किसी चेतावनी के अनुकूलित कर सकता है, उदाहरण के लिए जीसीसी बग 30475 _assert(int+100 > int) अनुकूलित दूर_ 2007 से देखें। यह काम करेगा हालांकि अहस्ताक्षरित पूर्णांकों के साथ ( a अहस्ताक्षरित, b संभवतः हस्ताक्षरित और b में a रूप में अधिक से अधिक बिट्स हैं)। 2020 से _ऑप्टऑट - कंपाइलर अपरिभाषित व्यवहार अनुकूलन_ लेख देखकर, जीसीसी व्यवहार स्पष्ट रूप से नहीं बदला है।