Re: r4 v. ext3, quick speed vs. cpu experiments

Re: r4 v. ext3, quick speed vs. cpu experiments

[Szakacsits Szabolcs]

How much memory you have? How big is mozilla-1.5a.tar? Did you include
'sync' in the tests? It seems reiser4 numbers are mostly in-memory
operations and not all data flushed to disk while this is apparently not
true for ext3. BTW, XFS numbers would be also/more interesting, ext[23] is
pretty outdated.

BTW, from your numbers it seems ext3 gives better overall performance.

	Szaka

On Tue, 5 Aug 2003, Grant Miner wrote:

> "mozilla-1.5a.tar" is mozilla 1.5alpha source tar, uncompressed.
> Partition mkfs.ext3 or mkfs.reiser4 --keys=SHORT is run before each run.
> Linux is 2.6.0-test2.
>
> untar mozilla-1.5a.tar (file is on a reiser3 partition):
> ext3: 17.64s 28% cpu
> reiser4: 10.79s 67% cpu
> sum: reiser4 0.61x time, 2.39x cpu
>
> cp -a mozilla-src mozilla-src-copy, same partition:
> ext3: 0:56.35sec 11% cpu
> reiser4: 0:16.50 55% cpu
> sum: reiser4 0.29x time, 5x cpu
>
> tar c mozilla-src > mozilla.tar, same partition:
> ext3: 0:36.47sec 10%cpu
> reiser4: 0:16.90sec 25%cpu
> sum: reiser4 0.46x time, 2.5x cpu
>
> i'm impressed!

Re: r4 v. ext3, quick speed vs. cpu experiments

[Szakacsits Szabolcs]

On Tue, 5 Aug 2003, Brandon Low wrote:
> On Tue, 08/05/03 at 23:08:31 +0200, Szakacsits Szabolcs wrote:
> > BTW, from your numbers it seems ext3 gives better overall performance.
> >
> That is an incorrect statement.  Reiserfs is KNOWN to be heavier on CPU
> than other filesystems, it's benefit is not there, it's benefit is in
> speed of operation, and efficiency of disk accesses.  It would be near
> impossible for a filesystem with 4x (unsure of this figure) the code of
> ext3 to execute in the same CPU time, but the fact that it is
> consistently a LOT faster on the total run time is very impressive.

Yes, if you have enough CPU capacity (aka you don't run anything else, just
bechmarking filesystems). Otherwise it seems to be slower. That's I was
refering to.

	Szaka

r4 v. ext3, quick speed vs. cpu experiments

[Grant Miner]

"mozilla-1.5a.tar" is mozilla 1.5alpha source tar, uncompressed. 
Partition mkfs.ext3 or mkfs.reiser4 --keys=SHORT is run before each run. 
Linux is 2.6.0-test2.

untar mozilla-1.5a.tar (file is on a reiser3 partition):
ext3: 17.64s 28% cpu
reiser4: 10.79s 67% cpu
sum: reiser4 0.61x time, 2.39x cpu

cp -a mozilla-src mozilla-src-copy, same partition:
ext3: 0:56.35sec 11% cpu
reiser4: 0:16.50 55% cpu
sum: reiser4 0.29x time, 5x cpu

tar c mozilla-src > mozilla.tar, same partition:
ext3: 0:36.47sec 10%cpu
reiser4: 0:16.90sec 25%cpu
sum: reiser4 0.46x time, 2.5x cpu

i'm impressed!

Re: r4 v. ext3, quick speed vs. cpu experiments

[Brandon Low]

On Tue, 08/05/03 at 23:08:31 +0200, Szakacsits Szabolcs wrote:
> BTW, from your numbers it seems ext3 gives better overall performance.
> 
That is an incorrect statement.  Reiserfs is KNOWN to be heavier on CPU
than other filesystems, it's benefit is not there, it's benefit is in
speed of operation, and efficiency of disk accesses.  It would be near
impossible for a filesystem with 4x (unsure of this figure) the code of
ext3 to execute in the same CPU time, but the fact that it is
consistently a LOT faster on the total run time is very impressive.

--Brandon

> 	Szaka
> 

Re: r4 v. ext3, quick speed vs. cpu experiments

[Brandon Low]

