Lapack: 표준 index-32 라이브러리와 함께 index-64 라이브러리를 설치할 수 있습니까?

안녕 Aisha, 그것은 나에게 완전히 이해되지만 다른 사람들로부터 피드백이 있는지 봅시다. 그러니 며칠만 기다리자. 제이

확실히, 그것은 좋은 계획처럼 들립니다.

세상에 @langou
당신은 너무 빠릅니다 : 심장 :

완전성을 위해, 나는 우리가 아직 해야 할 일들을 기록하고 있습니다:

• 32비트 API와 64비트 API가 공존할 수 있도록 헤더 이름을 지정하는 방법 알아보기
• 인쇄에 올바른 한정자를 사용하도록 printf/fprintf 문을 수정합니다.

첫 번째 요점을 해결하기 위한 제안을 환영합니다. 불행히도 "깨끗한" 솔루션이 없습니다.

파일 이름 지정을 처리하는 데 도움이 되는 몇 가지 질문

• cblas_f77.h 와 cblas_test.h 사이에 중복 정의가 많은 것 같습니다. 그게 정말 필요한가요?
• cblas_test.h 를 설치해야 합니까? 이름(및 사용된 파일)을 감안할 때 테스트 단계에서만 사용되는 것으로 가정합니다. 시스템 차원에서 이 파일을 설치하면 안 될까요?

안녕하세요 @epsilon-0

이것을 표준 설치와 공존할 수 있도록 하기 위해 염두에 두었던 몇 가지 사항 - 라이브러리 이름을 libblas64.so, libcblas64.so, liblapack64.so, liblapacke64.so로 지정하면 라이브러리 이름 사이에 충돌이 없습니다( 물론 libblas와 libblas64를 동시에 연결할 수는 없습니다.

당신은 PR #218을 찾고 있을지도 모릅니다. 이 PR의 저자는 Fedora Project의 Björn Esser입니다.

안녕하세요 @epsilon-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

(etc.) 그것이 .pc 파일이 말하고자 하는 바이며, 다른 헤더 파일 이름을 전달하는 것보다 훨씬 쉽습니다. 그것들은 아직 일관성이 없지만 수정하고 있습니다. 지금까지 사람들은 모든 참조 라이브러리를 귀찮게 하는 경우 배포판에서 해킹한 것 같습니다.

하지만 그 헤더에 대해 한 가지 질문이 있습니다.

cmake 빌드를 해킹하여 각 구성 요소를 개별적으로 빌드하고 다른 수정을 시도하고 있습니다(https://github.com/Reference-LAPACK/lapack/pull/556 참조). libblas.so 및 libblas64.so 라이브러리가 잘 빌드되고 헤더 디렉토리가 구성됩니다. 하지만 설치된 cblas.h 및 lapacke.h는 32비트 및 64비트 인덱싱 버전에서 동일합니다. 이것은 openblas와 상충합니다. 거기에 netlib 빌드에서 볼 수 없는 중요한 차이점이 있습니다.

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년 전에는 재미있었을 수도 있음) . 사람들은 프로덕션에서 최적화된 BLAS 라이브러리를 사용하기 때문에 사실상 표준은 사용자에게 공개하지 않는 것입니다. 참조, IMHO 및 ILP64 빌드에서 설치된 헤더에 대한 이러한 피드백은 64비트 라이브러리에 연결할 때 앱 충돌을 피하기 위해 펑키 플래그가 필요하지 않아야 합니다.

올바른 정수를 정의하기 위해 빌드 시 헤더를 수정하는 것이 올바른 솔루션이라는 데 동의합니까?

Btw, 설치된 cblas 구성 파일도 필요한 def에 대한 참조를 놓치고 있으므로 64비트 인덱스 빌드에 대해 손상된 것 같습니다. 하지만 사실, 나는 이것들을 전혀 설치하지 않는 것을 고려합니다. 그것들은 .pc 파일과 중복되며 BLAS_LIBS etal을 통해 패키지 프로그램 선택을 수락하도록 cmake를 사용하는 종속 패키지를 설득하기가 더 어려울 수 있습니다.

추신: Intel MKL에는 중앙 스위치 -DMKL_ILP64 를 설정할 수 있습니다. 사소한 설정을 상상해
include/intel-mkl64/cblas.h

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

일반적인 계획에 맞게. 또한 이상한 netlib 정의에 대해 동일한 정의를 BLAS_INCLUDES에 넣을 수 있습니다. 더 나은 것은 무엇입니까? 인텔처럼 하고 싶습니까, 아니면 OpenBLAS처럼 하고 싶습니까?

올바른 정수를 정의하기 위해 빌드 시 헤더를 수정하는 것이 올바른 솔루션이라는 데 동의합니까?

예. 나는 그것에 동의하고 전체 헤더를 복제하지 않는 솔루션을 선호합니다. 더 깨끗한 것 같아요.

Btw, 설치된 cblas 구성 파일도 필요한 def에 대한 참조를 놓치고 있으므로 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으로 대체해야 하며, 결과 헤더는 현재 빌드에 설치됩니다.

(Btw.: long은 Windows에서 작동하지 않습니다. stdint가 있는 모든 플랫폼에서 long long ... 또는 int64_t입니다.)

오른쪽. 방금 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에 연결될 수 있음)에서 처리됩니다.

