ISO_C_BINDING：对性能/优化的影响

Question

在使用派生数据类型的 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 时是否还有其他陷阱？对代码施加了哪些限制以及禁用了哪些优化？

Answer 1

我不会那么担心。 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;
}

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

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

• 模块iso_c_binding 本身应该对优化没有影响，因为它只是参数、类型定义和过程的集合。它可能会迫使您使用比平时更多的指针。