C 将缓慢的IO委派到部分会使OpenMP的速度变慢

我正在尝试使用OpenMP（和C）并行化我的应用程序，并希望从I/O部分开始。最初，读取和计算部分是顺序的，每个部分大约需要3秒钟

int *mask, width, height
Picture *pic;

pic = readFile("some big file");   // 3 secs
mask = computeMask(width, height); // 3 secs

使用OpenMP：

#pragma parallel default(none) shared(pic, mask, width, height)
{
 #pragma sections
 {
  #pragma section
  {
   pic = readFile("some big file");
  }
  #pragma section
  {
   mask = computeMask(width, height);
  }
 }
}

但是现在总的时间大约是10秒（实际上是花在I/O任务上）

---

在我开始责怪RAM的并发访问造成瓶颈之前。我很想知道我这里是否出了问题。

OpenMP部分同时执行，例如，

computeMask

将在

readFile

读取文件时执行。如果

computeMask

使用

readFile

泵送的数据，那么它将产生不正确的结果（它可能访问尚未读取的数据），或者（错误）共享将导致缓存未命中率大幅增加。I/O通常是尽可能快的（带宽限制操作），而使其更快的唯一方法是在具有多个I/O控制器的（分布式）系统上运行。@hristoilev这两个部分可以同时执行，因为它们彼此不共享任何数据

readFile

将磁盘中的一些数据泵入内存，同时

computeMask

填充另一个内存区域。最后一个操作使用它们来计算目标图片。我明白了。那么您可能也会受到内存带宽的限制。

readFile

是对文件内容进行一些处理（例如解压缩），还是只是将其二进制读入内存？如果是后者，那么您可以尝试内存映射，而不是按需从磁盘读取数据。

malloc

多年前就已经锁定了。这是--

glibc

使用几乎无锁的

malloc

实现。而且您不需要同步

mmap

调用（您链接到的内容在

malloc

的上下文中谈论

mmap

，因为

malloc

使用它进行大量分配）。您是我的新圣经！：-）使用

mmap

，

readFile

操作现在几乎是即时的。非凡的非常感谢。