mir.pe (일반/어두운 화면)
최근 수정 시각 : 2024-11-01 15:52:18

고급 벡터 확장

AVX에서 넘어옴

명령어 집합
CISC AMD64 ● x86 ● · M68K · 68xx · Z80 · 8080 · MOS 65xx · VAX
RISC AArch64 ARM · RISC-V ● · MIPS ● · DEC Alpha · POWER PowerPC · CELL-BE
LoongArch · OpenRISC · PA-RISC · SPARC · Blackfin · SuperH · AVR32 AVR
VLIW
EPIC 		E2K · IA-64 · Crusoe

<rowcolor=#fff> x86 · AMD64 확장 명령어 집합
인텔 주도 확장 명령어
범용 APX
SIMD MMX · SSE SSE2 · SSE3 · SSSE3 · SSE4.1 · SSE4.2 · AVX AVX2 · AVX-512 · AVX10 · AMX
AVX-512: F · CD · DQ · BW · VL · IFMA · VBMI · VBMI2 · VNNI · VAES · GFNI · BITALG
AVX[1]: AVX-VNNI · AVX-IFMA
AVX10: AVX10.1 · AVX10.2
비트 조작 BMI1 · BMI2 · ADX
보안 및 암호 AES-NI · CLMUL · RDRAND · RDSEED · SHA · MPX · SGX · TME · MKTME
가상화 및 기타 VT-x(VMX) · SMX · TSX
AMD 주도 확장 명령어
SIMD 및 비트 연산 3DNow! PREFETCHW · F16C · XOP · FMA FMA4 · FMA3
비트 조작 ABM
보안 및 암호 SME
가상화 및 기타 AMD-V
[1] 512-bit EVEX 인코딩된 AVX-512 명령어의 256-bit VEX 인코딩 버전

1. 개요2. 특징
2.1. AVX2.2. AVX22.3. AVX-512(AVX3)
2.3.1. 프로파일
2.3.1.1. F, CD, ER, PF2.3.1.2. VL, DQ, BW2.3.1.3. IFMA52, 4FMAPS, VBMI, VBMI22.3.1.4. VPOPCNTDQ2.3.1.5. VNNI, 4VNNIW2.3.1.6. BF162.3.1.7. BITALG2.3.1.8. VP2INTERSECT
2.3.2. AVX_VNNI2.3.3. AVX_IFMA
2.4. AVX10
2.4.1. 프로파일
2.4.1.1. AVX10.12.4.1.2. AVX10.2
2.5. AMX
3. 지원 프로세서
3.1. AVX3.2. AVX23.3. AVX-5123.4. AVX10
4. 관련 문서

1. 개요

파일:989283488234.jpg

고급 벡터 확장(Advanced Vector eXtensions)은 2008년 4월 인텔 개발자 포럼에서 발표된 x86 SIMD 명령어 세트로 SSE 명령어 세트 시리즈의 후속작이다. 2011년에 출시한 인텔 샌디브릿지 마이크로아키텍처에서 최초로 지원한다.

2. 특징

파일:efd4878170b6090e7eba79943fa9be1d.jpg
파일:SIMD AVX2 512.gif

MMX에서 SSE로 넘어가던 시기에서 최대 4배에 이르는 성능 향상폭을 기록했던 것 처럼, AVX의 지원은 최대 2.5배, AVX-512에서는 7배가 넘는 큰 성능 향상폭을 기록한다.
성능 향상에 대한 상세 설명

이 명령어를 활성화하면[1] 엄청난 부하가 걸려 어마어마한 발열을 볼 수 있다. 하지만 무턱대고 꺼버리면, 해당 명령어를 지원하는 SW[2]에서 성능이 몇 % 수준이 아니라 수배나 떨어지기 때문에, 성능을 위해 오버클럭하는 사람들은 함부로 못 끈다. 하지만 성능이 아니라 단순히 높은 클럭만을 위하는 변태 오버클럭커들은 반드시 끄는 명령셋 중 하나이다.[3]

성능 향상이 커 페도라(운영 체제) 32 부터는 필수 옵션이라 일반 사용자는 성능을 떠나서 함부로 끄면 안된다. 부팅이 안될 수 도 있다.

