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. GREAT ;) > - 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. not really other then 'try to approximate your own problem'. maybe varying the 1K chunks to <512 byte, 512 byte aligned, unaligned,... >> 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 100% wrong. rawspeed came from somewhere else, I still don't know what it does, and scince it gave very inconsistent results, I wrote RAWREAD where I know what it does, and source is available. >> 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. agreed. YOU did. but everybody else measured a different test, and different configurations. >> 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. it's not the move. IMO it's reading data single sector wise(even linearily) - which is damned slow, UDMA or not > I will include some alignment test in my test program. Do you have some > piece of code to send? google rawread 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
