1. 64k L1 cache per CPU
2. 256k shared L2 cache
3. 512k shared L2 cache
4. 2 MB shared L2 cache
5. 32k L2 cache per CPU
6. 64k L2 cache per CPU
7. 128k L2 cache per CPU
8. 256k L2 cache per CPU
9. 512k L2 cache per CPU
10. 1 MB L2 cache per CPU
11. 1.5 MB L2 cache per CPU
12. 2 MB L2 cache per CPU
13. 4 MB L2 cache per CPU
14. 8 MB L2 cache per CPU
15. 12 MB L2 cache per CPU
16. 1 MB L3 cache per CPU
17. 2 MB L3 cache per CPU
18. 4 MB L3 cache per CPU
19. 6 MB L3 cache per CPU
20. 8 MB L3 cache per CPU
21. 12 MB L3 cache per CPU
22. No memory interleaving
23. 2-way memory interleave
24. 4-way memory interleave
25. 8-way memory interleave
26. Memory parity checking enabled
27. Memory parity checking disabled
28. Fastest result
29. Median result
30. Slowest result
31. benchmarked from CD miniroot
32. Used more CPU time than elapsed on clock
33. Command line: dd if=/dev/dsp ...
34. R7 SM100 CPU with one RT605/RT601 disabled
35. System bogged down running "electropaint" screen saver
36. GNU time v1.7
37. SMP kernel
38. Non-SMP kernel
39. 2 MB Chip RAM + 16 MB Fast RAM
40. 4 MB ST RAM + 32 MB TT RAM
41. LPAR mode
42. VM guest

27 September 2023

This is a purposely silly benchmark, invented by Mike Knell in early 2000, and named by Melissa Binde. It measures the time (in seconds) to read one million 1 KB blocks from /dev/zero, immediately throwing them away via /dev/null. I extended it by also measuring the mean time (in seconds) to run 2, 4, 8, or 16 copies of the benchmark in parallel.

The canonical form of this benchmark is,

time dd if=/dev/zero of=/dev/null bs=1024 count=1000000

Mike Knell's original benchmarking exercise considered all results valid, even if it represented only the time to print dd: /dev/zero: no such file or directory. Such results are excluded here, because despite being deliberately absurd as a measure of machine performance, some useful things can nevertheless be inferred. For example:

1. overall, the score is influenced more by software than it is by hardware; even on identical hardware linux is twice as fast as anything else at the fhlushstone.
2. IRIX has some pathological performance characteristics as the number of CPUs increases, which are apparently fixed sometime after IRIX 6.5.13.
3. if non-parity RAM is used in the Apple Network Server, it will be clocked at 80ns instead of the normal 70ns; the ~10% performance penalty is directly observable.

...and so on.

Use the selection lists below to filter the results.