Block
memory allocation/deallocation:
These benchmarks test the block memory allocation/deallocation subsystem
of Flux. It promises significant speedups when allocating many blocks
of the same size, such as the headers of token tree nodes.
We ran comparisons by allocating
8192 blocks of a given size, and then freeing them, repeating the process
2000 times per block size, comparing standard malloc()/free()
from glibc 2.1 with the block allocation subsystem in Glib 1.2.6 (in G_ALLOC_AND_FREE
mode) and the bmem subsystem in the upcoming Flux 0.4.0, using getrusage().
While glibc's near linear falloff
with block size is to be expected, given that it's not optimized for same-size
block allocation, Glib gives disappointing and somewhat unexpectedly poor
results, especially for larger block sizes.

This graph compares the performance on an older system,
a 200Mhz Pentium with 96 Megabytes of RAM, running RedHat Linux 6.1 with
kernel 2.2.12-20. The system was brought down to single user mode before
performing the tests, so the test results were minimally affected by external
factors.

Here we see the performance on Simplemente's main workhorse
server, an Aspen Systems 533Mhz Alpha 21164 system with 256 Megabytes
of RAM, running RedHat Linux 6.0 with kernel 2.2.14. This system was in
regular use while the tests were performed, so it is possible that the
results are slightly less precise. However, rerunning the tests several
times gave no perceptible differences in the results, and we believe that
external factors would most likely influence all three contenders equally.
Conclusion: Flux performs
significantly and consistently better than both glibc and Glib on all
block sizes, and in particular excels on medium-to-large block sizes,
and/or on 64-bit platforms.
|