- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

I am new to AVX512 instruction set and I write the following code as demo.

#include <iostream> #include <array> #include <chrono> #include <vector> #include <cstring> #include <omp.h> #include <immintrin.h> #include <cstdlib> int main() { unsigned long m, n, k; m = n = k = 1 << 30; auto *a = static_cast<double*>(aligned_alloc(512, m*sizeof(double))); auto *b = static_cast<double*>(aligned_alloc(512, n*sizeof(double))); auto *c = static_cast<double*>(aligned_alloc(512, k*sizeof(double))); memset(a, 1, m * sizeof(double)); memset(b, 1, n * sizeof(double)); memset(c, 1, k * sizeof(double)); std::chrono::time_point<std::chrono::system_clock> start, end; start = std::chrono::system_clock::now(); for (int iter = 0; iter < 30; iter++) { for (unsigned long i = 0; i < n; i+=4) { // __m512d x1 = _mm512_load_pd(&a); // __m512d x2 = _mm512_load_pd(&b); // __m512d result = _mm512_add_pd(x1, x2); // _mm512_store_pd(&c, result); __m256d x1 = _mm256_load_pd(&a); __m256d x2 = _mm256_load_pd(&b); __m256d result = _mm256_add_pd(x1, x2); _mm256_store_pd(&c, result); } } end = std::chrono::system_clock::now(); std::chrono::duration<double> elapsed_seconds = end - start; std::cout << "elapsed time: " << elapsed_seconds.count() << std::endl; return 0; }

I allocate the aligned memory and use the AVX instruction set to improve the computation performance. However, after I compile and execute it as the following.

szhangcj@gpu3:~/HPC$ g++ -O2 -msse -msse2 -mavx512f -fopenmp main_avx.cpp -o avx szhangcj@gpu3:~/HPC$ ./avx elapsed time: 77.8923 szhangcj@gpu3:~/HPC$ g++ -O2 main.cpp -o single szhangcj@gpu3:~/HPC$ ./single elapsed time: 70.0907

My single thread version just replaces the for loop part as the following.

for (int iter = 0; iter < 30; iter++) { for (unsigned long i = 0; i < n; i++) { c= a+ b; } }

I expect that the computation performance should be improved a lot. But it seems that there is no improvement at all. What is wrong with that? I also want to combine the OpenMP with AVX instruction set to further improve it.

The following information is about my server.

Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 44 On-line CPU(s) list: 0-43 Thread(s) per core: 1 Core(s) per socket: 22 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 85 Model name: Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz Stepping: 4 CPU MHz: 1000.019 CPU max MHz: 2101.0000 CPU min MHz: 1000.0000 BogoMIPS: 4200.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 1024K L3 cache: 30976K NUMA node0 CPU(s): 0-21 NUMA node1 CPU(s): 22-43 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb cat_l3 cdp_l3 invpcid_single pti intel_ppin ssbd mba ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt clwb intel_pt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku ospke md_clear flush_l1d

- Tags:
- Intel® Advanced Vector Extensions (Intel® AVX)
- Intel® Streaming SIMD Extensions
- Parallel Computing

Link Copied

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Each array is 8 GiB, so the test is reading 2*8 GiB (for "a" and "b"), reading 8 GiB for "c" (this is a "write-allocate"), and writing back 8 GiB from array "c".

Since each array is much larger than the caches, the processor must move 32 GiB per iteration, or 960 GiB for the 30 iterations specified.

The execution times of 77.9 seconds and 70.0 seconds therefore correspond to (raw) DRAM bandwidth of 13.2 GB/s (decimal) and 14.7 GB/s (decimal), respectively. These are both reasonable numbers for single-threaded operation on an SKX processor. Performance in this case is limited by the maximum number of outstanding cache misses, and not by the time required to execute the arithmetic instructions. I discuss these issues in many of the blog entries at http://sites.utexas.edu/jdm4372/ -- search for "concurrency" and/or "bandwidth". The series of posts from November of 2010 is still very relevant.

Full performance from any of the SIMD instruction sets requires that at least half of the input data come from registers, and the remainder come almost entirely from the L1 Data Cache.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

Hi John, thank you for your explanation first. I totally agree with your point. However, I am still a little bit confused about that. I also wrote another demo about the same question as the following.

