并行二进制搜索的性能比串行版本差

时间:2019-12-06 17:12:50

标签: c multithreading parallel-processing openmp hpc

我编写了以下代码,该代码在数组中执行一定数量的二进制搜索。我将其与OpenMP并行化,似乎我添加线程的次数越多,完成时间就越多。 该程序将应用Bsearch的数组的长度和初始化在第一个数组中要搜索的值的search数组的长度作为参数。并行化应用于所有三个for循环。

我在具有20个核心的单个节点上的HPC群集上使用以下脚本运行该程序:

for threads in 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ; do
    export OMP_NUM_THREADS=${threads}
    ./binary_search_parallel.x 1000000000 100000000
done

我的问题是该程序根本无法扩展:我添加线程越多,花费的时间就越多。串行版本的性能更好。 有人知道问题出在哪里吗?还是事实是针对并行开销的性能吞吐量不足?


#include <stdlib.h>
#include <stdio.h>
#include <time.h>
#include <string.h>
#include <omp.h>

#define CPU_TIME (clock_gettime( CLOCK_PROCESS_CPUTIME_ID, &ts ), (double)ts.tv_sec + \
          (double)ts.tv_nsec * 1e-9)


int mybsearch(int *data, int low, int high, int Key)
 {

   int register mid;

   mid = (low + high) / 2;
   while(low <= high) {     


     if(data[mid] < Key)
       low = mid + 1; 
     else if(data[mid] > Key)
       high = mid - 1;
     else 
       return mid;

     mid = (low + high) / 2;
   }

   /* if ( Key == data[low] ) */
   /*   return 0; */
   /* else */
     return -1;
 }

#define N_DEFAULT  (1024*1024*128)
#define N_search_DEFAULT (N_DEFAULT / 10)

int main(int argc, char **argv)
{
  int N, Nsearch, i, n_threads = 1;
  int *data, *search;

  #ifndef _OPENMP
    printf("serial binary search\n");
  #else
  #pragma omp parallel
  {
    #pragma omp master
    {
      n_threads = omp_get_num_threads();
      printf("omp binary search with %d threads\n", n_threads );
    }
  }
  #endif

  if(argc > 1)
    N = atoi( *(argv+1) );
  else
    N = N_DEFAULT;

  if(argc > 2)
    Nsearch = atoi ( *(argv + 2) );
  else
    Nsearch = N_search_DEFAULT;

  printf("performing %d lookups on %d data..\n", Nsearch, N);

  printf("set-up data.."); fflush(stdout);
  data = (int*)malloc(N * sizeof(int));

  #if defined(_OPENMP)
   #pragma omp parallel for
      for (i = 0; i < N; i++)
        data[i] = i;
  #else
    for(i = 0; i < N; i++)
      data[i] = i;
  #endif

  printf(" set-up lookups.. "); fflush(stdout);  
  search = (int*)malloc(Nsearch * sizeof(int));
  srand(time(NULL));

  #if defined(_OPENMP)
    #pragma omp parallel for
      for (i = 0; i < Nsearch; i++)
        search[i] = rand() % N;
  #else
    for (i = 0; i < N; i++)
      search[i] = rand() % N;
  #endif


  int found = 0;
  double tstart, tstop;
  struct timespec ts;

  printf("\nstart cycle.. "); fflush(stdout);
  tstart = CPU_TIME;

  #if defined(_OPENMP)
    #pragma omp parallel for
      for (i = 0; i < Nsearch; i++)
        if( mybsearch(data, N, search[i]) >= 0)
          found++;
  #else
    for ( i = 0; i < Nsearch; i++)
      if(mybsearch(data, N, search[i]) >= 0)
        found++;
  #endif

  tstop = CPU_TIME;

  printf("time elapsed: %g\n", tstop - tstart);

  //free(data);
  //free(search);

  return 0;
 }

1 个答案:

答案 0 :(得分:0)

20个硬件线程来自同一套接字?您的计算机是否具有NUMA(非统一内存访问)体系结构?

也许这可能是您的瓶颈:从内存访问开始计时。如果您的计算机是NUMA,则一旦并行初始化数据,由于内存位置错误,您可能会付出大量执行时间。

在48核NUMA计算机(8个NUMA节点x 6核)上使用代码进行测试时,如果提供的代码扩展性较差,

  1. 您不要将线程固定到核心上(如果在单个插槽中使用的线程数少于或等于核心数)
  2. 您使用多个NUMA存储库。您的代码的内存访问模式非常不规则,数据可以位于任何NUMA节点中。

以下是10000000 10000000参数的一些计时时间:

  • 序列号:〜6,57
  • 固定(带有任务集)序列号:〜5,27
  • 平行

Parallel without pin

  • 平行固定(OMP_PLACES=cores OMP_PROC_BIND=close

enter image description here

您会注意到,每次包含新的NUMA节点(7、13、19、25、31、37和43个线程)时,秒数都会增加。从第二个并行解决方案到第一个并行解决方案,平均时间要短一些,因为在第二个解决方案中,我们对正在使用的NUMA节点数量有所控制(由于线程固定),从而减少了线程迁移到另一个NUMA节点的机会数据实际所在的节点。