Проецируемые на память файлы , быстродействие и т.д.

Цитата Ace @ 27.06.06, 08:23

32 разрядность архитектуры тут не причем...

Как раз-таки причем. Адресное пространство 32-х разрядной машины как раз есть 4Gb.
Но, если я не ошибаюсь, есть способы работы с большими файлами (мапить куски файла, а не целиком), но это уже неудобно.

Сообщение отредактировано: mo3r - 27.06.06, 08:36

Цитата Ace @ 27.06.06, 08:23

32 разрядность архитектуры тут не причем...

Как раз очень даже причем: как ты будешь адресовать более 4Gb в одном сегменте?

Цитата Ace @ 27.06.06, 08:23

Изв. но почему-то не напоролся

Возьми образ DVD-5 и попробуй его замапить от первого до последнего байта.
Hint: sizeof(SIZE_T) чему равно на 32-битной платформе, а?

Добавлено 27.06.06, 08:44

Цитата mo3r @ 27.06.06, 08:35

Как раз-таки причем. Адресное пространство 32-х разрядной машины как раз есть 4Gb.

Э, нет. Виртуальное адресное пространство i386 составляет 64Tb! Но реально он мог адресовать лишь 4Gb физической памяти.
С появлением возможности PAE (Page Address Extension) база адреса стала 36-битной и таким образом современные 32-битные процы могут адресовать 2^36 = 4Gb * 16 = 64Gb физической оперативки.

Цитата mo3r @ 27.06.06, 08:35

Но, если я не ошибаюсь, есть способы работы с большими файлами (мапить куски файла, а не целиком), но это уже неудобно.

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

Сообщение отредактировано: linuxfan - 27.06.06, 08:46

linuxfan
1. Сам сказал что есть PAE, и windows ее поддерживает.
2. мапить файл кусками ... если тебе не удобно то извини. по мне так очень и очень удобно. а если набросать проооостенький классец raper для проекции файла, то можно вообще инкапсулировать это дело.... проблем нет никаких, в общем..

Цитата LuckLess @ 27.06.06, 08:47

1. Сам сказал что есть PAE, и windows ее поддерживает.

PAE к mmap никаким боком не относится.

Цитата LuckLess @ 27.06.06, 08:47

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

Зависит от того, что тебе требуется: если задача сводится к последовательной обработке всего файла от первого до последнего байта, буферизованное чтение будет намного удобнее.
Если нужен рандомный доступ, то написанный руками класс, предоставляющий функции mmap'а с помощью блочного чтения может быть эффективнее, чем mmap, т. к. будет экономиться время на генерацию исключения для отсутствущей в памяти страницы. Только такой подход выглядит не столь прозрачно и отдельные фрагменты уже существующего кода скорее всего придетстя переделывать под работу с этим классом.
mmap -- это же фактически чтение блоками по 4096 байт -- не самый оптимальный вариант, но экономит кучу времени и нервов на относительно небольших (<2Gb) файлах.

Цитата linuxfan @ 27.06.06, 08:57

PAE к mmap никаким боком не относится.

Как так не относится? Больше места - больший файл смогу замапить.

Цитата linuxfan @ 27.06.06, 08:57

Если нужен рандомный доступ, то написанный руками класс, предоставляющий функции mmap'а с помощью блочного чтения может быть эффективнее, чем mmap, т. к. будет экономиться время на генерацию исключения для отсутствущей в памяти страницы.

Ох хоспади. 1-о сключение никак на производительности не скажется.
Обычное чтение может быть выгоднее только в варианте Overlapped IO когда кроме работы с файлом есть еще чем заняться.

Цитата LuckLess @ 27.06.06, 09:01

Как так не относится? Больше места - больший файл смогу замапить.

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

Цитата LuckLess @ 27.06.06, 09:01

Ох хоспади. 1-о сключение никак на производительности не скажется.

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

Добавлено 27.06.06, 09:15
Вообще забавно дискутировать о hardware с C++-никами, для которых слово "исключение" -- это throw/try/catch.
Интересно, а кто из присутствующих может обосновать необходимость буферизованного чтения (fread, ifstream)? Современные ОС все равно выполняют read-ahead, т. е. из без этого буферизуют.

Цитата linuxfan @ 27.06.06, 09:12