#include <cmath> #include <iostream> #include <chrono> #include <emmintrin.h> #include <immintrin.h> void normal_res(float* __restrict__ a, float* __restrict__ b, float* __restrict__ c, unsigned long N) { for (unsigned long n = 0; n < N; n++) { c= sqrt(a ) + sqrt(b ); } } void normal(float* a, float* b, float* c, unsigned long N) { for (unsigned long n = 0; n < N; n++) { c = sqrt(a ) + sqrt(b ); } } void sse(float* a, float* b, float* c, unsigned long N) { __m128* a_ptr = (__m128*)a; __m128* b_ptr = (__m128*)b; for (unsigned long n = 0; n < N; n+=4, a_ptr++, b_ptr++) { __m128 asqrt = _mm_sqrt_ps(*a_ptr); __m128 bsqrt = _mm_sqrt_ps(*b_ptr); __m128 add_result = _mm_add_ps(asqrt, bsqrt); _mm_store_ps(&c , add_result); } } void avx(float* a, float* b, float* c, unsigned long N) { __m256* a_ptr = (__m256*)a; __m256* b_ptr = (__m256*)b; for (unsigned long n = 0; n < N; n+=8, a_ptr++, b_ptr++) { __m256 asqrt = _mm256_sqrt_ps(*a_ptr); __m256 bsqrt = _mm256_sqrt_ps(*b_ptr); __m256 add_result = _mm256_add_ps(asqrt, bsqrt); _mm256_store_ps(&c , add_result); } } int main(int argc, char** argv) { unsigned long N = 1 << 30; auto *a = static_cast<float*>(aligned_alloc(128, N*sizeof(float))); auto *b = static_cast<float*>(aligned_alloc(128, N*sizeof(float))); auto *c = static_cast<float*>(aligned_alloc(128, N*sizeof(float))); std::chrono::time_point<std::chrono::system_clock> start, end; for (unsigned long i = 0; i < N; ++i) { a = 3141592.65358; b= 1234567.65358; } start = std::chrono::system_clock::now(); for (int i = 0; i < 5; i++) normal(a, b, c, N); end = std::chrono::system_clock::now(); std::chrono::duration<double> elapsed_seconds = end - start; std::cout << "normal elapsed time: " << elapsed_seconds.count() / 5 << std::endl; start = std::chrono::system_clock::now(); for (int i = 0; i < 5; i++) normal_res(a, b, c, N); end = std::chrono::system_clock::now(); elapsed_seconds = end - start; std::cout << "normal restrict elapsed time: " << elapsed_seconds.count() / 5 << std::endl; start = std::chrono::system_clock::now(); for (int i = 0; i < 5; i++) sse(a, b, c, N); end = std::chrono::system_clock::now(); elapsed_seconds = end - start; std::cout << "sse elapsed time: " << elapsed_seconds.count() / 5 << std::endl; start = std::chrono::system_clock::now(); for (int i = 0; i < 5; i++) avx(a, b, c, N); end = std::chrono::system_clock::now(); elapsed_seconds = end - start; std::cout << "avx elapsed time: " << elapsed_seconds.count() / 5 << std::endl; return 0; }

The result is confused. The computation time for the normal function is 10 seconds. However, the computation time for the SSE2 is around 1s. It seems that my second demo will have the same problem with the first one. Why can I get such big improvement? By the way, I expect the SSE2 is 4 times faster than the naive version, because I use the 128-bit vectors which contains 4 single precision floating points. Why can I get so much improvement? Thank you a lot.

McCalpin, John (Blackbelt) wrote:

Each array is 8 GiB, so the test is reading 2*8 GiB (for "a" and "b"), reading 8 GiB for "c" (this is a "write-allocate"), and writing back 8 GiB from array "c".

Since each array is much larger than the caches, the processor must move 32 GiB per iteration, or 960 GiB for the 30 iterations specified.

The execution times of 77.9 seconds and 70.0 seconds therefore correspond to (raw) DRAM bandwidth of 13.2 GB/s (decimal) and 14.7 GB/s (decimal), respectively. These are both reasonable numbers for single-threaded operation on an SKX processor. Performance in this case is limited by the maximum number of outstanding cache misses, and not by the time required to execute the arithmetic instructions. I discuss these issues in many of the blog entries at http://sites.utexas.edu/jdm4372/ -- search for "concurrency" and/or "bandwidth". The series of posts from November of 2010 is still very relevant.

Full performance from any of the SIMD instruction sets requires that at least half of the input data come from registers, and the remainder come almost entirely from the L1 Data Cache.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content

This was answered (twice) at https://stackoverflow.com/questions/60472794/why-does-not-avx-further-improve-the-performance-compared-with-sse2/60478430

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page