Lapack: LAPACK에 대한 프로세서 요구 사항

언더플로 자체가 진정한 문제는 아닙니다. 언더플로 후 알고리즘은 언더플로 경향이 적은 CABS1로 전환됩니다. 생성하는 문제는 TEMP가 정확히 단일하지 않아 Z에서 반올림이 발생한다는 것입니다.

가능한 솔루션은 CABS1을 사용하여 사전 스케일링한 다음 ABS를 사용하여 수정하는 것입니다(첫 번째 스케일링으로 인해 ABS는 더 이상 오버플로되지 않아야 함). (내 컴퓨터에서 언더플로가 발생하지 않으므로 테스트할 수 없습니다.)

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

나는 테스트가 인기 있는 FORTRAN 컴파일러 세트에 대해 성공하도록 확실히 설계되었다고 생각합니다. 왜냐하면 그것이 단순히 실행되는 방식이기 때문입니다. 언더/오버플로를 예측하는 것은 매우 어렵습니다. 적어도 제 경우에는 이러한 서브루틴을 (인기 있는 컴파일러를 사용하여) 철저히 테스트하고 발견한 오버플로/언더플로를 수정하여 설계되었습니다.

감사합니다! 이것은 매우 도움이 됩니다.
CABS1을 사용하여 언더플로에서 복구를 시도했습니다. 그러나 우리의 시도는 충분하지 않았습니다. 귀하의 제안이 훨씬 더 나은 것 같습니다. 사용 ...

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

... 이 반복은 성공적으로 완료됩니다(ABS()에 대해 SSE 레지스터를 사용하는 경우에도).

나는 테스트가 인기 있는 FORTRAN 컴파일러 세트에 대해 성공하도록 확실히 설계되었다고 생각합니다. 왜냐하면 그것이 단순히 실행되는 방식이기 때문입니다. 언더/오버플로를 예측하는 것은 매우 어렵습니다. 적어도 제 경우에는 이러한 서브루틴을 (인기 있는 컴파일러를 사용하여) 철저히 테스트하고 발견한 오버플로/언더플로를 수정하여 설계되었습니다.

테스트 스위트는 엄청난 도움이 됩니다! 대략적인 추정은 테스트의 1% 미만이 이와 유사한 오버플로 문제(컴파일러를 사용할 때)의 영향을 받는다는 것입니다. 언더/오버플로에 대한 테스트를 더욱 강력하게 만드는 것은 LAPACK을 더 많은 플랫폼으로 가져오는 데 도움이 될 수 있습니다. 위의 (실패한) 시도는 한 가지 예일 뿐이며, 우리 측에서 수정 사항을 거의 찾아낼 수 없음을 분명히 보여줍니다. 여러 관련 문제를 시작하기 전에 그러한 여정에 관심이 있는지 여부와 좋은 접근 방식이 무엇인지에 대한 토론을 시작하고 싶습니다.

@hokb 및 @thijssteel 개선에 감사드립니다! 수정 사항으로 PR을 작성해야합니까 아니면 그렇게 할 의향이 있습니까, @hokb?

프로젝트에 대한 제한된 경험을 감안할 때 귀하의 노력과 PR을 냄비의 지침으로 삼을 기회에 감사드립니다. 우리의 미래 PR... (괜찮다면?)

안녕하세요 @hokb 님

사양을 좀 찾아봤는데 아직 안나오네요. 모든 링크도 감사하겠습니다. 미리 감사드립니다!

나는 아무 것도 지정되지 않았는지 확실하지 않습니다.

컴파일러는 .NET CLR을 대상으로 합니다. 그것의 JIT는 ABS(TEMP)에 대해 SSE 레지스터를 사용하기로 결정하고, 이는 크기의 중간 계산에서 언더플로로 이어집니다. Ifort(또 다른 예)는 이 상황에서 부동 소수점 레지스터를 사용하므로 언더플로가 발생하지 않습니다(길이가 더 길기 때문에: 80비트). 런타임에 컴파일러/프로세서에서 필요한 정밀도/숫자 범위와 관련하여 LAPACK에서 무엇을 기대해야 하는지에 대한 명확한(어) 그림을 얻으려고 합니다.

굵은 문장: 모든 계산이 IEEE 64비트 산술을 사용하여 수행되면 LAPACK이 작동해야 합니다.

LAPACK은 80비트 레지스터가 언제든지 계산에 도움이 될 것으로 기대하지 않습니다. 알고리즘은 64비트 산술을 염두에 두고 설계되었습니다. 이제 @thijssteel이 언급한