샌디브릿지가 엄청난 인기를 끌 수 있었던 비결 중의 하나이기도 하다. 반면에 펜티엄, 셀러론, 아톰 시리즈에서는 보통 지원하지 않으며, 샌디브릿지 세대에 들어서야 SSE4.x를 지원하게 되었다. 하지만 엘더레이크 셀러론과 그레이스몬트부터 AVX2를 지원한다고 인텔 Ark 상에 명시하면서 지원을 발표했다.

파일:95c731a13444632.jpg
인텔에서 만들기 때문에 전통적으로 인텔이 AMD나 VIA 보다 빠르게 적용중이다. AMD에서 지원해도 초기에는 반쪽짜리 지원을 한다. 가령 ZEN1~ZEN+까지 AVX2 구동시 128bit로 나누어 2 싸이클 동안 연산했으며 시간이 지나 ZEN 2부터 한 사이클에 256bit AVX2를 처리할 수 있게되었다. 그 후 ZEN 4에서 AVX-512 지원이 추가되는데, 얘도 256bit 2싸이클로 나누어서 연산한다.[4] 이 때문에 최신 AVX 명령어는 AMD에서 여전히 성능적으로 향상이 있지만 인텔만큼 크게 성능이 향상되지는 않는 편이다. 가령 위의 그래프 처럼 인텔 CPU에서 AVX-512는 최대 7.2배 성능이 향상되지만 AMD ZEN 4에서는 최대 3.6배 성능이 향상된다. # 이는 ZEN4에선 512비트의 레지스터가 없어 512비트 명령어 자체는 처리할 수 있으나 2사이클로 나누어 처리하기 때문에 실제 최종 스루풋은 256bit의 AVX2와 동일하기 때문. 물론 이는 이론상 최대치 기준이며, 최종적인 실제 테스트에서는 이 정도로까지 효율이 현격하게 벌어지진 않는다. 현실적으로 모든 프로그램들의 코드가 전부 100% 512bit로만 되어 있는 게 아니기 때문.

CPU에 직접 명령어를 요청하여 사용하기 때문에 각각의 기능을 사용하기 위해서는 프로그래머가 개별적으로 코드를 추가해야 하며, 이미 만들어진 프로그램을 운영체제나 CPU에서 추후에 기능을 활용하게 만들 수는 없다. 게다가 자동으로 각각의 명령어 별로 SSE도 SSE, SSE2, SSE3, Supplement SSE3, SSE4.1, SSE4.2 이렇게 조금씩 조금씩 명령어를 추가했기 때문에, 다양한 플랫폼에 동작하는 SSE 최적화 구현을 만들려면 예를 들어 up-to-SSE2 구현, up-to-Supp.SSE3 구현, up-to-SSE4.2 구현 이렇게 여러 구현을 만들어두고, CPU 가 지원하는 명령어셋을 인식해서 그에 맞는 구현을 호출하도록 해야했다. 아니면 최신 명령어셋이 주는 이점을 포기하는 대신 가장 널리 지원되는 쪽에 초점을 맞추어 up-to-SSE2 혹은 up-to-Supp.SSE3 구현 하나만 만들던가. 물론 시간이 한참 흐른 요즘에야 저전력 Intel N 시리즈 CPU 도 SSE4.2 까지 다 지원하고 Microsoft .NET 8 이상의 프레임워크는 자동으로 AVX/AVX-512 사용을 식별해 적극 사용토록 한다던지 등 개발환경의 번거로움이 많이 사라졌지만, ARM NEON 이 그냥 ARM NEON 명령어 셋 하나로 끝나는 것에 비하면 Intel SSE 최적화는 엄청나게 번거로워 프로그래머의 원성을 살 수 밖에 없었다.

