MapViewOfFile() ускоряет загрузку файлов?

← →
K-1000 © (2015-11-25 21:53) [0]

Есть статья: http://www.gamedev.ru/code/tip/?id=3842
Так ли это? Комментарии не единогласны.

← →
Dimka Maslov © (2015-11-25 22:23) [1]

Да, и причём в разы. Недавно грузил большой объём данных (текстовые данные переводил в двоичные). При стандартных функциях чтения 45 гигабайт текста перерабатывались в 700 мегабайт двоичных данных за ночь, после замены только механизма чтения на mapped files, та же обработка стала происходить менее чем за час.

← →
Игорь Шевченко © (2015-11-25 22:24) [2]

Нет, не ускоряет. Отображение файлов в память встроено в чтение/запись на самом низком уровне, лишний вызов ничего не ускорит.

← →
K-1000 © (2015-11-25 22:27) [3]

О, и здесь комментарии не единогласны. :)

← →
Игорь Шевченко © (2015-11-25 22:39) [4]

K-1000 © (25.11.15 22:27) [3]

У тебя вопрос содержит несколько вариантов ответа, что же тут удивительного. Что такое "загрузка файлов", в первую очередь, относительно чего меряется возможное ускорение, и т.д.

← →
K-1000 © (2015-11-25 22:48) [5]

> Игорь Шевченко © (25.11.15 22:39) [4]

Ок. Допустим есть бинарный файл весом в 1 Гб. (Данные для комп. игры)
Нужно его целиком загрузить в программу как можно скорее ведь игроки не любят лишний раз ждать.

← →
Игорь Шевченко © (2015-11-25 22:56) [6]

K-1000 © (25.11.15 22:48) [5]

Дозволяю, загружай. Да пребудет с тобой сила.

http://segfault.kiev.ua/smart-questions-ru.html

← →
K-1000 © (2015-11-25 22:59) [7]

> Игорь Шевченко © (25.11.15 22:56) [6]
>
> K-1000 © (25.11.15 22:48) [5]
>
> Дозволяю, загружай. Да пребудет с тобой сила.

А как же слово "допустим"?

Суть вопроса не меняется, ваш ответ номер 2 противоположен ответу номер под номером 1.

← →
Dimka Maslov © (2015-11-25 23:04) [8]

> Суть вопроса не меняется, ваш ответ номер 2 противоположен
> ответу номер под номером 1.

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

← →
Игорь Шевченко © (2015-11-25 23:09) [9]

K-1000 © (25.11.15 22:59) [7]

Ты ссылку почитай пожалуйста. Вот эта фраза: "Допустим есть бинарный файл весом в 1 Гб. (Данные для комп. игры)
Нужно его целиком загрузить в программу как можно скорее ведь игроки не любят лишний раз ждать.
"
не говорит ровным счетом ничего о механизме загрузки, который надо ускорять. Ни как читается файл (неважно, бинарный, тернарный или еще какой), ни объем данных, нужный единомоментно, ничего. И на основании этого говорит об ускорении просто бессмысленно.
Данные с диска (с моего в данном случае) читаются в среднем со скоростью 140 мб/с, следовательно, быстрее, чем за 7 секунд весь гигабайт никак не прочитать.

← →
Игорь Шевченко © (2015-11-25 23:12) [10]

Dimka Maslov © (25.11.15 23:04) [8]

Зачем ты человеку голову морочишь :) Данные читаются постранично, в любом случае, размер страницы 4 кб, количество страниц за одно чтение определяется политиками диспетчера памяти :)

← →
K-1000 © (2015-11-25 23:15) [11]

> Dimka Maslov © (25.11.15 23:04) [8]

Так "в разы" или "ничего не ускоряет"? ;)

← →
K-1000 © (2015-11-25 23:24) [12]

> Игорь Шевченко © (25.11.15 23:09) [9]
>не говорит ровным счетом ничего о механизме загрузки, который надо ускорять. >Ни как читается файл (неважно, бинарный, тернарный или еще какой), ни объем >данных, нужный единомоментно, ничего. И на основании этого говорит об >ускорении просто бессмысленно.
>Данные с диска (с моего в данном случае) читаются в среднем со скоростью 140 мб/с, следовательно, быстрее, чем за 7 секунд весь гигабайт никак не прочитать.

Ок.
Тогда ответь пожалуйста максимально расширенно, когда ускоряет, когда не ускоряет и т.д.

← →
Юрий Зотов © (2015-11-25 23:50) [13]

> K-1000 © (25.11.15 22:48) [5]
> есть ... файл весом в 1 Гб. Нужно его целиком загрузить

Не получится. Сами посудите - нижние 64 Кб и верхние 2 Гб система (32-х битная) резервирует. Если она загрузит еще и 1 Гб Ваших данных, то что останется приложению из общего объема 4 Гб? Менее 1 Гб. Система не настолько глупа, чтобы так разбазаривать память.