Интересно, а кто из присутствующих может обосновать необходимость буферизованного чтения (fread, ifstream)? Современные ОС все равно выполняют read-ahead, т. е. из без этого буферизуют.

Меньшим количеством переходов в режим ядра.

Hryak, тогда подтверди неверующему LuckLess'у, что для последовательной обработки файла последовательное чтение большими блоками будет быстрее, чем mmap.

Цитата linuxfan @ 27.06.06, 09:41

Hryak, тогда подтверди неверующему LuckLess'у, что для последовательной обработки файла последовательное чтение большими блоками будет быстрее, чем mmap.

А чего-то я не вижу места, где он утверждал обратное.

название темы "как быстрее" + первый пост с последовательным вычитыванием +

Цитата LuckLess @ 27.06.06, 08:47

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

Звучит так, будто мапить по кускам быстрее.
И по-любому, при чем тут PAE?

Цитата LuckLess @ 27.06.06, 08:47

1. Сам сказал что есть PAE, и windows ее поддерживает.

Цитата linuxfan @ 27.06.06, 09:41

...что для последовательной обработки файла последовательное чтение большими блоками будет быстрее...

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

Цитата Ace @ 27.06.06, 09:55

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

Свопятся страницы, которые давно никем не использовались.

Цитата Ace @ 27.06.06, 09:55

Слишком зависит от текущих условий работы системы

Только от состояния дискового кэша.

Цитата linuxfan @ 27.06.06, 10:06

Свопятся страницы, которые давно никем не использовались.

Очень внимательно перечитай последнее предложение в моём посте. А то такие перлы выдаёшь...

Цитата Ace @ 27.06.06, 10:13

Очень внимательно перечитай последнее предложение в моём посте. А то такие перлы выдаёшь...

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

а) последовательное чтение read'ом:
1. выделяем блок памяти под буфер (например, 1 метр)
2. читаем кусок файла в буфер
3. обрабатываем
4. если не eof, goto 2
В итоге имеем обращения к ядру только для чтения и относительно небольшой буфер фиксированного размера

б) последовательное чтение mmap:
1. отображаем файл в память
2. при чтении следующего фрагмента возникает исключение, ОС реально выдеояет память и читает туда кусок файла; при это надо не забыть поправить область дескрипторов страниц и сбросить кэш страниц
3. файл здоровый, а памяти и так мало => при последующих обращениях ОС будет вынуждена засвопить какую-то страницу (страницы)
4. goto 2 пока не финиш
В итоге имеем кучу неприятностей, включая мухлеж со страничной адресацией и своппинг и необходимость в куче свободной памяти.

Интересно, так что же будет работать быстрее?

P. S. если mmap на read only, то думаю, ОС достаточно умна, чтобы не свопить произвольную страницу, а просто объявить что-нибудь из отображенной области недействительным и воспользоваться освободившимся пространством.

Цитата linuxfan @ 27.06.06, 09:12

Чтобы узнать больше об аппаратных исключениях и о том, как они сказываются на производительности RTFM про процы.

int main()
   {
   int rt = 0;
   int tm = GetTickCount();
   for (int j = 5 ; j < 20000; ++j)
      rt += isSimp (j);
   std::cout << (double(GetTickCount()) - tm)/1000 << "\n";
 
   rt = 0;
   tm = GetTickCount();
   for (int j = 5 ; j < 20000; ++j)
      {
      rt += isSimp (j);
      __try
         {
         *(int*)0 = 4;
         }
      __except(EXCEPTION_EXECUTE_HANDLER)
         {
         }
      }
   std::cout << (double(GetTickCount()) - tm)/1000 << "\n";
 
   }

Угадай, на сколько посл код будет медленней!?
А теперь пощитай будут ли исключения генериться с такойже скоростью как и тут?

Цитата linuxfan @ 27.06.06, 09:48

Звучит так, будто мапить по кускам быстрее.

Я тут оспаривал не скорость( ее я нигде не оспариваю) а УДОБНОСТЬ маппинга.
Если тебе это звучит както подругому - извини.

Цитата linuxfan @ 27.06.06, 09:12

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

Читал, не беспокойся. Но про ПАЕ подзабыл, ибо не пользую. Освежил память - действительно ошибся.