Ребят, потестите пожалуйста

← →
Sapersky (2013-02-15 00:21) [80]

говорят замер времени таким образом не совсем точный на многоядерных процессорах

Я читал, что в Висте/7 пофиксили, так что сейчас уже не особо актуально. Да и глюки были только со старыми AthlonX2, вроде.

FILE_FLAG_NO_BUFFERING - надо посмотреть как работает

Под "лучше использовать FILE_FLAG_NO_BUFFERING" я подразумевал - для теста, чтобы не сбрасывать кэш вручную. И скорее для чтения, чем для записи, на чтении больше вероятность, что кэш не сработает.

Запись (или чтение) на диск - достаточно затратная операция. Причём в этот момент проц почти не грузится, а мы тупо ждём работы HDD. Для повышения производительности я попробовал реализовать двойной буфер. Пока один буфер используется нами, второй взаимодействует с диском в дополнительном потоке.

Теоретически неплохая идея, при условии, что второй поток занят чем-то существенным, например, при загрузке текстового файла начинает парсинг предыдущего загруженного фрагмента, или в случае сжатых данных упаковкой/распаковкой.
Т.е. параллельно ввод-вывод и обработка. В тесте у тебя обработки как таковой нет, поэтому никакого эффекта не видно.

Интересно, можно ли получить какую-то выгоду от асинхронных операций, есть ли разница между просто вводом-выводом в отдельном потоке и асинхронными запросами.
Вот здесь товарищ получил:
http://blog.gamedeff.com/?p=142#more-142
хотя, конечно, задача у него сильно другая - случайное чтение с минимальными задержками. На последовательном, наверное, куча асинхронных запросов не поможет, разве что файл сильно фрагментирован.

← →
Игорь Шевченко © (2013-02-15 00:27) [81]

Sapersky (15.02.13 00:21) [80]

> Теоретически неплохая идея, при условии, что второй поток
> занят чем-то существенным

Иллюстрация самая наглядная - это обычная бесхитростная запись с использованием системого кэша, а в ряде случаев и чтение, с указанием FILE_FLAG_SEQUENTIAL_SCAN, в этом случае рабочий поток кэша занимается опережающим чтением или отложенной записью данных параллельно с работой потока приложения.

← →
Jeer © (2013-02-15 00:30) [82]

Чисто методически:

Нет смысла гонять "примитивные" методы доступа к той или иной памяти, если не поставлена общая задача обработки данных. (С)

← →
Игорь Шевченко © (2013-02-15 00:56) [83]

Jeer © (15.02.13 00:30) [82]

+100500

← →
Sapersky (2013-02-15 01:23) [84]

Значит всё-таки волшебные флажки помогают в некоторых случаях.
Но получается, чтобы опережающее чтение работало, надо не грузить непрерывно, а вперемешку загрузил фрагмент - обработал (система тем временем подгрузила новую порцию). При записи не так критично, но тоже желательно, чтобы кэш сильно не разбухал.
Причём угадать, какую конкретно нужно делать "паузу", довольно тяжело.
Возможно, лучше таки использовать асинхронность. Насоздавали запросов - обрабатываем по мере готовности, параллельно с выполнением следующих.

← →
Jeer © (2013-02-15 01:40) [85]

> Sapersky (15.02.13 01:23) [84]

"Смысл оптимизации частного не может быть выше смысла оптимизации общего" (С) Jeer.

← →
DevilDevil © (2013-02-15 09:50) [86]

> Sapersky (15.02.13 00:21) [80]

> Теоретически неплохая идея, при условии, что второй поток
> занят чем-то существенным, например, при загрузке текстового
> файла начинает парсинг предыдущего загруженного фрагмента,
> или в случае сжатых данных упаковкой/распаковкой.
> Т.е. параллельно ввод-вывод и обработка. В тесте у тебя
> обработки как таковой нет, поэтому никакого эффекта не видно.

обижаете, товарищ!
в данном примере (reading_benchmark.exe) как раз происходит распарсивание текста, подсчёт суммы всех чисел в файле. В correct_file.txt 22млн строк, каждую из которых мы распарсиваем и переводим к инту.