Если верить Джеффри Рихтеру и Игорю Шевченко, то файлы объемом более одной страницы (4 Кб) система не загружает в прямом смысле этого слова. Вместо этого она проецирует файл на адресное пространство процесса, а загружает его постранично, по мере надобности (естественно, через кэш). То есть File Mapping уже используется и еще один (Ваш) скорее всего, только навредит.

← →
sniknik © (2015-11-26 00:21) [14]

> Нужно его целиком загрузить в программу
странная постановка фразы/"задачи"... в программе файлов нет.
чем-то напомнило "классическое" "как загрузить программу в трей". :)

← →
Германн © (2015-11-26 01:29) [15]

> Ок.
> Тогда ответь пожалуйста максимально расширенно, когда ускоряет,
> когда не ускоряет и т.д.

А учебники почитать и самому разобраться - влом?
P.S.
В который раз на форумах отвечаю что волшебных палочек не существует! Разве только в сказках.

← →
DayGaykin © (2015-11-26 01:35) [16]

Кстати, а как выделить реально оперативной памяти? Или как сделать, чтобы динамический массив располагался в памяти и не сбрасывался в подкачку?

И ещё вопрос: в какой момент система загружает данные из файла подкачки? В момент команды mov [...], ...?

← →
Dimka Maslov © (2015-11-26 08:38) [17]

> Так "в разы" или "ничего не ускоряет"? ;)

Ускоряется не чтение, а обработка.

>DayGaykin

Рекомендую почитать классиков - Рихтера.

K-1000 © (25.11.15 23:24) [12]

> Тогда ответь пожалуйста максимально расширенно, когда ускоряет,
> когда не ускоряет и т.д.

Это платная услуга

>в какой момент система загружает данные из файла подкачки?
По потребности системы. Не угадаешь.

> K-1000 © (25.11.15 22:48) [5]
>
> > Игорь Шевченко © (25.11.15 22:39) [4]
>
>
> Ок. Допустим есть бинарный файл весом в 1 Гб. (Данные для
> комп. игры)
> Нужно его целиком загрузить в программу как можно скорее
> ведь игроки не любят лишний раз ждать.

Он точно весь сразу же весь нужен? Грузи частями причем первая часть должна дать визуализацию сразу, типа загружено можно играть, пока игрок чешет репу и думает - в фоне грузится остальное. Это как бы уже стандарт.

MMF упрощают лишь обработку больших файлов. Ускорение при их использовании будет лишь по сравнению со совсем убогим кодом (без кэширования и т.д.).

Помню Rouse_ писал, что чтение по 256 Кб оптимально по скорости. Теперь, если где-то что-то большое нужно прочитать и обработать, использую для чтения буфер такого размера.

Если нужен постоянный() доступ к произвольному месту всего содержимого файла - то FileMapping однозначно дает выигрыш - особенно в случае нехватки физической памяти.
Т.к.
- если выделить память - и загрузить содержиме из файла
1. все страницы будут захвачены по Page Fault при копировании из буфера ввода/вывода.
2. при вытеснении страницы - её содержимое как минимум один раз будет записано в системный файл подкачки...

- если отмапировань файл:
1. загрузка страницы происходит только при обращении к соответствующей ячейке памяти в первый раз(тот же Page Fault).
2. выгрузка страниц при вытеснении(а там еще вялотекущая очередь выгрузки есть) - если содержимое страницы не изменялось - не происходит, т.к. оно уже на диске...
3. запись на диск - помимо механизма подкачки(п.2.) - происходит только при закрытии с диском происходит только после того как все процессы сделают UnmapViewOfFile или явного FlushViewOfFile.
4. И таки да - все процессы - мапируют в одну и ту же разделяемую физическую память...
(см. UnmapViewOfFile function - Remarks)
- нюанс с FILE_MAP_COPY - после операции записи на каждую страницу - все выродится в вариант с чтением в выделяемую память...
... When a process writes to a copy-on-write page, the system copies the original page to a new page that is private to the process. The new page is backed by the paging file. The protection of the new page changes from copy-on-write to read/write.
...

> чтение по 256 Кб оптимально по скорости

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

ИМХО: увеличение размера буфера - даст выигрыш при наличии NCQ(и тому подобного) и чуток уменьшит штраф на прыжки между кольцами защиты...
У меня оптимально 64К выходило(и насколько помню - это минимальный размер аппартного буфера SCSI) - дальше в пределах погрешности...

> DayGaykin © (26.11.15 12:26) [22]
> Помню Rouse_ писал, что чтение по 256 Кб оптимально по скорости.

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

MapViewOfFile() ускоряет загрузку файлов? Найти похожие ветки