On Tue, 15 Mar 2005 23:49:27 -0800, Christopher Smith <[EMAIL PROTECTED]> wrote:
> Barry Gershenfeld wrote:
>
> > I originally understood that you ran the k3b md5'er separately. I guess
> > this isn't possible, which is, (say it with me) un-Unix-like. So maybe
> > someone who thinks C++ is easy, and the source clear and simple, can
> > compile
> > us a standalone "kmd5" program to test with.
>
> Done. I stripped out all the Qt/KDE bits to make it easier to build. The
> code is at:
>
> http://rijmen.xman.org/md5bench.tar.bz2
>
> I didn't spend any time optimizing this, and in particular, I think the
> I/O could most definitely be tuned. I also probably could more carefully
> select compiler optimizations and use something cleaner than the evil
> hack I used for writing out the hash values, but all-in-all, I expect
> it's a fair representation of the kind of performance you can get from
> this stuff. I compiled with:
>
> g++ -O3 -o md5bench kmdcodec.cpp md5bench.cpp
>
> Performance is about 25% slower than md5sum. Not great, but certainly
> much less than the kind of performance differences we're talking about.
> I haven't profiled it, but I'd be willing to bet most of the lost time
> is not spent doing md5 calculations.
Finally I have found the right place to point the finger. I must
apologize for the old-fashioned assumption that when a compute-bound
process starts up and the CPU becomes 100% busy, it is that process
that is using the resources.
Observation using "top" has shown me that K3b does its MD5 sums in two
different ways -- with and without the graphic thermometer display.
When checksumming a file in preparation for burning it to CD, there is
no graphic display, and I measure the performance to take 150% of the
time that the command-line mdtsum would use. When checksumming the
same file after making the CD, and when checksumming the CD itself,
the graphic display shows the percent completion in "real time", and a
lot of real time passes.
During that process, the CPU is used 50% by the metacity display
manager, and 25% by the X window manager. K3b gets about 20%, to
distribute between reading the file and checksumming it, and perhaps
sending data to metacity which then sends it to X. At the end, the
metacity and X usages drop back to near zero.
I don't know how freqently the thermometer display is being updated,
but I bet that it is a lot faster than the once per second that would
be reasonable.
carl
--
carl lowenstein marine physical lab u.c. san diego
[EMAIL PROTECTED]
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
