Ребят, прошу потестировать файловую систему

← →
DevilDevil © (2013-03-19 18:20) [0]

Продолжаю реализовывать оптимальный доступ к диску (для задач потокового чтения/записи)

В одной из предыдущих веток выяснилось, что я предусмотрел не самые оптимальные параметры
В связи с этим я модифицировал тест файловой системы: http://zalil.ru/34362059
Проблема в том, что теперь тестируемых комбинаций значительно больше (суммарно около 3000 итераций)

Напомню, в архиве есть тест на чтение "read_test.exe" и тест на запись "write_test.exe"
Каждый из которых пишет лог: "read_test.log" и "write_test.log" соответственно
В лог пишется операционная система, размер сектора/кластера, ход событий, а так же главное - "ТОП 20"

Да, результаты конечно скачат (это же многозадачная Windows)
Поэтому каждая из комбинаций размер буфера/опций повторяется по 4 раза
Чтобы в итоге посмотреть на ТОП и сделать выводы

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

Логи отсылайте мне на softforyou[ГАВ-ГАВ].inbox.ru
Или выкладывайте здесь
В любом случае интересует ОС, параметры винтчестера, ТОП 20 и конечно направление: read/write

Спасибо за участие!

← →
antonn © (2013-03-19 18:54) [1]

если запись будет с таким же кол-вом что и чтение, то запись (конкретно у меня) займет около 40-60 минут...

← →
Sapersky (2013-03-19 19:53) [2]

Честно говоря, жалко свой диск - он уже не молод, как бы не крякнулся от непрерывной 2-часовой нагрузки...
Да и не очень понятно, чего ты добиваешься. В предыдущих тестах чтения - там, где небольшая нагрузка на процессор - уже была скорость, близкая к максимально возможной (о чём я писал). Сейчас, как ни оптимизируй, дополнительно ты выжмешь максимум несколько процентов, и их ещё нужно увидеть за погрешностью измерений.

Вообще, дисковые операции - фигня. Программирование игроприставок - вот где настоящий рай для маньяка-оптимизатора!
http://ironpeter.livejournal.com/6471.html
Железо там потенциально очень мощное, но и очень капризное - вроде Пня-4, только ещё хуже. Требуется ювелирное выпиливание лобзиком - всё как ты любишь :)

Можно ещё податься в GPGPU, там схожие по сути проблемы. Даже более реальный вариант - заниматься на профессиональном уровне всё равно сразу не получится, а на любительском для GPGPU не нужно спец. железа и его можно применить для каких-то текущих задач на PC.

← →
DevilDevil © (2013-03-19 20:18) [3]

> antonn © (19.03.13 18:54) [1]

эт да

> Sapersky (19.03.13 19:53) [2]

всё-таки не всё предусмотрел
на другом форуме мерились письками - там у чувака был тест, который на одних машинах работал в два раза медленней моего, а ну других - в два раза быстрее

← →
Sapersky (2013-03-19 20:47) [4]

Условия точно равные - сброс кэшей, зависимость от CPU? У тебя в последнем тесте чтение в CPU упиралось, насколько помню.
Машина на кот. тормозит - не XP? В CachedBuffers для XP какие-то махинации с NO_BUFFERING...

← →
DevilDevil © (2013-03-19 21:08) [5]

да всё вроде по честному было

← →
antonn © (2013-03-19 22:09) [6]

← →
DevilDevil © (2013-03-19 22:33) [7]

> antonn © (19.03.13 22:09) [6]

спасиб!
а какая операционка ?

ты бы запустил перед сном "RUN_AND_SHUTDOWN.exe"
комп сам выключится когда всё отработает

← →
Rouse_ © (2013-03-19 22:35) [8]

← →
antonn © (2013-03-19 22:42) [9]

> а какая операционка ?
>
> ты бы запустил перед сном "RUN_AND_SHUTDOWN.exe"
> комп сам выключится когда всё отработает

