Marco Leise wrote: >Am 31.08.2011, 22:53 Uhr, schrieb Johannes Pfau <[email protected]>: > >> Andrei Alexandrescu wrote: >>> >>> This will happen all the more if you have multiple threads. >>> >>> You clearly have a good expertise on OS, I/O, and related matters, >>> and I am honoured by your presence and by the value you're adding >>> to this group. However, in this particular argument you're only >>> firing blanks. Are you sure you have a case? >>> >>> >>> Andrei >> >> So why don't we benchmark this? >> Here's a first, naive attempt: >> https://gist.github.com/1184671 >> >> There's not much to do for the sync implementation, but the async one >> should maybe keep a pool of buffers and reuse those. However, the >> async implementation was already ~10% faster in simple tests >> (copying a 700mb ubuntu .iso; source and target on the same >> harddisk). I wouldn't have expected this, but it seems the async >> copy is actually be faster. > >I cannot verify your numbers at all. I drop the caches before every >run and make two runs with --async first and --sync second and two >runs the other way round. On a 1GB file the async version adds an >average of 0.22%. With a larger buffer size that margin increases even >more. Did you actually clear the disk cache before runs and no other >application used the disk much? Browsers tend to save the session in >intervals. At the bottom of your heart you know that your numbers must >be wrong. :p Verify it once more!
Yeah I only did 2-3 quick tests on my desktop machine. I tested that on a file-server machine now (I know for sure that no other application accesses the disk there) and dropped the caches as you said. And you're right, there's no big difference anymore. Well, I guess I'll just wait till phobos has an async copy function and let someone else do the benchmarks ;-) -- Johannes Pfau