나는 이것이 당신이 의미한 것이 _아닙니다_ 라는 의심이 있지만, 나는 그것이 더 낫다고 확신시키고 싶습니다;-)

/foo/include/cblas.h에 'the' 헤더를 배치하고 WeirdNEC를 정의함으로써만 /foo/include/netlib64/cblas.h에 헤더를 포함하도록 하여 헤더를 복제하지 않으려고 시도할 수 있지만, 이는 64 비트 및 32비트 패키지는 공통 헤더 파일을 공유하므로 패키징이 지저분합니다. 각각이 파일을 별도의 장소/이름에 넣는 것이 훨씬 좋습니다. #include <cblas.h> 행을 교체하고 싶지 않기 때문에 이름은 cblas.h로 유지해야 합니다.

편집: 또한 cblas.h가 ../cblas.h를 포함하는 것은 그 자체로 지저분합니다. 또한 cmake에 대한 _one_ 헤더 설치 디렉토리를 정의합니다. 기본적으로 /foo/netlib64/include가 아니라 /foo/include입니다. 이 기본값을 변경하지 않을 것입니다. 패키지 작성자는 다음과 같이 하위 디렉토리를 지정해야 합니다(pkgsrc에서 BSD make):

.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)

(댓글은 위에 설탕입니다.)

CMake 빌드가 생각하기에 훨씬 덜 성숙하다는 느낌이 듭니다. 프로젝트가 기본 빌드로 사용하는 것에 대해 진지한가요? 아니면 그냥 드라이브 바이 기여인가요? 저는 예전 스타일의 Makefile을 수정하고 싶고, 소란도 덜었습니다. 하지만 이제는 CMake를 수정하는 데 너무 많은 시간을 할애하여 어쨌든 싫어합니다. 그래서 나는 그것을 끝내고 싶습니다.

나는 지금 포기해야합니다 ... 위에 표시된대로 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로, 또한 최상위 CMakeLists.txt에서 @HAVE_ILP64@ 를 1 또는 0으로 정의했습니다. 그러나 나는 평생 동안 더 높은 수준의 CMakeLists.txt에 있는 설치 항목을 생성된 헤더 또는 ${LAPACK_BINARY_DIR}/include 에서 동일한 이상한 복사본을 설치하는 방법을 알아낼 수 없습니다(정말? A 소스 트리 내에서 복사하시겠습니까?)

매크로 append_subdir_files는 무엇을 해야 합니까? 헤더 경로에 접두사 사본을 추가하는 것 같습니다. 소스 헤더 파일에 대한 경로가 충분하지 않거나 너무 많습니다. HERE에서 THERE로 헤더 파일을 설치하고 싶습니다. 젠장.

지식이 있는 사람이 여기에서 도움을 줄 수 있습니까? 내일이면 알 수 있을 것 같지만, 감정적 안도감을 위해 현실 세계에서 무언가를 부수지 않고는 확신할 수 없습니다.

예. 나는 그것에 동의하고 전체 헤더를 복제하지 않는 솔루션을 선호합니다. 더 깨끗한 것 같아요.

이것은 나에게 모호합니다. 더 깨끗한 솔루션은 무엇입니까? 제가 지금 준비하고 있는 것은 다음과 같습니다.

#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으로 대체해야 하며, 결과 헤더는 현재 빌드에 설치됩니다.

(Btw.: long은 Windows에서 작동하지 않습니다. stdint가 있는 모든 플랫폼에서 long long ... 또는 int64_t입니다.)

오른쪽. 방금 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에 연결될 수 있음)에서 처리됩니다.

