Numpy: NumPy에서 BLIS 지원에 대한 추적기 문제

BLIS가 site.cfg 에 포함 된 것을 확인했습니다.
libFLAME 도 지원할 수 있습니까?

https://www.cs.utexas.edu/%7Eflame/web/libFLAME.html 의 설명은 수정이 필요할 수 있지만 libFLAME이 실제로 LAPACK API를 구현한다는 것이 분명하지 않습니다.

@rgommers libflame은 실제로 netlib LAPACK API를 제공하고 libflame이 기본적으로 제공하지 않는 모든 것에 대한 구현을 제공합니다.

FWIW, BLIS는 이번 호가 열린 이래로 큰 진전을 이루었습니다. 예를 들어, BLIS는 이제 런타임 구성을 구현하고 구성 시간 구성이 런타임 인프라 측면에서 다시 구현되었습니다. BLIS는 이제보다 포괄적 인 테스트 스위트 외에도 통합 된 BLAS 테스트 드라이버를 제공합니다. 모 놀리 식 헤더 생성 (500 개 이상의 개발 헤더 대신 단일 blis.h)과 마찬가지로 라이브러리 자체 초기화도 적용되어 설치된 제품을 더 쉽게 관리 할 수 ​​있습니다. 또한 정적 및 공유 라이브러리 빌드에 대해보다 표준화 된 라이브러리 이름 지정 규칙을 따르며 soname 합니다. 마지막으로, 빌드 시스템은 컴파일러와 어셈블러 호환성을 검사하는 것이 훨씬 더 똑똑합니다. 그리고 그것이 바로 제 머리 위에서 생각할 수있는 것입니다.

@fgvanzee 감사합니다. 이 경우 나는 numpy.distutils 에 지원을 추가하기 위해 +1입니다.

지금은 시간이 너무 부족해서 적어도 9 월까지는 일할 수 없습니다. 다른 사람이이 문제를 해결하고 싶다면 상대적으로 간단해야합니다 (gh-7294와 같은 줄을 따라). 문제 해결 / 검토를 도와 드리겠습니다.

그것은 큰 진전처럼 들립니다. numpy / scipy (성능 및 안정성 측면)에 대해 OpenBLAS의 실행 가능한 대안이되기까지 얼마나 걸립니까?

(Fortran 엉망으로 인해 Windows에 conda 에 대한 scipy-openblas가 아직 없습니다 : https://github.com/conda-forge/scipy-feedstock/blob/master/recipe/ meta.yaml # L14)

MSVC ABI 호환 BLAS 및 LAPACK을 원하는 경우 여전히 쉬운 완전한 오픈 소스 옵션이 없습니다. 요즘에는 clang-cl과 flang이 존재하지만 문제는 예전과 같은 컴파일러 가용성이 아니라 시스템 유연성을 구축하고 라이브러리 작성자가 이전에 평가하거나 지원 한 적이없는 조합을 사용하려는 것입니다. 참조 https://github.com/flame/blis/issues/57#issuecomment -284614032

@rgommers BLIS는 현재 OpenBLAS에 대한 실행 가능한 대안이라고 말하고 싶습니다. AMD가 ACML을 포기하고 BLIS를 새로운 오픈 소스 수학 라이브러리 솔루션의 기반으로 완전히 수용 한 것은 충분히 실행 가능합니다. (우리는 기업 후원자가 있으며 과거 수년 동안 국립 과학 재단의 후원을 받았습니다.)

성능 측면에서 정확한 특성화는보고있는 작업, 부동 소수점 데이터 유형, 하드웨어 및 관심있는 문제 크기 범위에 따라 달라집니다. 그러나 일반적으로 BLIS는 일반적으로 OpenBLAS를 충족하거나 능가합니다. 가장 작은 문제 크기를 제외한 모든 문제에 대한 수준 3 성능 (300 개 미만). 또한 OpenBLAS가 제공하는 것보다 더 유연한 레벨 3 병렬화 전략을 사용합니다 (모 놀리 식 어셈블리 커널 설계로 인해).

안정성 측면에서 BLIS가 상당히 안정적이라고 생각하고 싶습니다. 우리는 버그 보고서에 매우 대응하기 위해 노력하고 있으며 지난 5 개월 동안 커뮤니티의 관심이 급증한 덕분에 많은 문제를 식별하고 수정할 수있었습니다 (대부분 빌드 시스템 관련). 이를 통해 최종 사용자와 패키지 관리자의 사용자 경험이 원활 해졌습니다.

또한 BLIS는 (0 일째부터) BLAS와 유사한 기능의 상위 집합을 제공했으며 BLAS 호환성 계층과 분리 된 두 개의 새로운 API를 통해 수행했습니다.

• 명시 적으로 형식화 된 BLAS 유사 API
• 암시 적으로 형식화 된 객체 기반 API

이는 BLAS 연결이 필요한 소프트웨어를 이미 보유하고있는 레거시 사용자를 지원할뿐만 아니라 BLAS 인터페이스에 대한 특별한 친화력을 느끼지 못할 수있는 사용자 지정 고밀도 선형 대수 솔루션을 처음부터 구축하는 데 관심이있는 사용자에게 훌륭한 도구 상자를 제공합니다.

기존 BLAS 구현과 BLAS API 자체의 다양한 단점에 대한 좌절감에서 태어난 BLIS는 2012 년부터 제 사랑의 노동이었습니다. 아무데도 가지 않고 더 나아질 것입니다. :)