Я специально подбирал такие тесты, чтобы не очень загружать процессор при записи файла (ибо при записи процессор обычно не сильно напрягается, данные уже есть), а при чтении файла - подгрузить процессор (потому что при чтении, будь то парсинг или обычное потоковое чтение, мы процессор нагружаем).

В том то и дело...
Получается, нужно протестировать чтение: с FILE_FLAG_SEQUENTIAL_SCAN, с асинхронным чтением, FILE_FLAG_NO_BUFFERING.

Я не думаю, что если данные находятся в дисковом кеше, то хинт FILE_FLAG_NO_BUFFERING сбросит его. Скорее просто оптимальнее распорядится памятью

← →
DevilDevil © (2013-02-15 10:00) [87]

> Jeer ©

видимо ты слишком редко сталкивался с такими задачами, если не врубился "зачем всё это"
потоковое чтение или потоковая запись больших файлов - одна из сложнейших задач, особенно если стоит задача выжать максимальную производительность. К примеру в writing_benchmark.exe показано, как можно записать 100мб текста стандартным способом

← →
Jeer © (2013-02-15 10:27) [88]

Удалено модератором

← →
Jeer © (2013-02-15 10:28) [89]

Удалено модератором

← →
DevilDevil © (2013-02-15 10:33) [90]

напоминаю, актуальный (мой) бенчмарк здесь:http://zalil.ru/34257617
для удобства есть "benchmarks.bat", который выдаёт "benchmarks.log"

можете закомментировать строки "DoubleBuffered" варианты
можно вписывать флаги CreateFile() в TCachedFileWriter.Initialize() и заменить FileOpen() на CreateFile() с флагами в TCachedFileReader.Initialize()

← →
DevilDevil © (2013-02-15 10:34) [91]

Удалено модератором

← →
Sapersky (2013-02-15 19:28) [92]

в данном примере (reading_benchmark.exe) как раз происходит распарсивание текста, подсчёт суммы всех чисел в файле.

Пардон, не смотрел в исходник.
Тем не менее, 2 потока в среднем быстрее всего на 2-3%, если это не погрешность измерений. И с NO_BUFFERING, когда система не должна делать упреждающее чтение, тоже (сам диск делает?).
Не знаю уж, в чём дело. Возможно, в том, что скорость некэшированного чтения и так уже близка к максимально возможной (у меня 100-120 мб/c), больше ускоряться некуда. Т.е. и правда, не нужно "серебряной пули", обычные свинцовые нормально работают.
В NO_BUFFERING смысла нет, только замедляется всё на 5-10%. Кэш при этом сбрасывается (кстати, удобно для тестирования некэшированного чтения - сначала открыть с NO_BUFFERING, закрыть, открыть как обычно).
В FILE_FLAG_SEQUENTIAL_SCAN тоже особой магии нет (и на практике эффекта не видно), к тому же менеджер кэша может автоматически переключаться в этот режим:
http://blogs.msdn.com/b/oldnewthing/archive/2012/01/20/10258690.aspx

Асинхронное чтение здесь тестировали:
http://www.gamasutra.com/view/feature/129988/fast_file_loading_pt_1.php?print=1
Результат тот же, что и с обычным. Вывод забавный: лучший способ ускорить загрузку - уменьшить (сжать) файл. Но для тебя это неприемлемо, как я понимаю.

← →
DevilDevil © (2013-02-15 21:23) [93]

> Sapersky (15.02.13 19:28) [92]

за выходные постараюсь соорудить тест, который будет работать с разными размерами буфера и опциями

> Не знаю уж, в чём дело. Возможно, в том, что скорость некэшированного
> чтения и так уже близка к максимально возможной (у меня
> 100-120 мб/c), больше ускоряться некуда. Т.е. и правда,
> не нужно "серебряной пули", обычные свинцовые нормально работают.

мне знакомы люди, да и я сам в таких ситуациях бываю... когда по прошествии времени начинаешь маяться: правильно сделал, неправильно сделал, что мог сделать лучше. Подобные муки совести меня не интересуют. Поэтому я придерживаюсь философии делать максимум, на что способен. Если уж я взялся делать универсальный кешированный подход для чтения/записи данных (файлов), то с размером буферов и опциями я должен разобраться. Чтобы потом не парить себе мозг