나는 이것이 당신이 의미한 것이 _아닙니다_ 라는 의심이 있지만, 나는 그것이 더 낫다고 확신시키고 싶습니다;-)

죄송합니다. 설명하겠습니다. 처음에는 원래 헤더 cblas.h 하고 include/netlib64/cblas.h 및 include/netlib/cblas.h 를 다음과 같이 만드는 아이디어가 좋았습니다.

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

/foo/include/cblas.h에 'the' 헤더를 배치하고 WeirdNEC를 정의함으로써만 /foo/include/netlib64/cblas.h에 헤더를 포함하도록 하여 헤더를 복제하지 않으려고 시도할 수 있지만, 이는 64 비트 및 32비트 패키지는 공통 헤더 파일을 공유하므로 패키징이 지저분합니다. 각각이 파일을 별도의 장소/이름에 넣는 것이 훨씬 좋습니다. #include <cblas.h> 행을 교체하고 싶지 않기 때문에 이름은 cblas.h로 유지해야 합니다.

편집: 또한 cblas.h가 ../cblas.h를 포함하는 것은 그 자체로 지저분합니다. 또한 cmake에 대한 _one_ 헤더 설치 디렉토리를 정의합니다.

하지만 예, 한 헤더에 다른 헤더가 포함되어 있으면 include/netlib64 및 include 를 포함 디렉토리로 사용해야 합니다.

기본적으로 /foo/netlib64/include가 아니라 /foo/include입니다. 이 기본값을 변경하지 않을 것입니다. 패키지 작성자는 다음과 같이 하위 디렉토리를 지정해야 합니다(pkgsrc에서 BSD make):

.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}

그것은 나에게 좋은 것 같다. 따라서 컴파일러 플래그를 _추측_할 필요 없이 LAPACK을 빌드하는 대안만 추가하면 됩니다. 그러나 현재의 방식도 효과가 있을 것입니다.

(Btw.: long은 Windows에서 작동하지 않습니다. stdint가 있는 모든 플랫폼에서 long long ... 또는 int64_t입니다.)

알아 둘만 한. BLAS++ 및 LAPACK++는 long long 대신 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

(long vs. int64는 다른 문제지만, 저는 BLAS++처럼 그 변경을 하는 데 찬성합니다)