아 감사합니다 @tkelman. Cygwin :( :(

Linux / macOS에서 BLIS에 대해 컴파일 된 numpy를 사용하는 사람들의 경험을 듣는 것은 흥미로울 것입니다.

@fgvanzee 컨텍스트에 감사드립니다. libFLAME 지원을 추가하고 SciPy 벤치 마크 제품군을 사용해 보면 흥미로울 것입니다.

@rgommers Re : libflame : 관심을 가져 주셔서 감사합니다. libflame은 일부 TLC를 사용할 수 있습니다. BLIS만큼 모양이 좋지는 않습니다. (우리는 원하는대로 지원할 시간 / 자원이 없으며 지난 6 년 동안 거의 100 % 관심을 기울여 BLIS가 OpenBLAS의 실행 가능하고 경쟁력있는 대안이 될 수있는 곳으로 이동하는 데 집중했습니다. 외)

언젠가 BLIS가 성숙하고 연구 방법이 소진되면 libflame / LAPACK 수준 기능 (예 : Cholesky, LU, QR 분해)으로 다시주의를 돌릴 것입니다. 이는 이러한 구현을 BLIS에 점진적으로 추가하는 형태를 취하거나 궁극적으로 libflame을 대체하기 위해 완전히 새로운 프로젝트를 포함 할 수 있습니다. 후자의 경우 BLIS의 하위 수준 API를 활용하도록 설계되어 현재 BLAS를 통해 피할 수없는 일부 함수 호출 및 메모리 복사 오버 헤드를 피할 수 있습니다. 이것은 우리가 조사하기를 기대하는 많은 주제 중 하나 일뿐입니다.

멀티 스레딩없이 Intel Skylake에서 NumPy 1.15 및 BLIS 0.3.2 로이 기사의 벤치 마크를 실행

Dotted two 4096x4096 matrices in 4.29 s.
Dotted two vectors of length 524288 in 0.39 ms.
SVD of a 2048x1024 matrix in 13.60 s.
Cholesky decomposition of a 2048x2048 matrix in 2.21 s.
Eigendecomposition of a 2048x2048 matrix in 67.65 s.

인텔 MKL 2018.3 :

Dotted two 4096x4096 matrices in 2.09 s.
Dotted two vectors of length 524288 in 0.23 ms.
SVD of a 2048x1024 matrix in 1.11 s.
Cholesky decomposition of a 2048x2048 matrix in 0.19 s.
Eigendecomposition of a 2048x2048 matrix in 7.83 s.

4.29 초에 두 개의 4096x4096 행렬을 점으로 구분했습니다.

@homocomputeris 죄송합니다. 전에 두 행렬에 대한 연산을 설명하는 데 사용 된 "점"동사를 들어 본 적이 없습니다. 그게 행렬 곱셈인가요?

@fgvanzee 요즘 BLIS에서 Windows 지원 상태는 어떻습니까? Windows에서 빌드하는 것이 대부분 지원되지 않았던 것을 기억합니다.

@fgvanzee 및 예, numpy.dot 은 Python에서 GEMM을 호출하는 전통적인 방법입니다. (이상한 이름의 일종이지만 벡터-벡터, 벡터-행렬, 행렬-행렬을 모두 동일한 API에서 처리하기 때문입니다.)

@njsmith "기본"Windows 지원 상태는 대부분 변경되지 않습니다. 안타깝게도 이러한 지원이 이루어 지도록하는 데에는 여전히 전문성과 관심이 부족합니다. 그러나 Windows 10이 출시 된 이후로 "Windows 용 우분투"또는 일종의 bash 호환성 환경이있는 것 같습니다. 이는 아마도 Windows 지원을 달성하기위한 훨씬 더 유망한 방법 일 것입니다. (그러나 우리 그룹의 아무도 Windows에서 개발하거나 사용하지 않으므로 해당 옵션도 조사하지 않았습니다.)

좋아, 지금은 마지막 게시물 하나 ...

@homocomputeris 는 이와 같은 벤치 마크를 위해

@fgvanzee 네이티브 strided 지원에 대해 말하면,

@fgvanzee "bash for Windows"는 특히 빠르고 원활한 VM 인 Windows에서 Linux VM을 실행하는 것과 실질적으로 동일하지만 기본 환경은 아닙니다. 따라서 좋은 소식은 이미 Windows 용 bash를 지원한다는 것입니다. :-)하지만 나쁜 소식은 기본 Windows 지원을 대체하지 않는다는 것입니다.

@njsmith 내 결과는 기사에서와 거의 동일합니다.
최신 MKL, 예 :

Dotted two 4096x4096 matrices in 2.09 s.
Dotted two vectors of length 524288 in 0.23 ms.
SVD of a 2048x1024 matrix in 1.11 s.
Cholesky decomposition of a 2048x2048 matrix in 0.19 s.
Eigendecomposition of a 2048x2048 matrix in 7.83 s.

필자는 CPU가 최적화 할 수있는 모든 것과 멀티 스레드를 사용하기 위해 BLIS를 컴파일하는 방법을 모른다는 점에 주목하고 싶습니다. MKL은 거의 모든 것을 기본적으로 가지고 있습니다.

@njsmith 업데이트에 감사드립니다. 기본 OS 지원을 능가하는 것은 없다는 데 동의합니다. 또한 @homocomputeris 의 타이밍을 적절하게 해석하기 위해 다른 라이브러리에서 실행되는 벤치 마크를 확인해야한다는 데 동의합니다.

네이티브 보폭 지원에 대해 말하자면, 요즘 보폭에 어떤 제한이 있습니까? 데이터 크기의 정확한 배수, 양수, 음수가 아니고 정렬되어야합니까? (기억 하시겠지만, numpy 배열은 바이트 단위로 측정되는 완전히 임의적 인 스트라이드를 허용합니다.)

@njsmith 정렬? 아니, 긍정적? 우리가 그 제약을 해제했다고 생각하지만 철저하게 테스트되지 않았습니다. 데이터 유형의 정확한 배수? 그래, 그래도.

@devinamatthews 를 토론에 가져

@homocomputeris size 대해 다른 값으로 벤치 마크를 다시 실행 하시겠습니까? 저자가 사용한 값 (4096)이 2의 거듭 제곱이라는 것이 BLIS의 경우 특히 나쁜 사용 사례인지, 어쨌든 대부분의 응용 프로그램에서 특히 현실적이지 않은지 궁금합니다. 대신 4000 (또는 3000 또는 2000)을 시도하는 것이 좋습니다.

@homocomputeris 그리고 BLIS 결과는 단일 스레드이고 MKL 결과는 다중 스레드라고 말했습니까?

FWIW, 얼마 전에 Windows에서 BLIS를 구축하는 방법을 살펴 보았습니다. 현재 가장 큰 문제점은 빌드 시스템입니다. clang을 사용하여 MSVC 호환 바이너리를 생성하도록 mingw의 make를 얻을 수 있습니다. 나는 그것을 할 수있는 시간 동안 결코 그것을 얻지 못했지만 가능해 보입니다.

실제 소스 코드 내에서 상황은 그리 나쁘지 않습니다. 최근에는 어셈블리 커널에 매크로를 사용하는 것으로 전환하여 Windows 지원에 대한 한 가지 장벽이 제거되었습니다. https://github.com/flame/blis/issues/220#issuecomment -397842370 및 https://github.com/flame/blis/pull/224를 참조하세요. 소스 파일 자체가 MSVC를 기반으로하는 몇 가지 매크로 / ifdef가 더 많은 것처럼 보이지만 이것이 외부인으로서의 제 관점입니다. 또한 기존 BLIS 메이크 파일을 MSVC와 함께 사용하는 방법도 모릅니다.

@insertinterestingnamehere Ian을 되지 않았습니다 . 또한 MSVC는 아직 C99를 지원합니까? 그렇지 않다면 그것은 또 다른 장애물입니다. (BLIS에는 C99가 필요합니다.)

글쎄, 나는 BLIS가 다른 것들과 비교할 수 있음을 보여주기 위해 위의 예를 주었기 때문에 더 구체적인 것은 포함하지 않았습니다.

그러나 당신이 묻는대로 : 스마일 :

• 최신 BIOS 및 Spectre / Meltdown 용 패치가 포함 된 Intel Core i5-6260U 프로세서
• Linux 4.17.3-1-ARCH
• 모든 것이 gcc 8.1.1 20180531로 컴파일됩니다.
• NumPy 1.15.0rc1
• 나는 행렬 차원에 대한 소수를 선택했습니다

Intel MKL 2018.3은 2 개의 스레드로 제한됩니다 (즉, 물리적 CPU 코어).

Dotted two 3851x3851 matrices in 1.62 s.
Dotted two vectors of length 492928 in 0.18 ms.
SVD of a 1925x962 matrix in 0.54 s.
Cholesky decomposition of a 1925x1925 matrix in 0.10 s.
Eigendecomposition of a 1925x1925 matrix in 4.38 s.

BLIS 0.3.2 컴파일
CFLAGS+=" -fPIC" ./configure --enable-cblas --enable-threading=openmp --enable-shared x86_64

Dotted two 3851x3851 matrices in 3.82 s.
Dotted two vectors of length 492928 in 0.39 ms.
SVD of a 1925x962 matrix in 12.82 s.
Cholesky decomposition of a 1925x1925 matrix in 2.02 s.
Eigendecomposition of a 1925x1925 matrix in 67.80 s.

따라서 BLIS는 Windows 사용 사례가 '작동하면 만지지 마십시오'라고 상상하기 때문에 적어도 Unix / POSIX / 어떤 유사 시스템에서 NumPy에 의해 확실히 지원되어야하는 것 같습니다.
내가 모르는 유일한 것은 MKL / BLIS와 LAPACK / libFLAME 간의 연결입니다. 인텔은 LAPACK, FFT 등과 같이 BLAS 외에 최적화 된 많은 기능을 가지고 있다고 주장합니다.

@fgvanzee 왜 2의 거듭 제곱이 BLIS에 나쁜가요? 가장 빠른 FFT를 원하는 경우 collocations 메서드에 대해 매우 일반적입니다.

numpy 등의 경우 mingw / MSYS2에서 건물을 관리하는 것으로 충분할 것입니다 .--- 현재 Windows에서 openblas로 수행하는 작업입니다 (그 자체로 는 일종의 해킹이지만). CRT 리소스를 전달하지 않는 "전통적인"API로 사용을 제한하지만 BLAS / LAPACK에서는 괜찮습니다.

@fgvanzee C99에 대한 좋은 지적. WRT C99 전 처리기, 놀랍게도 MSVC 2017 전 처리기조차도 거기에서 완전히 잡히지 않았습니다. 아마도 그들은 현재 그것을 수정하고 있습니다 (https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance#note_D).

@fgvanzee @njsmith 다음은 임의의 바이트 스트라이드를 지원하기 위해 수행해야하는 작업입니다.

1) 인터페이스를 수정합니다. 나에게 발생하는 가장 편리한 일은 개체 인터페이스에 stride_units 플래그와 같은 것을 추가하는 것입니다.
2) 모든 내부를 리팩터링하여 바이트 스트라이드 만 사용합니다. 어쨌든 이것은 나쁜 생각이 아닐 수 있습니다.
3) 패킹 할 때 데이터 유형 정렬을 확인하고 그렇지 않은 경우 일반 패킹 커널을 사용합니다.
a) 일반 패킹 커널도 memcpy 를 사용하도록 업데이트해야합니다. 리터럴 크기 매개 변수를 사용하도록 정의 할 수 있다면 끔찍하게 짜증나 지 않아야합니다.
4) C가 정렬되지 않은 경우 memcpy 사용하여 C에 액세스하는 가상 마이크로 커널도 사용합니다.

이것은 입력 및 출력 행렬에만 해당됩니다. alpha 및 beta 가 임의의 포인터가 될 수 있다면 더 많은 문제가 있습니다. x86에서는 정렬되지 않은 데이터를 읽고 쓸 수 있지만 다른 아키텍처 (특히 ARM)가 문제가 될 수 있습니다. 컴파일러는 자동 벡터화 할 때 추가 정렬 문제를 일으킬 수도 있습니다.

@homocomputeris :

1. 나는 2의 거듭 제곱이 "야생에서"발생하지 않는다는 것을 의미하는 것이 아니라, 우리 컴퓨터 중심의 인간이 2의 거듭 제곱으로 계산하기를 좋아하기 때문에 벤치 마크에서 과도하게 표현된다는 것을 의미 할뿐입니다. :)
2. 이러한 벤치 마크 결과는 정말 유사합니다. 이 다음 질문에 대한 대답이 "아니오"이면 좋겠지 만 MKL (또는 BLIS)이 연결된 상태에서 실수로 두 벤치 마크를 모두 실행했을 가능성이 있습니까?
3. FFT 관련 응용 프로그램에서 두 가지 권한이 발생한다는 데 전적으로 동의합니다. 나는 신호 처리에서 일 했었기 때문에 이해합니다. :)
4. BLIS가 2의 거듭 제곱으로 잘되지 않는 것에 대한 나의 우려는 실제로 BLIS만의 문제가 아닙니다. 그러나 우리가 관찰하고있는 현상은 BLIS에서 더 두드러 져서 MKL과 같이 엄청나게 최적화 된 솔루션에 비해 BLIS에 대한 순 "페널티"일 수 있습니다. 문제는 다음과 같습니다. 행렬이 2의 거듭 제곱 인 차원 인 경우 "선행 차원"도 2의 거듭 제곱 일 가능성이 높습니다. (행렬 차원은 행렬이 열에 저장 될 때 열 보폭에 해당하고 행에 저장 될 때 행 보폭에 해당합니다.) 모멘트 행 저장을 가정 해 보겠습니다. 선행 차원이 2의 거듭 제곱 일 때 요소 (i, j)가있는 캐시 라인은 요소 (i + 1, j), (i + 2, j)가있는 캐시 라인과 동일한 연관성 세트에 있습니다. , (i + 3, j) 등이 라이브입니다. 즉, 후속 행의 동일한 요소입니다. 즉, gemm 연산이 C의 배정 밀도 실수 6x8 마이크로 타일을 업데이트 할 때 해당 6 개 행은 모두 L1 캐시에 설정된 동일한 연관성에 매핑되며 불가피하게 일부는 제거되기 전에 제거됩니다. 재사용. 이러한 소위 충돌 실패는 성능 그래프에 가끔 성능이 급증하는 것으로 표시됩니다. 내가 아는 한,이 성능 저하를 쉽게 해결할 수있는 방법은 없습니다. 우리는 이미 행렬 A와 B를 패킹 / 복사하기 때문에 큰 영향을 미치지는 않지만, 엄청난 메모리 복사 히트를받지 않고는 행렬 C를 더 유리한 선행 차원으로 패킹 할 수 없습니다. (치료법은 질병보다 더 나쁠 것입니다.) 이제 MKL은이를 완화 할 수있는 방법을 가지고있을 수 있습니다. 아마도 충돌 누락 횟수를 최소화하는 다른 모양의 마이크로 커널로 전환 할 수 있습니다. 아니면 그렇지 않을 수도 있지만 BLIS가이를 완화하기 위해 어떤 조치도 취하지 않는다는 것을 알고 있습니다. 귀하의 질문에 대한 답변이 되었기를 바랍니다.
5. MKL이 BLAS + LAPACK 기능 이상이라는 것이 맞습니다. 그러나 MKL은 상업적으로 보유 된 비공개 소스 솔루션입니다. 비상업적 인 목적으로 "무료"로 사용할 수 있지만 인텔이 앞으로 대중이 MKL을 사용할 수 없도록 만들거나 다시 충전을 시작하지 않을 것이라는 보장은 없습니다. 또한 구현을 이해하거나 구현을 조정 또는 수정하거나 잘 이해 된 구성 요소를 기반으로 연구를 구축하려는 컴퓨터 과학자에게는 그다지 좋지 않습니다. 즉, 원하는 것은 문제를 해결하고 하루를 계속 진행하는 것이며 BLAS를 통해이를 표현해도 괜찮은 것입니다. :)

