【问题标题】:OpenMP performance of different data types on NUMA architectureNUMA 架构上不同数据类型的 OpenMP 性能
【发布时间】:2017-04-29 00:52:02
【问题描述】:

我正在尝试优化一些在 MAESTRO 处理器上使用 OpenMP 的矩阵-矩阵乘法基准代码。 MAESTRO 有 49 个处理器,以 7x7 配置的二维阵列排列。每个内核都有自己的 L1 和 L2 缓存。可以在此处查看板的布局:http://i.imgur.com/naCWTuK.png

我的主要问题是:不同的数据类型(char、short 和 int 等)能否直接影响 OpenMP 代码在基于 NUMA 的处理器上的性能?如果是这样,有什么办法可以缓解吗?以下是我为什么要问这个的解释。

我得到了一组基准,一个研究小组使用这些基准来衡量给定处理器的性能。基准测试提高了其他处理器的性能,但他们遇到了在 MAESTRO 上运行它们时看不到相同类型结果的问题。这是我收到的基本代码中矩阵乘法基准的 sn-p:

头文件中的相关宏(MAESTRO 是 64 位):

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#include <sys/time.h>
#include <cblas.h>
#include <omp.h>

//set data types
#ifdef ARCH64
    //64-bit architectures
    #define INT8_TYPE char
    #define INT16_TYPE short
    #define INT32_TYPE int
    #define INT64_TYPE long
#else
    //32-bit architectures
    #define INT8_TYPE char
    #define INT16_TYPE short
    #define INT32_TYPE long
    #define INT64_TYPE long long
#endif
#define SPFP_TYPE float
#define DPFP_TYPE double

//setup timer

//us resolution
#define TIME_STRUCT struct timeval
#define TIME_GET(time) gettimeofday((time),NULL)
#define TIME_DOUBLE(time) (time).tv_sec+1E-6*(time).tv_usec
#define TIME_RUNTIME(start,end) TIME_DOUBLE(end)-TIME_DOUBLE(start)

//select random seed method
#ifdef FIXED_SEED
    //fixed
    #define SEED 376134299
#else
    //based on system time
    #define SEED time(NULL)
#endif

32 位整数矩阵乘法基准:​​

double matrix_matrix_mult_int32(int size,int threads)
{


//initialize index variables, random number generator, and timer
    int i,j,k;
    srand(SEED);
    TIME_STRUCT start,end;

//allocate memory for matrices
INT32_TYPE *A=malloc(sizeof(INT32_TYPE)*(size*size));
INT32_TYPE *B=malloc(sizeof(INT32_TYPE)*(size*size));
INT64_TYPE *C=malloc(sizeof(INT64_TYPE)*(size*size));

//initialize input matrices to random numbers
//initialize output matrix to zeros
for(i=0;i<(size*size);i++)
{
    A[i]=rand();
    B[i]=rand();
    C[i]=0;
}

//serial operation
if(threads==1)
{
    //start timer
    TIME_GET(&start);
    //computation
    for(i=0;i<size;i++)
    {
        for(k=0;k<size;k++)
        {
            for(j=0;j<size;j++)
            {
                C[i*size+j]+=A[i*size+k]*B[k*size+j];
            }
        }
    }
    //end timer
    TIME_GET(&end);
}
//parallel operation
else
{
    //start timer
    TIME_GET(&start);
    //parallelize with OpenMP
    #pragma omp parallel for num_threads(threads) private(i,j,k)
    for(i=0;i<size;i++)
    {
        for(k=0;k<size;k++)
        {
            for(j=0;j<size;j++)
            {
                C[i*size+j]+=A[i*size+k]*B[k*size+j];
            }
        }
    }
    //end timer
    TIME_GET(&end);
}

//free memory
free(C);
free(B);
free(A);

//compute and return runtime
return TIME_RUNTIME(start,end);
}

连续运行上述基准测试比使用 OpenMP 运行它产生更好的性能。我的任务是优化 MAESTRO 的基准以获得更好的性能。使用以下代码,我能够获得性能提升:

