我们有数百万个小文件要由某些程序处理。
精确的程序 并不重要 变化 也 精确的任务。但是，这些是较小的C ++程序，我们有源代码，但它们本质上不可并行化。
使用单个平均CPU核心（Intel i7系列）时，处理一个小文件大约需要15秒。程序运行时需要大约200 MB的RAM。
我们希望在GPU上并行化这一点，并在每个GPU核心（例如Cuda-core）上运行该程序的一个实例。因此，如果GPU有3000个CUDA核心，那么我们希望并行运行3000个实例。如果可能的话，我们想要使用像OpenCL这样的通用框架技术（而不是Cuda，但如果这种情况需要Cuda可以加入）。
现在我们正在尝试评估这是否可行（我们在GPGPU编程方面还没有太多经验）。我们想象的主要问题是记忆。如果我们并行运行3000个实例，并且每个实例需要200 MB VRAM，那么我们需要600 GB的内存。
我们主要考虑的显卡是高端Geforce卡，通常有8 GB到11 GB的内存。我们有GPU工作站，每个案例/主板有4张卡，我们最初会用它（但后来也可能在其他GPU系统上，因此我们更喜欢像OpenCL这样的通用框架）。
有哪些方法可以解决这个问题？
精确的计划并不重要
这是一厢情愿的想法。你试图解决的问题非常重要;如果它就像重新编译C ++代码到GPU着色器二进制文件一样简单，几乎所有的软件都会这样做以实现免费的速度提升。
您通常无法将整个C ++程序1：1转换为GPU内核，即使您设法执行此操作，它也会执行得非常糟糕。您真的需要努力在SIMD类型操作方面重新思考您的问题，以便随时随地使用GPU。
特别是，您似乎认为每个GPU“核心”都是独立的。情况并非如此，它们的组合都处于锁定状态，所以如果你的代码很多，那么你的利用率就会很低。它们还共享内存总线，因此如果每个线程访问不相关的内存区域，这将大大减慢执行速度，并且您将无法足够快地提供ALU / FPU。
内存也是一个问题，但不仅仅是因为你指出VRAM的总量，还因为局部变量使用“私有”内存，它们实际上是寄存器，而且是非常有限的资源（以千字节为单位）最好）。
我建议查看所有主要GPU供应商发布的OpenCL优化指南。这将使您更好地了解哪种代码执行良好，哪些代码没有执行，以及在决定卸载到GPU以及如何卸载代码时需要考虑哪些因素。