@fgvanzee 업데이트되었습니다. 내 잘못은 BLIS를 구성에 넣었지만 어떤 이유로 MKL로 컴파일되었습니다.
SVD 및 EVD가 LAPACK에 구현되어 있습니까?

@homocomputeris 예, LAPACK은 SVD 및 EVD를 구현합니다. 그리고 MKL의 구현이 매우 빠르기를 기대합니다.

그러나 EVD는 약간 모호합니다. 일반화 된 고유 값 문제와 Hermitian (또는 대칭) EVD가 있습니다. 삼각 EVD도 있지만 일반적으로 Hermitian EVD를 구현하는 사람들을 제외하고는 그것에 관심이있는 사람은 거의 없습니다.

NumPy는 2018 년 말에 Python 2.7 및 3.4 지원을 중단 할 예정이며, 이는 C99를 준수하는 최신 MSVC 컴파일러를 사용할 수 있도록 할 것입니다. 이는 공식 2.7 지원이 종료되기 전에 우리가 이동하는 이유 중 하나입니다. 최신 MSVC 컴파일러의 C99 지원에 대한 자세한 내용은 http://tinyurl.com/yazmczel 을 참조하십시오. 지원이 완전하지는 않지만 (완전한 사람이 있습니까?) 충분할 수 있습니다. 일부 (Intel)가 향상된 수치 지원을 위해 요청 했으므로 NumPy 자체를 언젠가 C99로 옮길 것입니다.

@charris 이 정보를 주셔서 감사합니다, Charles. 아마 충분할 것이다 구현 될 것이다 어떤 경우지만, 우리는 그것을 시도 할 때까지 우리는 확실히 알 수 없습니다.

어쨌든 BLIS는 널리 채택되기 시작하기 위해 MKL을 이길 필요가 없습니다. 직접적인 경쟁자는 OpenBLAS입니다.

BLIS는 널리 채택되기 시작하기 위해 MKL을 이길 필요가 없습니다. 직접적인 경쟁자는 OpenBLAS입니다.

더 이상 동의 할 수 없습니다. MKL은 자체 리그에 있습니다.

@njsmith Just curious : numpy 커뮤니티는 혼합 정밀도 및 / 또는 혼합 도메인에서 gemm 를 수행 할 수있는 새로운 API / 기능에 얼마나 관심이 있습니까? 즉, 각 피연산자는 A와 B 중 하나 또는 둘 다와 (잠재적으로) 다른 정밀도로 수행되는 계산과 함께 다른 데이터 유형일 수 있습니다.

@fgvanzee 관심이 있습니다. 흔들리지 않습니다 . 그러나 현재 우리는 시간과 메모리를 소모하는 유형 변환을 수행합니다. 또한 정수 유형에 대해 최적화 된 루틴을 갖는 아이디어를 가지고 놀았습니다.하지만 부울이 오버플로로 인해 돌이킬 수없는 고통을 겪지 않는 유일한 유형일 수 있습니다.

그리고 항상 float16이 있습니다. ML 직원은 이러한 기능에 더 관심이있을 수 있습니다. @GaelVaroquaux 생각?

@charris 예, 사례의 수가 gemm 대해 128 개의 유형 조합이 있으며,이 숫자는 행렬 저장 가능성뿐만 아니라 전치 / 활용 매개 변수에서 모든 조합 팽창을 제외합니다 (이 경우 최대 55,296).

성능이 낮은 참조 구현을 통해서도 128 개 케이스를 완전히 구현하는 것은 주목할 만하 며, 오버 헤드를 최소화하는 고성능 방식으로 수행하는 것은 매우 특별합니다. (그리고 BLIS의 객체 기반 기반 덕분에 이것을 구현하면 추가 객체 코드 측면에서 비용이 거의 들지 않습니다.)

관심이 있으시면 앞으로 며칠 또는 몇 주 안에 저희 프로젝트를 시청하시기 바랍니다. :)

BLIS 포크는 안전한가요?

어쨌든 BLIS는 널리 채택되기 시작하기 위해 MKL을 이길 필요가 없습니다. 직접적인 경쟁자는 OpenBLAS입니다.

과연. 솔직히 말해서 NumPy + BLAS가 내 시스템에서 작동하도록 만들 수는 없었지만 이전에 인용 한 기사를 보면 매우 비슷한 성능을 보이는 것 같습니다.
아마도 libFLAME은 NumPy에 연결되면 LAPACK 작업 속도를 높일 수 있습니다.

AMD의 BLIS / libFLAME 포크를 최신 Zen CPU에 벤치마킹하여 개선되었는지 확인하는 또 다른 흥미로운 질문입니다. 문제가있는 Intel 프로세서의 관점에서 볼 때 훨씬 더 흥미로워집니다.

Linux 및 Windows에서 현재 numpy의 공식 휠에는 OpenBLAS의 사전 빌드 된 사본이 포함되어 있으므로 이러한 플랫폼에서 사본을 얻는 가장 빠른 방법은 pip install numpy 입니다. (물론이 버전은 로컬에서 BLIS를 빌드하는 데 사용되는 컴파일러와 다른 컴파일러로 빌드 되었기 때문에 완전히 공정하지 않습니다.하지만 한 가지 아이디어를 얻을 수 있습니다.)

BLIS 포크는 안전한가요?

@jakirkham 나는 이것에 대해 @devinamatthews에게 말씀, 그는 대답은 '예'라고 생각하는 것 같다. BLIS는 OpenBLAS처럼 스레드 풀을 유지하는 대신 요청시 (예 : gemm 가 호출 될 때) 스레드를 생성합니다.

그래도 궁금합니다. numpy는 어떤 종류의 스레딩 모델을 기대 / 선호 / 종속합니까? 여러 개의 매우 작은 문제를 연속적으로 호출하는 사용 사례에서 오버 헤드를 줄이기 위해 스레딩 풀이 필요합니까? (BLIS의 주문형 스레딩은 이러한 종류의 사용에 적합하지 않습니다.)

편집 : 비슷한 맥락에서 pthreads가 필요합니까, 아니면 OpenMP를 사용할 수 있습니까?

정보에 대해서 감사드립니다.

그렇다면 pthreads, OpenMP를 모두 사용하고 있습니까? FWIW에는 GCC의 OpenMP에 알려진 문제가 있으며 AFAIK가 해결되지 않았다는 @ogrisel ). 파이썬에서 multiprocessing 모듈을 통해 분기하는 것은 가장 일반적인 병렬 처리 전략 중 하나입니다. 일반적으로 파이썬에서는 포크 안전 방식으로 스레드 (위의 이유로 pthreads 선호)를 사용할 수있는 것이 매우 중요합니다. 요즘에는 fork-exec를 사용하는 loky 와 같은 옵션이 더 많이 있지만.

분명히 Nathaniel은 나보다 이것에 대해 더 많이 알겠지만, 이미이 주석을 쓰기 시작했기 때문에 IIUC NumPy는 외부 라이브러리 (예 : BLAS)를 제외하고는 스레딩 자체를 사용하지 않습니다. NumPy는 GIL 을 충분히 자주 릴리스하므로 Python의 스레딩이 다소 효과적 일 수 있습니다. Joblib, Dask 등과 같은 것들이이 전략을 활용합니다.

스레드 풀에 관해서는 NumPy / SciPy를 사용하여 Python에서 일련의 BLAS 루틴을 수행하는 성능을 최대화하기 위해 ML 기술을 프로파일 링하는 중이었기 때문에 이에 대해 질문하는 것이 흥미 롭습니다. OpenBLAS와 적절한 수의 코어를 사용하면이 루틴은 Python에서 명시적인 스레딩 (NumPy 및 SciPy 포함)이 사용되지 않더라도 루틴의 길이에 대해 코어를 포화시킬 수 있습니다. OpenBLAS가 일상. 예, 스레드 풀은 믿을 수 없을만큼 가치가 있습니다.

다른 점에서 BLIS는 동적 아키텍처 감지를 처리합니까? 이것은 한 번 빌드하고 다양한 다른 시스템에 배포 할 수있는 아티팩트를 빌드하는 데 매우 중요합니다.

@jakirkham 귀하의 의견에 감사드립니다. 스레드 풀이없는 것으로 관찰 된 비용은 전달하는 행렬 피연산자의 크기와 수행중인 작업에 따라 달라집니다. gemm 이 (가) 목표로하는 일반적인 작업이라고 가정합니다 (내가 틀린 경우 수정 해주세요).하지만 일반적인 문제 크기는 무엇이라고 생각하십니까? BLIS의 create / join 모델의 비용은 A, B, C가 40x40 인 행렬 곱셈을 반복적으로 수행하는 경우 나타날 수 있지만 400x400 이상에서는 그다지 많지 않을 것입니다. (TBH, 40x40 문제를 병렬화함으로써 시작되는 속도 향상을 기 대해서는 안됩니다.)