단 이건 ARM이 훨씬 짧은 역사를 가졌고 저전력을 추구하는 프로세서였던 탓도 있다. ARM 도 VFP 라고 현재 사실상 사장된 벡터 명령어셋이 있다. VFP 는 명령어 하나로 여러개의 floating point register 여러개를 벡터처럼 묶어서 동시처리하는 것. 하지만 32b floating point register 숫자 자체에 빡빡한 한계가 있기 때문에 제대로 활용하기도 힘들도 성능 향상도 한계가 있다. 또한 NEON은 기능이 그렇게 많지 않다. SSE2와 NEON간은 기능 차이가 크게 나지 않기에 상호 이식도 나름 쉬운 편이지만 SSE3 부터는 NEON에서 지원하지 않는 기능들이라 1:1 매칭이 어렵다.[5] 즉 ARM 도 뻘짓하다가 뻘짓을 깨닫고 VFP 를 사장시키고 단일화된 128b NEON 을 내놓으면서 교통정리에 신경을 쓰고 있는 반면 인텔은 SSE 에서 지속적인 뻘짓을 해놓고도 이를 AVX 에서도 이어갔으며 AVX-512 에서는 오히려 뻘짓을 극대화시켰다는게 차이라고 볼 수 있다. ARM도 언젠가 시간이 NEON의 스펙이 세월에 뒤떨어지게 되면 결국 파편화가 되던지 하위 호환을 포기하던지 아예 고성능 벡터 명령어셋을 더 추가하는 식의 선택을 하게 될 것이다. 실제로 ARM은 회사마다 커스텀 되는 정도의 차이가 심해서 벡터 길이가 들쭉날쭉 하는 경우가 많아 x86의 SIMD 파편화보다 더 심각한 상태다.[6]참고로 AMD는 SSE5나 3DNow! 같은 더 큰 삽질을 반복 하다가 2020년대부터 포기하고 얌전히 인텔의 SIMD 명령어를 따라가기 시작하여 교통정리에 일조하고있다.[7]

범용 소프트웨어에서 이러한 확장 명령어들의 장벽은 생각보다 높다. AVX가 2008년에 발표되었음에도 불구하고, 2021년 가을에 나온 디아블로 2 레저렉션에서 정식출시판 요구사항에 AVX 명령어를 포함시켰다가 자기 시스템에서는 돌아가지 않는다고 아우성치는 많은 유저들의 성화 때문에 비 AVX 패치를 황급히 개발하거나 2020년에 나온 사이버펑크 2077은 AVX를 요구사항으로 명시하지 않아 AVX가 없는 CPU에서는 로딩조차 힘들어지면서 엄청난 비난을 받고 부랴부랴 AVX 제거패치를 하는 등[8] 해프닝이 끊임없이 일어난다. 마이크로소프트는 아예 에이지 오브 엠파이어 4 최소요구사항에 AVX 명령어를 켜라고 명시까지 해서 이러한 불만을 원천 차단했다.

아무리 '상식적으로 못돌릴 리가 없는' 옛날 기준 사양이라도 많은 사용자가 이용하는 프로그램이라면 누군가는 그 조선컴을 쓰려고 하다가 실패해서 항의를 보내기 때문에, 많은 유저를 확보해야 하는 게임 같은 경우라면 추후 패치를 내보내서라도 지원범위를 넓히는 일이 많다. 게다가 인텔 같은 경우에는 자사 제품의 계급 차이를 나누며 명령어 지원여부를 벽으로 두기 때문에, 아무리 최근 나온 CPU라 하더라도 i3에서는 지원을 뺀다거나, 셀러론 혹은 펜티엄에서는 지원을 뺀다거나 하는 식으로 생각지도 못하게 기능이 미지원인 상황도 있다.

2.1. AVX

SIMD 레지스터 폭이 128비트에서 256비트로 증가되었고, 2 피연산자 구조에서 3 피연산자 구조로 변경[9]되었다. 다만 3 피연산자 연산은 VEX인코딩을 사용하는 SIMD 명령어에 한정되고, EAX와 같은 범용 레지스터를 지원하지 않는다. 또 SIMD 메모리 피연산자의 정렬 요구도 완화되었으며 새롭게 VEX 코딩 방식이 도입되어 레거시 SSE와 AVX코드를 함께 사용하여도 속도 저하를 피할 수 있다.
이 VEX 코드가 적용된 어셈블리 명령은 앞에 v를 붙이게 되고 Mutation하는 레지스터에 따라 AVX-128, AVX-256 등으로 나뉘며 예를 들어 XMM만을 지원하는 movdqa는 vmovdqa가 되고 VEX 버전의 경우 XMM과 YMM을 모두 사용할 수 있고 속도 저하도 일어나지 않기 때문에 SSE 코드를 그대로 컴파일만 다시 하면 속도 저하 페널티가 없다는 장점이 있다.