On Tue, 08/05/03 at 23:35:12 +0200, Szakacsits Szabolcs wrote:
> 
> On Tue, 5 Aug 2003, Brandon Low wrote:
> > On Tue, 08/05/03 at 23:08:31 +0200, Szakacsits Szabolcs wrote:
> > > BTW, from your numbers it seems ext3 gives better overall performance.
> > >
> > That is an incorrect statement.  Reiserfs is KNOWN to be heavier on CPU
> > than other filesystems, it's benefit is not there, it's benefit is in
> > speed of operation, and efficiency of disk accesses.  It would be near
> > impossible for a filesystem with 4x (unsure of this figure) the code of
> > ext3 to execute in the same CPU time, but the fact that it is
> > consistently a LOT faster on the total run time is very impressive.
> 
> Yes, if you have enough CPU capacity (aka you don't run anything else, just
> bechmarking filesystems). Otherwise it seems to be slower. That's I was
> refering to.
> 
And admittedly, reiser4 does have a ways to go in terms of getting those
5x numbers down to reasonable levels, in those benchmarks I wouldn't
call either of the FSs a clear winner or loser... I would say that it
really depends on where your particular system's bottleneck is.  If it
is in CPU then don't use reiser4, but if it is in the IO, then reiser
may be a very good choice.

--Brandon

> 	Szaka

Re: r4 v. ext3, quick speed vs. cpu experiments

[Grant Miner]

Szakacsits Szabolcs wrote:
> How much memory you have? How big is mozilla-1.5a.tar? Did you include
> 'sync' in the tests? It seems reiser4 numbers are mostly in-memory
> operations and not all data flushed to disk while this is apparently not
> true for ext3. BTW, XFS numbers would be also/more interesting, ext[23] is
> pretty outdated.
> 
> BTW, from your numbers it seems ext3 gives better overall performance.
> 
> 	Szaka
> 
Good suggestion.  With ext3, 'sync' adds 10.2 seconds average to total
time (others about 1.6 sec).  Here is a list of averages, including sync
time.  Each fs was run 3 times.  Note that I did not count sync's cpu %
in cpu %.

xfs: average 44.3 seconds, 32% cpu
ext3: average 44.0 seconds, 27% cpu
r4: average 30.2 seconds, 39% cpu

I have 512MB memory.  File tree is about 295 MB.  This was just a "for
fun" test, and it probably not accurate.  I may try better ones later.

Re: r4 v. ext3, quick speed vs. cpu experiments

[Hans Reiser]

Grant Miner wrote:

> Szakacsits Szabolcs wrote:
>
>> How much memory you have? How big is mozilla-1.5a.tar? Did you include
>> 'sync' in the tests? It seems reiser4 numbers are mostly in-memory
>> operations and not all data flushed to disk while this is apparently not
>> true for ext3. BTW, XFS numbers would be also/more interesting, 
>> ext[23] is
>> pretty outdated.
>>
>> BTW, from your numbers it seems ext3 gives better overall performance.
>>
>>     Szaka
>>
> Good suggestion.  With ext3, 'sync' adds 10.2 seconds average to total
> time (others about 1.6 sec).  Here is a list of averages, including sync
> time.  Each fs was run 3 times.  Note that I did not count sync's cpu %
> in cpu %.
>
> xfs: average 44.3 seconds, 32% cpu
> ext3: average 44.0 seconds, 27% cpu
> r4: average 30.2 seconds, 39% cpu
>
> I have 512MB memory.  File tree is about 295 MB.  This was just a "for
> fun" test, and it probably not accurate.  I may try better ones later.
>
>
>
>
Expect the CPU time to drop a lot, because we first got rid of the IO 
consuming kruft, now we are getting rid of the CPU consuming kruft.

That is, expect it to drop up until we ship a compression plugin.....

Can you post your numbers on lkml also?

-- 
Hans

Re: r4 v. ext3, quick speed vs. cpu experiments

[Matthias Andree]

Szakacsits Szabolcs <szaka@sienet.hu> writes:

> Yes, if you have enough CPU capacity (aka you don't run anything else, just
> bechmarking filesystems). Otherwise it seems to be slower. That's I was
> refering to.

This has been the situation with reiserfs 3.5/3.6 before, and it got
resolved, or so it appears. I haven't ext3-vs-reiserfs3.6 figures at
hand, but I'm not aware of CPU bottlenecks in reiserfs3.6 code. Just
wait a couple of months until the reiserfs gurus got their reiserfs4
beast stable and debugged and can focus on tuning.

To a previous post about code size and execution speed: it's not
generally true that larger code is also slower. It depends how that code
is arranged. If you have many abstractions, then maybe it's slower. If
you have many specialized functions in an otherwise flat profile, it can
be a good deal faster than a simpler (less complex) code.

-- 
Matthias Andree