다른 점에서 BLIS는 동적 아키텍처 감지를 처리합니까? 이것은 한 번 빌드하고 다양한 다른 시스템에 배포 할 수있는 아티팩트를 빌드하는 데 매우 중요합니다.

예. 이 기능은 얼마 전인 2017 년 하반기에 구현되었습니다. BLIS는 이제 일부 휴리스틱 (예 : cpuid 통해 런타임시 선택되는 특정 하위 구성으로 소위 "구성 제품군"을 대상으로 할 수 있습니다 intel64 , amd64 , x86_64 입니다.

@fgvanzee 실제로 작은 행렬의 성능이 OpenBLAS의 약점 중 하나라고 생각하므로 BLIS가 다시 느려지면 약간 걱정됩니다 ... 사람들은 분명히 모든 종류의 상황에서 numpy를 사용하므로 라이브러리를 정말 중요하게 생각합니다. 특정 경우에 대한 조정없이 "그냥 작동"합니다. (나는 이것이 가장 중요한 두 가지 경우가 벤치 마크를 실행하는 알고리즘 작성자와 전문 시스템 관리자와 함께 일주일 동안 슈퍼 컴퓨터 작업을 실행하는 전문가 인 고전적인 고밀도 선형 대수 설정과 약간 다른 것 같습니다.) 예를 들어, 사람들은 종종 numpy를 3x3 행렬.

어떤 경우에는 이것을 적절하게 처리하는 것이 너무 작은 문제가 있음을 인식하고 스레딩을 완전히 건너 뛰는 문제 일 수 있습니다. 3x3 gemm의 경우 최적의 방법은 가능한 한 어리석은 것입니다.

하지만 이러한 종류의 조정 (또는 스레드 풀 대 스레드 풀 없음)은 BLIS가 광범위하게 배포되기 시작하면 커뮤니티가 뛰어 들고 수행 할 작업 일 수 있습니다.

사실 저를 상기시켜줍니다. 저는 지난주에 자신의 라이브러리에서 더 높은 수준의 스레딩을 관리하고 있었기 때문에 gemm 단일 스레드를 호출하기를 원한다는 것을 알고 있던 누군가와 이야기했습니다. 그는 표준 blas 라이브러리를 사용하는 유일한 방법입니다. 제어는 임의의 라이브러리 내부에서 호출하기 쉬운 전역 설정을 통해 이루어집니다. BLIS의 네이티브 API를 사용하면 사용자가 호출 단위로 스레드 구성을 제어 할 수 있습니까? IIRC는 BLAS 호환성 레이어 외부에 전역 구성이 전혀 없기 때문에 그렇다고 생각합니다.

저는 실제로 작은 행렬의 성능이 OpenBLAS의 약점 중 하나라고 생각합니다. 따라서 BLIS가 다시 느려진다면 약간 걱정이됩니다. 사람들은 모든 상황에서 numpy를 확실히 사용하므로 "그냥 특정 경우에 맞게 조정할 필요가 없습니다.

나는 그것이 "그냥 작동하기"를 바라는 것을 이해한다. 그러나 나는 당신에게 현실적이고 정직하게하려고 노력하고있다. 3x3 문제가 있고 성능이 정말 중요하다면 BLIS를 사용하지 않아야 할 것입니다. BLIS가 3x3의 순진한 트리플 루프보다 10 배 느리게 실행된다는 말이 아닙니다. BLIS의 구현이 뛰어난 문제 크기가 아니라는 것입니다.

작은 문제에 대해 OpenBLAS에 다소 불만족 하신다는 말을 듣고 놀랐습니다. 당신의 기준점은 무엇입니까? 큰 문제보다 성능이 낮다는 것뿐입니까? 작은 문제에 대해 가능한 최고의 성능을 얻으려면 큰 문제와는 다른 전략이 필요합니다. 이것이 대부분의 프로젝트가 둘 중 하나를 대상으로 한 다음 대상이 아닌 경우를 차선으로 처리하는 이유입니다.

어떤 경우에는 이것을 적절하게 처리하는 것이 너무 작은 문제가 있음을 인식하고 스레딩을 완전히 건너 뛰는 문제 일 수 있습니다. 3x3 gemm의 경우 최적의 방법은 가능한 한 어리석은 것입니다.

컷오프가 이상적이라는 데 동의합니다. 그러나 그 컷오프가 어디에 있어야하는지 결정하는 것은 사소한 일이 아니며 가장 확실하게 아키텍처 (및 레벨 3 운영 전반)에 따라 다릅니다. 그래서 그것은 매우 가능하지만 아직 구현되지 않았거나 잘 고려되지 않았습니다.

하지만 이러한 종류의 조정 (또는 스레드 풀 대 스레드 풀 없음)은 BLIS가 광범위하게 배포되기 시작하면 커뮤니티가 뛰어 들고 수행 할 작업 일 수 있습니다.

예.

사실 저를 상기시켜줍니다. 저는 지난주에 자신의 라이브러리에서 더 높은 수준의 스레딩을 관리하고 있었기 때문에 gemm 단일 스레드를 호출하기를 원한다는 것을 알고 있던 누군가와 이야기했습니다. 그는 표준 blas 라이브러리를 사용하는 유일한 방법입니다. 제어는 임의의 라이브러리 내부에서 호출하기 쉬운 전역 설정을 통해 이루어집니다.

멀티 스레드 애플리케이션의 순차 gemm 는 우리가 가장 좋아하는 사용 사례 중 하나입니다. (알림 : 순차 gemm 만 사용하는 경우 멀티 스레딩을 비활성화 한 상태로 BLIS를 구성 할 수 있습니다.하지만 한 번 빌드하고 나중에 스레딩을 결정한다고 가정 해 보겠습니다.)

BLIS의 네이티브 API를 사용하면 사용자가 호출 단위로 스레드 구성을 제어 할 수 있습니까? IIRC는 BLAS 호환성 레이어 외부에 전역 구성이 전혀 없기 때문에 그렇다고 생각합니다.

멀티 스레딩이 활성화 된 상태에서 BLIS를 구성하더라도 기본적으로 병렬 처리는 비활성화됩니다 (하나의 스레드). 이것이 그가 문제를 해결할 수있는 두 번째 방법입니다.

그러나 런타임에 병렬 처리 정도를 변경하고 싶다고 가정 해 보겠습니다. BLIS의 병렬 처리는 런타임에 설정할 수 있습니다. 그러나 여전히 BLIS 내부적으로 setenv() 및 getenv() 를 통해 환경 변수를 설정하고 읽는 작업이 포함됩니다. (자세한 내용은 멀티 스레딩 위키 를 참조하십시오.) 그래서 그것이 당신의 친구에게 거래를 방해하는지 확신하지 못합니다. 스레딩을보다 프로그래밍 방식 (환경 변수를 포함하지 않음)으로 지정할 수있는 API를 구현하고 싶지만 아직 그 정도는 아닙니다. 대부분은 인터페이스에 관한 것입니다. 인프라가 모두 제자리에 있습니다. 문제의 일부는 우리 모두가 병렬화 할 때 하나의 숫자를 지정하도록 수년에 걸쳐 (예 : OMP_NUM_THREADS 등) 교육을 받았으며, 이는 BLIS가 선호하는 정보를 지나치게 단순화 한 것입니다. gemm 알고리즘에는 5 개의 루프가 있으며 그중 4 개는 병렬화 될 수 있습니다 (향후 5 개). 하나의 숫자로 추측 할 수 있지만 하드웨어 토폴로지에 따라 다르기 때문에 일반적으로 이상적이지 않습니다. 이것이이 전선에서 진행을 방해하는 부분의 일부입니다.

@devinamatthews 같은 맥락에서 TBLIS를 추가 할 기회가 있습니까?

3x3 문제가 있고 성능이 정말 중요하다면 BLIS를 사용하지 않아야 할 것입니다. BLIS가 3x3의 순진한 트리플 루프보다 10 배 느리게 실행된다는 말이 아닙니다. BLIS의 구현이 뛰어난 문제 크기가 아니라는 것입니다.

3x3 문제에 대해 최적의 성능을 얻는 것에 대해 그다지 걱정하지 않습니다 (물론 얻을 수 있다면 좋겠지 만!). 그러나 극단적 인 예를 들자면 : numpy가 기본 선형 대수 라이브러리로 BLIS로 컴파일되고 일부 사용자가 numpy를 사용하여 코드에 a @ b 를 작성하면 10 배 느리게 실행되지 않기를 바랍니다. 순진한 구현보다. 사용자가 3x3 행렬을 다중화하기 전에 numpy를 다시 빌드하기를 기대하는 것은 너무 많은 질문입니다. :-). 특히 한 곳에서 3x3 행렬을 곱하는 동일한 프로그램이 다른 곳에서도 1000x1000 행렬을 곱할 수 있기 때문입니다.

알림 : 순차 gemm이 유일한 사용 사례 인 경우, 그는 멀티 스레딩을 비활성화 한 상태에서 BLIS를 구성 할 수 있습니다. 하지만 한 번 빌드하고 나중에 스레딩을 결정한다고 가정 해 보겠습니다.

그는 Python 라이브러리를 배송하고 있습니다. 그는 사용자가 자신의 라이브러리를 가져 와서 동일한 프로세스에서 함께 실행되는 다른 라이브러리 및 자체 코드와 결합 할 것으로 기대합니다. 그의 라이브러리는 GEMM을 사용하며, 그가 제어하지 않거나 심지어 알고있는 다른 코드 중 일부도 GEMM을 사용하기를 원할 것입니다. 그는 동일한 프로세스에서 발생할 수있는 GEMM에 대한 다른 관련없는 호출에 우연히 영향을주지 않고 GEMM에 대한 호출에 대한 스레딩을 제어 할 수 있기를 원합니다. 이상적으로는 GEMM 사본을 직접 배송하지 않고도이 작업을 수행 할 수 있습니다. 제대로 수행하는 것은 매우 성 가시고, 프로그램에 대형 라이브러리의 사본 두 개를 포함해야한다는 것은 개념적으로 모욕적입니다. 따라서 단일 정수 변수 number_of_threads 두 복사본을 얻을 수 있습니다. 그게 더 말이 되나요?