우리는 이러한 문제를 해결하기 위한 여정에서 체계적인 조치를 취하지 않았습니다. 일반적으로 우리는 알고리즘이 테스트 스위트를 통과했을 때 충분히 만족하며, 80비트 레지스터의 도움이 있다면 그렇게 될 것입니다.

배정밀도에 대한 모든 테스트는 최소 64비트 레지스터를 요구하도록 설계되었습니까? 아니면 오늘날 사용 가능한 인기 있는 FORTRAN 컴파일러 세트에 성공할 수 있도록 설계되었습니까? (위의 문제(및 유사한 다른 문제)의 첫 번째 경우에 주의가 필요할 수 있습니다. 문제를 제기해야 합니까?)

대략적인 추정은 테스트의 1% 미만이 이와 유사한 오버플로 문제(컴파일러를 사용할 때)의 영향을 받는다는 것입니다.

어머. 1%? 무서운 숫자입니다.

테스트는 언더플로 및 오버플로 영역을 중심으로 많이 테스트 중이므로 사용자의 코드보다 이 문제를 트리거하는 측면에서 테스트가 훨씬 더 가능성이 높지만 여전히 그럴 것으로 예상할 수 있습니다.

언더/오버플로에 대한 테스트를 더욱 강력하게 만드는 것은 LAPACK을 더 많은 플랫폼으로 가져오는 데 도움이 될 수 있습니다.

더 많은 플랫폼으로의 이식성은 실제로 하나의 관심사입니다. 또 다른 관심은 GMP와 같은 패키지를 사용하여 정밀도를 확장하는 것입니다. 여기서 정밀도는 계산 전반에 걸쳐 고정됩니다. (예를 들어 당신은 256비트 생각이고 300비트 레지스터는 당신을 도울 수 없습니다.)

위의 (실패한) 시도는 한 가지 예일 뿐이며, 우리 측에서 수정 사항을 거의 찾아낼 수 없음을 분명히 보여줍니다. 여러 관련 문제를 시작하기 전에 그러한 여정에 관심이 있는지 여부와 좋은 접근 방식이 무엇인지에 대한 토론을 시작하고 싶습니다.

예. 우리는 관심이 있습니다. 하지만 우리는 할 수 있는 만큼만 할 수 있습니다. 그리고 우리 접시에 많이 있습니다. 그래서 우리는 이 문제를 한 번에 하나씩 처리하고 우리가 얼마나 멀리 갈 수 있는지 알 수 있습니다.

어쨌든 GitHub에 문제를 게시하는 것은 항상 좋은 생각입니다. 문제에 대한 인식을 제공하고 문제를 해결하기 위한 아이디어와 도움을 수집하는 데 도움이 됩니다.

우리가 이 길을 가게 되어 기쁩니다. 그러나 저는 느긋하게 가는 것이 좋습니다.

gfortran의 경우 테스트 목적으로 -mfpmath=sse -msse2 플래그로 컴파일해야 합니다. 나는 이것이 모든 계산이 64비트 산술로 수행되도록 할 것이라고 생각합니다. 확실하지 않습니다.

프로젝트에 대한 제한된 경험을 감안할 때 귀하의 노력과 PR을 냄비의 지침으로 삼을 기회에 감사드립니다. 우리의 미래 PR... (괜찮다면?)

확신하는! #577을 참조하십시오.

@weslleyspereira 굉장합니다! 이것이 CLAHQR에도 동일하게 적용되는지 계속 확인하고 있습니다. 내 결과를 최대한 빨리 게시할 것입니다(내일)

안녕하세요 @langou님 !

굵은 문장: 모든 계산이 IEEE 64비트 산술을 사용하여 수행되면 LAPACK이 작동해야 합니다.

멋진! 내 생각에 '작업'이란 다음을 의미합니다. '특정 범위의' 데이터가 공급될 때 주어진 레지스터 크기로 인해 데이터가 오버플로되지 않습니까?

LAPACK은 80비트 레지스터가 언제든지 계산에 도움이 될 것으로 기대하지 않습니다. 알고리즘은 64비트 산술을 염두에 두고 설계되었습니다. 이제 @thijssteel이 언급한

우리는 이러한 문제를 해결하기 위한 여정에서 체계적인 조치를 취하지 않았습니다. 일반적으로 우리는 알고리즘이 테스트 스위트를 통과했을 때 충분히 만족하며, 80비트 레지스터의 도움이 있다면 그렇게 될 것입니다.

매우 합리적인 소리!

대략적인 추정은 테스트의 1% 미만이 이와 유사한 오버플로 문제(컴파일러를 사용할 때)의 영향을 받는다는 것입니다.

어머. 1%? 무서운 숫자입니다.