win server 2008 r2, и поэтому особо ждать не мог - для работы была нужна :)
в ночь запускать не хочется, все равно там значения больше 3000ms на запись были, уменьшил бы кол-во проходов, в чтении на ~700 остановилось, а запись за 1000 уже зашла, я обрубил ее (по завершению мог бы тоже сделать сброс текущих результатов)

← →
DevilDevil © (2013-03-19 23:45) [10]

> Rouse_ © (19.03.13 22:35) [8]
> Я так понимаю это то о чем и шла речь у нас?

угу
опять 256кб :)

> ЗЫ пока не тестировал - завтра на рабочем вечером запущу
> без шатдауна (чейто сегодня не коннектится, упал тимвьюв
> видать)

отлично!

> запись за 1000 уже зашла, я обрубил ее (по завершению мог
> бы тоже сделать сброс текущих результатов)

мне кажется там до 3х тысяч должно дойти

← →
Sapersky (2013-03-20 03:47) [11]

← →
DevilDevil © (2013-03-20 09:46) [12]

← →
DevilDevil © (2013-03-20 09:51) [13]

КСТАТИ Я ПЕРЕКОМПИЛИЛ, КАЧАЙТЕ http://zalil.ru/34363890
чтобы выдача была по 50 позиций и ещё одна маленькая вещь

← →
brother © (2013-03-20 09:59) [14]

опять час ждать? ну, нафиг! делай время тестирования приемлимое!

← →
DevilDevil © (2013-03-20 10:30) [15]

> brother © (20.03.13 09:59) [14]

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

← →
DevilDevil © (2013-03-20 16:39) [16]

← →
Rouse_ © (2013-03-20 17:07) [17]

← →
DevilDevil © (2013-03-20 17:10) [18]

← →
DevilDevil © (2013-03-20 17:13) [19]

> Rouse_ © (20.03.13 17:07) [17]

выводите пожалуйста информацию об ОС и диске

> Хм, плывет:

ну так это же операционная система Windows с многопоточностью )
поэтому и сделано сразу 4 раза
чтобы лучше видеть общую картину

> если не просадка на третьей итерации 256 Default лидировал бы.

а здесь вообще не средний показатель берётся
в "рейтинге" участвуют все позиции

← →
DevilDevil © (2013-03-20 18:03) [20]

[b]качать здесь[/b]: http://zalil.ru/34365391
должно работать быстрее раз в 6

← →
Inovet © (2013-03-20 19:23) [21]

> [17] Rouse_ © (20.03.13 17:07)
> Хм, плывет:

Да это вообще неправильная постановка эксперимента. Я уже в прошлых ветках размышлял на этут тему, но автор сказал, что ему пофиг, что я там говорю.

← →
DevilDevil © (2013-03-20 20:10) [22]

почему пофиг ?

очевидно размер буфера и опции влияют на производительность взаимодействия с диском
каким ещё образом выявить закономерности ?

ради бога - готов выслушать

← →
Inovet © (2013-03-20 20:43) [23]

> [22] DevilDevil © (20.03.13 20:10)

Надо постараться свести к минимуму влияющие на измерение, но не относящиеся у цели эксперимента факторы. Как то, влияние других процессов и самой ОС, заполненость диска. Второе можно легко сделать с первым сложнее, и полностью исключить вряд ли можно, но вот снизить до приемлемой погрешности, наверное, возможно, скажем в безопасном режиме или лучше в спец конфигурации. Но кто же массово станет это делать.

Во всяуом случае нужна методика оценки погрешности влияния потусторонних сил. Хотябы вывести отклонение из имеющейся статистики для конкретного компьютера и винчестера. А вот потом уже сделать выводы о влиянии размера буфера и флагов. А то как окажется, что они утонут в отклонении.

← →
brother © (2013-03-20 20:48) [24]

кстати, дефрагментированность ФС учитывается? иначе согласен с [23]!