← →
DevilDevil © (2013-02-17 03:08) [94]

я думаю надо в лог выводить название операционной системы и винчестера
поделитесь кодом у кого есть

← →
Sapersky (2013-02-17 04:29) [95]

Мог бы и сам поискать, вроде без проблем такие вещи находятся:
http://www.delphidabbler.com/download?id=sysinfo&type=src
http://home.earthlink.net/~akonshin/files/IdeInfo2.zip (нужны админские права)

← →
DevilDevil © (2013-02-17 10:09) [96]

> Sapersky (17.02.13 04:29) [95]

я просто за разделение труда
выуди пожалуйста оттуда код, берущий ProductName из PJSysInfo.pas
и ModelNumber из Ioctl.pas (только он берёт инфо первого диска, а надо инфо диска, с которого запускается exe)

← →
DevilDevil © (2013-02-17 19:55) [97]

Мне кажется я склепал толковый тест. И на чтение, и на запись
Каждая из тестовых утилит ведёт лог, можно взять данные оттуда
http://zalil.ru/34269667

Мои цифры:

write_test.exe Windows XP, ST380011A Top 8: 3895ms: 256kb, Overlapped | WriteThrough 4116ms: 128kb, Overlapped | Sequential | WriteThrough 4125ms: 256kb, NoBuffering 4146ms: 128kb, Overlapped | WriteThrough 4186ms: 256kb, NoBuffering | Sequential 4227ms: 256kb, NoBuffering | Overlapped | Sequential 4297ms: 256kb, NoBuffering | Overlapped 4396ms: 256kb, Overlapped | Sequential | WriteThrough Worse 8: 10776ms: 16kb, WriteThrough 10505ms: 16kb, Sequential | WriteThrough 10465ms: 16kb, NoBuffering | Overlapped | WriteThrough 9954ms: 16kb, NoBuffering | Overlapped | Sequential | WriteThrough 9815ms: 16kb, NoBuffering | WriteThrough 9754ms: 16kb, NoBuffering | Sequential | WriteThrough 8452ms: 32kb, Sequential | WriteThrough 8302ms: 16kb, Overlapped | WriteThrough

read_test.exe Windows XP, ST380011A Top 5: 2333ms: 256kb, NoBuffering | Overlapped | Sequential 2353ms: 64kb, NoBuffering | Overlapped 2354ms: 64kb, NoBuffering | Overlapped | Sequential 2394ms: 256kb, NoBuffering | Overlapped 2394ms: 16kb, Default Worse 5: 5878ms: 256kb, Overlapped 5048ms: 256kb, Default 4696ms: 16kb, NoBuffering 4587ms: 256kb, NoBuffering | Sequential 4326ms: 256kb, NoBuffering

← →
Sapersky (2013-02-17 21:45) [98]

Пока смотрел только чтение.
NoBuffering специально через один чтобы сбрасывать кэш? Но в самом начале файл тоже может быть закэширован (и у меня сначала первый тест выдал результат в 2 раза лучше). И даже если не закэширован, результаты первого теста могут отличаться, надо бы сначала сделать прогон "для разогрева". Вообще результаты довольно сильно "болтает", может из-за того, что они близки друг к другу. Но Sequential почти всегда оказывается в топе. Чистый NoBuffering - кхм, в боттоме.
Windows 7, ST3500412AS Top 5 (с пяти прогонов): 904ms: 64kb, Sequential 920ms: 32kb, Default 920ms: 128kb, Sequential 921ms: 64kb, Overlapped | Sequential 921ms: 16kb, Overlapped | Sequential 905ms: 64kb, Sequential 920ms: 64kb, Overlapped 920ms: 32kb, Default 920ms: 128kb, Sequential 921ms: 128kb, Default 905ms: 32kb, Sequential 920ms: 256kb, NoBuffering | Overlapped 921ms: 32kb, NoBuffering | Overlapped | Sequential 936ms: 128kb, NoBuffering | Overlapped | Sequential 936ms: 64kb, Overlapped | Sequential 936ms: 64kb, Sequential 951ms: 16kb, Sequential 952ms: 32kb, Default 952ms: 32kb, Sequential 952ms: 16kb, Overlapped | Sequential 920ms: 32kb, Overlapped | Sequential 920ms: 128kb, Overlapped 921ms: 64kb, Default 936ms: 16kb, Overlapped 936ms: 64kb, NoBuffering | Overlapped Worse 5: 1436ms: 16kb, NoBuffering 1419ms: 16kb, NoBuffering | Sequential 1279ms: 32kb, NoBuffering | Sequential 1264ms: 32kb, NoBuffering 1263ms: 256kb, NoBuffering | Overlapped | Sequential

