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

Цитата LuckLess @ 27.06.06, 10:26

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

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

Цитата LuckLess @ 27.06.06, 10:26

Угадай, на сколько посл код будет медленней!?

Я не гадалка и тем более не дурак, чтобы на замерах малых промежутков времени верить чему-то кроме rdtsc. Ты хочешь попытаться убедить меня, что переключение userspace <-> kernelspace + изменение страничных каталогов + сброс кэша страниц -- очень быстрая операция?
Сравни побайтовое чтение read (ReadFile в WinAPI -- хотя там, конечно, большая часть времени будет тратиться на заталкивание аргументов в стек) и побайтовое чтение fread. Основная разница будет получена как раз за счет минимизирования числа переключений между kernel и userspace.
P.S. на файле размером 100 байт разницу почуствовать не удастся

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

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

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

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

Я не гадалка и тем более не дурак, чтобы на замерах малых промежутков времени верить чему-то кроме rdtsc. Ты хочешь попытаться убедить меня, что переключение userspace <-> kernelspace + изменение страничных каталогов + сброс кэша страниц -- очень быстрая операция?

если тебя не устраивает кроошечная погрешность, то простите.
но намоем камне 50000 исключений = 1 секунде.
50000 исключений = 50000страниц = (приблизительно) 200 МБ.
200МБ я копирую за 10 секунд(рейд у меня). значит выходит, что потери на исключениях будут порядка 10 процентов.
Еслиб небыло рейда, потери былиб меньше(порядка 5%).

На остольном будут еще 1-2 процента потерь. того выходит 7-12%(в зависимости от производительности винта) потерь.
Конечно, это довольно большое число.
И конечно для копирования файлов маппинг использовать не надо(не только изза производительности, а еще и изза того, что обычное АПИ использовать даже проще!!).
Но для рандом акссес маппинг незаменим, вне зависимости от размеров файла.

Цитата LuckLess @ 27.06.06, 11:06

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

Не такой уж он простенький будет. По сути, надо будет написать свое распределение ресурсов (адресное пространство --- это ресурс). А это уже совсем другой калибр.

Цитата mo3r @ 27.06.06, 11:12

Не такой уж он простенький будет. По сути, надо будет написать свое распределение ресурсов (адресное пространство --- это ресурс). А это уже совсем другой калибр

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

Цитата LuckLess @ 27.06.06, 11:14

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

В этом месте прозрачность уже потеряна, т. к. операции вот такого вот вида:

len = strlen(mapped);

при частичном маппинге уже не покатят. На каждое обращение к отображенной памяти (причем обращение видимо происходит блоками фиксированного размера, т. к. иначе как ты определишь, когда надо еще одну часть мапить?) у тебя происходит выполнение дополнительного кода проверок, который будет выполнять два сравнения (а это три чтения: нижняя граница, верхняя граница и сам адрес), т. е. накладные расходы превышают 300% * размер_указателя (или оффсета) / размер_блока, т. е. если это побайтовое чтение, то накладные расходы на 32-битной архитектуре составят более 1200%!
И после этого мы удивляемся, что компы так тормозят!

Цитата linuxfan @ 27.06.06, 11:32

при частичном маппинге уже не покатят. На каждое обращение к отображенной памяти (причем обращение видимо происходит блоками фиксированного размера, т. к. иначе как ты определишь, когда надо еще одну часть мапить?) у тебя происходит выполнение дополнительного кода проверок, который будет выполнять два сравнения (а это три чтения: нижняя граница, верхняя граница и сам адрес), т. е. накладные расходы превышают 300% * размер_указателя (или оффсета) / размер_блока, т. е. если это побайтовое чтение, то накладные расходы на 32-битной архитектуре составят более 1200%!
И после этого мы уд

Мдааа..
strlen() говоришь? Он применяеться для строк! В данном случае мы работаем с бинарным файлом, и никакой strlen() применен быть не может.
Object.size(); вот и вся прозрачность.
А про накладные расходы - это вообще сказка.
Мне надо хранить
1. текущий offset(для точо, чтобы не мапить , что уже замапено)
2. размер (можно и не хранить а все время вычислять.)
3. Handle файла и мапы.
4. Указатель на мапу.
5. Размер блока(если вдруг захочеться понастраивать объект, задавая ему разный размер блока)
24 байта!! Это очень небольшой расход??? учитывая что без этого объекта нам бы все равно пришлось бы это все вычислять.
два сравнения говоришь. Я сейчас просто заплачу.
1200% насчитал.
побайтовой чтение, мдаа...

Цитата LuckLess @ 27.06.06, 11:43

Он применяеться для строк! В данном случае мы работаем с бинарным файлом, и никакой strlen() применен быть не может.

В файле вполне могут храниться строки.

Цитата mo3r @ 27.06.06, 11:47

В файле вполне могут храниться строки.