← →
Rouse_ © (2013-03-20 20:49) [25]

Кстати верное замечание - попробуй SetThreadPriority + THREAD_PRIORITY_TIME_CRITICAL
Далее нужно не забывать что хардешники бывают разные, не зря для их тестирования пишут программы наподобие этой: http://sourceforge.jp/projects/crystaldiskmark/downloads/46482/CrystalDiskMark3_0_2dSrc.zip/

Попробуй сначала замерить реальную производительность диска, таким образом получив некий коэффициэнт, который можно уже будет применить к выдаваемым тобой результатам.

← →
Rouse_ © (2013-03-20 20:49) [26]

> brother © (20.03.13 20:48) [24]
> кстати, дефрагментированность ФС учитывается? иначе согласен
> с [23]!

Если ипользуется семерка, этот момент можно не учитывать, она в фоне дефраг делает и поэтому практически 90 процентов времени диск в нормальном состоянии.

← →
Дмитрий С © (2013-03-20 20:52) [27]

Я надеюсь она SSD не дефрагментирует.

← →
Inovet © (2013-03-20 20:53) [28]

> [26] Rouse_ © (20.03.13 20:49)
> она в фоне дефраг делает

Вот как раз хотел сказать и об этом. Мы же не знаем как фаза Луны влияет на измерения, может ОС в во время измерений захотела вдруг дефрагментацию устрить.

← →
Rouse_ © (2013-03-20 20:54) [29]

>
> Дмитрий С © (20.03.13 20:52) [27]
> Я надеюсь она SSD не дефрагментирует.

Зависит от настроек: http://support.microsoft.com/kb/2727880

← →
brother © (2013-03-20 21:01) [30]

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

← →
brother © (2013-03-20 21:03) [31]

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

← →
Inovet © (2013-03-20 21:06) [32]

> [30] brother © (20.03.13 21:01)
> нужны лабораторные условия, похожие у всех пациентов

Это называется повторяемость. Сейчас её нет. Даже в процессе одного теста разброс вон какой. А результат должен повторяться в пределах известной погрешности, о вычислении которой автор вообще не подумал. Раз не повторяется, значит методологическая ошибка сидит в самой постановке.

← →
Rouse_ © (2013-03-20 21:06) [33]

> brother © (20.03.13 21:01) [30]
> ну, например, у автора XP ... это я так...
> зы. для начала тестирования и сбора информации нужны лабораторные
> условия, похожие у всех пациентов, либо, некий коэффициент,
> уравновешивающий пациентов.

Ну так я об чем и говорю.
Впрочем опять же повторюсь на моих тестах (расчет CRC32 папки с файлами) 256 Кб дал наиболее производительный результат. Использовался обычный TFileStream

← →
Inovet © (2013-03-20 21:10) [34]

> [31] brother © (20.03.13 21:03)
> имхо, замерять скорости работы винта под виндой и при этом
> требовать наиболее точных результатов - в корне не верно!

Вот и я в прошлой ветке шутил, что надо без Винды мерять. Кстати, может, теоретически и возможно кусок ядра выдрать и на нём запускать этот тест.

← →
brother © (2013-03-20 21:15) [35]

> кусок ядра

да даже дело не в этом, а в занятости самого винта! нужно наиболее гарантировать что головки работают над нашей областью тестовых данных и не занимаются другими делами)

← →
brother © (2013-03-20 21:16) [36]

> 256 Кб дал наиболее производительный результат

мы говорим о среднем значении для всех пациентов (с небольшими отклонениями) и не выжимаем последние капли производительности!

← →
brother © (2013-03-20 21:18) [37]

автору: не обижайся, но мое имхо - ты страдаешь фигней, ибо ... ну понятно?

← →
brother © (2013-03-20 21:19) [38]

либо гарантируй реализацию условий в [30]

← →
Inovet © (2013-03-20 21:20) [39]

