tom ehlert escreveu:
Hello Alain,
just a general hint in benchmarking (for beginners):
a) try to measure something with something that you understand what it
does; else your measurements might not be interpretable
scince you don't know what rawspeed does (*exactly*), or what your
indexing app does (again, *exctly), interpratation might be hard.
choose an application that you really understand; maybe by writing
some 100 lines of code where you *know* what they do
Ok, I can do that and I am willing.
- First test is obvious, so I will start right away: Writing a very big
file, in big chunks (32k) and rereading it.
Second: simulating the index problem: creating two files (index case was
1.5 to 2.5Mb size) and random reading one, whine random
reading/modifying the other in 1k chunks (I know index have 1k nodes).
Please suggestions, specially on the second one.
at least for Jack's 'unzip 2 GB file* it's clear what it does: it
writes a single, real big file, most probably in big chunks (but even
that is unknown)
That is exactly what the author of raw speed said it does. he was the
amtainer of UDMA and made it specialy for this test
b) compare apples to apples
the reason for any speed difference may dependend on many things like
OS: buffering strategy, cache replacement strategy, cache size,...
APP: write size, alignment (see below),...
I tried that: Clean test machine, allways the same test and the same data.
UMB, and possibly the reason for the real slowdown:
I know that Freedos won't read data directly into a UMB
destination; these data are read single-sectorwise through a buffer
loaded in low RAM (that's at least what I remember to have
implemented). this IS slow.
the reason for this is, that UMBPCI was/is popular for freedos as UMB
provider, and reading with DMA to UMB area wouldn't work on a
significant subset of all machines.
while this was DMA for floppies, this is probably still true for UDMA,
as it's a UMBPCI+chipset problem
so we (I and Bart agreed) decided to read everything above 0xa000
through this single deblocking buffer.
That completely rules out my hipotesis... I don't believe the extra move
can be responsible for all the slow down that I found.
so it comes down to:
if anybody read's data directly into UMB (using int21 or int25/26),
this will be slow; usually this uncommon
Int 25/26 is "absolute disk read/write" and would not have generated a
file (I checked, it was there). So this is 99.999% probabily ruled ou,
*or* ther is another way to do it.
re:UDMA and alignment 'problem'
just by aligning read buffers proper to 32 bit boundaries, I could
gain ~10% total performance.
reason: with proper alignment, UDMA can read directly into my user
buffers, else it has to read+copy to/from XMS.
'caused' by UDMA, but it's certainly not UDMA to blame.
it's just that UDMA works best if you follow the rules; if not you
have to pay some performance
I will include some alignment test in my test program. Do you have some
piece of code to send?
Alain
tom
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
