2001-12-09 15:15:14

by Russell Coker

[permalink] [raw]
Subject: per-char IO tests

I have released a new experimental version of Bonnie++ that includes a
program to test per-char IO using putc()/getc(), putc()/getc() when linked in
a non-threaded way (significantly improves performance)
putc_unlocked()/getc_unlocked(), and write()/read().

Here's the results of testing my Thinkpad T20 with P3-650:

Version 1.93 write read putcNT getcNT putc getc putcU getcU
lyta 142 651 8189 9348 1763 1813 22174 44887
lyta,142,651,8189,9348,1763,1813,22174,44887

Here's the results of testing my Athlon 800 play machine:

Version 1.93 write read putcNT getcNT putc getc putcU getcU
test 146 607 7356 7280 1834 1971 41995 59100
test,146,607,7356,7280,1834,1971,41995,59100

Both machines run ReiserFS. A quick test indicates that using Ext2 instead
of ReiserFS triples the performance of write(fd, buf, 1), but this is
something I already knew (and had mentioned before on the ReiserFS list).

Also based on previous tests I expect Solaris to outperform Linux with glibc
on putcNT, getcNT, putc, and getc. The regular performance of putc() on
Solaris comes close to putc_unlocked() on Linux with glibc.




I'd like to thank Andrew Morton for forwarding messages from L-K that
provoked me to write this new test program.

I was tempted to subscribe to L-K to join this discussion, but it seems that
Linus is saying everything that needs to be said anyway so there's no point.
;)

--
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/ My home page


2001-12-09 16:04:24

by Chris Mason

[permalink] [raw]
Subject: Re: per-char IO tests



On Sunday, December 09, 2001 04:14:30 PM +0100 Russell Coker
<[email protected]> wrote:

> Both machines run ReiserFS. A quick test indicates that using Ext2 instead
> of ReiserFS triples the performance of write(fd, buf, 1), but this is
> something I already knew (and had mentioned before on the ReiserFS list).

This is most likely from logging the inode as you extend the file. Recent
pre releases for 2.4.17 include a from patch from Andrew that should help,
but I expect reiserfs to still be somewhat slower.

-chris