글쎄요, 아마도 그보다 '훨씬 적습니다';)

더 많은 플랫폼으로의 이식성은 실제로 하나의 관심사입니다. 또 다른 관심은 GMP와 같은 패키지를 사용하여 정밀도를 확장하는 것입니다. 여기서 정밀도는 계산 전반에 걸쳐 고정됩니다. (예를 들어 당신은 256비트 생각이고 300비트 레지스터는 당신을 도울 수 없습니다.)

흥미롭게 들리지만 이러한 고정 정밀도 시도에 대한 경험이 부족하기 때문에 이에 대해 언급할 수 없습니다.

예. 우리는 관심이 있습니다. 하지만 우리는 할 수 있는 만큼만 할 수 있습니다. 그리고 우리 접시에 많이 있습니다. 그래서 우리는 이 문제를 한 번에 하나씩 처리하고 우리가 얼마나 멀리 갈 수 있는지 알 수 있습니다.

나는 여전히 좋은 일반적인 접근 방식이 무엇인지 확신할 수 없습니다. 내 이해가 너무 순진하다면 나와 함께하십시오. 하지만 오버플로/언더플로는 항상 입력 데이터와 알고리즘 모두에 의존하지 않습니까? 따라서 코드를 새로운 조건부 테스트와 복구를 위한 새로운 코드로 채우는 대신 입력 데이터에 대한 '허용 범위'를 줄일 수 있습니까? 그러나 두 접근 방식 모두에 필요한 노력에 대한 통찰력이 없습니다. 그래서 무엇이 더 실현 가능한지 판단할 수 없습니다.

어쨌든 GitHub에 문제를 게시하는 것은 항상 좋은 생각입니다. 문제에 대한 인식을 제공하고 문제를 해결하기 위한 아이디어와 도움을 수집하는 데 도움이 됩니다.

좋은. 우리는 가는 대로 문제를 제기할 것입니다. 언더플로를 재현할 수 없는 상태에서 해결 방법을 찾는 것이 어려울 것이라는 점을 이해합니다. 그렇다면 문제를 보다 명확하게 하기 위해 어떤 정보를 제공할 수 있습니까? 콘크리트 언더플로로 내려가는 경로가 도움이 됩니까? 예: 반복 횟수, 파일 이름과 함께 로컬의 현재 값 등을 제공합니까?

우리가 이 길을 가게 되어 기쁩니다. 그러나 저는 느긋하게 가는 것이 좋습니다.

여기도 마찬가지! :)

#577의 한 가지 결과는 LAPACK이 FORTRAN 컴파일러에 의존하여 합리적으로 강력한(언더/오버플로) 복잡한 분할 및 ABS()를 구현한다는 것입니다. 문서 유지 관리를 시작하고 이와 유사한 요구 사항을 수집해야 하는지 궁금합니다. 다른/새 컴파일러와 함께 LAPACK을 사용하려는 사람, 컴파일러 빌더 및 LAPACK 알고리즘의 일부 또는 전체를 다른 언어로 전송하기 위해 모두 똑같이 중요하고 유용합니다.

확신하는! 이 정보를 잘 문서화하는 것이 좋습니다.

우선 LAPACK/SRC/z*.f (COMPLEX*16 알고리즘) 형식의 파일에서 모든 분할을 추적하는 데 시간을 보냈습니다.

 REAL / COMPLEX   or   COMPLEX / COMPLEX

총 53개의 파일을 찾았습니다. 첨부 파일 참조: complexDivisionFound.code-search

• 이를 위해 Visual Studio Code에서 REGEX 표현식을 사용했습니다.

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

gfortran의 경우 테스트 목적으로 -mfpmath=sse -msse2 플래그로 컴파일해야 합니다. 나는 이것이 모든 계산이 64비트 산술로 수행되도록 할 것이라고 생각합니다. 확실하지 않습니다.

예, GCC를 사용할 때 해야 하지만 이 플래그는 x86-64에서도 기본적으로 설정되어야 합니다. 아래에서 발췌한 문서는 GCC 11용이지만 훨씬 이전 GCC 버전에서도 동일한 동작을 보여야 합니다. GNU 컴파일러 컬렉션(GCC) 사용: 3.19.59 x86 옵션

sse

SSE 명령어 세트에 있는 스칼라 부동 소수점 명령어를 사용합니다. 이 명령어 세트는 Pentium III 및 최신 칩에서 지원되며 AMD 라인에서는 Athlon-4, Athlon XP 및 Athlon MP 칩에서 지원됩니다. SSE 명령어 세트의 이전 버전은 단정밀도 산술만 지원하므로 배정밀도 및 확장 정밀도 산술은 여전히 ​​387을 사용하여 수행됩니다. Pentium 4 및 AMD x86-64 칩에만 있는 최신 버전은 배정밀도 산술을 지원합니다. 도.