참고로 AVX는 GCC 4.6, 인텔 컴파일러 11.1, Open64 컴파일러 4.5.1, Free Pascal 컴파일러 2.7.1부터 지원하며, 운영체제는 Windows 7 SP1, 리눅스 커널 2.6.30 이상부터 지원한다.

2.2. AVX2

인텔 하스웰 마이크로아키텍처에서 최초로 지원한다.

대부분의 벡터 정수 SSE와 256비트 AVX 명령어가 확장되었고, AVX에서 지원하지 않았던 범용 레지스터에서의 3 피연산자 덧셈/곱셈 연산을 지원하며, FMA3과도 호환된다. 또한 벡터 주소 방식을 지원하고, 벡터 요소의 비 연속 메모리 위치의 로드를 지원하며 벡터 시프트도 가능하게 되었다.

AVX, AVX2 FMA3 부터 AMD64 명령어 레벨인 x86-64-v3에 해당된다.

2.3. AVX-512(AVX3)

2016년 제온 파이 x200 시리즈(Knights Landing)에서 먼저 도입되었으며, 서버용 CPU는 2017년 제온 스케일러블 시리즈에 사용된 스카이레이크-SP, 데스크탑 CPU 중에선 2017년 인텔 코어 X 시리즈에 사용된 스카이레이크-X에서 최초로 지원한다. 요약하자면 256-bit 단위이던 AVX2가 512-bit로 확장된 명령어 세트이다. 기존 AVX와 달리 프로세서별로 지원 명령어가 파편화되어 있다(...) 어느 쪽이든 AVX-512F와 AVX-512CD는 기본적으로 지원하나 그 이상부턴 HEDT/제온 기반 CPU인가 제온 Phi 기반 CPU인가에 따라서 확연하게 갈리게 된다.

Prime95 개발진인 GIMPS 측에 따르면 AVX-512 지원의 경우 이를 제대로 사용하려면 DDR4 규격 기준으로 쿼드 채널 메모리가 필요하다고 한다. 구조적으로 메모리 4개가 필요한 것은 아니지만, 현 세대 메모리들이 512-bit나 되는 거대한 레지스터 폭을 가진 연산을 뒷받침하려면 쿼드 채널 상당의 메모리 대역폭 정도는 되어야 하기 때문.[10] 이러다보니 AVX-512로 얻을 수 있는 이득을 제대로 뽑아 먹을 수 있는 상용 프로그램은 거의 없다고 봐도 된다. 초기에는 Trial factoring에 한해서만 제한적으로 사용되었지만, 2019년 4월 23일에 발표된 29.8 버전부터 정식으로 사용 가능해졌다. 린팩도 AVX-512 자체는 몇 년 전부터 지원해왔지만 제대로 지원하는 건 극히 최근의 일이기 때문.

256-bit 폭을 지닌 기존의 AVX도 처음 등장할 당시에는 구세대 SSE 계열이나 MMX에 비해 엄청난 발열과 부하로 인해 많은 오버클러커들을 좌절시켰지만, AVX-512는 그보다 더더욱 심각한 수준이라 FM 수준의 오버클럭 안정화를 고수하던 매니아 유저들마저도 회의적으로 만들 정도로 심각한 부하를 자랑한다. Windows의 작업 관리자나 모니터링 프로그램에서 CPU 이용률이 100%로 같더라도 실제 소비전력과 온도 및 발열량에서 차이가 나타나서, 오버클럭 부하 테스트 시에 AVX 명령어를 쓰거나 쓰지 않거나의 여부를 나누기도 한다. 물론 그에 비례해서 성능도 크게 오르기도 한다.

이러한 문제 때문에 인텔은 일부 컴파일러에 프로그래머가 직접 어셈블리나 인트린식으로 AVX-512 명령을 사용하거나 수동으로 옵션을 주는 것이 아닌 Auto Vectoriziation의 경우 AVX-512의 ZMM을 사용하지 않고 AVX의 YMM을 사용하도록 제한을 걸어뒀다.[11]

파편화 문제로 리누스 토르발스에게 욕을 얻어먹었다. # 차라리 AVX에 할당할 트랜지스터를 모아서 AMD처럼 코어 수나 늘리라고 했다.[12]