순진한 구현보다 10 배 느리게 실행되지 않기를 바랍니다.

이제 생각해 보면 매우 작은 (3x3) 문제에 대해 순진한 것보다 몇 배 느리다고해도 놀라지 않을 것입니다.하지만 크로스 오버 포인트는 16x16만큼 작을 수도 있습니다. 그리고 이것은 반창고를 붙이기 쉬운 문제입니다. (모든 레벨 3 작업에 대해 수행하고 싶습니다.)

그는 Python 라이브러리를 배송하고 있습니다. 그는 사용자가 자신의 라이브러리를 가져 와서 동일한 프로세스에서 함께 실행되는 다른 라이브러리 및 자체 코드와 결합 할 것으로 기대합니다. 그의 라이브러리는 GEMM을 사용하며, 그가 제어하지 않거나 심지어 알고있는 다른 코드 중 일부도 GEMM을 사용하기를 원할 것입니다. 그는 동일한 프로세스에서 발생할 수있는 GEMM에 대한 다른 관련없는 호출에 우연히 영향을주지 않고 GEMM에 대한 호출에 대한 스레딩을 제어 할 수 있기를 원합니다. 이상적으로는 GEMM 사본을 직접 배송하지 않고도이 작업을 수행 할 수 있습니다. 제대로 수행하는 것은 매우 성 가시고, 프로그램에 대형 라이브러리의 사본 두 개를 포함해야한다는 것은 개념적으로 모욕적입니다. 따라서 단일 정수 변수 number_of_threads의 두 복사본을 얻을 수 있습니다. 그게 더 말이 되나요?

네, 도움이되었습니다. 세부 사항에 감사드립니다. 그는 아직 존재하지 않는 스레딩 API에 대한 완벽한 후보가 될 것 같습니다. (개인적으로는 환경 변수 규칙은 경계선의 미친 짓 하나 개 이상의 경우에 내 협력자에 내 감정을 표현했다 생각합니다. 그 말은 HPC 사용자 / benchmarkers의 넓은 한번 벤 면적에 오히려 편리하다, 우리가 간다해야하므로 환경 변수 사용을 배제하지 않는 적절한 런타임 API를 사용하여 모두가 만족할 수 있도록합니다.)

이것이 확실히 우리의 레이더에 있다는 것을 그에게 전달 하시겠습니까? 나는 로버트와 함께 모이겠습니다. 그는 내가이 일에 시간을 보내는 것을 조만간 승인 할만큼 충분히 관심이있을 것입니다. (스레딩 API는 한동안 그의 위시리스트에있었습니다.)

MSVC ABI를 대상으로하는 clang.exe를 사용하여 Windows에 BLIS를 빌드하는 것은 확실히 가능합니다. 몇 시간을 보냈고 여기 에 변경 사항이 있습니다. 필요한 변경 횟수는 OpenBLAS에 비해 놀랍도록 적었습니다.
로그는 여기에 있습니다 . 모든 BLIS 및 BLAS 테스트를 통과합니다.

@isuruf 시간을내어

풀 리퀘스트에 관해서는 몇 가지 코멘트 / 요청 (모두 아주 사소한)이 있지만 풀 리퀘스트 자체에 대한 대화를 시작하겠습니다.

