|Philosophy||1) Benchmark language implementations, not individual programs (simple tasks with few pitfalls).|
2) Benchmark one language a time, not a mixture of languages (no non-standard libraries in other languages; no language extension).
|CPU||Intel(R) Xeon(R) CPU E5440 @ 2.83GHz|
|OS||Debian GNU/Linux 5.0|
|Source code||https://github.com/attractivechaos/plb (MIT licensed)|
|Note on update||The benchmark was originally conducted in June, 2011. The results for a few implementations have been updated since then, but others have not. The original results can be found at here. The picture below is for the old results.|
|sudoku:t||CPU time in seconds for solving 20x50 Sudokus (20 extremely hard Sudokus repeated 50 times) using an algorithm adapted from suexco. This algorithm is not the fastest, but it is very easy to reimplement. Note that "sudoku" and "matmul" evaluate the performance of the language itself. "Patmch" and "dict" below effectively evaluate the performance of libraries.|
|matmul:t||CPU time in seconds for multiplying two 1000x1000 matrics using the standard cubic-time algorithm. This benchmark evaluates the performance of nested loops with a simple inner loop, which is frequent in scientific computing.|
|matmul:m||Memory in megabytes for multiplying two 1000x1000 matrics using the standard cubic-time algorithm.|
|patmch:1t||CPU seconds for finding lines matching regexp "([a-zA-Z][a-zA-Z0-9]*)://([^ /]+)(/?[^ ]*)" in this file. This benchmark evaluates the performance of regex matching common in the context of biological sequence analyses. The uncompressed text file is copied to /dev/shm to avoid I/O overhead. For C, reading the input file line by line with fgets() takes 0.1 CPU second.|
|patmch:2t||CPU seconds for finding lines matching "([a-zA-Z][a-zA-Z0-9]*)://([^ /]+)(/?[^ ]*)|([^ @]+)@([^ @]+)" in this file. This benchmark evaluates the performance given the "|" regex operator which is known to hurt back-tracking based regex matching algorithms.|
|dict:t||CPU seconds for counting the occurrence of each distinct string among 5 million strings. The average occurrence is 4. This benchmark evaluates the efficiency of associative arrays. The strings are generated by this program. For C, reading the input file line by line takes 0.3 CPU second.|
|dict:m||Memory in megabytes for counting the occurrence of each distinct string among 5 million strings.|
1) C programs are compiled with "gcc/clang -O3 -fomit-frame-pointer" or "icc -O3 -fomit-frame-pointer -xSSE4.1"|
2) D programs are compiled with "ldc -O3 -release" or "gdc -O3 -frelease -inline".
3) Mono-sgen is used for implementations requiring the .NET framework. Mono-sgen is usually faster but costs more memory than mono.
4) `999.9' in the table indicates that the language does not support the feature or no implementations are available.
1) For these Sudokus, JSolve can find the solutions in 0.23 CPU seconds.|
1) LDC, PyPy, CPython2/3, JS, LuaJIT and IronPython use "v2" and the rest use "matmul_v1.*" in the source code directory.|
2) The built-in Matrix class in Ruby does not transpose the second matrix before multiplication. Using the built-in class is twice as slow.
3) Using the built-in matrix multiplication operator, R takes 2.7 sec in 57.0 MB memory, a huge difference.
1) The file used in the benchmark contains non-ASCII characters, which
are removed by this program.|
2) C uses "patmch_v2.*" and the rest use "patmch_v1.*" in the repository.
3) The regexp9 library from the Plan 9 project is used for the C implementation. Better libraries exist in C++.
|patmch:2t||1) Lua built-in string matching, which is different regex matching, does not support the "|" regex operator.|
1) All language implementations use "dict_v1.*" in the repository.|
2) My khash library is used for the C implementation. The C++ implementation takes 3.4 sec using 71.1MB memory.
3) The C implementation manipulates the memory, which may be unfair to other implementations.
In the following plots, a number in red indicates that the corresponding implementation requires explicit compilation; in blue shows that the implementation applies a Just-In-Time compilation (JIT); in black implies the implementation interprets the program but without JIT.
The bar chart is updated on June 21, 2011. It may not always be synchronized with the table.