인텔이 실수한 점으로 돌아가, SSE 다음으로 도입한 AVX 에서도 명령어셋을 AVX, AVX2 로 쪼개놓은 것을 두고 아직 Intel은 정신 못차렸다고 욕먹을 만 한데, 한 술 더 떠 AVX-512 에서는 명령어셋을 여러 개로 쪼개놓은 것도 모자라 최신 CPU가 더 많은 명령어셋을 포괄적으로 지원하는 것도 아니고 라인업 별로 각각 다른 셋을 지원하게 만들어놨으니 엄청난 욕을 처먹는 수 밖에.

아래의 AVX-512 프로파일 문단에서 확인 할 수 있듯이, AVX에서 가능한 벡터 연산들은 AVX-512에서 추가된 기능들도 있긴 하지만 F, CD, ER, PF로 죄다 쪼개뒀다. 아마도 지원 프로세서가 모두 특수목적/서버 CPU들이고, 해당 플랫폼에서 돌아가는 소프트웨어가 한정적이다 보니 그 소프트웨어의 개발사들과 협업하는 선에서 필요한 명령어들을 선택적으로 선택하는 식으로 트랜지스터 소비를 최적화했겠지만, 결국 극도로 니치한, 몇몇 케이스 이외에는 거의 쓰이지 않을 명령어를 자처하게 되었다는 비난은 피할 수 없다.[13]

그나마 AVX2 대비 압도적인 성능 향상이 있다면 어떻게든 여러 소프트웨어 개발사들이 투자를 해서 개별 AVX-512 최적화 구현을 하거나 생태계를 넓혀 볼 기대라도 할 수 있겠지만, AVX 대비 벡터 길이가 고작 2 배 늘어난 것에 불과한 터라 성능 향상에는 한계가 있다. 따라서 거의 대부분 사용하지 않을, 단지 Intel의 마케팅 용 기술로 전락한 AVX-512 에 투자할 트랜지스터가 있으면 다른데 투자하라는 일침이 나오는 것이다.

그런데 제온 파이가 몰락하고 단종되면서 본의 아니게 파편화 문제가 해결되어 AMD64 계열의 차세대 명령어의 자리가 AVX계열로 굳어졌다. 당장 AMD도 아무도 안쓰는 자체 개발 명령어셋(3DNow!, SSE5)을 포기하고 AVX로 넘어오고 있으며, 젠 아키텍처 4세대부터는 AVX-512를 사용하기로 했다. 인텔 또한 10nm 공정의 CPU 부터 AVX-512 지원 모델의 수를 늘리고 있다. 심지어 VIA 조차 차세대 CPU 부터 AVX-512를 지원한다.[14]

성능 문제 역시 현재 대두되는 AI 연산 등 큰 벡터 길이를 요구하는 부분에서 GPU가 속도 면에서 앞서나가지만 GPU는 그리 범용적이지 않아서 CPU가 여전히 그 연산을 주도 중이라[15] 결국 대안은 큰 벡터길이를 지원하는 AVX-512나 AMX를 지원하는 CPU이기에 그 중요성이 다시 주목 받고있다.

다만 인텔은 또다른 문제점에 직면했는데, 인텔 코어 i 시리즈/12세대부터 인텔 코어 Ultra 시리즈/2세대 까지 E코어가 AVX2까지만 지원하는 관계로 E코어가 활성화 되었을 때 코어 스위칭을 위해 AVX-512가 동작하지 않게 만들었다. 또한 이후 AVX-512 기능을 완전히 비활성화 시키는 펌웨어도 나오고 있으며, 이에 따라 인텔이 메인보드 회사들에게 요청해 업데이트 되고 있는 것이 아니냐는 추측이 있다. # 또한 12세대 후기형 부터 레이저 컷팅으로 P코어의 AVX-512를 비활성화하고 있다. 정작 AMD는 인텔의 E코어 같은 리틀코어인 젠 아키텍처 4C를 만들때 캐시 메모리를 줄여서라도 디코더 부분은 온전하게 남겨놓아 E코어 역시 AVX-512를 지원하는 것과 대조적이다. 따라서 일반사용자용 CPU에선 인텔이 자사의 명령어 AVX-512를 AMD나 VIA보다 지원을 못하는 아이러니한 일이 벌어지고 있다.