double matrix_matrix_mult_int32(int size,int threads)
{

//initialize index variables, random number generator, and timer
    int i,j,k;
    srand(SEED);
    TIME_STRUCT start,end;


    //allocate memory for matrices
    alloc_attr_t attrA = ALLOC_INIT;
    alloc_attr_t attrB = ALLOC_INIT;
    alloc_attr_t attrC = ALLOC_INIT;

    alloc_set_home(&attrA, ALLOC_HOME_INCOHERENT);
    alloc_set_home(&attrB, ALLOC_HOME_INCOHERENT);
    alloc_set_home(&attrC, ALLOC_HOME_TASK);

    INT32_TYPE *A=alloc_map(&attrA, sizeof(INT32_TYPE)*(size*size));
    INT32_TYPE *B=alloc_map(&attrB, sizeof(INT32_TYPE)*(size*size));
    INT64_TYPE *C=alloc_map(&attrC, sizeof(INT64_TYPE)*(size*size));

    #pragma omp parallel for num_threads(threads) private(i)
    for(i=0;i<(size*size);i++)
    {

        A[i] = rand();
        B[i] = rand();
        C[i] = 0;
        tmc_mem_flush(&A[i], sizeof(A[i]));
        tmc_mem_flush(&B[i], sizeof(B[i]));
        tmc_mem_inv(&A[i], sizeof(A[i]));
        tmc_mem_inv(&B[i], sizeof(B[i]));
    }


    //serial operation
    if(threads==1)
    {
        //start timer 
        TIME_GET(&start);

        //computation
        for(i=0;i<size;i++)
        {
            for(k=0;k<size;k++)
            {
                for(j=0;j<size;j++)
                {   
                    C[i*size+j]+=A[i*size+k]*B[k*size+j];
                }
            }
        }

     TIME_GET(&end);

    }
    else
    {

      TIME_GET(&start);

      #pragma omp parallel for num_threads(threads) private(i,j,k) schedule(dynamic)
      for(i=0;i<size;i++)
      {
          for(j=0;j<size;j++)
          {
              for(k=0;k<size;k++)
              {
                  C[i*size+j] +=A[i*size+k]*B[k*size+j];
              }
          }
      }

      TIME_GET(&end);
    }


    alloc_unmap(C, sizeof(INT64_TYPE)*(size*size));
    alloc_unmap(B, sizeof(INT32_TYPE)*(size*size));
    alloc_unmap(A, sizeof(INT32_TYPE)*(size*size));


    //compute and return runtime
    return TIME_RUNTIME(start,end);
}

使两个输入数组的缓存不连贯并使用具有动态调度的 OpenMP 帮助我获得了超过串行性能的并行化性能。这是我第一次使用具有 NUMA 架构的处理器,所以我的“优化”很轻,因为我还在学习。无论如何,我尝试在所有相同条件(线程数和数组大小)下对上述代码的 8 位整数版本使用相同的优化:

double matrix_matrix_mult_int8(int size,int threads)
{

//initialize index variables, random number generator, and timer
    int i,j,k;
    srand(SEED);
    TIME_STRUCT start,end;


    //allocate memory for matrices
    alloc_attr_t attrA = ALLOC_INIT;
    alloc_attr_t attrB = ALLOC_INIT;
    alloc_attr_t attrC = ALLOC_INIT;

    alloc_set_home(&attrA, ALLOC_HOME_INCOHERENT);
    alloc_set_home(&attrB, ALLOC_HOME_INCOHERENT);
    alloc_set_home(&attrC, ALLOC_HOME_TASK);

    INT8_TYPE *A=alloc_map(&attrA, sizeof(INT8_TYPE)*(size*size));
    INT8_TYPE *B=alloc_map(&attrB, sizeof(INT8_TYPE)*(size*size));
    INT16_TYPE *C=alloc_map(&attrC, sizeof(INT16_TYPE)*(size*size));

    #pragma omp parallel for num_threads(threads) private(i)
    for(i=0;i<(size*size);i++)
    {

        A[i] = rand();
        B[i] = rand();
        C[i] = 0;
        tmc_mem_flush(&A[i], sizeof(A[i]));
        tmc_mem_flush(&B[i], sizeof(B[i]));
        tmc_mem_inv(&A[i], sizeof(A[i]));
        tmc_mem_inv(&B[i], sizeof(B[i]));
    }


    //serial operation
    if(threads==1)
    {
        //start timer 
        TIME_GET(&start);

        //computation
        for(i=0;i<size;i++)
        {
            for(k=0;k<size;k++)
            {
                for(j=0;j<size;j++)
                {   
                    C[i*size+j]+=A[i*size+k]*B[k*size+j];
                }
            }
        }

     TIME_GET(&end);

    }
    else
    {

      TIME_GET(&start);

      #pragma omp parallel for num_threads(threads) private(i,j,k) schedule(dynamic)
      for(i=0;i<size;i++)
      {
          for(j=0;j<size;j++)
          {
              for(k=0;k<size;k++)
              {
                  C[i*size+j] +=A[i*size+k]*B[k*size+j];
              }
          }
      }

      TIME_GET(&end);
    }


    alloc_unmap(C, sizeof(INT16_TYPE)*(size*size));
    alloc_unmap(B, sizeof(INT8_TYPE)*(size*size));
    alloc_unmap(A, sizeof(INT8_TYPE)*(size*size));


    //compute and return runtime
    return TIME_RUNTIME(start,end);
}