нужна строка, пользуй
std::ifstream& operator>> (std::ifstream&, std::string&)

Не бывает одного инструмента на все! случаи жизни. И таких инструментов не будет никогда.

Цитата LuckLess @ 27.06.06, 11:43

1200% насчитал.

1200% --- это накладные расходы по времени.

Добавлено 27.06.06, 11:52

Цитата LuckLess @ 27.06.06, 11:49

нужна строка, пользуй
std::ifstream& operator>> (std::ifstream&, std::string&)

Строки внутри структур данных, например.

Цитата LuckLess @ 27.06.06, 11:49

Не бывает одного инструмента на все! случаи жизни. И таких инструментов не будет никогда.

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

Цитата mo3r @ 27.06.06, 11:50

1200% --- это накладные расходы по времени.

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

Добавлено 27.06.06, 11:54

Цитата mo3r @ 27.06.06, 11:50

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

Не сложно, а "накладно".

Цитата LuckLess @ 27.06.06, 11:43

А про накладные расходы - это вообще сказка.
Мне надо хранить
1. текущий offset(для точо, чтобы не мапить , что уже замапено)
2. размер (можно и не хранить а все время вычислять.)
3. Handle файла и мапы.
4. Указатель на мапу.
5. Размер блока(если вдруг захочеться понастраивать объект, задавая ему разный размер блока)
24 байта!! Это очень небольшой расход??? учитывая что без этого объекта нам бы все равно пришлось бы это все вычислять.
два сравнения говоришь. Я сейчас просто заплачу.
1200% насчитал.

Ты меня неправильно понял. Предположим, что у тебя есть прокси-класс, который выполняет отображение различных кусков файла по мере необходимости. Допустим, что для этого класса у тебя определен оператор [], читающий один байт.
Для того, чтобы прочитать один байт из отображенной части файла тебе надо проверить, лежит ли этот байт в уже замапленой части файла или нет (две дополнительных операции чтения + чтение переданного параметра -- номера ячейки). Т. е. для осуществления каждой операции чтения байта нам надо осуществить три операции чтения 32-битных слов и две операции сравнения этих слов.
Кроме того, в "простеньком классе" не обработаешь хорошо случайный доступ -- периодически будет выполняться ремаппинг одних и тех же частей, а для последовательного чтения обычный (f)read проще, удобнее и быстрее.

Добавлено 27.06.06, 12:07

Цитата LuckLess @ 27.06.06, 11:53

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

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

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

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

Я чувствую мы просто все время о разных вещах говорим
Ты говориш берем следующий - это понятно и так)
Я говорю про случай, когда мы не знаем кто следующий!
Например у тебя попросили 5-и миллиардный байт, затем 62-й , затем 3-х миллиардый потом 3-й.
И как ты тут будешь определять кто следующий. Все равно придеться делать эти проверки(о которых я выше говорил).
Но если читать read() - ом , писать это дело будет тяжелее.
Я говорю о произвольном доступе к различным(не последовательным) частям файла. Причем используя кэширующее чтение(т.е. не побайтовое ессесно), с возможностью изменения размера блоков для чтения.

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

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

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

Добавлено 27.06.06, 12:15
Былиб 64-ые процессоры более массовыми...

Цитата LuckLess @ 27.06.06, 12:14

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

Это че такое?
Если ты будешь заново мапить старый кусок, то это будет нести те же накладные расходы на перестройку каталогов страниц. Если такой ремаппинг будет частым, то комбинация seek & read вполне сможет его обогнать.
И вообще, не бывает таких задач, чтобы читать совсем рандомные участки файлов (кроме тестов скорости винчестеров). Такую задачу эффективно можно решить только при корректной полной постановке, когда можно будет воспользоваться соображениями о внутреннем устройстве файла, загрузить в память часто используемые области (например, индексы БД) и т. д.

Цитата LuckLess @ 27.06.06, 12:14

Былиб 64-ые процессоры более массовыми...

Вообще-то они уже массовые. И на работе, и дома.

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

Вообще-то они уже массовые. И на работе, и дома.

Знаю 1-го челоека с 64-ым камнем.
Сам куплю Конрое..

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

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

Да. Но не будет чтения с диска, который суть - основной тормоз.
Вспомни, я говорю о удобном но не максимально быстром классе

В побайтовом чтении fseek() + read() то обойтет скорее всего.
Но когда надо работать с диапазонами адресов расположенными в разных участках файла...

В общем, на самом деле, с чем сложно не согласиться, так это с

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

Такую задачу эффективно можно решить только при корректной полной постановке

Так что расссуждать бессмысленно, если нет этой самой полной постановки

ps: я вообще за fstream + отрезания яиц тем, кто лепит большие файлы

Цитата LuckLess @ 27.06.06, 12:34

ps: я вообще за fstream + отрезания яиц тем, кто лепит большие файлы

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