E코어부터 AVX-512 지원은 가까운 세대에 계획이 없다고 알려져있어 E코어만을 사용하는 아톰계열이나 P코어와 E코어가 함께 구성된 하이브리드 빅리틀 CPU 제품군에서 AVX-512를 사용하는 것은 장기간 불가능해 보인다. 만일 AVX-512를 지원하는 E코어가 나온다면 인텔은 E코어 아키텍처와 아톰 시리즈 아키텍처를 함께 공유하기 때문에 아톰 시리즈도 AVX-512를 지원하게 되겠지만, 인텔의 공식적 입장은 급을 나누기 위해 특정 급 이하에서 지원을 중단했다는 것이기에 현 정책이 계속되는 한 E코어에서는 앞으로도 지원되지 않을 가능성이 높다. 이문제는 인텔 내부에서도 고민인지 내부 개발자들의 말로는 지속적으로 개인 사용자용 CPU에 AVX-512 복귀를 노력중이라고 한다. # #

이러한 노력에 힘입어 인텔이 AVX-512의 파편화 문제를 해결한 새로운 확장인 AVX10을 발표함에 따라 AVX-512 명령어 집합에 더 이상의 추가는 없을 예정이다.

AVX-512부터 AMD64 명령어 레벨인 x86-64-v4에 해당된다.

2.3.1. 프로파일

2.3.1.1. F, CD, ER, PF
SSE, AVX의 512비트 버전이자 제온 파이 나이츠 랜딩과 Skylake-EP, Zen4에서 지원한다.
각각 Foundation, Conflict Detection, Exponential-Reciprocal & Prefetch 의 약어로 AVX-512가 처음 등장하고 가장 먼저 도입된 프로파일이다.
2.3.1.2. VL, DQ, BW
각각 Vector Length, Doubleword-Quadword & Byte-Word 의 약어로 정수 관련 연산들과 8비트 부터 64비트 단위의 정수 관련 연산들이 추가되어 MMX, SSE2, AVX2의 연산을 모두 커버한다.
Skylake-X와 Cannon Lake, Zen 4 이후부터 지원한다.
2.3.1.3. IFMA52, 4FMAPS, VBMI, VBMI2
Integer Fused Multiply Add와 Vector Byte Manipulation Instruction 의 약자로 기존 FMA의 512비트 버전이다.
다만 IFMA52의 경우 52비트의 3항 연산이 지원되고, 4FMAPS의 경우 4항 연산을 지원한다.
2.3.1.4. VPOPCNTDQ
비트의 수를 세는 POPCNT 명령어와 동일하나 512비트에서 32비트 또는 64비트 단위로 마스크 입혀서 한 명령어로 처리가 가능하다.
AMD Zen 4 마이크로아키텍처부터 지원한다.
2.3.1.5. VNNI, 4VNNIW
Vector Neural Network Instruction의 약자.
8비트 또는 16비트 단위의 페어를 연산하고 4VNNIW의 경우 4개의 블럭을 한번에 처리할 수 있다.

이름에서 알 수 있듯이 머신러닝에서 사용되는 인공 신경망 가속을 위한 기능이고 AVX2의 epi8단위 연산을 사용해서 구현하는 것 보다 VNNI를 사용하면 스루풋이 훨씬 증가한다. 다만 VNNI를 지원하는 최고 성능의 CPU를 2소켓으로 구현해도 한개의 GPGPU처리보다 느리다는것이 함정이긴 한데 상단 항목에서 서술한 구글 통계나 AMD RDNA 설계자의 발언 같이 아직 일반사용자들은 AI 연산을 CPU에 의존하고 있음으로 실사용에 꽤 도움이 되는것도 사실이다.
AMD Zen 4 마이크로아키텍처부터 지원한다.
2.3.1.6. BF16
Bfloat16, 또는 Brain Float Point 16 를 처리하는 명령어 세트.
스칼라곱 연산을 지원하고 VNNI와 함께 쓰이며 bfloat16 연산을 위해 32비트 부동소숫점을 16비트 부동소수점으로 라운딩 하는 보조적인 기능도 있다.
AMD Zen 4 마이크로아키텍처부터 지원한다.
2.3.1.7. BITALG
Bit Algorithm 의 약자.
8비트 또는 16비트의 세트의 POPCNT 계산이나 비트 단위의 셔플링을 지원한다.
AMD Zen 4 마이크로아키텍처부터 지원한다.
2.3.1.8. VP2INTERSECT
Vector Pair Intersection의 약자.
두 벡터간 교집합을 연산하기 위해 사용되며, 만약 두 레지스터간 중복되는 원소들이 있으면 해당되는 비트마스크를 리턴한다.
다만 원소는 32비트 또는 64비트 정수로 제한된다.
AMD Zen 5 마이크로아키텍처부터 지원한다.