Sequential задаёт поведение менеджера кэша (я же давал ссылку), поэтому при NoBuffering ни на что не влияет.
Можно ещё тестировать отдельно чтение из кэша. Чисто ради интереса, насколько эффективен кэш на разных ОС, например.

← →
DevilDevil © (2013-02-17 21:50) [99]

> Sapersky (17.02.13 21:45) [98]

в модуле TestPlatform.pas есть цикл в RUN_BENCHMARK()
там для каждого размера буфера запускается разный набор опций

у тебя кстати достаточно близкие значения
у меня разброс больше

выводи сразу и запись

← →
DevilDevil © (2013-02-17 21:54) [100]

а FlushFileBuffers я вызываю дважды
при старте и при завершении
но судя по всему это не всегда правильное действие оказывает
хз

кстати не забывай, что начиная с семёрки (или висты) используется особое кеширование файлов

← →
Игорь Шевченко © (2013-02-17 22:56) [101]

http://blog.dummzeuch.de/2013/02/16/35-gigabyte-text-file-meet-largetextviewer/

← →
Sapersky (2013-02-17 23:09) [102]

← →
DevilDevil © (2013-02-17 23:43) [103]

> Sapersky (17.02.13 23:09) [102]

а ты можешь откорректированные исходники со сброшенным кешем кинуть ?
я одного не понимаю
почему результаты настолько близки друг к другу

> Игорь Шевченко © (17.02.13 22:56) [101]

зачем ?

← →
Sapersky (2013-02-18 09:31) [104]

Нет там особенных проблем с кэшем, только на первом тесте могут быть. Поменяй условие:
if (i and 1 = 0) then Include(Mode.Options, foNoBuffering);
тогда тесты будут начинаться с небуферизованного режима, который сбрасывает кэш.
Неплохо бы ещё вместе с лучшими и худшими результатами выводить вариант без спец. флагов, чтобы понять, сколько собственно выгадано этими экспериментами. Судя по логам, заметный прирост получился на записи, раза полтора. На чтении не очень, 0-10%.

В [101] вероятно был вариант улучшения отклика программы с т.з. пользователя (вроде тебе это и требуется): начинать выводить данные, не загружая их полностью, вместо попыток ускорить загрузку ещё на несколько процентов. Ну или вместе с попытками, если хочется.

из загрузки. оптимизации загрузки до одурения. Ну или вместе с оптимизацией.

← →
Sapersky (2013-02-18 09:33) [105]

Последняя строчка лишняя :)

← →
DevilDevil © (2013-02-18 09:47) [106]

> Sapersky (18.02.13 09:31) [104]

> if (i and 1 = 0) then Include(Mode.Options, foNoBuffering);
> тогда тесты будут начинаться с небуферизованного режима,
> который сбрасывает кэш.

сделано
http://zalil.ru/34271095

> Неплохо бы ещё вместе с лучшими и худшими результатами выводить
> вариант без спец. флагов

варианты без спец флагов - это "Default". Только в топы он судя по результатам не попадает

> В [101] вероятно был вариант улучшения отклика программы
> с т.з. пользователя

не совсем понял, что ты имеешь ввиду

← →
megavoid © (2013-02-18 10:00) [107]

← →
megavoid © (2013-02-18 10:05) [108]

Windows 8, [Kingston KVR16N11] (RAM)

