【发布时间】：2020-02-14 23:47:40
【问题描述】：
我已经矢量化了色彩空间转换算法（RGB 到 YCbCr）。当我不使用线程（#pragma omp parallel for）时，一切似乎都很好。但是当我尝试使用线程时，它无法提高我的代码的矢量化版本的性能（它也会降低）。
线程加速了标量代码、自动向量化代码和 OpenMP SIMDized 代码 (#pragma omp parallel for simd)
我不知道发生了什么，需要您的帮助。
提前致谢
我使用 fedora 31，Intel corei7 6700HQ，12GB RAM，ICC 19.0.3 (-Ofast [-no-vec] -qopenmp -xHOST
代码如下：
标量：
//Scalar for basline
#include <stdio.h>
#define MAX1 512
#define MAX2 MAX1
float __attribute__(( aligned(32))) image_r[MAX1][MAX2], image_g[MAX1][MAX2], image_b[MAX1][MAX2], image_y[MAX1][MAX2], image_cb[MAX1][MAX2], image_cr[MAX1][MAX2];
float coeff_RTY[3][3] = {{0.299, 0.587, 0.114},{-0.169, -0.331, 0.500},{0.500, -0.419, -0.081}};
inline void fill_float(float a[MAX1][MAX1])
{
int i,j;
for(i=0; i<MAX1; i++){
for(j=0; j<MAX2; j++){
a[i][j] = (i+j+100)%256;
}
}
}
int main()
{
fill_float(image_r);
fill_float(image_g);
fill_float(image_b);
int i, j;
long t1,t2,min=100000000000000;
do{
t1=_rdtsc();
//#pragma omp parallel for
for( i=0; i<MAX1; i++){
for( j=0; j<MAX2; j++){
image_y[i][j] = coeff_RTY[0][0]*image_r[i][j] + coeff_RTY[0][1]*image_g[i][j] + coeff_RTY[0][2]*image_b[i][j];
image_cb[i][j] = coeff_RTY[1][0]*image_r[i][j] + coeff_RTY[1][1]*image_g[i][j] + coeff_RTY[1][2]*image_b[i][j] + 128;
image_cr[i][j] = coeff_RTY[2][0]*image_r[i][j] + coeff_RTY[2][1]*image_g[i][j] + coeff_RTY[2][2]*image_b[i][j] + 128;
}
}
t2=_rdtsc();
if((t2-t1)<min){
min=t2-t1;
printf("\n%li", t2-t1);
}
}while(1);
printf("%f", image_y[MAX1/2][MAX2/2]);
printf("%f", image_cb[MAX1/2][MAX2/2]);
printf("%f", image_cr[MAX1/2][MAX2/2]);
return 0;
}
以及使用 AVX（浮点）的矢量化版本：
//AVX
#include <stdio.h>
#include <x86intrin.h>
#define MAX1 512
#define MAX2 MAX1
float __attribute__(( aligned(32))) image_r[MAX1][MAX2], image_g[MAX1][MAX2], image_b[MAX1][MAX2], image_y[MAX1][MAX2], image_cb[MAX1][MAX2], image_cr[MAX1][MAX2];
float coeff_RTY[3][3] = {{0.299, 0.587, 0.114},{-0.169, -0.331, 0.500},{0.500, -0.419, -0.081}};
inline void fill_float(float a[MAX1][MAX1])
{
int i,j;
for(i=0; i<MAX1; i++){
for(j=0; j<MAX2; j++){
a[i][j] = (i+j+100)%256;
}
}
}
int main()
{
//program variables:
//calculate filter coeff or use an existing one
__m256 vec_c[3][3], vec_128;
__m256 vec_r, vec_g, vec_b, vec_y, vec_cb, vec_cr;
__m256 vec_t[3][3], vec_sum;
vec_c[0][0] = _mm256_set1_ps(coeff_RTY[0][0]);
vec_c[0][1] = _mm256_set1_ps(coeff_RTY[0][1]);
vec_c[0][2] = _mm256_set1_ps(coeff_RTY[0][2]);
vec_c[1][0] = _mm256_set1_ps(coeff_RTY[1][0]);
vec_c[1][1] = _mm256_set1_ps(coeff_RTY[1][1]);
vec_c[1][2] = _mm256_set1_ps(coeff_RTY[1][2]);
vec_c[2][0] = _mm256_set1_ps(coeff_RTY[2][0]);
vec_c[2][1] = _mm256_set1_ps(coeff_RTY[2][1]);
vec_c[2][2] = _mm256_set1_ps(coeff_RTY[2][2]);
vec_128 = _mm256_set1_ps(128);
//iorder to avoid optimization for zero values
fill_float(image_r);
fill_float(image_g);
fill_float(image_b);
int i, j=0;
long t1,t2,min=100000000000000;
do{
t1=_rdtsc();
//#pragma omp parallel for
for( i=0; i<MAX1; i++){
for( j=0; j<MAX2; j+=8){
//_mm_prefetch(&image_r[i][j+8],_MM_HINT_T0);
//_mm_prefetch(&image_g[i][j+8],_MM_HINT_T0);
//_mm_prefetch(&image_b[i][j+8],_MM_HINT_T0);
vec_r = _mm256_load_ps(&image_r[i][j]);
vec_g = _mm256_load_ps(&image_g[i][j]);
vec_b = _mm256_load_ps(&image_b[i][j]);
vec_t[0][0] = _mm256_mul_ps(vec_r, vec_c[0][0]);
vec_t[0][1] = _mm256_mul_ps(vec_g, vec_c[0][1]);
vec_t[0][2] = _mm256_mul_ps(vec_b, vec_c[0][2]);
vec_t[1][0] = _mm256_mul_ps(vec_r, vec_c[1][0]);
vec_t[1][1] = _mm256_mul_ps(vec_g, vec_c[1][1]);
vec_t[1][2] = _mm256_mul_ps(vec_b, vec_c[1][2]);
vec_t[2][0] = _mm256_mul_ps(vec_r, vec_c[2][0]);
vec_t[2][1] = _mm256_mul_ps(vec_g, vec_c[2][1]);
vec_t[2][2] = _mm256_mul_ps(vec_b, vec_c[2][2]);
//vec_y = vec_t[0][0] + vec_t[0][1] + vec_t[0][2]
vec_sum = _mm256_add_ps(vec_t[0][0], vec_t[0][1]);
vec_y = _mm256_add_ps(vec_t[0][2], vec_sum);
//vec_cb = vec_t[1][0] + vec_t[1][1] + vec_t[1][2] +128
vec_sum = _mm256_add_ps(vec_t[1][0], vec_t[1][1]);
vec_sum = _mm256_add_ps(vec_t[1][2], vec_sum);
vec_cb = _mm256_add_ps(vec_128, vec_sum);
//vec_cr = vec_t[2][0] + vec_t[2][1] + vec_t[2][2] +128
vec_sum = _mm256_add_ps(vec_t[2][0], vec_t[2][1]);
vec_sum = _mm256_add_ps(vec_t[2][2], vec_sum);
vec_cr = _mm256_add_ps(vec_128, vec_sum);
_mm256_stream_ps(&image_y[i][j], vec_y);
_mm256_stream_ps(&image_cb[i][j], vec_cb);
_mm256_stream_ps(&image_cr[i][j], vec_cr);
}
}
t2=_rdtsc();
if((t2-t1)<min){
min=t2-t1;
printf("\n%li", t2-t1);
}
}while(1);
//inorder to avoid optimization for non used values
printf("%f", image_y[MAX1/2][MAX2/2]);
printf("%f", image_cb[MAX1/2][MAX2/2]);
printf("%f", image_cr[MAX1/2][MAX2/2]);
return 0;
}
更新：
128x128 图像尺寸的最佳记录周期如下：
单核：
Scalar code: 88k
Auto-vectorized: 59k
Vectorized using intrinsics: **21k**
vectorized by #pragma omp simd: 59k
多核：
Scalar code: 25k
Auto-vectorized: 13k
Vectorized using intrinsics: **226k**
vectorized by #pragma omp .. simd: 22k
对于1024x1024的图片尺寸如下：
单核：
Scalar code: 7M
Auto-vectorized: 3M
Vectorized using intrinsics: **3M**
vectorized by #pragma omp simd: 3M
多核：
Scalar code: 6M
Auto-vectorized: 6M
Vectorized using intrinsics: **15M**
vectorized by #pragma omp parallel for simd: 8M
【问题讨论】：
-
线程化并不意味着它会比单线程版本更快。
-
i7-6700HQ 可以（几乎？）用单核使内存带宽饱和。一般来说，如果您的代码已经最大限度地利用了单核内存带宽，我预计并行化会带来小幅加速，如果不是，则加速会更大。如果您重复少量工作，线程开销可能会杀死您，尤其是在您的 RDTSC 时间包括线程调度开销的情况下。
-
_mm256_stream_ps也很可疑。 512*512 * 4B/float = 每个 2D 阵列 1MiB 的缓存占用空间，或总共 6MiB，适合 CPU 的 L3 缓存。绕过 L3 存储到 DRAM 意味着更慢。我不确定为什么更多的核心这样做会更糟，除了单核 turbo 与全核 turbo 限制降低非核心（L3/环形总线）时钟速度。 -
如果您的测试仅限于单一选择的线程数和固定，则应该是每个核心 1 个线程，且 omp_places=cores。标量代码完全有可能使用比 simd 代码更多的线程来实现峰值性能。如上所述，您可能需要测试 2 个线程，它们都固定到特定内核以及在内核之间浮动，但不是超线程。这几乎不是一个新话题。在 AMD 多核 CPU 的早期，将 simd 和线程（OpenMP 和 MPI 也不行）结合起来几乎没有什么好处。同样，集群是否应该禁用超线程的问题
-
@Martin 老实说，您的输入相当小，因此您看到任何加速都很有趣。也就是说，也许还值得看看你如何在线程之间分配工作，添加
num_threads(2) schedule(static, MAX1/2)或类似的东西可能是明智的。我很想看看这种情况下的结果。