但是,8 位 OpenMP 版本导致时间比 32 位 OpenMP 版本慢。 8 位版本的执行速度不应该比 32 位版本快吗?造成这种差异的原因可能是什么?有哪些可能的事情可以缓解这种差异?可能与我正在使用的数组的数据类型或其他有关吗?

【问题讨论】:

  • 说这个芯片是 7X7 NUMA 是一种误导,因为 7x7 NUMA 意味着每个集群有 7 个节点,总共有 7 个集群。这个芯片显然只有4个外部控制器。
  • 这个芯片的核心实际上有一个相当大的二级缓存,所以如果你的数据集不够大,那么使用较小的数据类型将浪费大量时间来转换全宽类型.如果压缩数据并不能提高你的表现,那就意味着没有必要这样做。
  • 矩阵的大小是多少?顺便说一句,这是我的帮助lemire.me/blog/2013/09/13/…
  • 你为什么不使用例如int32_t 而不是 INT32_TYPE 定义你自己的类型?这就是在 C99 中定义它们的主要原因。
  • 你使用了什么编译器优化?您使用了哪些编译器选项?什么编译器?

标签: c performance openmp matrix-multiplication numa


【解决方案1】:

我想到了两件事

您的 8 位(一个字节)数据类型与 32 位(四个字节)数据类型以及将数据结构对齐到 N 字节边界的给定编译器。我认为它通常是 4 字节边界,特别是当它默认为 32 位时。有一个编译器选项可以强制对齐边界。

Why does compiler align N byte data types on N byte boundaries?

在处理单字节数据类型时可能会发生额外的操作,其中其他 3 个字节必须被屏蔽才能获得正确的值,而标准 32 位(或 64-位)数据类型。

另一个是处理器和内存亲和性,以及在给定内核上运行的并行 OPENMP 代码是否从未直接连接到该 cpu 内核的内存中获取或写入数据。然后,无论提取必须通过什么集线器才能到达远处的内存,显然都会导致运行时间增加。我不确定这是否适用于我不熟悉的 MAESTRO 类型的系统;但我所描述的是通过 Intel quickpath connect (QPI) 连接的最新型号 INTEL 4-cpu 系统。例如,如果您在 cpu 0 的核心 0 上运行,那么从最接近该 cpu 核心的 DRAM 模块的内存中获取将是最快的,而不是通过连接到 CPU 3 上的核心 N 的 QPI 访问 DRAM,而不是通过一些集线器或 infiniband 来访问访问其他刀片或节点上的 DRAM,依此类推。 我知道可以用 MPI 处理亲和力,我相信它可以用 OPENMP 处理,但可能不是那么好。您可以尝试研究“openmp cpu memory affinity”。

【讨论】:

    猜你喜欢
    • 2012-10-21
    • 1970-01-01
    • 2012-08-11
    • 2012-08-27
    • 2017-07-11
    • 2018-02-02
    • 2014-07-10
    • 2011-06-08
    • 2020-06-10
    相关资源
    最近更新 更多