x86-32 컴파일러의 경우 -march=cpu-type , -msse 또는 -msse2 스위치를 사용하여 SSE 확장을 활성화하고 이 옵션을 적용해야 합니다. x86-64 컴파일러의 경우 이러한 확장은 기본적으로 활성화되어 있습니다.

결과 코드는 대부분의 경우 상당히 빨라야 하고 387 코드의 수치적 불안정성 문제를 피해야 하지만 임시가 80비트가 될 것으로 예상하는 일부 기존 코드가 손상될 수 있습니다.

이것은 x86-64 컴파일러, Darwin x86-32 대상에 대한 기본 선택이며 -ffast-math 가 활성화된 경우 SSE2 명령어 세트가 있는 x86-32 대상에 대한 기본 선택입니다.

예시:
XEIGTSTZ < zec.in - ZLAHQR의 언더플로로 인해 실패합니다.
재현 단계: ZGET37 -> knt == 31, ZHSEQR -> ZLAHQR -> 두 번째 QR 단계(ITS == 2) 끝에서 다음 코드는 언더플로를 유발합니다(특정 레지스터의 경우 아래 참조).

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

컴파일러는 .NET CLR을 대상으로 합니다. 그것의 JIT는 ABS(TEMP)에 대해 SSE 레지스터를 사용하기로 결정하고, 이는 크기의 중간 계산에서 언더플로로 이어집니다. Ifort(또 다른 예)는 이 상황에서 부동 소수점 레지스터를 사용하므로 언더플로가 발생하지 않습니다(길이가 더 길기 때문에: 80비트). 런타임에 컴파일러/프로세서에서 필요한 정밀도/숫자 범위와 관련하여 LAPACK에서 무엇을 기대해야 하는지에 대한 명확한(어) 그림을 얻으려고 합니다.

요약하자면:

• Fortran77의 50만 라인을 C#으로 트랜스파일했습니다.
• .NET just-in-time 컴파일러를 사용할 때 트랜스파일된 코드 테스트가 실패합니다.
• 인텔 포트란 컴파일러(ifort)를 사용할 때 바닐라 LAPACK 코드 테스트가 성공합니다.
• 두 경우 사이에서 관찰된 차이점은 언더플로를 방지하는 ifort에 의해 80비트 중간체를 사용한다는 것입니다.

옳은?

기본적으로 GCC는 x86-64에서 64비트 부동 레지스터에 대한 코드만 생성하고 내 컴퓨터에서는 일반적으로 하나 또는 두 개를 제외한 모든 LAPACK 테스트를 통과합니다.

GCC로 컴파일할 때 Netlib LAPACK 테스트 스위트가 통과합니까?

편집: 해결 https://github.com/Reference-LAPACK/lapack/pull/577#issuecomment -859496175

gfortran의 경우 테스트 목적으로 -mfpmath=sse -msse2 플래그로 컴파일해야 합니다. 나는 이것이 모든 계산이 64비트 산술로 수행되도록 할 것이라고 생각합니다. 확실하지 않습니다.

나는 MacOS와 Linux 모두에서 GCC 11을 사용하여 -mfpmath=sse -msse2 를 시도했습니다: https://github.com/weslleyspereira/lapack/actions/runs/966071530. 해당 플래그가 없는 워크플로와 비교할 때 추가 오류는 없었습니다( https://github.com/Reference-LAPACK/lapack/actions/runs/945060330). #591 참조

@hokb , SSE 플래그를 사용하여 GCC에서 https://github.com/Reference-LAPACK/lapack/issues/575#issuecomment -855880000에서 언급한 오버플로 문제를 재현할 수 있습니까? 도와줄 수 있니?

@weslleyspereira 나는 GCC도 시도하지 않았습니다. 내가 액세스할 수 있는 / 실행 중인 설정은 Windows의 ifort뿐입니다. 테스트하기 위해 cygwin을 통해 GCC를 시작하고 실행하는 데 며칠이 걸릴 것입니다.
최소한 https://godbolt.org/z/YYv5oPxe9 에 따르면 플래그를 사용하는 것은 gfortran에서 생성된 코드에 영향을 미치지 않습니다. 그러나 물론 테스트 실행만이 확실히 알 수 있습니다 ...

나는 창을 사용하지 않지만 여기에 있습니다. Ubuntu에서 ifort를 사용하여 LAPACK을 테스트하고 어떤 일이 일어나는지 먼저 살펴보겠습니다. 휴가를 즐기십시오!