Ещё вот что интересно. Будет ли Виндоус писать физически в одно и то же место диска НТФС новый экземпляр файла на н+1 прогоне, после удаления предыдущего файла н-ного прогона, при условии, естественно, что туда никто не написал уже. Это должно быть документировано по идее.

← →
brother © (2013-03-20 21:23) [40]

> Будет ли Виндоус писать физически в одно и то же место диска
> НТФС

вопрос не к винде, а именно к ФС! и далеко не факт, что будет.

← →
brother © (2013-03-20 21:24) [41]

либо тестировать без ФАТ, резервируюя для себя некую физическую область винта. но это отдельная песня

← →
Inovet © (2013-03-20 21:46) [42]

> [41] brother © (20.03.13 21:24)
> либо тестировать без ФАТ

ДОС вот на диске ФАТ смотрела и тупо писала последовательно в свободные кластеры, про ФАТ в Виндоус фиг знает. Про НТФС даже предполагать не могу, ибо пальцем в небо, тут читать документацию на ФС надо.

← →
DevilDevil © (2013-03-21 10:38) [43]

Ого вы понаписали !
Спасибо за внимание к вопросу

В целом - я и так уже мучаюсь с тестами не первую неделю
Если действительно есть желание докапываться до истины - ради бога меняйте исходники (или пишите свои) - они в всегда в архиве

← →
DevilDevil © (2013-03-21 10:40) [44]

← →
DevilDevil © (2013-03-21 10:42) [45]

Windows XP, SectorSize: 512, ClasterSize: 4kb

read_test.exe

Top 19:
843ms: 64kb, NoBuffering | Overlapped
843ms: 128kb, NoBuffering | Overlapped | Sequential
843ms: 64kb, NoBuffering | Overlapped
844ms: 32kb, Overlapped
844ms: 64kb, Default
844ms: 4kb, Overlapped
844ms: 128kb, Default
844ms: 4kb, Sequential
844ms: 256kb, Overlapped
844ms: 4kb, Default
844ms: 16kb, Overlapped | Sequential
844ms: 16kb, Overlapped | Sequential
844ms: 16kb, Sequential
844ms: 16kb, Overlapped | Sequential
844ms: 128kb, Overlapped
844ms: 16kb, Sequential
844ms: 16kb, Overlapped | Sequential
844ms: 128kb, Overlapped
859ms: 128kb, NoBuffering | Overlapped | Sequential

write_test.exe
Top 38:
2281ms: 256kb, Overlapped | Sequential | WriteThrough
2312ms: 256kb, Overlapped | Sequential | WriteThrough
2344ms: 128kb, Overlapped | Sequential | WriteThrough
2359ms: 256kb, Default
2360ms: 128kb, Overlapped | Sequential | WriteThrough
2360ms: 256kb, Sequential
2375ms: 128kb, Sequential
2375ms: 128kb, Default
2390ms: 128kb, Overlapped | WriteThrough
2390ms: 128kb, Default
2390ms: 256kb, Overlapped | WriteThrough
2390ms: 128kb, Overlapped | WriteThrough
2390ms: 64kb, Sequential
2391ms: 128kb, Default
2391ms: 256kb, Sequential
2391ms: 128kb, Overlapped | Sequential | WriteThrough
2406ms: 128kb, Overlapped | WriteThrough
2406ms: 128kb, Default
2406ms: 256kb, Default
2406ms: 256kb, Sequential
2406ms: 256kb, Default
2422ms: 128kb, Sequential
2422ms: 256kb, Sequential
2437ms: 128kb, Sequential
2438ms: 256kb, Default
2453ms: 256kb, Overlapped | WriteThrough
2453ms: 64kb, Overlapped | WriteThrough
2469ms: 128kb, Sequential
2484ms: 64kb, Overlapped | WriteThrough
2484ms: 64kb, Default
2485ms: 64kb, Sequential
2500ms: 64kb, Sequential
2515ms: 64kb, Default
2531ms: 64kb, Sequential
2532ms: 64kb, Overlapped | Sequential | WriteThrough
2578ms: 256kb, Overlapped | WriteThrough
2578ms: 64kb, Default
2593ms: 128kb, Overlapped | Sequential | WriteThrough

