我已经阅读了Metcalf,Reid和Cohen的Fortran 95书以及Fortran 90中的Numerical Recipes.他们建议使用WHERE,FORALL和SPREAD以避免不必要的程序序列化.
但是,我偶然发现这个答案,声称FORALL在理论上很好,但在实践中毫无意义 - 你也可以编写循环,因为它们也可以并行化,你可以使用OpenMP(或某些编译器的自动功能)明确地将它们并行化.英特尔).
任何人都可以从经验中验证他们是否通常发现这些结构比显式循环和if并行性能方面的语句更具优势吗？
是否还有其他语言的并行功能,这些功能在原则上是好的但在实践中不值得？
我很欣赏这些问题的答案在某种程度上依赖于实现,因此我对gfortran,Intel CPU和SMP并行性最感兴趣.
M. *_* B. 13
正如我在对另一个问题的回答中所说的那样,人们普遍认为,FORALL在引入语言时并没有像希望的那样有用.正如在其他答案中已经解释的那样,它具有限制性要求和有限的角色,并且编译器已经非常善于优化常规循环.编译器越来越好,编译器和编译器之间的功能各不相同.另一个线索是Fortran 2008再次尝试...除了向语言添加显式并行化(共同数组,已经提到过)之外,还有"do concurrent",一个需要限制的新循环形式,应该更好地允许编译器执行自动并行优化,但应该足够通用才能有用 - 请参阅ftp://ftp.nag.co.uk/sc22wg5/N1701-N1750/N1729.pdf.
在获得速度方面,我主要选择好的算法和程序以提高可读性和可维护性.只有当程序太慢时才能找到瓶颈并重新编码或实现多线程(OpenMP).这将是一个罕见的情况,其中FORALL或WHERE与显式do循环将具有有意义的速度差异 - 我更多地看他们如何清楚地表明程序的意图.
我看起来很浅薄,而且很难报告,通常会发现编写我的循环显然会导致比你编写的并行结构更快的程序.即使是简单的全数组赋值,例如A = 0通常也可以通过do循环来表现.
我手头没有任何数据,如果我这样做,那就太过分了.我真的应该把所有这些都放到一个测试套件中再试一次,编译器会改进(有时它们会变得更糟).
我仍然使用并行结构,特别是全数组操作,当它们是表达我想要实现的最自然的方式时.我还没有在OpenMP工作共享构造中测试这些构造.我真的应该.