젠장, `#include ".../cblas.h"가 다른 들여쓰기된 헤더만 찾을 것이라고 가정하는 것이 안전한지 확신할 수 없습니다. C 표준은 검색 순서가 구현에 따라 정의되며 반드시 현재 헤더와 관련이 있는 것은 아니라고 말하는 것 같습니다. 패키저로서의 주요 문제는 해당 공통 헤더에 대해 별도의 패키지가 필요하거나 64비트 패키지가 32비트 패키지에 종속되도록 해야 한다는 것입니다. 이것은 짜증날 것입니다.

나중에 업스트림 코드에 대한 변경 사항을 해결하기 위해 지금 pkgsrc에 대한 이러한 변경을 진행하고 싶습니다. 어떤 헤더( -DNETLIB_INDEX_BITS=64 ?)와 함께 명시적으로 32비트 인덱스 또는 64비트 인덱스를 강제 실행하는 새로운 기호에 대해 논의할 수 있습니다.

우리가 의도한 솔루션이 이것에 대한 동의를 얻을 수 있습니까?

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

그리고

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

LAPACK 코드의 각 빌드는 최소한 기본적으로 사용자가 아무것도 정의하지 않고 설치된 라이브러리와 일치하는 헤더를 생성합니다. 좋아요?

그런 다음 pkgsrc의 다음 릴리스(마감 임박) 전에 이를 미룰 수 있으며, 새 LAPACK 릴리스와 함께 여기에 무언가를 병합한 후 패치를 삭제할 수 있도록 해당 구현의 세부 사항에 대해 더 논의할 수 있습니다. 이 변경으로 일반 Makefile 빌드도 수정이 필요하지만 CMake 빌드를 사용할 때 _my_ 패치에는 아직 수정이 필요하지 않습니다.

(그 이상한 CMake 빌드를 제출로 이기려고 할 때 어떻게든 내 성질을 확인해야 합니다. 여기에서 빌드 디렉토리 주변의 헤더 복사본을 섞은 다음 설치를 위해 찾을 수 없습니다. 또는 우리에게 도움이 되는 깨진 .cmake 파일에 대해 결정하십시오. 아마도 설치에서 삭제하십시오 ... 우리는 pkg-config를 얻었습니다!)

아무것? 이것이 우리가 사용하는 주요 구현인 openblas에 의해 설정된 예이기 때문에 실제로 다른 솔루션에 대한 기회가 많지 않다는 것을 인정해야 합니다. 인텔이 64비트/32비트 인덱스 헤더에 대한 하위 디렉토리를 갖도록 설득하는 것도 상상할 수 있습니다. 그렇지 않으면 나는 그것들을 제공하는 간단한 패키지를 만듭니다.

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

현재, cblas와 cblas64가 동일한 헤더를 설치하는 재미있는 -DWeirdNEC -DHAVE_LAPACK_CONFIG_H -DLAPACK_ILP64 라인이 있는 빌드를 제공하기 위해 pkgsrc에 기계를 추가했습니다. 그대로 유지될 수 있지만 여전히 빌드 ABI와 일치하도록 헤더를 설정하는 것이 합리적이라고 생각합니다.

@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 와 논의했고 그도 이것이 좋은 해결책이 될 것이라고 확신했습니다.

(long vs. int64는 다른 문제지만, 저는 BLAS++처럼 그 변경을 하는 데 찬성합니다)

오른쪽. 이것은 다른 문제에서 다루어져야 합니다.

나중에 업스트림 코드에 대한 변경 사항을 해결하기 위해 지금 pkgsrc에 대한 이러한 변경을 진행하고 싶습니다. 어떤 헤더( -DNETLIB_INDEX_BITS=64 ?)와 함께 명시적으로 32비트 인덱스 또는 64비트 인덱스를 강제 실행하는 새로운 기호에 대해 논의할 수 있습니다.

우리가 의도한 솔루션이 이것에 대한 동의를 얻을 수 있습니까?

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

그리고

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

예. 앞으로 나아가서 PR을 제안할 수 있을 것 같아요, 감사합니다! 저는 개인적으로 NETLIB_INDEX_BITS 와 같은 새로운 기호가 완전히 의미가 있다고 생각합니다. 기본값이 32로 유지되고 -DWeirdNEC -DNETLIB_INDEX_BITS=64 의미하는지 확인합니다.

LAPACK 코드의 각 빌드는 최소한 기본적으로 사용자가 아무것도 정의하지 않고 설치된 라이브러리와 일치하는 헤더를 생성합니다. 좋아요?

나에게 좋은 소리.

그런 다음 pkgsrc의 다음 릴리스(마감 임박) 전에 이를 미룰 수 있으며, 새 LAPACK 릴리스와 함께 여기에 무언가를 병합한 후 패치를 삭제할 수 있도록 해당 구현의 세부 사항에 대해 더 논의할 수 있습니다. 이 변경으로 일반 Makefile 빌드도 수정이 필요하지만 CMake 빌드를 사용할 때 _my_ 패치에는 아직 수정이 필요하지 않습니다.

확인! 아마도 2021년 2학기에 LAPACK이 출시될 것입니다. 그리고 네, Makefile은 그에 따라 조정되어야 하며, 저는 기꺼이 도와드리겠습니다.

이것은 다소 관련이 있습니다. 우리는 netlib CBLAS의 헤더가 netlib에 의해서만 제공되는 것이 아니라는 사실을 잊어서는 안 됩니다. NumPy는 항상 자체 헤더를 사용합니다.

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);

문제를 일으킬 수 있는지 궁금합니다. Netlib의 경우 인덱스 유형이 하나만 있는 반면 다른 구현에서는 인덱스 함수에 대해 다른 반환 값 유형을 사용합니다. OpenBLAS는 예를 설정합니다. 그들은 isamax가 unsigned size_t를 반환한다고 말하지만 C 래퍼는 실제로 부호 있는 정수를 반환하는 Fortran 함수를 호출합니다(편집: 64에서 부호 없는 64비트 변수에 대한 전달 참조에 부호 있는 32 또는 64비트 정수 값을 쓰는 서브루틴 비트 시스템).

참조 구현에 이에 대한 의견이 있습니까? size_t 값은 항상 isamax()에서 음수가 아닌 반환값을 유지할 수 있기 때문에 실제 문제는 _추측_입니다. 하지만 퀴퀴한 냄새가 난다. (편집: size_t가 32비트인 32비트 시스템에서 64비트 인덱스로 빌드할 수 있습니다. 그런 다음 오버플로가 발생했습니다. 게다가 size_t * 를 int * 로 캐스팅하는 불편함도 있습니다.)

최적화된 구현이 거기에서 size_t를 결정한 것 같기 때문에 참조가 그 사실을 받아들이고 따라야 합니까?

그리고 실제로 numpy를 참조 cbla와 연결하는 것이 얼마나 위험한가요?

OpenBLAS는 예를 설정합니다. (...)
최적화된 구현이 거기에서 size_t를 결정한 것 같기 때문에 참조가 그 사실을 받아들이고 따라야 합니까?

나는 확실히 numpy(또는 그 문제에 대해 mkl 등)에 대해 말할 수는 없지만 OpenBLAS가 어떤 형태로든 규범적이라고 주장하는 것을 주저하고 싶습니다. .

확신하는. 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의 일부도 아닌 함수 호스트를 정의하는 MKL 및 OpenBLAS를 봅니다.

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 vs int 는 64비트 시스템에서 심각한 문제인 것 같습니다. 이것은 어떤 식으로든 해결되어야 합니다. Netlib 방식이 합리적인 것 같습니다. 인덱스에 사용되는 것과 같은 유형입니다. 모든 포트란 루틴은 결국 이와 같이 호출됩니다.

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 소스에서 이 참조 구현 이외의 다른 구현을 찾지 못했습니다. 그들은 그런 외부 유형을 변경하는 바보입니까, 아니면 매우 기본적인 것을 간과하고 있습니까? 실제로 이러한 기능을 사용하는 사람이 있습니까?

안녕 모두, 참조 BLAS, 참조 CBLAS, 참조 LAPACK, 이 프로젝트의 두 가지 주요 추진력은 (1) 수치 알고리즘 및 (2) 공통 인터페이스 정의, 참조 구현 및 이를 위한 테스트 제품군입니다. 이 프로젝트에 참여하는 모든 사람이 다른 프로젝트(OpenBLAS, MKL 등)에서 소프트웨어 엔지니어링, 소프트웨어 배포 모범 사례 등에 대해 보고 배우는 것을 기쁘게 생각합니다. 우리는 이러한 프로젝트에서 배울 점이 많습니다. (그리고 우리는 또한 다른 수치 선형 대수학 프로젝트에서 많은 것을 배웁니다!) 어쨌든: 참조 BLAS, CBLAS, LAPACK은 CMake 패키징, 인터페이스에서 약간의 개선을 사용할 수 있으며 OpenBLAS(예:)에 더 나은 프로세스가 있는 경우 우리 모두는 이 모델로 나아가는 데 찬성합니다.

컨텍스트를 추가하기 위해 CBLAS는 1996년부터 2000년까지 BLAS를 재방문하기 위해 일한 위원회(Basic Linear Algebra Subprograms Technical Forum)에서 탄생했으며, 이 위원회의 일부로 BLAS용 C 인터페이스를 정의했습니다. 보다:
http://www.netlib.org/blas/blast-forum/
특히 참조:
http://www.netlib.org/blas/blast-forum/cinterface.pdf
저는 LAPACK에서 제공하는 CBLAS가 25년 전 Basic Linear Algebra Subprograms Technical Forum에서 정의한 인터페이스의 구현이라고 믿습니다.

CBLAS를 개선하기 위한 제안이 있으면 함께 보내십시오. 나는 이것을 다양한 이해 관계자에게 전달할 수 있습니다.

포인터 주셔서 감사합니다. 따라서 관련 부분은 해당 사양에서 B.2.2인 것 같습니다. BLAS_INDEX 일반적으로 size_t 이지만 다음에 사용되는 (서명된) Fortran 정수 유형과 동일하도록 선택될 수도 있습니다. 인덱싱. 그것은 구현에 달려 있습니다.

따라서 널리 사용되는 최적화된 구현은 size_t 선택했고 Netlib 참조는 Fortran에 사용하는 것과 동일한 정수를 선택한 것 같습니다. 나는 lib를 사용하는 다양한 프로젝트에서 cblas.h의 사본을 볼 수 있습니다.

#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 ... WeirdNEC의 CBLAS_INDEX 스위치가 64비트 빌드 이전에 있었던 것을 알 수 있습니다. 와우, 최근 커밋입니다. 이제 size_t 가 2015년까지 참조 cblas.h에 있었고 83fc0b48afd1f9a6d6f8dddb16e69ed7ed0e7242가 이를 변경하고 WeirdNEC 정의를 도입했음을 알 수 있습니다. 이게 이렇게 최근일줄은 상상도 못했어요! 혼란스럽습니다.

또한 이전 버전의 cblas.h 가 int CBLAS_INDEX 포트란 호출에 전달되었음을 알 수 있습니다. CBLAS_INDEX 를 정수 유형으로 일관되게 사용하고 Fortran 부분에서 32비트 또는 64비트용 스위치를 사용하면 이것이 올바른 것 같습니다.

그러나 size_t 로 cblas.h의 이전 버전을 상속했지만 참조에서 현재 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 값을 0으로 초기화하면 도움이 되지만 아마도 리틀 엔디안의 경우에만 해당될 것입니다. 아무도 이것 때문에 곤경에 빠지지 않습니까? 나는 뭔가를 놓치고 있어야합니다.

결론적으로:

1. 참조 CBLAS는 먼저 반환 값으로 size_t 를 가졌습니다.
2. 그러나 Fortran에 대한 실제 호출에서는 int를 사용했습니다.
3. 다운스트림(최적화된 BLAS, CBLAS 사용자)은 이전 버전의 헤더로 실행됩니다.
4. 참조 CBLAS는 특정 시스템에 대한 WeirdNEC 해킹을 도입하여 size_t를 int 또는 long으로 대체합니다(Fortran 측과 일치?!)
5. 64비트 참조 CBLAS 인터페이스는 Fortran 기본 정수에 대해 모든 곳에서 CBLAS_INDEX 사용하여 그 위에 빌드됩니다.
6. 다운스트림은 64비트 지원으로 자체 작업을 수행했지만 항상 size_t인 CBLAS_INDEX 에서 분리했습니다.
7. 다운스트림은 CBLAS_INDEX 를 사용하여 기본 정수를 예상하는 Fortran을 호출하는 CBLAS 래퍼를 상속합니다.

결과적으로 멋진 파손처럼 들립니다. 헤더와 코드가 분기되었습니다. 아직 아무도 문제를 눈치채지 못한 이유는 무엇입니까? 아니면 isamax와 친구를 위한 참조 CBLAS 래퍼 코드가 실제로 사용되지 않는 부분을 놓쳤습니까?

OpenBLAS는 최소한 Reference-LAPACK의 CBLAS 래퍼 코드를 사용하지 않습니다.

@martin-frbg 반갑습니다. cblas_isamax()에 대한 실제 계산에 size_t가 전달되는 방법을 보여주는 x86-64에 대한 코드 경로를 지적할 수 있습니까? 특정 커널 구현을 찾았지만 일반적인 경우는 잘 모르겠습니다.

아무도 실제로 (size_t*) 를 Fortran 인터페이스에 전달하지 않는다는 것을 아는 것이 좋습니다.

확실히 프로젝트가 가정하는 것은 좋지 않습니다.

size_t cblas_isamax(…)

실제 라이브러리가 int 또는 long(또는 int64_t)을 반환 값으로 제공할 때. 대부분의 경우 64비트 레지스터의 값으로 작동할 수 있지만 좋지 않습니다. 구현에서 이를 수정할 수 있습니까? 사람들은 CBLAS_INDEX 의 일관된 사용에 대해 지난 5년 동안 Netlib의 예를 선택하지 않았습니다.

관련 코드는 OpenBLAS/인터페이스에 있습니다. 예를 들어 interface/imax.c는 CBLAS가 정의될 ​​때 cblas_isamax()로 컴파일되며 호출 그래프에는 Fortran 코드가 포함되지 않습니다.

오 굿. 따라서 실제로 문제가 되는 한 가지 경우는 라이브러리에 맞지 않는 cblas.h 복사본을 사용하는 프로젝트에 의존하는 것입니다.

NumPy(및 SciPy)에서 cblas_isamax() 및 친구의 실제 사용법을 찾지 못하므로 이것은 이론적인 문제일 수 있습니다. 그럼에도 불구하고 수정되어야 합니다. 그래서:

1. 다른 것들은 크기 반환과 인덱스 인수 모두에 대해 int32_t/int64_t를 사용하는 Netlib 예제를 따릅니다.
2. Netlib는 다른 사람들과 마찬가지로 이러한 수익에 대해 동굴 안으로 들어가 size_t 로 되돌아갑니다.

이건 따로 논의할 문제인가요? 그러나 32비트 또는 64비트 라이브러리 선택과 관련이 있습니다.

추신: API의 열거형이 좋은 아이디어인지(함수 인수 및 구조체 멤버에 대한 실제 데이터 유형으로) 여전히 그 아래에서 사용되는 정수를 변경하는 컴파일러 옵션이 있는지 확신할 수 없습니다. 실제로 관련이 없지만 그럼에도 불구하고 나를 불안하게 만듭니다.

생각하면 할수록 옵션 2: API에 size_t가 아주 오랫동안 있었습니다. 그런 다음 Netlib는 해당 size_t를 int 또는 long으로 변경했습니다. Fortran 코드와 더 잘 일치하거나 더 일관성이 있는 것과 관계없이 size_t는 API로 설정되었고 Netlib 참조는 이를 깨뜨렸습니다.

변경 사항에 대한 PR을 열어야합니까?

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에서 우리는 이제 기본적으로 "Netlib를 나사로, 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 모든 요소를 ​​인덱싱할 수 있음을 보장합니다(참조). cppference.com: size_t .

편집: size_t가 32비트인 32비트 시스템에서 64비트 인덱스로 빌드할 수 있습니까? 그런 다음 오버플로가 발생했습니다.

32비트 시스템에는 4GB 이상의 가상 메모리가 있을 수 있지만(Linux는 이를 지원함) 단일 32비트 프로세스는 4GB 이상에 액세스할 수 없기 때문입니다. 즉, 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

내가 이것을 조사했을 때, 나는 C++ 컨테이너 인덱스에 대해 서명되지 않은 유형을 사용하는 것이 역사적인 오류라는 사실을 우연히 알게 되었고, 아마도 size() 메서드의 반환 유형까지도 빠르게 서명된 숫자와 서명되지 않은 숫자를 혼합하게 되므로 어떤 방법으로. Netlib의 현재 상태는 크기와 인덱스에 대해 항상 서명된 유형을 사용하여 자체적으로 일관성이 있지만 물론 malloc() 와 일치하지 않습니다. 32비트(또는 이론상 64비트).

내가 작성한 코드에서 결국 인덱스를 함수 호출에 대한 오프셋으로 넘겨주는 부분에 대해 스스로 궁금합니다. 인덱스는 부호가 없고 오프셋은 부호가 있습니다. -unsigned_value 인해 컴파일러(MSVC)가 혼동되는 것을 제외하고는 변환 시 발생할 수 있는 오버플로에 대해 항상 걱정해야 한다는 의미입니다.

그러나 어쨌든 malloc()과 친구들에게 넘겨줄 메모리 크기를 계산하는 것이라면 size_t는 자연스러운 것이며 이전에 CBLAS에 있었습니다.

코드의 현재 상태와 관련된 가능한 문제에 대해 빌드에서 공급업체 cblas.h 와 일치하지 않습니다.

32비트 시스템에는 4GB 이상의 가상 메모리가 있을 수 있지만(Linux는 이를 지원함) 단일 32비트 프로세스는 4GB 이상에 액세스할 수 없기 때문입니다. 즉, 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비트 시스템(ARM의 일부 형식)을 상상해 보십시오. 원하는 값의 절반을 반환할 수 있을까요?

32비트 프로그램에서는 64비트 인덱스가 필요한 비희소 데이터로 작업할 수 없습니다. 그러나 _at_least_가 잘못된 결과를 제공하는 일치하지 않는 함수 호출을 할 수 있다는 것은 건강에 해로운 것 같습니다.

x86 Linux(x86-64 시스템의 경우 gcc -m32 에서 빠른 테스트를 수행했습니다. 상위 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비트를 조용히 0으로 만들기 위해 다소 잘 정의됩니다. 그러나 약간 이상한 함수 정의를 사용하는 재미가 있습니다.

$ 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비트는 실제로 실제 코드에서 0이 될 것이라고 생각합니다. 하지만 누가 알겠습니까... 컴파일러는 호출자가 모든 플랫폼에서 하위 32비트 이상을 사용하지 않을 것으로 예상합니다... 거기에 쓰레기를 저장할 수도 있습니다.

그래서 ... Netlib를 다시 size_t로 반환 값으로 옮기는 데 동의합니까?

이 모든 귀중한 의견에 감사드립니다!

이 주제에 대해 @langou와 약간 논의했습니다. 여기에서 논의한 내용을 바탕으로 제 제안은 다음과 같습니다.

별도의 PR에서:

1. CBLAS_INDEX와 CBLAS_INT라는 두 개의 정수 정의를 사용하는 cblas.h 로 다시 이동합니다. 이것이 MKL(CBLAS_INDEX 및 MKL_INT) 및 OpenBLAS(CBLAS_INDEX 및 blasint)에서 발생합니다. CBLAS_INDEX는 i*amax 의 반환에만 사용됩니다. 이를 통해 다른 BLAS와 호환되는 ABI를 복원합니다.
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 Scientific Library 및 Numpy는 모두 기본적으로 size_t 를 사용합니다.
• BLAS용 C 인터페이스(https://www.netlib.org/blas/blast-forum/cinterface.pdf)는 일반적으로 CBLAS_INDEX = size_t 임을 나타냅니다.

동의하십니까? 그렇게 하면 PR을 열 수 있습니다. 또는 @drhpc 가 그렇게 하고

나는 동의한다. 그리고 PR을 진행해주세요.

@mgates3 은 Slate 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비트 시스템(ARM의 일부 형식)을 상상해 보십시오. 원하는 값의 절반을 반환할 수 있을까요?

게임 오버입니다. 32 비트 팔의 CPU에서 네 개의 32 비트 값이 전달 될 수 레지스터에 반환, 64 비트의 값은 두 개의 연속 된 레지스터를 차지 섹션 6.1.1.1를 참조 지지대 Architecture_에 대한 _Procedure 호출 표준 . 하나의 레지스터에 쓰는 대신 호출 수신자는 64비트 정수로 두 개의 레지스터를 복잡하게 만듭니다. 이것은 분명히 문제입니다. 호출자가 매개변수에 대한 레지스터를 모두 사용하는 즉시 스택이 사용됩니다. 스택 정렬은 32비트이지만 32비트를 읽거나 쓰는 대신 수신자가 64비트를 씁니다. 다시 말하지만, 이것은 게임이 끝났고 이 문제(스택 읽기/쓰기 크기의 불일치)는 어느 시점에서 모든 명령어 세트 아키텍처에서 문제를 일으킬 것입니다.

• Arm ABI 문서

내가 작성한 코드에서 결국 인덱스를 함수 호출에 대한 오프셋으로 넘겨주는 부분에 대해 스스로 궁금합니다. 인덱스는 부호가 없고 오프셋은 부호가 있습니다. 컴파일러(MSVC)가 -unsigned_value로 혼동되는 것을 제외하고는 변환 시 발생할 수 있는 오버플로에 대해 항상 걱정해야 한다는 의미입니다.

아니요, C 및 C++ 뒤에 있는 표준 위원회는 다음과 같은 경우 코드가 명백한 방식으로 동작하도록 합니다. 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 (C 구문)은 다음과 같이 평가됩니다.

• (u + s) mod (M + 1) 경우 s >= 0 ,
• 그렇지 않으면 (u + s + M + 1) mod (M + 1) 입니다.

오버플로 또는 언더플로가 없는 경우 이 표현식은 직관적으로 원하는 결과인 u + s 평가됩니다.

내가 이것을 조사했을 때, 나는 C++ 컨테이너 인덱스에 대해 서명되지 않은 유형을 사용하는 것이 역사적인 오류라는 사실을 우연히 알게 되었고, 아마도 size() 메서드의 반환 유형까지도 빠르게 서명된 숫자와 서명되지 않은 숫자를 혼합하게 되므로 어떤 방법으로.

모든 곳에서 부호 있는 정수를 사용할 것을 제안하는 일부 C++ 프로그래머(C++의 발명가 포함)가 있습니다. C++ 핵심 지침을 참조하십시오. 그러나 나는 이것을 승인이라고 부르지 않을 것입니다. "모든 곳에서 부호 있는 정수" 정책의 문제는 다음과 같습니다.

• 최소값 확인: 부호 없는 정수의 경우 많은 경우 최소값을 확인하는 것이 불필요하고 부호 있는 정수의 경우 필수입니다. 이것은 오류가 발생하기 쉽고 보안 문제를 일으킬 수 있습니다(예: CWE-839 _최소 검사 없는 숫자 범위 비교_ 참조) .
• 오버플로: 부호 없는 오버플로는 결과가 잘 정의된 반면 부호 있는 정수 오버플로는 정의되지 않은 동작을 구성합니다.

a + b < a 표현식을 사용하여 서명된 오버플로를 확인하려고 시도할 수 있지만 컴파일러는 경고 없이 이를 최적화할 수 있습니다. 예를 들어 GCC bug 30475 _assert(int+100 > int) optimized away_ from 2007. 이 작동합니다. 하지만 부호 없는 정수를 사용합니다( a unsigned, b 가능 부호 및 b 최대 a ). 2020년의 _OptOut – 컴파일러 정의되지 않은 동작 최적화_ 기사를 보면 GCC 동작이 변경되지 않은 것 같습니다.