4

在具有派生数据类型的 MPI 的上下文中，有人告诉我在使用该bind(C)构造时要小心，因为它会抑制编译器的某些优化。考虑这个（不太可能的例子）：

type, bind(C) :: myType
  integer(2) :: a
  complex    :: z
  integer(2) :: b
end type myType

如果没有该bind(C)语句，编译器可能会重新排序结构并将两个整数分组以更好地对齐。特别是对于大型结构和尝试使用自动矢量化时，这将是有益的。

使用bind(C)，这种重组是不可能的（为了保持与 的兼容C，编译器可能不会优化那么多）。如果所有元素都与单词对齐，这将导致大量内存消耗（三个单词而不是两个单词），或者导致对齐丢失。（至少，有人告诉我。）

直到最近，我从未混合过 C 和 Fortran，也从未将派生类型用于 MPI 通信。在不久的将来，我将研究混合语言编程，这些问题似乎很重要。

所以我的问题有两个：

  • bind(C)：这种错位是否在“现实世界”应用程序中起作用？有没有人在这里遇到过性能/优化问题？
  • iso_c_binding：（另外）使用该模块时是否还有其他陷阱iso_c_binding？对代码施加了哪些限制以及禁用了哪些优化？
4

1 回答 1

5

我不会那么担心。C 编译器也会在结构中插入填充，尤其是当元素不是 4 字节的倍数时。情况会更糟sequence，但那是不同的。

在 C 中尝试这个等价的派生类型：

#include <stdio.h>
#include <stdint.h>
#include <complex.h>

typedef struct{
  int16_t  a;
  float complex b;
  int16_t c;
} t;

int main(){
 t o;
 printf("%x %x %x \n",&o.a,&o.b,&o.c);
 return 0;
}

我的编译器（gcc在 x86_64 上）将组件对齐到 4 字节的倍数，即使没有任何优化。gfortran更重要的是，对齐方式与启用所有优化时选择的方式完全相同。

icc,ifort和suncc也使用相同的对齐方式sunf90。

  • 模块iso_c_binding本身应该对优化没有影响，因为它只是参数、类型定义和过程的集合。它可能会迫使您使用比通常更多的指针。
于 2013-09-18T08:38:22.430 回答