← →
DevilDevil © (2013-03-21 10:43) [46]

Windows XP, SectorSize: 512, ClasterSize: 4kb

read_test.exe
Top 19:
1406ms: 16kb, Overlapped
1406ms: 4kb, Overlapped
1406ms: 32kb, Overlapped | Sequential
1406ms: 64kb, Sequential
1406ms: 64kb, NoBuffering | Overlapped | Sequential
1406ms: 128kb, Sequential
1406ms: 256kb, Default
1406ms: 256kb, Sequential
1406ms: 4kb, Overlapped
1406ms: 16kb, Default
1406ms: 32kb, Sequential
1406ms: 64kb, Sequential
1406ms: 128kb, Overlapped
1406ms: 128kb, Overlapped | Sequential
1406ms: 128kb, NoBuffering | Overlapped | Sequential
1406ms: 4kb, Overlapped
1406ms: 4kb, Sequential
1406ms: 16kb, Default
1406ms: 16kb, Overlapped

write_test.exe
Top 38:
4015ms: 256kb, Overlapped | WriteThrough
4016ms: 256kb, Overlapped | Sequential | WriteThrough
4016ms: 256kb, Overlapped | WriteThrough
4046ms: 256kb, Overlapped | Sequential | WriteThrough
4047ms: 256kb, Overlapped | WriteThrough
4047ms: 256kb, Overlapped | WriteThrough
4187ms: 256kb, Overlapped | Sequential | WriteThrough
4203ms: 128kb, Overlapped | WriteThrough
4250ms: 128kb, Overlapped | WriteThrough
4266ms: 256kb, Sequential
4281ms: 256kb, Sequential
4282ms: 256kb, Sequential
4297ms: 256kb, Sequential
4297ms: 128kb, Overlapped | Sequential | WriteThrough
4297ms: 256kb, Default
4328ms: 128kb, Sequential
4359ms: 256kb, Default
4360ms: 128kb, Overlapped | Sequential | WriteThrough
4390ms: 128kb, Overlapped | WriteThrough
4390ms: 128kb, Sequential
4422ms: 64kb, Default
4438ms: 256kb, Default
4438ms: 128kb, Sequential
4438ms: 128kb, Default
4438ms: 128kb, Overlapped | Sequential | WriteThrough
4453ms: 64kb, Sequential
4454ms: 128kb, Default
4468ms: 64kb, Sequential
4469ms: 256kb, Default
4500ms: 64kb, Sequential
4515ms: 64kb, Default
4547ms: 256kb, NoBuffering | Overlapped | Sequential
4547ms: 64kb, Sequential
4562ms: 256kb, NoBuffering
4562ms: 256kb, NoBuffering
4562ms: 256kb, NoBuffering | Sequential
4562ms: 256kb, NoBuffering | Overlapped | Sequential
4562ms: 256kb, NoBuffering | Sequential

← →
DevilDevil © (2013-03-21 10:45) [47]

← →
Inovet © (2013-03-21 10:46) [48]

> [43] DevilDevil © (21.03.13 10:38)
> Если действительно есть желание докапываться до истины

А у тебя нет что ли такого желания?

← →
DevilDevil © (2013-03-21 10:57) [49]

Windows 7, SectorSize: 512, ClasterSize: 4kb