추신 : f2c 오류를 알아낼 수있어서 다행입니다. libf2c의 충분한 부분을 BLAS 테스트 드라이버 소스 ( libf2c.a 로 컴파일 됨)로 가져 와서 링크를 만들 수 있도록했습니다. 비록 헤더 파일에 약간의 해커가 필요했습니다. (저는 Fortran 코드를 유지하는 것을 좋아하지 않습니다. Fortran보다 f2c'ed C를 보는 것이 낫습니다.

인텔 MKL 2018.3 :

Dotted two 4096x4096 matrices in 2.09 s.
Dotted two vectors of length 524288 in 0.23 ms.
SVD of a 2048x1024 matrix in 1.11 s.
Cholesky decomposition of a 2048x2048 matrix in 0.19 s.
Eigendecomposition of a 2048x2048 matrix in 7.83 s.

위에서 사용 된 벤치 마크에 대한 단어. Robert는이 벤치 마크 (또는 numpy?)가 Cholesky, EVD 및 SVD를 구현하는 방법을 알지 못한다면 해당 작업의 결과가 그다지 의미가 없을 것임을 상기 시켰습니다. 예를 들어 촐레 스키 분해에 netlib LAPACK 코드를 사용하면 알고리즘 블록 크기가 잘못됩니다 (이상적인 것과는 거리가 멀어짐). 또한 MKL에 대한 numpy 링크 방법에 따라 MKL에는 빠른 gemm 외에도 자체 Cholesky 인수 분해 구현이 있기 때문에 상황이 더 왜곡 될 수 있으므로 비교할 때 사과 대 사과가 아닐 수도 있습니다. MKL.

나는 당신이 단순히 성능에 대한 일반적인 아이디어를 얻기 위해 그것을 사용했을 수도 있다는 것을 알고 있으며, 괜찮습니다. 아주 근사한 비교를 위해 그것을 사용하는 것을 허용하지 않는 세부 사항에 악마가 숨어있을 수 있음을 이해하십시오.

일반적으로 numpy는 사용 가능한 LAPACK 또는 LAPACK 유사 라이브러리에 대해 이와 같은 작업을 연기합니다. MKL 빌드는 인텔이 MKL 내부에 제공하는 LAPACK의 튜닝 된 포크를 거의 확실히 사용하고 있습니다. BLIS 빌드는 아마도 참조 LAPACK 또는 이와 유사한 것을 사용하고있을 것입니다.

어떤 의미에서 이것은 공정합니다. 빠른 SVD를 수행하기 위해 numpy 구성을 선택하려는 경우 MKL에 사용 가능한 조정 된 버전이 있고 BLIS에는없는 것이 관련이 있습니다. (저는 OpenBLAS가 그 사이에 있다고 믿습니다. 그들은 라이브러리와 함께 LAPACK의 수정 된 버전을 제공하지만 MKL 버전보다 참조 구현에 훨씬 더 가깝습니다.)하지만 BLIS가 무엇인지, 왜 그 이유를 이해하려고한다면 결과는 이와 같이 보입니다. 순수한 GEMM 효율성보다 SVD / 등에 더 많은 것이 있다는 것을 기억하는 것이 중요합니다.

어떤 의미에서 이것은 공정합니다.

나는 이해하고 동의한다. 일부 사람들은 이전에 제안 된 것과 같은 벤치 마크를 사용하여 단일 하드웨어에서 절대 성능을 측정하고 (즉, 구현이 최고 성능에 비해 얼마나 좋은지 판단하기 위해),이를 사용하여 구현을 비교한다는 사실로 인해 복잡합니다. 나는 로버트의 Cholesky et al. 후자보다 전자를 더 많이 겨냥합니다.

@njsmith @insertinterestingnamehere @rgommers @charris Isuru 의 빠른 작업 덕분에 우리는 그의 Appveyor 기반 Windows 지원을 BLIS의 master 브랜치로 구체화하고 병합 할 수있었습니다. 이 문제가 numpy에 대한 Windows 지원 문제를 해결했는지 여부와 정도를 알려주십시오.

@fgvanzee PR에 연결할 수 있습니까?

PR에 연결할 수 있습니까?

네, 여기 있습니다.

초기 빌드 설정은 훌륭합니다! 적어도 이론 상으로는 Windows에서 BLIS로 numpy를 빌드하는 것으로 충분해야합니다. dll 빌드 또는 MinGW 지원과 같은 것은 나중에 추가 할 수 있습니다.

이 경우 사용되는 종속성에 대해주의해야 할 사항 : pthreads-win32는 LGPL입니다. 그래도 그것에 대해 무엇을해야하는지 IDK.

라이선스는 어려운 문제입니다. 나는 법적 정책으로 인해 LGPL과 같은 "카피 레프트"라이센스를 사용하기 어렵지만 "허용"라이센스는 문제가되지 않는 몇몇 대기업을 알고 있습니다. NumPy / SciPy 코드베이스 또는 휠에 LGPL 코드를 추가하는 것은 정당하건 아니건 확실히 우려의 원인이 될 것입니다.

여기서 코드베이스에 추가하지 않습니다. LGPL 부품을 바퀴로 운송하는 것은 문제가되지 않습니다. 이제 런타임 예외가있는 GPL 인 gfortran dll을 제공하고 있습니다. gh-8689 참조

과연. 또한 그러한 회사가 MKL을 선호하더라도 놀라지 않을 것입니다.

LGPL 구성 요소가 정적으로 링크되지 않았는지 확인하면됩니다.

@jakirkham 귀하의 의견에 감사드립니다. 스레드 풀이없는 것으로 관찰 된 비용은 전달하는 행렬 피연산자의 크기와 수행중인 작업에 따라 달라집니다. gemm이 당신이 목표로 삼는 전형적인 작업이라고 생각하지만 (내가 틀렸다면 수정하십시오), 어떤 문제 크기가 전형적인 것으로 간주합니까? BLIS의 create / join 모델의 비용은 A, B, C가 40x40 인 행렬 곱셈을 반복적으로 수행하는 경우 나타날 수 있지만 400x400 이상에서는 그다지 많지 않을 것입니다. (TBH, 40x40 문제를 병렬화함으로써 시작되는 속도 향상을 기 대해서는 안됩니다.)

주로 GEMM과 SYRK가 일반적입니다. GEMV가 가끔 나오지만 가능하면 큰 GEMM 작업으로 통합되는 경우가 많습니다.

적어도 10 ^ 6 요소의 차원 인 1 차원을 갖는 것은 우리에게 비정형이 아닙니다. 다른 하나는 10 ^ 3에서 10 ^ 6까지입니다. 그래서 그것은 상당히 다릅니다. 스레드 풀을 사용하기 위해해야 ​​할 일이 있습니까, 아니면 자동으로 발생합니까? 또한 프로세스가 분기되면 스레드 풀이 어떻게 작동합니까?

다른 점에서 BLIS는 동적 아키텍처 감지를 처리합니까? 이것은 한 번 빌드하고 다양한 다른 시스템에 배포 할 수있는 아티팩트를 빌드하는 데 매우 중요합니다.

예. 이 기능은 얼마 전인 2017 년 하반기에 구현되었습니다. BLIS는 이제 일부 휴리스틱 (예 : cpuid 명령)을 통해 런타임시 선택되는 특정 하위 구성을 사용하여 소위 "구성 제품군"을 대상으로 할 수 있습니다. 지원되는 제품군의 예는 intel64, amd64, x86_64입니다.

이에 대해 약간의 머리말을 붙이기 위해 Broadwell을 통해 Nehalem을 사용하는 오래된 컴퓨터가 있습니다. 새로운 개인용 컴퓨터에는 Kaby Lake가있을 수 있습니다. 따라서 지원되지 않는 내장 함수를 사용하여 고대 컴퓨터에서 실행하는 경우 충돌하지 않는 동시에 제공되는 아키텍처를 최대한 활용할 수있는 것이 중요합니다. Flame의 하위 구성이이 범위를 지원합니까? 다른 아키텍처에서 적절한 커널을 디스패치하기 위해 내장 된 추가 코드가 있습니까? 이것은 얼마나 세분화됩니까? 이러한 커널이 있는지 확인하기 위해 빌드 중에 수행해야 할 작업이 있습니까?

x86_64 구성을 사용하여 @jakirkham을 구축하면 다음과 같은

• Penryn (Nehalem 및 기타 64 비트 SSSE3 Intel 칩 포함)
• 샌디 브리지 (아이비 브리지 포함)
• Haswell (+ Broadwell, Skylake, Kaby Lake 및 Coffee Lake, 마지막 3 개에 대해 완전히 최적 은 아닐 수 있음)
• Xeon Phi (1 세대 및 2 세대, 필요한 경우 3 세대도 가능)
• Skylake SP / X / W (아마도 Cannon Lake에서도 최적에 가깝습니다)
• 불도저 / 파일 드라이버 / 스팀 롤러 / 굴착기
• 라이젠 / EPYC

이들 중 일부는 새로운 컴파일러 및 / 또는 binutils 버전이 필요하지만 빌드 머신에서만 필요합니다.

AFAIK libflame에는 아키텍처에 대한 특수 커널이 없습니다. 이는 모두 BLIS에 달려 있습니다.

@jakirkham 우리는 스레드 풀 구현을 추가해야합니다. 지금은 포크로부터 안전해야하는 기본 fork-join 구현입니다.

AFAIK libflame에는 아키텍처에 대한 특수 커널이 없습니다. 이는 모두 BLIS에 달려 있습니다.

이것은 대부분 정확합니다. libflame에는 Givens 회전을 적용하기위한 몇 가지 내장 (현재 SSE 만) 커널이 있지만 이러한 커널은 libflame에 속하지 않으며 BLIS가 작성 될 당시 존재하지 않았기 때문에 존재하기 때문에 다른 곳이 없었습니다. 그들을 수용하십시오. 결국 이러한 커널은 다시 작성되고 업데이트되며 BLIS로 재배치됩니다.

Flame의 하위 구성이이 범위를 지원합니까? 다른 아키텍처에서 적절한 커널을 디스패치하기 위해 내장 된 추가 코드가 있습니까? 이것은 얼마나 세분화됩니까? 이러한 커널이 있는지 확인하기 위해 빌드 중에 수행해야 할 작업이 있습니까?

@jakirkham 이 경우 "불꽃"이 무슨 뜻인지 잘 모르겠습니다. libflame과 BLIS의 두 가지 제품이 있습니다. libflame은주의가 필요하고 재 작성이 필요할 수 있지만 지난 몇 년 동안 거의 모든주의가 BLIS에있었습니다.

텍스트로 "Flame"을 "BLIS"로 바꾸면 대답은 "예, 대부분"입니다.

얼마나 세분화됩니까?

무슨 뜻인지 잘 모르겠지만 BLIS의 커널 지원은 OpenBLAS만큼 광범위하지 않습니다. 예를 들어, 우리는 종종 복잡한 도메인 trsm 최적화하지 않습니다. 커널은 일부 조합에서 하위 구성에 의해 활용됩니다. 하위 구성은 cpuid 를 통해 선택됩니다. 하위 구성에 의해 "등록"된 커널을 정확하게 얻습니다. 너트와 볼트에 대한 자세한 내용은 구성 위키를 참조하십시오.

이러한 커널이 있는지 확인하기 위해 빌드 중에 수행해야 할 작업이 있습니까?

당신이 하드웨어 검색을 런타임 필요하면 구성 제품군 (예 : 대상 intel64 , x86_64 대신 특정 하위 구성의 구성 타임에 () 또는 auto , 선택을 특정 하위 구성). 그게 다야.

스레드 풀을 사용하기 위해해야 ​​할 일이 있습니까, 아니면 자동으로 발생합니까? 또한 프로세스가 분기되면 스레드 풀이 어떻게 작동합니까?

이전에이 스레드에서 말했듯이 BLIS는 스레드 풀을 사용하지 않습니다. 그리고 나는 포크 안전에 대해 Devin에게 연기합니다 (그리고 그는 포크가 문제가되지 않을 것이라고 생각하는 것 같습니다).

참고로 BLIS conda 패키지는 conda-forge의 Linux, osx, Windows에서 사용할 수 있습니다. (현재 개발 브랜치를 구축 중이며 릴리스를 기다리고 있습니다). 패키지는 pthread가 활성화되고 x86_64 구성으로 빌드되었습니다.

그는 Python 라이브러리를 배송하고 있습니다. 그는 사용자가 자신의 라이브러리를 가져 와서 동일한 프로세스에서 함께 실행되는 다른 라이브러리 및 자체 코드와 결합 할 것으로 기대합니다. 그의 라이브러리는 GEMM을 사용하며, 그가 제어하지 않거나 심지어 알고있는 다른 코드 중 일부도 GEMM을 사용하기를 원할 것입니다. 그는 동일한 프로세스에서 발생할 수있는 GEMM에 대한 다른 관련없는 호출에 우연히 영향을주지 않고 GEMM에 대한 호출에 대한 스레딩을 제어 할 수 있기를 원합니다.

@njsmith 로버트와 이야기를

@jakirkham 인텔 담당자 중 한 명인 @jeffhammond 는 OpenMP 구현이 내부적으로 스레드 풀 모델을 일상적으로 사용한다고 알려줍니다. 따라서 그는 BLIS 내에서 스레드 풀을 중복으로 구현하는 것을 권장하지 않습니다.

이제 제안한대로 numpy가 pthread를 필요로하거나 선호하는 경우 일 수 있습니다.이 경우 fork / join-style pthreads API 아래에서 발생하는 실제 fork / join으로 돌아갈 수 있습니다.

그렇다면 pthreads, OpenMP를 모두 사용하고 있습니까?

또한이 질문에 대답하는 것을 잊었다는 것을 깨달았습니다. BLIS의 다중 스레드 병렬 처리는 구성 가능합니다. pthreads 또는 OpenMP를 사용할 수 있습니다. (그러나 이것은 라이브러리 초기화에 사용되는 pthread_once() 에 대한 의존으로 인해 pthread에 대한 BLIS의 무조건 런타임 종속성과 혼동해서는 안됩니다.)

불행히도 OpenMP 구현 (예 : GOMP)이 일반적으로 포크에 대해 더 강력 해지지 않는 한, Python에서는 실제로 안전한 옵션이 아닙니다. 특히 스택에서 NumPy만큼 낮은 것은 아닙니다.

불행히도 OpenMP 구현 (예 : GOMP)이 일반적으로 포크에 대해 더 강력 해지지 않는 한, Python에서는 실제로 안전한 옵션이 아닙니다. 특히 스택에서 NumPy만큼 낮은 것은 아닙니다.

그럴 수 있지. 따라서 numpy는 BLIS를 통한 멀티 스레딩을 위해 --enable-threading=pthreads 구성 옵션에 의존하는 것처럼 들립니다.

pthread로 컴파일 할 때 numpy를 호출하는 Python 프로세스 / 스레드 풀과 중첩 된 병렬 처리를 수행 할 때 초과 구독 문제를 방지하기 위해 프로그래밍 방식으로 제어 할 수있는 일부 공용 API가 있습니까?

좀 더 구체적으로 내가 찾는 공용 기호의 종류는 다음과 같습니다.

https://github.com/tomMoral/loky/pull/135/files#diff -e49a2eb30dd7db1ee9023b8f7306b9deR111

MKL 및 OpenMP 용 https://github.com/IntelPython/smp 에서 수행되는 작업과 유사합니다.

pthread로 컴파일 할 때 numpy를 호출하는 Python 프로세스 / 스레드 풀과 중첩 된 병렬 처리를 수행 할 때 초과 구독 문제를 방지하기 위해 프로그래밍 방식으로 제어 할 수있는 일부 공용 API가 있습니까?

@ogrisel 좋은 질문입니다, Olivier. 런타임에 스레딩 매개 변수를 설정하는 방법이 있지만 현재 전역 의미론으로 수행됩니다. ( gemm 또는 그 어떤 것이 든 호출 당 기준이 아니라 전역이 아닌) 환경 변수를 통해 공급하기 때문에 차선책입니다.

저는 현재 누군가가 BLIS의 소위 "전문가"하위 API 중 하나를 사용하여 추가 데이터 구조를 gemm 로 전달할 수 있도록 기본 코드를 약간 재 설계하고 있습니다. 호출자가 호출별로 병렬화 전략을 지정해야합니다. 앞서 언급 한 데이터 구조를 통해 사람들은 단일 스레드 수를 지정할 수 있으며 BLIS가 병렬 처리를 얻을 위치 또는 행렬 곱셈 알고리즘 (BLIS가 선호하는대로)의 각 루프에 대한 병렬 처리 수준을 파악하기 위해 자동으로 최선을 다할 수 있습니다.

어느 쪽이든이 새로운 접근 방식이 귀하의 요구를 충족시킬 것이라고 생각합니다. 나는 이미 변경 사항을 반쯤 완료했기 때문에 새로운 기능을 github에 푸시한지 1 주일 정도라고 생각합니다. 이 계획이 귀하에게 효과가있는 것처럼 들리거나이 주제에 대해 다른 우려 사항이나 요청이있는 경우 알려주십시오.

추신 : 당신이 제공 한 로키 링크를 살펴 보았습니다. 이러한 기호는 모두 스레드의 전역 설정을 위해 설정됩니다. 내가 제안한 솔루션은 전 세계적으로 설정하는 것을 배제하지는 않지만 이것이 유일한 옵션이 아니도록 설계되었습니다. 따라서 최대 8 개의 코어 / 스레드를 사용하려는 사람은 응용 프로그램에서 2 개의 스레드를 생성 할 수 있으며 각 스레드는 4 방향 병렬 처리를 제공하는 gemm 인스턴스를 호출합니다. 또는 3 개의 애플리케이션 스레드에서 2 개는 양방향 병렬 처리로 gemm 를 호출하고 세 번째는 4 방향 병렬 처리를 사용합니다. (당신은 아이디어를 얻습니다.)

환경 변수를 통해 공급합니다.

무슨 뜻이에요? 특정 Python 프로세스에서 이미 초기화 된 경우 Python의 ctypes를 사용하여 기본 / 전역 BLIS 스레드 풀의 크기를 재구성 할 수 있습니까?

환경 변수를 통해 공급합니다.

무슨 뜻이에요?

@ogrisel 이것이 의미하는 것은 BLIS에 OpenMP의 omp_get_num_threads() 및 omp_set_num_threads() 와 유사한 스레드 수를 설정하거나 가져 오는 작은 API가 있다는 것입니다. 그러나 이러한 BLIS API 함수는 getenv() 및 setenv() 호출로 구현됩니다. 이것은 BLIS의 원래 사용 사례 중 하나가 셸에 하나 이상의 환경 변수 (예 : bash )를 설정 한 다음 BLIS 연결 응용 프로그램

특정 Python 프로세스에서 이미 초기화 된 BLIS 스레드 풀의 크기를 재구성하기 위해 Python의 ctypes를 사용할 수 있습니까?

BLIS는 명시 적으로 스레드 풀을 사용하지 않습니다. 오히려 우리는 pthread를 통해 병렬성을 추출하기 위해 create / join 모델을 사용합니다. 그러나 예, BLIS가 초기화 된 후 애플리케이션 (또는 호출 라이브러리)은 적어도 원칙적으로 함수 호출을 통해 런타임에 스레드 수를 변경할 수 있습니다. (그러나 이것이 실제로 작동하는지는 모르겠지만, 파이썬이 환경 변수를 설정 / 가져 오려고 시도하는 BLIS를 어떻게 처리할지 모르기 때문입니다.) 그러나 앞서 언급했듯이 몇 가지 수정을 완료하면 응용 프로그램 / 라이브러리는 레벨 3 작업이 호출 될 때 호출별로 사용자 지정 병렬화 체계를 지정할 수 있습니다. 이는 먼저 작은 struct 데이터 유형을 초기화 한 다음 struct 를 gemm 에 대한 BLIS API의 확장 된 "전문가"버전에 전달하여 수행됩니다.) 필요하지 않거나 원하지 않는 사람들에게 환경 변수를 불필요하게 만들 것입니다. 이것이 귀하의 질문에 대한 답변이 되었기를 바랍니다.