write_test.exe
Top 8: 1265ms: 128kb, NoBuffering | WriteThrough 1265ms: 256kb, Overlapped | WriteThrough 1266ms: 128kb, Overlapped | WriteThrough 1266ms: 128kb, NoBuffering | Sequential | WriteThrough 1266ms: 256kb, NoBuffering | Overlapped 1266ms: 256kb, NoBuffering | Sequential 1266ms: 256kb, NoBuffering | Overlapped | WriteThrough 1266ms: 64kb, Overlapped | Sequential | WriteThrough Worse 8: 1375ms: 16kb, Sequential | WriteThrough 1375ms: 16kb, NoBuffering 1375ms: 16kb, WriteThrough 1360ms: 32kb, WriteThrough 1344ms: 16kb, NoBuffering | WriteThrough 1344ms: 128kb, WriteThrough 1344ms: 16kb, NoBuffering | Sequential | WriteThrough 1343ms: 32kb, Sequential | WriteThrough

read_test.exe
Top 5: 344ms: 32kb, Sequential 344ms: 256kb, Overlapped | Sequential 359ms: 32kb, Default 359ms: 32kb, Overlapped 359ms: 16kb, Overlapped Worse 5: 406ms: 16kb, NoBuffering 375ms: 32kb, NoBuffering | Sequential 375ms: 16kb, NoBuffering | Overlapped | Sequential 375ms: 256kb, Sequential 375ms: 256kb, NoBuffering | Sequential

> megavoid ©

респект!

Вот мой тест на рабочем месте (правда касперский у нас дикий - может всё тормозить):

read_test.exe
Windows XP, SAMSUNG SP1213N

Top 5: 2156ms: 16kb, Default 2156ms: 16kb, Sequential 2156ms: 64kb, Sequential 2157ms: 32kb, Default 2171ms: 128kb, NoBuffering | Sequential Worse 5: 8312ms: 64kb, NoBuffering 5328ms: 64kb, Default 4125ms: 32kb, NoBuffering | Overlapped | Sequential 4078ms: 32kb, Overlapped | Sequential 3469ms: 16kb, NoBuffering Top 5: 2156ms: 128kb, Default 2157ms: 16kb, Default 2157ms: 128kb, NoBuffering | Sequential 2171ms: 16kb, NoBuffering | Overlapped 2171ms: 128kb, Overlapped Worse 5: 3500ms: 32kb, NoBuffering | Overlapped | Sequential 3422ms: 16kb, NoBuffering 3344ms: 256kb, Overlapped 3282ms: 256kb, Default 3204ms: 16kb, Overlapped Top 5: 2156ms: 32kb, Sequential 2156ms: 32kb, Overlapped | Sequential 2156ms: 64kb, Default 2156ms: 128kb, Sequential 2172ms: 32kb, Overlapped Worse 5: 4188ms: 16kb, Overlapped 3828ms: 16kb, NoBuffering 3234ms: 256kb, Default 3187ms: 128kb, NoBuffering 3187ms: 16kb, NoBuffering | Sequential

write_test.exe
Windows XP, SAMSUNG SP1213N
Top 8: 5859ms: 128kb, Overlapped | WriteThrough 6110ms: 256kb, Overlapped | WriteThrough 6156ms: 64kb, Default 6172ms: 128kb, Default 6234ms: 128kb, Overlapped 6297ms: 32kb, Default 6406ms: 256kb, Overlapped 6406ms: 256kb, Sequential Worse 8: 14672ms: 16kb, Sequential | WriteThrough 14250ms: 16kb, NoBuffering | Overlapped | Sequential | WriteThrough 14156ms: 16kb, WriteThrough 13828ms: 16kb, NoBuffering | WriteThrough 13640ms: 32kb, NoBuffering | Overlapped | Sequential 13235ms: 16kb, NoBuffering | Overlapped | WriteThrough 12812ms: 16kb, NoBuffering | Sequential | WriteThrough 11953ms: 64kb, NoBuffering | Overlapped | WriteThrough

Провели тест у коллеги

read_test.exe
Windows XP, Hitachi HDS721616PLA380
Top 5: 1406ms: 16kb, Default 1406ms: 16kb, NoBuffering | Overlapped 1406ms: 16kb, Overlapped 1406ms: 16kb, Sequential 1406ms: 16kb, NoBuffering | Overlapped | Sequential Worse 5: 3891ms: 32kb, Sequential 3172ms: 128kb, Sequential 2938ms: 16kb, NoBuffering | Sequential 2891ms: 16kb, NoBuffering 2016ms: 32kb, Overlapped

