杂谈——并行计算的四种道路

马上要找工作了呀…虽然鄙人方向是计算流体力学，但是这个方向找工作，呃…微妙…所以…我只好碰瓷人家并行方向。嘛，不过虽然不是专门做并行的，不过并行大规模的使用是没有瞎说的。这里在正式的面试之前，进行一个简单的总结。

目前笔者掌握的并行计算的方法有四种，分别是openMP并行，多线程并行MPI并行，以及CUDA并行。从前往后，从串行代码改写到并行代码的麻烦程度递增，不过加速比也是越来越好。这里要分别进行介绍(但愿面试第一轮面试前我能写完这个)

openMP并行

OK！我们先从最简单的开始，openMP并行其实是我最喜欢用的。因为他是一个共享存储式的并行，即并行的时候，所有的数据是存储在一块内存中的。这种存储方式有相应的好处，首先就是并行的时候，不存在数据传输的问题。齐次因为并行逻辑常常比较简单，所以openMP对原始的代码进行简单的注释，就可以获得还不错的加速比。

在组里面的小服务器只有两颗Xeon E5-2690(单颗十核)的情况下，2020的R7-4600(八核)处理器的运算能力其实已经和线上的CPU不是相差很多。在PC上借助openMP并行，处理一些二维和小规模的三维问题已经非常快速。

不过这样分布也有相对应的问题，首先就是只通过注释能够完成的算法并不多。基本上都是简单的傻并行才能这么写。另外就是在规模稍大的时候，可能10核的服务器是不够用的，那么就必须得改用分布式并行了。

我以我手中的一个射流计算的代码为例进行介绍。计算的结果差不多是这样

我们其中一个file中的代码

#include "main.h"
#include <iostream>
#include "omp.h"

using namespace std;

void ComputResidual(){
    double FluxI[6][nxall];
    double FluxJ[6][nyall];
    double FluxK[6][nzall];

    //用曲线守恒量重构，然后在cell face处计算物理量后使用Riemann求解器，但通量还得使用曲线守恒通量的
    // i direction
    FluxSplitLF(0);
    #pragma omp parallel for num_threads(16) private(FluxI)
    for (int k=nf; k<nb; k++){
        for (int j=nd; j<nu; j++){
            //--Flux-----
            EReconstruction(FluxI,j,k);
            //--rhs------
            for (int n=0; n<6; n++){
                for (int i=nl; i<nr; i++){
                    rhs[n][k][j][i] = (FluxI[n][i] - FluxI[n][i-1]);
                }
            }
        }
    }
    // j direction
    FluxSplitLF(1);
    #pragma omp parallel for num_threads(16) private(FluxJ)
    for (int k=nf; k<nb; k++){
        for (int i=nl; i<nr; i++){
            //--Flux------
            FReconstruction(FluxJ,k,i);
            //--rhs-------
            for (int n=0; n<6; n++){
                for (int j=nd; j<nu; j++){
                    rhs[n][k][j][i] = rhs[n][k][j][i] + (FluxJ[n][j] - FluxJ[n][j-1]);
                }
            }
        }
    }
    //k direction
    FluxSplitLF(2);
    #pragma omp parallel for num_threads(16) private(FluxK)
    for (int j=nd; j<nu; j++){
        for (int i=nl; i<nr; i++){
            //--Flux------
            GReconstruction(FluxK,i,j);
            //--rhs-------
            for (int n=0; n<6; n++){
                for (int k=nf; k<nb; k++){
                    rhs[n][k][j][i] = rhs[n][k][j][i] + (FluxK[n][k] - FluxK[n][k-1]);
                }
            }
        }
    }

}

嗯…其实就多了几行hhhhh，不过加速比是很明显的。我们用R7-4600做测试。我们选用6565129的网格，跑100步，分别测试单线程和16线程测试。得到的计算时间如下：


我们可以看到并行后运算时间已经接近原来的八分之一了。当然我们使用16线程并行，并不能让他达到16倍速。嘛，毕竟只有八个核嘛

多线程并行

这个其实平时不怎么用，甚至没有听说过，是参加华为软件挑战赛的时候才知道有这么个用法的。我之前写过一个帖子这里粘贴一下https://blog.csdn.net/qq_40583925/article/details/105235787

他的核心思想就是：

//四个子线程从四等分处向后解析数据
std::thread thread0(readAndCal0, buf);
std::thread thread1(readAndCal1, len, buf);
std::thread thread2(readAndCal2, len, buf);
std::thread thread3(readAndCal3, len, buf);

//等待四个子线程解析完
thread0.join();
thread1.join();
thread2.join();
thread3.join();

这种方法需要分别给出函数readAndCal0,readAndCal1,readAndCal2,readAndCal3的具体形式。前四行启动了四个线程，分别处理各个函数。后四行提供一个barrier，让四个线程均执行结束之后。程序才会往下执行。

这种并行方式的缺点非常明显，就是我居然需要将差不多一样的代码重复四次。我们当时比赛用的代码动不动就上千行，写程序的时候排版稍微难看一点，那个代码别人就很难懂了。

当然好处也是有的，首先他的并行效率和openMP差不多，都非常高。其次是他不需要我们额外添加openMP的编译选项，在当时比赛需要线上人家帮你运行的情况下，这种并行方式就是唯一的选择。

后续待更…