설명해 주셔서 대단히 감사합니다. 호출 별 전문가 API는 흥미롭지 만 Python 수준 호출자에게이를 노출하기 위해 특정 API를 유지하려면 numpy가 필요합니다. 우리가 그것을 원하는지 잘 모르겠습니다. numpy 사용자에게는 전역 (프로세스 수준) 병렬 처리 수준의 현재 값을 변경하는 방법이 있으면 충분하다고 생각합니다. 이 변경이 후속 BLAS-3 호출을 고려하는 한 env 변수의 현재 값을 변경하여 달성되었는지 개인적으로 신경 쓰지 않습니다.

@charris float16은 개인적인 경험이 없지만 적어도 예측 시간에는 일부 기계 학습 워크로드에 대해 실제로 흥미로울 수 있습니다.

numpy 사용자에게는 전역 (프로세스 수준) 병렬 처리 수준의 현재 값을 변경하는 방법이 있으면 충분하다고 생각합니다. 이 변경이 후속 BLAS-3 호출을 고려하는 한 env 변수의 현재 값을 변경하여 달성되었는지 개인적으로 신경 쓰지 않습니다.

알아 둘만 한. 그렇다면 BLIS는 numpy가 사용할 준비가 된 것에 훨씬 더 가깝습니다. (이전에 이러한 진행중인 수정을 먼저 수행하고 이전에 알지 못했던 경쟁 조건을 수정하고 싶습니다.)

getenv 는 매우 빠르지 않으므로 나중에 제거하는 것이 좋을 수 있기 때문에 모든 호출에서 다시 검사되는 환경 변수에 의존하지 않는 것이 좋습니다. (또한 스레드 안전성이 보장되지 않는다고 생각합니까?)하지만 bli_thread_set_num_threads API 호출은 괜찮을 것입니다. BLIS가 항상 getenv 호출을 중지하더라도 API가 호출되기 때문입니다. 작업을 계속하도록 조정할 수 있습니다.

장기적으로 보면 numpy에서 베어 BLAS API를 일부 공개하기 시작하는 것이 합리적이라고 생각합니다. BLIS를 처음부터 매력적으로 만드는 것 중 하나는 strided 행렬을 곱하는 기능과 같이 다른 BLAS 라이브러리가 제공하지 않는 기능을 제공 하고 다양한 방법으로 BLAS API를 확장하기위한 작업이 진행되고 있다는

numpy의 API에서 라이브러리 별 세부 사항을 하드 코딩하고 싶지는 않지만 (예 : np.matmul 가 BLIS의 JC, IC, JR 및 IR 매개 변수에 해당하는 인수를 가져 오는 것을 원하지 않습니다),하지만 해당 기능을 제공하는 백엔드에서만 작동하는 일반적인 "이 호출에 대한 스레드 수"인수를 제공하는 것이 좋습니다.

내가 언급하지 않은 한 가지는 인덱스 정밀도입니다. 대부분의 시스템 제공 라이브러리는 32 비트 정수를 사용하는 것으로 보이며 이는 요즘 일부 응용 프로그램의 제한 사항입니다. 어떤 시점에서 모든 인덱스가 64 비트이면 좋을 것입니다. 아마도 라이브러리를 제공해야 할 것입니다. 인덱스 크기와 관련하여 현재 무엇을하고 있는지 모르겠습니다. @ matthew-brett 여전히 32 비트 정수로 컴파일하고 있습니까?

@charris BLIS의 정수 크기는 구성시 32 비트 또는 64 비트로 구성 할 수 있습니다. 또한 내부 정수 크기와는 별도로 BLAS API에서 사용되는 정수 크기를 구성 할 수 있습니다.

사실 저를 상기시켜줍니다. 저는 지난주에 자신의 라이브러리에서 더 높은 수준의 스레딩을 관리하고 있었기 때문에 gemm 단일 스레드를 호출하기를 원한다는 것을 알고 있던 누군가와 이야기했습니다. 그는 표준 blas 라이브러리를 사용하는 유일한 방법입니다. 제어는 임의의 라이브러리 내부에서 호출하기 쉬운 전역 설정을 통해 이루어집니다.

@njsmith 앞서 언급 한 경쟁 조건을 수정하고 스레드로부터 안전한 호출 당 멀티 스레딩 API도 구현했습니다. 친구에게 fa08e5e (또는 해당 커밋의 자손)를 가리 킵니다. 멀티 스레딩 문서 도 업데이트되었으며 기본 예제와 함께 독자가 선택한 사항을 안내합니다. 커밋은 현재 dev 브랜치에 있지만 곧 master 에 병합 할 예정입니다. (이미 대부분의 속도를 통해 코드를 작성했습니다.)

편집 : 사소한 수정 커밋을 반영하도록 링크가 업데이트되었습니다.

지원되는 유형에 가능한 추가로 long double 어떻습니까? 일부 아키텍처가 (여전히 소프트웨어에서) 4 중 정밀도를 지원하기 시작하고 있으며 어느 시점에서 확장 정밀도가 인텔에서 4 중 정밀도로 대체 될 것으로 예상합니다. 나는 이것이 당장 시급하다고 생각하지 않지만, 수년이 지나면 일이 그렇게되기 시작했다고 생각합니다.

@charris 우리는 특히 기계 학습 / AI 애플리케이션 때문에 bfloat16 및 / 또는 float16 에 대한 지원을 고려하는 초기 단계에 있지만 double double 대한 수요도 알고 있습니다.

@charris https://en.wikipedia.org/wiki/Long_double 에 따르면 long double 는 다양한 의미를 가질 수 있습니다.

• x87에서 구현 된 80 비트 유형, 12B 또는 16B 스토리지 사용
• MSVC를 사용한 배정 밀도
• 배정 밀도
• 4 배 정밀도
  의미가 모호하고 하드웨어뿐만 아니라 사용되는 컴파일러에 따라 다르기 때문에 ABI가 잘 정의되지 않았기 때문에 라이브러리에 대한 완전한 재앙입니다.

성능 측면에서 SIMD 버전이 없기 때문에 float80 (예 : x87 long double)에 대한 상승은 보이지 않습니다. BLIS에서 double double 의 SIMD 버전을 작성할 수 있다면 더 나은 성능을 발휘할 것입니다.

소프트웨어의 float128 구현은 하드웨어의 float64보다 적어도 크기가 더 느립니다. 모든 FPE 처리를 건너 뛰고 SIMD를 사용할 수있는 float128의 새로운 구현을 작성하는 것이 현명 할 것입니다. libquadmath의 구현은 정확하지만 BLIS와 같은 고성능 BLAS 구현의 주목할 가치가 없습니다.