write_test.exe
Windows XP, Hitachi HDS721616PLA380

Top 8: 4110ms: 256kb, Overlapped | WriteThrough 4187ms: 256kb, Overlapped | Sequential | WriteThrough 4359ms: 128kb, Sequential 4359ms: 256kb, Sequential 4375ms: 256kb, Default 4500ms: 32kb, Default 4516ms: 128kb, Default 4516ms: 64kb, Default Worse 8: 34234ms: 16kb, WriteThrough 12157ms: 16kb, NoBuffering | Overlapped | WriteThrough 11797ms: 16kb, NoBuffering | Sequential | WriteThrough 11609ms: 16kb, Sequential | WriteThrough 11313ms: 16kb, NoBuffering | Overlapped | Sequential | WriteThrough 11031ms: 16kb, NoBuffering | WriteThrough 10796ms: 64kb, NoBuffering | Sequential | WriteThrough 8140ms: 16kb, Overlapped | WriteThrough

убрал из тестирования в среднем слабенькие размеры буфера 16кб и 32кб
чтобы тесты выдавали более объективную картину насчёт отпций
и чтобы выполнялись быстрее
http://zalil.ru/34271269

read_test.exe
Windows XP, SAMSUNG SP1213N
Top 5: 2157ms: 64kb, Overlapped | Sequential 2171ms: 128kb, Default 2172ms: 128kb, NoBuffering 2172ms: 128kb, NoBuffering | Overlapped | Sequential 2187ms: 256kb, NoBuffering | Overlapped | Sequential Worse 5: 5688ms: 256kb, Overlapped | Sequential 5344ms: 256kb, NoBuffering 4469ms: 128kb, NoBuffering | Sequential 4187ms: 256kb, Default 3984ms: 256kb, Overlapped Top 5: 2156ms: 64kb, Overlapped | Sequential 2172ms: 64kb, NoBuffering | Overlapped | Sequential 2172ms: 64kb, NoBuffering | Overlapped 2172ms: 128kb, NoBuffering 2172ms: 128kb, NoBuffering | Overlapped Worse 5: 6141ms: 256kb, NoBuffering | Overlapped 5266ms: 64kb, Sequential 3781ms: 256kb, NoBuffering | Sequential 3453ms: 256kb, Overlapped 3375ms: 64kb, Overlapped

write_test.exe
Windows XP, SAMSUNG SP1213N

Top 5: 6421ms: 128kb, Overlapped | Sequential | WriteThrough 6453ms: 256kb, Overlapped | WriteThrough 6484ms: 128kb, Overlapped | WriteThrough 6563ms: 256kb, Overlapped | Sequential | WriteThrough 6625ms: 64kb, Overlapped | Sequential Worse 5: 11687ms: 64kb, NoBuffering | Overlapped | Sequential | WriteThrough 9812ms: 256kb, WriteThrough 9625ms: 256kb, NoBuffering | WriteThrough 9079ms: 128kb, NoBuffering | Sequential | WriteThrough 8954ms: 64kb, NoBuffering | WriteThrough

Кстати сейчас самое время начать высказывать свои предположения и выводы насчёт оптимального размера буфера и набора опций.

я вот думаю надо принципиально разделять тесты по операционным системам. Условно говоря есть "старые винды" где работа с диском происходит старым образом, есть "новые винды", где всю свободную память занимает кеш файлов (кстати с какой версии? с семёрки или с висты?)