2.3.2. AVX_VNNI

뉴럴넷을 위한 가속 명령어인 VNNI. 본래는 AVX-512_VNNI에 도입된것이 먼저였으나 AVX-512_VNNI는 기본적으로 AVX-512 기반이므로 512비트의 ZMM 레지스터를 가지고 있는 HEDT급 프로세서가 아니면 사실상 못 쓰는 물건이었으나 AVX의 128/256 비트의 XMM/YMM 레지스터에서도 사용할 수 있도록 별도로 분리되었다.
명령어는 vpdpbusd, vpdpbusds, vpdpwssd, vpdpwssds 네개로 AVX-512_VNNI와 동일하기 때문에 오퍼랜드 레지스터가 ZMM만 아니면 코드를 그대로 사용 가능하다.
AMD Zen 4 마이크로아키텍처부터 지원한다.

2.3.3. AVX_IFMA

AVX-512_IFMA의 256-bit 버전.
AMD Zen 4 마이크로아키텍처부터 지원한다.

2.4. AVX10

AVX-512에서 대두된 하이브리드 아키텍처에서의 동작 및 파편화 문제를 해결하기 위해 나온 신규 AVX. 기존 AVX(AVX, AVX2, AVX-512, ...)와의 주요 차이점은 프로세서가 지원하는 벡터 길이를 별도의 CPUID 플래그로 분리하여 512-bit 벡터 레지스터를 갖추지 않아도 EVEX 인코딩을 사용하는 AVX-512 명령어의 128-bit 및 256-bit 버전과 AVX-512에서 추가된 16개의 XMM/YMM 레지스터를 사용할 수 있도록 하고, 기존에 각 확장별로 부여되었던 CPUID 플래그를 버전 번호로 통일한 것이다. 즉, AVX-512의 경우 개별 명령어의 지원 유무를 하나씩 확인하고 코드패스를 런타임에서 판단해야 했지만 AVX10은 하위호환성을 지키면서 기존 AVX512들의 개별 확장을 모두 지원하는 것으로 간주하는 것이 가능해 개발이 간편해진다.

2.4.1. 프로파일

2.4.1.1. AVX10.1
AVX128 (SSE), 256(AVX), 512를 포괄한다.

AVX-512는 다음과 같은 확장을 지원한다[16].
2.4.1.2. AVX10.2
256비트의 YMM레지스터에서 부동소숫점 오차 보정(엡실론)을 위한 정책 오버라이드 기능을 지원한다.

2.5. AMX

AVX512_VNNI와 같이 뉴럴 네트워크를 위한 명령어 세트. 스칼라곱을 위한 명령어로 채워져 있으며 1024bit 크기의 tmm레지스터를 사용한다.

3. 지원 프로세서

3.1. AVX

인텔
AMD

3.2. AVX2

인텔
AMD

3.3. AVX-512

인텔
AMD
VIA

3.4. AVX10

4. 관련 문서

