Benchmarking implementations of functional languages with ‘Pseudoknot’, a float-intensive benchmark
Benchmarking implementations of functional languages with ‘Pseudoknot’, a float-intensive benchmark
复制标题
使用“Pseudoknot”（浮动密集型基准）对函数式语言进行基准测试
DOI：
--
复制
发表时间：
1996
影响因子：
1.1
通讯作者：
Peter Wentworth
中科院分区：
文献类型：
--
作者：
Pieter H. Hartel;Marc Feeley;M. Alt;Lennart Augustsson;Peter Baumann;M. Beemster;Emmanuel Chailloux;Christine H. Flood;Wolfgang Grieskamp;John H. G. van Groningen;Kevin Hammond;Bogumil Hausman;M. Ivory;Richard E. Jones;J. Kamperman;Peter Lee;Xavier Leroy;R. D. Lins;S. Loosemore;Niklas Röjemo;Manuel Serrano;J. Talpin;J. Thackray;Stephen Thomas;Pum Walters;Pierre Weis;Peter Wentworth
超过25种功能性语言的实现，使用同一程序进行基准测试，从分子生物学中提取的浮点数是浮点数。如何修改和调整程序以获得每种语言实现的最大性能。该程序虽然大多数编译器都比当前的GNU C编译器快（GCC版本2.5.8）。当使用适当的注释时，总汇编时间的大部分都没有明确的区别：它在很大程度上实施了严格的应用程序，例如PSEUDOKNOT计划。首先要谨慎地解释，基于单个程序的基准不能涵盖广泛的“典型”应用程序。提供的优化，因此获得该程序的最佳版本所需的努力也有类似的不同。
Abstract Over 25 implementations of different functional languages are benchmarked using the same program, a floating-point intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation. With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time. There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implementations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations. The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of ‘typical’ applications. Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varied.