Update: Andras updated mbw to fix this.
I was testing a machine's memory performance, and ran across the "mbw" package in Ubuntu lucid.
$ mbw -a -n 1 1024
...
0Method: MEMCPYElapsed: 0.23493MiB: 1024.00000Copy: 4358.801 MiB/s
0Method: DUMBElapsed: 0.16298MiB: 1024.00000Copy: 6282.864 MiB/s
0Method: MCBLOCKElapsed: 0.08543MiB: 1024.00000Copy: 11986.562 MiB/s
I was curious why the MCBLOCK numbers were so much higher than the others, and this led me to the relevant piece of code:
for(t=0; t < array_bytes; t+=block_size) {
c=mempcpy(b,a,block_size);
}
if(t > array_bytes){
c=mempcpy(b,a,t-array_bytes);
}
Which appears to be completely broken. The mempcpy(b, a, block_size) call does exactly same thing every time. All I can figure is that the author either was trying to demonstrate cache performance, or fumbled an attempt to do the memcpy() calls on blocks of block_size each.
Anyway, it's a good reminder of Caveat Emptor when using random benchmarks.
I was testing a machine's memory performance, and ran across the "mbw" package in Ubuntu lucid.
$ mbw -a -n 1 1024
...
0Method: MEMCPYElapsed: 0.23493MiB: 1024.00000Copy: 4358.801 MiB/s
0Method: DUMBElapsed: 0.16298MiB: 1024.00000Copy: 6282.864 MiB/s
0Method: MCBLOCKElapsed: 0.08543MiB: 1024.00000Copy: 11986.562 MiB/s
I was curious why the MCBLOCK numbers were so much higher than the others, and this led me to the relevant piece of code:
for(t=0; t < array_bytes; t+=block_size) {
c=mempcpy(b,a,block_size);
}
if(t > array_bytes){
c=mempcpy(b,a,t-array_bytes);
}
Which appears to be completely broken. The mempcpy(b, a, block_size) call does exactly same thing every time. All I can figure is that the author either was trying to demonstrate cache performance, or fumbled an attempt to do the memcpy() calls on blocks of block_size each.
Anyway, it's a good reminder of Caveat Emptor when using random benchmarks.