read_test.exe
Top 19:
1170ms: 16kb, Default
1170ms: 32kb, Default
1170ms: 32kb, NoBuffering | Overlapped
1170ms: 64kb, Default
1170ms: 64kb, NoBuffering | Overlapped
1170ms: 128kb, Default
1170ms: 128kb, NoBuffering | Overlapped
1170ms: 128kb, NoBuffering | Sequential
1170ms: 4kb, Default
1170ms: 4kb, Sequential
1170ms: 4kb, Overlapped | Sequential
1170ms: 16kb, Overlapped | Sequential
1170ms: 32kb, NoBuffering | Overlapped
1170ms: 32kb, Overlapped | Sequential
1170ms: 64kb, NoBuffering | Overlapped
1170ms: 128kb, NoBuffering
1170ms: 128kb, NoBuffering | Overlapped
1170ms: 256kb, Default
1170ms: 256kb, NoBuffering | Overlapped

write_test.exe
Top 38:
1575ms: 256kb, WriteThrough
1607ms: 256kb, Overlapped | Sequential | WriteThrough
1701ms: 128kb, WriteThrough
1716ms: 256kb, NoBuffering | Overlapped | Sequential | WriteThrough
1747ms: 256kb, NoBuffering | Overlapped | Sequential | WriteThrough
1763ms: 256kb, Sequential | WriteThrough
1794ms: 128kb, WriteThrough
1809ms: 256kb, NoBuffering | Sequential | WriteThrough
1810ms: 256kb, NoBuffering | Overlapped | WriteThrough
1825ms: 256kb, Overlapped | Sequential | WriteThrough
1840ms: 256kb, Overlapped | WriteThrough
1841ms: 256kb, Sequential | WriteThrough
1841ms: 128kb, Overlapped | Sequential
1841ms: 256kb, NoBuffering | WriteThrough
1856ms: 128kb, Overlapped | WriteThrough
1857ms: 256kb, Sequential
1872ms: 256kb, Overlapped
1872ms: 256kb, Default
1872ms: 256kb, Overlapped | Sequential
1872ms: 256kb, Overlapped | WriteThrough
1887ms: 256kb, Overlapped | WriteThrough
1887ms: 256kb, Overlapped | Sequential
1887ms: 256kb, Default
1888ms: 256kb, Overlapped
1903ms: 256kb, Sequential
1903ms: 256kb, Default
1903ms: 256kb, Overlapped | Sequential
1918ms: 128kb, NoBuffering | WriteThrough
1919ms: 256kb, Sequential | WriteThrough
1934ms: 128kb, WriteThrough
1935ms: 128kb, Sequential | WriteThrough
1950ms: 256kb, NoBuffering | Sequential | WriteThrough
1950ms: 256kb, WriteThrough
1965ms: 256kb, Overlapped | WriteThrough
1966ms: 256kb, WriteThrough
1981ms: 128kb, NoBuffering | Sequential | WriteThrough
1981ms: 256kb, NoBuffering | Overlapped | WriteThrough
1996ms: 128kb, NoBuffering | Overlapped | WriteThrough

← →
DevilDevil © (2013-03-21 10:57) [50]

> Inovet © (21.03.13 10:46) [48]
> > [43] DevilDevil © (21.03.13 10:38)
> > Если действительно есть желание докапываться до истины
>
> А у тебя нет что ли такого желания?

у меня нет сил

> у меня нет сил

тогда зачем начинал это все???

Удалено модератором
Примечание: не в пивной...

> brother © (21.03.13 17:25) [54]

а тебе не видно эффективности одних наборов параметров и неэффективности других ?
раз так эдак в 5

долго мусолишь одно и то-же

как видишь оно того стоит
только мои ресурсы ограничены

Дим я тоже думаю, что в данном случае ты не верно делаешь - тесты плывут сильно. С этими данными нельзя работать даже на этапе предварительного анализа к сожалению...

> Rouse_ © (21.03.13 20:39) [58]

дак блин
ну давайте объединим свои усилия
сообществом разработчиков решим этот вопрос

я свой вклад внёс как смог
я ж не резиновый )

Цель задачи не понятная. Сделать максимально быстрое чтение запись?
Я не уверен что стоит оптимизировать файловые операции, это всегда было узким местом. Да уж если и хочешь оптимизировать, то тогда через свой драйвер, убирая внешние воздействия как делает тот же MS SQL

> Rouse_ © (21.03.13 21:37) [60]

идея конечно здравая
но я не обладаю информацией

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

размер буфера: 256кб
чтение Overlapped | Sequential | (если ОС < Win7)NoBuffering
запись Overlapped | Sequential | WriteThrough

> и пока не могу понять, почему ранее выбранные мной опции
> не являются максимально эффективными

Сколько миллисекунд ты хочешь выиграть на объеме от 100 Мб?
Что они тебе дадут? Пока у тебя плавает в маленьком диапазоне - что вообще монопенисюально для обычной прикладной программы, которые по сути своей крайне редко работают с таким объемом данных, на которых ты тестируешь.

> Rouse_ © (21.03.13 22:30) [62]

тут не вопрос "сколько выиграть"
тут вопрос "как вообще надо" выставлять опции и размер буфера в таких ситуациях

да и потом, как ты видел - разница бывает в разы
не просто в разы, а в разы медленнее априори очень медленных операций

← →
Sapersky (2013-03-21 23:30) [66]

Выкинуть No_Buffering без overlapped, которое всё равно в жизни никто не использует.
Тогда разница в разы уйдёт, останется разница на уровне погрешности измерений, и тест окончательно потеряет смысл :)

> DevilDevil © (21.03.13 23:15) [65]

Ну если честно - все :)
1. Тестирование нагрузки на железо через апи третьего кольца выдаст погрешность.
2. Зачем тестировать, где использовать результат?
3. Каких скоростей ты хочешь достигнуть? Сам понимаешь, проще в некоторых случаях сменить железо чем переписать программу.
4. Используемые тобой режимы не используют 99 процентов программистов, им достаточно классики. Я не думаю что до тебя не было сделавано исследование что мол ОПА - вот с таким флагом будет читаться сверхбыстро. Сколько лет уж прошло...

> Sapersky (21.03.13 23:30) [66]
> Выкинуть No_Buffering без overlapped, которое всё равно
> в жизни никто не использует.
> Тогда разница в разы уйдёт, останется разница на уровне
> погрешности измерений, и тест окончательно потеряет смысл
> :)

ну то есть ты хочешь сказать, что от Sequential и WriteThrough нет толка ?

> Rouse_ © (21.03.13 23:32) [67]

сейчас я отрою свою цитату из старой ветки :)

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

> [69] DevilDevil © (22.03.13 12:30)

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

Что получается? Не делать же замер перед каждым использованием приложения с этой библиотекой. Получается, надо взять некие параметры, дающие наилучшие результаты на большинстве систем. Но и это при условии достоверности измерений, о чём выше говорилось уже.

← →
Sapersky (2013-03-22 19:37) [71]

ну то есть ты хочешь сказать, что от Sequential и WriteThrough нет толка ?

От Sequential - возможно, есть эффект, но его сложно заметить, в топах всё перемешано. Ты бы хоть автоматически подсчитывал, сколько (например) в топе с Sequential, сколько без.
В любом случае, какого-то значительного отрыва от Default не видно. Почему - уже была ссылка:
http://blogs.msdn.com/b/oldnewthing/archive/2012/01/20/10258690.aspx
(менеджер кэша может автоматически переключаться в Sequential-режим)
Соображения в пользу Sequential больше теоретические - "в любом случае не повредит", как я здесь писал:
http://delphimaster.net/view/15-1360736756/
Но для таких соображений тест не нужен, достаточно документации.

Про запись - опять же см. старую ветку, [139] + [142].

> тут вопрос "как вообще надо" выставлять опции и размер буфера
> в таких ситуациях

еще раз: тк. не сделано одной опции и буфера, значит, зависит от железа и подгонятся под конкретну машину... золотой середины нет...

Ребят, прошу потестировать файловую систему Найти похожие ветки