[1] 프라임 95, 링스 등 [2] 게임, 인코딩, 시뮬레이션 등 CPU에 부하가 큰 SW들 [3] 이들은 성능이 아니라 고클럭으로 기록을 세워보는 것 자체가 목적이기 때문에 CPU에 수율 좋은 코어 1개만 살리고 모조리 꺼버리고 쿨링을 위해 액체 헬륨을 붓는 이들이라 AVX 같은건 장애물로 여긴다. [4] 이 반쪽짜리 2싸이클 지원은 인텔에 펜티엄 3 시절 SSE 지원당시 쓰던 방법이였다. 2020년 현재도 E코어나 아톰 계열은 백터 부분이 P코어 부분의 1/2 또는 1/4 수준으로 한사이클에 수행하지 않고 몇번 나눠서 한다. [5] 예를 들어 SSE3의 addsubpd를 NEON으로 이식하려면 레지스터 두개를 사용해서 vsub+vadd 후 vcombine(vget_low, vget_high)와 같은 식으로 코드를 풀어 쓰지 않고서는 이식이 불가능하다. [6] 오죽하면 AVX-512를 비판한 리누스 토발즈 마저 ARM 계통의 파편화가 너무 심해서 x86이 더 좋다고 발언할 정도였다. [7] 반대로 인텔이 x86 계열의 명령어를 완전히 장악하면서 이를 선도할 의무가 더 커진것이다. 이 때문인지 차기 명령어셋인 x86-S에서는 아예 업계 의견을 받겠다고 공개적으로 선언한 상태다. [8] 다만 이는 CD Project Red 입장에선 최소사항으로 명시한 CPU가 AVX를 지원했기 때문에 사람들이 최소사항 이하의 CPU로 게임을 할지 예상을 못한거라 정상참작의 여지가 있긴하다. [9] 기존의 SSE에서는 최대 'A=A+B' 연산밖에 불가능하지만, AVX에서는 'A=B+C'가 가능하다. 별 것 아닌 것 같아보이겠지만, A = 10 + 5라는 연산을 SSE에서는 A = 10을 먼저 수행하고 그 다음에 A = A+ 5로 총 2회의 연산이 들어가며, AVX에서는 A = 10 + 5로 한번에 연산할 수 있다는 것이다. 상당히 큰 영향이 있을 수밖에 없다. [10] 가령 메모리에서 값을 읽어오는데 1 사이클이 필요하다고 했을 때 2021년 개인용 컴퓨터에서 많이 사용되는 128비트의 메모리 대역폭으로는 한 레지스터를 모두 채우는데만 4사이클이 필요하게 된다. 물론 실제 프로그램들이 달랑 한 레지스터만 읽어오는게 아니라 여러 값들을 메모리에서 읽어오게 되기 때문에 메모리 대역폭이 실행 속도에 상당히 큰 영향을 주게 된다. [11] CPU가 AVX-512 명령어를 실행하는 경우 UEFI에서 설정한 값만큼 동작 클럭이 낮아지는데 이를 AVX Offset이라고 한다. 순수 SIMD 구현의 경우 이런 낮아진 클럭에도 본래 속도로 동작하는 AVX-256 코드보다 스루풋이 높기에 별 문제가 없지만 AVX-512 코드가 실행되는 도중 운영 체제가 스레드를 스케줄하는 경우 비 AVX-512 코드들 까지 낮아진 클럭으로 동작하게 되기에 전체적인 성능이 저하되는 문제가 있기 때문이다. 대체로 수동 어셈블리를 사용하지 않고 Auto Vectoriziation되는 코드들의 경우 스칼라 코드 사이에 작은 루프문이 끼워져 있는 형태라 성능 문제가 생기기 때문이다. [12] 엔비디아 또한 AVX-512로 얻는 이득보다 더 많은 코어 수로 얻는 이득이 더 컸다고 판단했는지, DGX A100에서는 24코어 제온 플레티넘을 버리고 64코어 에픽 프로세서를 탑재하였다. [13] 특히 AVX-512F, AVX-512BW 같은 메이저 셋을 제외하면 명령어 한두개를 위해 쪼개둔 것이 대부분이다. [14] 다만 이 차세대 센타우로스 CPU는 엔지니어링 샘플 만 나오고 VIA에서 x86계열 CPU를 포기해 버렸다. [15] 구글 발표 # 심지어 AMD 그래픽 부분 RDNA 설계자 데이비드 왕 조차 2023년 인터뷰에서 AI 연산은 CPU가 95% 가량 주도한다고 발언한다. # [16] 참고로 AMD ZEN 4 마이크로아키텍처의 AVX512 지원은 FP16이 없고, 512비트 레지스터가 없어 256비트 2사이클로 실행한다는 점만 빼면 사실상 같다. #1, #2

분류