[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: filesystem and x86 vs. x86_64 benchmarking...



David Liontooth <liontooth@cogweb.net> writes:

> Dale E. Martin wrote:
>
>>I mentioned the other day I was doing some benchmarking on my shiney new
>>amd64 system.  Here is a quick writeup about it:
>>http://www.the-martins.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=4&page=1
>>
>>My test setup will not exist by the end of today so if I missed something
>>obvious and/or important let me know ASAP!
>>
>>Thanks!
>>	Dale
>>
>>
> Thanks for doing this! Disappointing to see the poor amd64 results of
> course,
> but this is what we need to see.
>
> Cheers,
> Dave

Lets comment on those tests a bit.

First of all wall clock time is meaningless when comparing
results. When you have other processes competing for the CPU the wall
clock can rise drastically without the test being any slower. Wall
clock without % cpu usage is meaningless.

Secondly g++ using >1GB ram or temporary files in 64bit mode might not
be a bug at all but just the extra complexity of optimizing for
64bit. I noticed that gcc usualy uses 4 times as much ram in 64bit
than 32bit. Some worst case sources can increase that easily.

Looking over the compile tests it looks like a 64bit kernel is faster
in userspace but wastes about the same time in kernel space, probably
translating the 32bit syscalls to 64bit. It is too bad you have hardly
any comparable tests in there. A lot of 32bit tests without 64bit
counterpart.


And where is the bonie++ test with 64bit kernel? Do any of the FS
become faster/slower? Actualy I wan't three runs: 32bit kernel, 64bit
kernel + 32bit userland, 64bit kernel+userland.

We all have seen comparisons between FSes and that is a rather boring
repeat.

MfG
        Goswin



Reply to: