Файловый кэш

[metaclass]

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

Comments

[ktn-zoidberg.livejournal.com]

у тебя рихтер есть? который про Win32? там кеширование зверски рассписано...

[metaclass.livejournal.com]

О таки это мысль, надо перечитать.

[a-konst.livejournal.com]

наверно потому что венда херово делает кэширование файлов :)

[slonopotamus.livejournal.com]

+1 :)

[a-konst.livejournal.com]

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

[1ceheart.livejournal.com]

Ну, проц точно так же закэшит и страничку в виндовом кэше, какая ему разница. Если кэша хватит, конечно :)

Re: Reply to your comment...

[a-konst.livejournal.com]

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

Re: Reply to your comment...

[1ceheart.livejournal.com]

Не, ничего подобного. Cache line в L1 - вообще 64 байта, а в L2 - что-то типа 128, от проца зависит, но тоже немного. Меньше страницы, в любом случае.

Доля истины есть в том, что если прога, грубо говоря, читает по байту, вызывая каждый раз ReadFile, то между двумя последовательными вызовами ReadFile произойдет очень много всего - context switch, всякое прочее, и вероятность того, что вследствие этого "всякого прочего" нужные данные из кэша будут вытеснены, больше, чем если прога просто тупо делает memcpy из своего внутреннего кэша.

Но в реальности, если мы говорим действительно о небольших кусках данных - типа байт 16 - то это все равно пренебрежимо мало по сравнению с объемом кода, который нужно выполнить, чтобы все-таки скопировать эти 16 байт. Поэтому скорость в итоге определяется той разницей, что проге в user space потребуется выполнить, ну, грубо, килобайт кода, чтобы добраться до этих данных, а ReadFile - ну, килобайт 20-30.

[1ceheart.livejournal.com]

Ну, тому есть тысяча причин, но основные две. Во-первых, накладные расходы при вызове ReadFile, даже если все - в кэше, они не просто большие, они титанические. Это ж надо создать IRP, потом его долго и мучительно обрабатывает FSD, потом это долго и мучительно передается по стеку, и только потом дело дойдет до кэша и начнет тем же путем передаваться обратно.

Вторая проблема в том, что кэш - штука негарантированная, и закэшенную страничку винды могут внезапно взять и порешить использовать под что-то более, с их точки зрения, важное. Если же выделить себе память в user space, ее никто никогда под что-нибудь другое не заюзает (ну, конечно, если не считать своп, но в современном мире можно считать, что его нет).

[jek-hor.livejournal.com]

А если сделать mmap?

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

В принципе superfetch в комбинации с ReadyBoost достаточно близок к этому. Хотя сомневаюсь что там дефрагментация гарантирована, скорее просто рассчёт на то что флеш диски малочувствительны к фрагментации.

> получается быстрее чем читать их же напрямую?

[poige.livejournal.com]

Чем больше системных вызовов / sec, тем ниже быстродействие, при прочих равных ус-х, ибо переключения контекстов дорогое удовольствие.