(hint: качать тесты http://zalil.ru/34271269)

read_test.exe
Windows 7, ST3250410AS ATA Device
Top 5: 843ms: 64kb, Sequential 843ms: 256kb, Sequential 844ms: 256kb, NoBuffering | Overlapped | Sequential 859ms: 64kb, Overlapped | Sequential 860ms: 128kb, NoBuffering | Overlapped | Sequential Worse 5: 1312ms: 64kb, NoBuffering 1047ms: 128kb, NoBuffering 1032ms: 64kb, NoBuffering | Sequential 1016ms: 128kb, NoBuffering | Sequential 1015ms: 256kb, NoBuffering

write_test.exe
Windows 7, ST3250410AS ATA Device

Top 5: 3906ms: 128kb, Overlapped | WriteThrough 4125ms: 64kb, Overlapped | WriteThrough 4187ms: 256kb, NoBuffering 4188ms: 256kb, NoBuffering | Overlapped | Sequential 4266ms: 256kb, NoBuffering | Overlapped Worse 5: 23344ms: 64kb, Overlapped | Sequential | WriteThrough 19172ms: 64kb, NoBuffering | WriteThrough 10515ms: 64kb, NoBuffering | Overlapped | Sequential | WriteThrough 10297ms: 64kb, NoBuffering | Sequential | WriteThrough 9484ms: 128kb, NoBuffering | WriteThrough

какие лично у меня выводы пока напрашиваются

пока я совершенно точно вижу, что в write_test в худших преобладает NoBuffering. В "новых виндах" вредность этого флага очевидна. Потому что там вообще редко на диск скидывается, в основном пишется в память. Но для "старых виндов" вредность этого флага не совсем понятна. По идее NoBuffering + Overlapped должно работать лучше буферизированных аналогов. Но тесты говорят об обратном. Может это связано с тем, что NoBuffering файлы после записи надо обрезать?

с удовольствием выслушаю ваши рассуждения

> [113] Inovet © (18.02.13 10:50)
> Сигейт 5900 2ТБ

Ближе к началу диска

read_test.exe

Windows 7, unknown drive model

Top 5:
951ms: 128kb, Default
951ms: 256kb, Default
952ms: 128kb, Overlapped | Sequential
952ms: 64kb, NoBuffering | Overlapped
952ms: 256kb, Sequential

Worse 5:
1046ms: 128kb, NoBuffering | Overlapped
1046ms: 256kb, NoBuffering | Overlapped
1030ms: 128kb, NoBuffering
1030ms: 256kb, NoBuffering | Sequential
1029ms: 128kb, NoBuffering | Sequential

write_test.exe

Windows 7, unknown drive model

Top 5:
2075ms: 128kb, Overlapped | Sequential | WriteThrough
2075ms: 256kb, Overlapped | Sequential | WriteThrough
2090ms: 128kb, Overlapped | WriteThrough
2168ms: 256kb, Overlapped | WriteThrough
2168ms: 64kb, Overlapped | WriteThrough

Worse 5:
4056ms: 64kb, NoBuffering | Sequential | WriteThrough
4040ms: 64kb, NoBuffering | Overlapped | WriteThrough
4040ms: 64kb, NoBuffering | WriteThrough
3993ms: 64kb, NoBuffering | Overlapped | Sequential | WriteThrough
3806ms: 64kb, NoBuffering

read_test.exe

Windows 7, unknown drive model Сигейт 7200 320ГБ системный в районе средины диска

Top 5:
1435ms: 128kb, NoBuffering | Overlapped
1435ms: 128kb, Overlapped | Sequential
1435ms: 256kb, NoBuffering | Overlapped
1435ms: 256kb, Sequential
1436ms: 64kb, Default

Worse 5:
2839ms: 64kb, NoBuffering
2028ms: 64kb, NoBuffering | Overlapped
1997ms: 256kb, NoBuffering | Sequential
1966ms: 64kb, NoBuffering | Sequential
1888ms: 128kb, Overlapped

write_test.exe

Windows 7, unknown drive model тот же

Top 5:
2965ms: 128kb, Overlapped | WriteThrough
3261ms: 256kb, Overlapped | WriteThrough
3370ms: 128kb, Overlapped | Sequential | WriteThrough
3510ms: 256kb, Sequential | WriteThrough
3744ms: 256kb, Overlapped | Sequential | WriteThrough

Worse 5:
8721ms: 64kb, NoBuffering
8284ms: 128kb, NoBuffering
7316ms: 64kb, Default
7129ms: 64kb, Overlapped
6630ms: 64kb, NoBuffering | Overlapped

Ребят, потестите пожалуйста Найти похожие ветки