네, 문제입니다. 확장 된 정밀도는 노력할만한 가치가 없다고 생각합니다. 그리고 4 중 정밀도에 대한 필요성은 반점이 있고, double은 대부분의 일에 좋지만 필요할 때 필요합니다. 나는 성능에 대해 걱정하지 않고 속도가 아니라 정확성이 필요합니다. 물론 소프트웨어 구현 인 4 중 정밀도 long double을 사용하여 ARM64에 대한 지원을 확장했지만, 하드웨어가 어느 시점에서 따를 것으로 예상하고 무언가를 테스트하고 준비하는 것이 좋을 수 있습니다.

BLAS G2 제안 은

앞으로 나아가는 것을 보게되어 기쁩니다!

기록을 위해 @njsmith 가 소프트웨어에서 스레딩을 제어하는 ​​데 관심이있는 사람을 언급 한 사람입니다. 내 워크로드는 예측 시간에 당황 할 정도로 병렬 적이며 행렬 곱셈은 상대적으로 작습니다. 그래서 저는 더 큰 작업 단위를 병렬화하고 싶습니다.

약 1 년 전에 PyPi 용 Blis를 패키징하고 Cython 바인딩을 추가하는 작업을 수행했습니다. https://github.com/explosion/cython-blis

Blis는 이와 같은 C 확장으로 패키징하기가 매우 쉽다는 것을 알았습니다. 저에게 가장 큰 걸림돌은 Windows 지원이었습니다. 기억으로는 C99 문제 였지만 잘못 기억하고있을 수 있습니다.

내가 추가 한 Cython 인터페이스가 흥미로울 수 있습니다. 특히 Cython의 융합 유형을 사용하여 float 및 double 유형 모두에 대해 메모리 뷰 또는 원시 포인터로 호출 할 수있는 단일 nogil 함수가 있습니다. 더 많은 유형에 대해 더 많은 분기를 추가하는 것도 문제가되지 않습니다. 통합 된 유형은 기본적으로 템플릿입니다. 컴파일시 조건부 실행을 허용하여 오버 헤드가 없습니다.

나는 독립형 Blis 패키지를 유지하고, 바퀴를 만들고, 멋진 Cython 인터페이스를 유지하는 등 매우 기쁠 것입니다. 나는 그것을 numpy 내에 통합 된 것보다 별도의 패키지로 갖는 것이 매우 좋을 것이라고 생각합니다. 그런 다음 다른 BLAS 라이브러리가 지원하는 것에 제한을받지 않고 Blis의 API를 더 많이 노출 할 수 있습니다.

@honnibal 이 스레드에서 응답이 지연되어 죄송합니다, Matthew.

메시지를 보내 줘서 고마워요. 우리는 다른 사람들이 BLIS에 대해 흥분하는 것을 항상 기쁘게 생각합니다. 물론 Python 생태계 (애플리케이션, 라이브러리, 모듈 등)에 추가로 통합하기로 결정한 경우 필요할 때마다 조언 해 드리겠습니다.

Windows 지원에 대해서는 @isuruf가 최근에 추가 한 Windows ABI에 대한 clang / appveyor 지원을 확인하십시오. 마지막으로 그에게서 들었을 때 예상대로 작동했지만 여기 UT에서 Windows에 대한 개발을 수행하지 않기 때문에이 문제를 직접 확인할 수 없습니다. (Isuru가 한때 Travis CI와 비슷한 방식으로 appveyor에 가입 할 수 있다고 지적했지만)

또한 통화 별 스레딩 사용에 대해 궁금한 점이 있으면 알려주세요. (이 주제를 다루기 위해 멀티 스레딩 문서를 업데이트했습니다.)

BLIS 0.5.2부터는 Marvell ThunderX2를 포함한 다양한 많은 코어 아키텍처에서 대표적인 데이터 유형 세트와 레벨 3 작업에 대한 BLIS의 단일 스레드 및 다중 스레드 성능과 BLAS의 기타 구현을 보여주는 성능 문서가 있습니다. , Intel Skylake-X, Intel Haswell 및 AMD Epyc.

따라서 numpy 커뮤니티가 BLIS가 다른 선도적 인 BLAS 솔루션과 어떻게 비교되는지 궁금해한다면 간단히 살펴 보도록 권합니다!

매우 흥미 롭습니다. @fgvanzee에게 감사드립니다.

Epyc을 찾아야했습니다. Zen (언젠가는 Zen +로 업데이트되었을 수 있음) 아키텍처를 기반으로 한 브랜드 이름 인 것 같습니다. Zen으로 이름을 바꾸는 것이 더 낫습니까? 사용자 기반 Ryzen / Threadripper는 더 흥미로운 브랜드입니다. Zen은 인식 할 수 있지만 Epyc은 인식하지 못할 수 있습니다.

Epyc는 AMD 서버 라인의 이름입니다. 과거 AMD Opteron 제품의 후속 제품입니다.

안타깝게도 BLIS가 아키텍처 타겟에 레이블을 지정하는 고유 한 방법은 없습니다. 코드는 벡터 ISA (예 : AVX2), CPU 코어 마이크로 아키텍처 (예 : Ice Lake) 및 SOC / 플랫폼 통합 (예 : Intel Xeon Platinum 프로세서)에 의존하기 때문입니다. ). BLIS는 경우에 따라 (예 : Dunnington) 마이크로 아키텍처 코드 이름을 사용하지만 모든 사람에게 더 좋은 것은 아닙니다.

@fgvanzee GCC march / mtune / mcpu 이름에 해당하는 별칭을 추가하는 것을 고려할 수 있습니다.

@rgommers Ryzen 및 Epyc을 포함하는 BLIS 내의 하위 구성은 두 제품을 모두 캡처하므로 실제로 이미 zen 이름이 지정되었습니다.

Ryzen / Threadripper 또는 Epyc이 더 흥미로운 브랜드인지에 관해서는 (수많은 사용자에게도) 이렇게 말할 것입니다. 하나의 AMD Zen 시스템 만 벤치 마크 할 수 있다면 최고급 Epyc이 될 것입니다. Ryzen과 유사한 마이크로 아키텍처를 사용합니다. (b) 최대 64 개의 물리적 코어를 제공합니다 (또한 이러한 코어는 다소 참신한 NUMA와 유사한 구성으로 배열되어 있습니다). (c) BLIS 및 기타 구현에 최대 스트레스를가합니다. 이것이 기본적으로 우리가 여기서 한 일입니다.

이제 고맙게도 하나의 Zen 시스템 만 벤치마킹 할 수 있다는 규칙이 없습니다. :) 그러나, 특히 처음에 액세스 권한을 얻는 것과 관련하여 다른 장애물이 있습니다. 현재 Ryzen / Threadripper 시스템에 액세스 할 수 없습니다. 액세스 권한이 있으면 실험을 반복하고 그에 따라 결과를 게시하겠습니다.

Jeff는 우리가 직면 한 이름 지정 함정 중 일부를 지적합니다. 일반적으로 마이크로 아키텍처 측면에서 하위 구성 및 커널 집합의 이름을 지정하지만 아직 미묘한 차이가 있습니다. 예를 들어 Haswell, Broadwell, Skylake, Kaby Lake 및 Coffee Lake에서 haswell 하위 구성을 사용합니다. 기본적으로 모두 BLIS 커널 코드가 신경 쓰는 거의 모든 동일한 벡터 ISA를 공유하기 때문입니다. 그러나 이는 거의 사용자가 관심을 가질 필요가없는 구현 세부 사항입니다. ./configure auto 를 사용하면 이름이 zen 이든 haswell 이든 상관없이 거의 항상 시스템에 가장 적합한 하위 구성 및 커널 세트를 얻을 수 있습니다. 지금은 스레딩 체계를 최적으로 선택하는 데있어 더 많은 실습 접근 방식을 취해야하며, 여기에서 Jeff가 언급 한 SoC / 플랫폼 통합이 필요합니다.

@jeffhammond 제안 config 디렉토리)의 이름. 이제 BLIS가 예를 들어 ./configure haswell 를 통해 하위 구성을 수동으로 식별해야한다면 스케일이 귀하의 제안에 유리하게 팁을 준다고 생각합니다. 하지만 ./configure auto 은 (는) 꽤 잘 작동하므로 현재로서는 필요하지 않습니다. (원한다면이 주제에 대한 문제를 열어 커뮤니티 구성원들 사이에서 더 넓은 토론을 시작할 수 있습니다. 충분한 수요가 있으면 항상 마음을 바꿀 수 있습니다.)

예, 이름 지정은 항상 복잡합니다.) @fgvanzee 및 @jeffhammond 답변에 감사드립니다.

# 13132와 ​​# 13158은 관련이 있습니다.

토론은 조금 잊혀졌습니다. numpy에서 BLIS를 공식적으로 지원하기 위해 해결해야 할 나머지 문제는 무엇입니까?

순진하게, 나는 conda-forge (cf https://github.com/numpy/numpy/issues/14180#issuecomment-525292558)에서 BLIS로 numpy 테스트를 실행하려고 시도했으며 나에게는 Linux에서 모든 테스트가 통과되었습니다 (하지만 아마도 나는 놓친 것).

또한 동일한 환경에서 테스트 scipy 테스트 스위트를 실행하려고 시도했으며 누군가에 대한 의견이있는 경우 scipy.linalg (cf https://github.com/scipy/scipy/issues/10744 참조)에 여러 오류가 있습니다. 그.

conda-forge의 BLIS는 libflame 아니라 BLIS를 BLAS 구현으로 사용하는 LAPACK 구현으로 ReferenceLAPACK (netlib)을 사용합니다.

conda-forge의 BLIS 옵션에 대해 OpenBLAS 옵션과 달리 상자에서 단일 스레드로 구성되어 있다는 것이 맞습니까?

conda-forge 토론을 conda-forge로 옮기는 것이 아마도 더 좋습니다 🙂