Дискуссия о распределении памяти в ОС

Сообщение от Замабувараев Картинку можно будет взять хоть миллион на миллион пикселей

Умножьте миллион на миллион и на 3. Узнаете сколько нужно памяти для хранения данных картинки.
Нужно 2793 ГБ. У вас установлено столько в компе?

0

Сообщение от Pro_grammer Не забываем, что у меня 16ГБ оперативки. И по уму система должна вначале кушать её, а как закончится, то добрать 40+ ГБ из файла подкачки. Но этого не происходит.

Нет, она не должна так делать. Система резервирует адресные пространства для всех процессов в системе и резервирует под них место. Поэтому тебе доступны далеко не все 16ГБ. Вызови VirtualAlloc к примеру с 6ГБ памяти, и посмотри в диспетчере задач что изменилось.
Во-вторых, своп может быть уже заполнен на какую-то величину, т.к. система может сбрасывать туда страницы исходя из нескольких факторов. Ты и сам можешь посмотреть на сколько у тебя заполнен файл подкачки через счетчики производительности:


По твоему файлу - у меня все заработало, хотя и памяти меньше чем у тебя. Память выделяется в хипе. Могу сделать вывод что у тебя просто недостаточно памяти и система просто не может зарезервировать нужный регион памяти, т.к. ты создал файл подкачки "впритык" 50ГБ и выделяешь 49.999ГБ. Всеми процессами и ядром у тебя занято больше чем ((файл подкачки + RAM) - вся выделенная память) < 50ГБ. Сделаешь чуть больше размер - все заработает.

К примеру я при файле подкачки в 50ГБ + оперативки 14ГБ могу выделить максимум 58ГБ:

0

Сообщение от The trick Хотите использовать много памяти

Наоборот, в принципе не котирую затею использовать то, чего нет в оперативе.
Ничего хорошего из этого не выйдет. А ограничиловка эта она скорее не чтобы
сильно ограничить, а чтобы не дать выжрать всё полностью. Потому что опять же
ты не знаешь включен своп или нет у человека, и есть ли даже та память, которая
была затребована для этого "окошка". Как бы если включен, то мы получаем
хард резет от пользователя. У него вообще может не быть свободного места на диске.
Плюс это надо сильно заморочиться и на FB сделать как написал Замабувараев,
т.е. адресовать голую память, а не массив. Это всё не особо удобно, сразу придётся
думать, чем заменить привычные DIM, REDIM PRESERVE, UBOUND\LBOUND.

Сообщение от The trick Я вообще не могу понять вашу логику. Я изначально говорил о лимитах виртуальной памяти которые намного больше чем имеется установленной RAM - все.

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

Сообщение от The trick Какая разница? Ты думаешь память как-то по другому работает когда ты дергаешь VirtualAlloc? Оберни всю эту логику что я выше написал в функцию - возвращает такой же указатель на память. Просто в одном случае система страницы подгружает/выгружает в системный файл подкачки, в том примере что я скинул система выгружает в файл пользователя. Разницы нет.

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

Добавлено через 10 минут
Ну и по поводу что "всё нормально" тоже нет. Может у тебя на SSD в рейде и нормально.
Но у меня все харды обычные и много где тоже самое, выше приводил задачи,
которые в прямом смысле станут невозможными при постоянном свопе с одного диска.
Не нужно забывать что мы в многозадачной среде и пользователь не будет сидеть
и ждать пока программа отработает, он захочет сделать всё параллельно и
бонусом будет рыться на сайтах и смотреть ютьюб. Ну если у него, кончено, нет
второго компа. В случае с 4\8 Гб это всё запросто приводит к свопам.

Добавлено через 8 минут

Сообщение от The trick К примеру я при файле подкачки в 50ГБ

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

1

Сообщение от Quiet Snow Наоборот

Тогда не понимаю в чем претензии. Я написал - не хотите не используйте. Для вас эта задача в этом случае нерешаема. Для меня она решаема.

Сообщение от Quiet Snow Это всё не особо удобно, сразу придётся думать, чем заменить привычные DIM, REDIM PRESERVE, UBOUND\LBOUND.

Ну это ничего не меняет, я об их внутреннем строении ничего не знаю и не спорил и не спорю. Я говорил о лимитах виртуальной памяти.

Сообщение от Quiet Snow Достаточно проделать это на одном HDD в системе(частый кейс) и всё станет ясно.

И что случится? В чем принципиальное отличие от того как ты говорил выше ты сделаешь все руками (запись в файл)?

Сообщение от Quiet Snow Просто не вижу этому нормального человеческого применения. И мой пример с браузером тому очень яркое доказательство. Т.е. пример реальной попытки далеко выйти за пределы физической памяти в своп, ты ведь сам утверждал, что он работает абсолютно одинаково.

Так как часто в реальной задаче тебе необходимо перелопатить все 100ГБ в файле? Для реальной задачи тебе понадобится в большинстве случаев несколько тысяч страниц. То что оно работает одинаково - это так и есть. Я уже выше написал Pro_grammer'у - просто выдели виртуальной памяти около 6ГБ (или сколько у тебя там оперативки свободно) и посмотри в диспетчере задач сколько у твоего процесса потребление памяти.

Сообщение от Quiet Snow чтобы поользователь не страдал почём зря

Это просто настраиваемая опция, отключаемой ее сделали не из-за этого.

Сообщение от Quiet Snow Ну и по поводу что "всё нормально" тоже нет. Может у тебя на SSD в рейде и нормально. Но у меня все харды обычные и много где тоже самое, выше приводил задачи, которые в прямом смысле станут невозможными при постоянном свопе с одного диска. Не нужно забывать что мы в многозадачной среде и пользователь не будет сидеть и ждать пока программа отработает, он захочет сделать всё параллельно и бонусом будет рыться на сайтах и смотреть ютьюб. Ну если у него, кончено, нет второго компа. В случае с 4\8 Гб это всё запросто приводит к свопам.

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

Добавлено через 2 минуты

Сообщение от Quiet Snow Файл подкачки в 50 Гб будет означать что это пространство ты не сможешь использовать для себя этот файл будет лежать на диске мёртвым грузом. Не сказать что ценный мех, но как-бы жалко.

У меня нет файла подкачки, я его включил чтобы продемонстрировать некоторым товарищам тут что они заблуждаются. Изначальный пример был с файл-маппингом, а не с системным файлом подкачки, который можно удалить после работы приложения. Ну и 50ГБ в современном мире - ничто.

0

Сообщение от Quiet Snow Ради прикола создал изображение 15000x15000, на 2 с фигом гигабайта, свернул прогу. Через час разверну.

Кстати проверил, за это время несколько раз опускал комп в спячку, несколько раз запускал и выгружал полностью браузер, с где-то 30-ю вкладками, запускал разные проги. Поднял GIMP, поводил по окну навигации, глядя на
индикатор жёсткого диска - ноль затупов. Вообще ничего не выгрузило. Да я помню что иногда выгружает,
но в каких обстоятельствах - хз. Видимо пока другие проги не начнут жрать много.
А может ему просто комфортно когда 32 гига оперативы. Надо попробовать на меньших объёмах.

Сообщение от The trick В чем принципиальное отличие от того как ты говорил выше ты сделаешь все руками (запись в файл)?

Отличие наверное в том что программист может искусственно сделать работу со значительно более крупными
кусками и не параноидально как ОС, а методично.
Ты пишешь что там идут выгрузки по 4 кб, в большинстве стандартных случаев это соотв. размеру кластера.
Но когда память нужна из разных кусков, диск начинает колбасить(т.е. позиционирование читающей головки
или попросту - растёт время доступа). Когда диск ещё и фрагментирован - это становится большой проблемой.
Например архиватор, который распаковывает с диска C:\ на диск C:\. Он читает линейный кусок(который тоже
может быть фрагментирован и чаще так и есть) и пишет множество разных файлов, для записи головка должна
ещё сместиться на FAT и обратно. Уже приличный расколбас. Попытка в этот же момент открыть любую программу
которая сама по себе обычно грузится за долю секунды может обернуться ожиданием в минуту. Открытие
же чего-то большего можно ждать часами. При этом разархивация замедляется ровно во столько же раз,
ползунок прогресса просто останавливается, с диска идёт не чтение, а он тупо колбасится между файлами
пытаясь быстро выдрать маленький кусочек и отдать проге, т.е пытается разорваться на всех.
Думаю, каждый это видел и чувствовал, не знаю какие тут могут быть вопросы. Это всё проверяется,
Не с бодуна это пишу, сам сидел на 4 гигах 10 лет и на 8 гигах 6 лет, такая себе радость, особенно когда
надо пооткрывать вкладок и чтобы ещё куча софта в фоне висело.

Сообщение от The trick Или в твоем случае хард не будет "надрываться"?

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

Добавлено через 16 минут

Сообщение от The trick Ты мне что хочешь сказать? Что запись в файл напрямую быстрее? Нет - это не так

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

Сообщение от The trick Так как часто в реальной задаче тебе необходимо перелопатить все 100ГБ в файле?

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

Добавлено через 17 минут

Сообщение от The trick отключаемой ее сделали не из-за этого

Имхо как раз из-за этого, других причин нет. И как ты правильно заметил виртуальная память
никуда не девается, это неотъемлемая часть системы.

Сообщение от The trick я об их внутреннем строении ничего не знаю

Так мне тоже не сильно это надо, написал оператор - память завелась. Нету памяти - прога вылетела.
Всё логично. А что там внутри, global alloc, heap alloc или что-то ещё - это уже не моё дело.
При желании, наверное, можно залезть в исходники FB и увидеть что там наворотили.
Думаю обычный сишный malloc.

0

Сообщение от The trick Нет, она не должна так делать. Система резервирует адресные пространства для всех процессов в системе и резервирует под них место. Поэтому тебе доступны далеко не все 16ГБ.

Ну вот так рекомендовано установить файл подкачки:

Стандартные настройки выглядят приблизительно так: При 2 Гб ОЗУ или менее — 2-4 Гб виртуальной памяти в качестве подкачки (100-200%). При 4-6 Гб ОЗУ — 4-6 Гб (100-150%). При 8-10 Гб ОЗУ — 2-4 Гб (50% и менее). При 16, 32 Гб памяти можно оставить выбор на усмотрение системы.

Другими словами в принципе не рекомендуется файл подкачки больше чем оперативка *2
И если оставить " выбор на усмотрение системы", то система сама никогда не выделит 100ГБ и уж тем более 2.5ТБ
Собственно с этого и начали, что система сама не может.
Т.о. из многочисленных опытов можно сделать только один вывод, что эта ситуация

Сообщение от Замабувараев Картинку можно будет взять хоть миллион на миллион пикселей

практически невозможна.

0

Сообщение от Pro_grammer Ну вот так рекомендовано установить файл подкачки

Кто рекомендует? Есть ссылка на источник? Например, Руссинович так не говорит.

Сообщение от Pro_grammer практически невозможна

А как же фотографии звёздных небес со всяких Хабблов?
Так уж и практически невозможна? Вот опровержение: https://www.blenda.by/blog/sam... apikselej/

0

Сообщение от Замабувараев Вот опровержение:

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

0

Сообщение от Pro_grammer Это программная фишка

Я правильно понимаю, что вы считаете создание картинки миллион на миллион пикселей невозможным?

0

Сообщение от Quiet Snow Отличие наверное в том что программист может искусственно сделать работу со значительно более крупными кусками и не параноидально как ОС, а методично. Ты пишешь что там идут выгрузки по 4 кб, в большинстве стандартных случаев это соотв. размеру кластера. Но когда память нужна из разных кусков, диск начинает колбасить(т.е. позиционирование читающей головки или попросту - растёт время доступа). Когда диск ещё и фрагментирован - это становится большой проблемой. Например архиватор, который распаковывает с диска C:\ на диск C:\. Он читает линейный кусок(который тоже может быть фрагментирован и чаще так и есть) и пишет множество разных файлов, для записи головка должна ещё сместиться на FAT и обратно. Уже приличный расколбас. Попытка в этот же момент открыть любую программу которая сама по себе обычно грузится за долю секунды может обернуться ожиданием в минуту. Открытие же чего-то большего можно ждать часами. При этом разархивация замедляется ровно во столько же раз, ползунок прогресса просто останавливается, с диска идёт не чтение, а он тупо колбасится между файлами пытаясь быстро выдрать маленький кусочек и отдать проге, т.е пытается разорваться на всех. Думаю, каждый это видел и чувствовал, не знаю какие тут могут быть вопросы. Это всё проверяется, Не с бодуна это пишу, сам сидел на 4 гигах 10 лет и на 8 гигах 6 лет, такая себе радость, особенно когда надо пооткрывать вкладок и чтобы ещё куча софта в фоне висело.

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

Сообщение от Quiet Snow А если читать и писать в случайные адреса из этих 100 гигабайт, то увидишь что там случится, это будет крах.

Не будет. Я уже выше написал, пока рабочий набор не исчерпается, хард не будет "подхвачен". При твоем способе ручной записи в файл, как раз все те проблемы о которых ты тут пишешь.

Сообщение от Quiet Snow Хочу сказать, что сам механизм, когда прога пытается оперировать тем, что не имеет - это плохо для пользователя.

Что она не имеет? У нее есть виртуальное АП которое она имеет.

Сообщение от Quiet Snow А пишет оно само собой одинаково. И без разницы это будет своп или простой доступ к файлу. Ничего особо не поможет.

Не одинаково. В одном случае ты осуществляешь чтение/запись всегда (при непосредственной записи в файл), при использование свопа - только при необходимости + минуя всякие буфера.

Сообщение от Quiet Snow Да ни разу не требовалось. Я бы помер ждать пока оно что-то там перелопатит, редко делаю дефраг.

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

Сообщение от Quiet Snow Имхо как раз из-за этого, других причин нет.

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

Сообщение от Quiet Snow Так мне тоже не сильно это надо, написал оператор - память завелась. Нету памяти - прога вылетела.

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

Сообщение от Pro_grammer Ну вот так рекомендовано установить файл подкачки:

Какая разница как рекомендовано? Мы разве это обсуждаем? Ты о чем написал, что даже при включенном файле подкачки невозможно выделить памяти больше чем установлено RAM. Я же написал что возможно. Все. Более того ты написал что с выключенным файлом подкачки это невозможно. Я написал что возможно использую файл-маппинги. Все. Не нужно ничего приплетать больше.

Сообщение от Pro_grammer И если оставить " выбор на усмотрение системы", то система сама никогда не выделит 100ГБ и уж тем более 2.5ТБ

С чего ты это взял? На что ты ссылаешься? Размер файла подкачки может увеличиваться на величину 3 * RAM [+1GB]. И при больших объемах RAM файл подкачки может быть любого размера.

Сообщение от Pro_grammer Собственно с этого и начали, что система сама не может.

Может. Не нужно сейчас выворачивать дискуссию и подменять факты. Тобою было выдвинуто утверждение что невозможно выделить память больше чем доступно RAM. Был показан пример с файл-маппингом который позволяет выделить памяти гораздо больше чем RAM присутствует на машине за счет использования механизма виртуальной памяти. Все. Дальнейшие твои "перлы" про системный файл подкачки также ни что не опровергают и ни что не показывают. Что системный файл подкачки, что файл-маппинг, по сути почти одно и тоже. И создав достаточно большой файл подкачки можно и твои любимые функции (DIM) использовать. Все. Не зря тебе изначально посоветовали почитать Руссиновича.

Сообщение от Pro_grammer Т.о. из многочисленных опытов можно сделать только один вывод, что эта ситуация

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

0

Сообщение от The trick у нас есть возможность использовать файл-маппинг.

У вас есть. Но повторюсь, не будешь же серьёзно утверждать, что Винда умеет сочинять музыку и писать стихи?
Мы сами должны сказать системе, сколько надо, а она сама не умеет выделить сколько нужно, если в оперативку не лезет. Всё?

Добавлено через 27 минут

Сообщение от Замабувараев создание картинки миллион на миллион пикселей невозможным?

Тут вопрос не в создании, а как её посмотреть на обычном компьютере именно в разрезе выделения памяти, коей нужно более 2ТБ. С это же началось всё. Вопрос именно загрузить её в память без программных трюков. Т.е. тупо LoadImage.
Файл подкачки считаем включен в режим "система сама определяет размер", хард имеет достаточный размер, пусть 5ТБ.
Получится?

0

Сообщение от Pro_grammer Мы сами должны сказать системе, сколько надо, а она сама не умеет выделить сколько нужно, если в оперативку не лезет. Всё?

А ты когда память для массива выделяешь система сама за тебя определяет сколько тебе памяти нужно? Ты и в этом случае делаешь ReDim с нужным тебе количеством элементов. Только причем тут это вообще? Что ты этим хочешь сказать? Я не вижу связи между твоим утверждением что это в принципе невозможно и тем что ты пишешь сейчас. Ну да, мы должны сказать системе сколько надо памяти, ну и что?

Сообщение от Pro_grammer Файл подкачки считаем включен в режим "система сама определяет размер", хард имеет достаточный размер, пусть 5ТБ. Получится?

Не нужно на ходу придумывать новые условия. LoadImage поддерживает BMP который по определению не может быть таким большим.

0

Сообщение от Pro_grammer как её посмотреть на обычном компьютере именно в разрезе выделения памяти, коей нужно более 2ТБ

Загрузить только кусок файла. Вот фильмы UltraHD Video на 100 гигабайт — вы тоже думаете, что их целиком в память загружают?

0

Сообщение от The trick Не нужно на ходу придумывать новые условия. LoadImage поддерживает BMP который по определению не может быть таким большим.

Речь шла о картинке. BMP это картинка.
Можно ли создать картинку функцией CreateCompatibleBitmap или подобной размером миллион на миллион точек используя виртуальную память о которой вы пишите? Потом нужно сохранить результат в виде графического файла (картинки) чтобы в дальнейшем загрузить и отобразить на экране.

0

Сообщение от locm Речь шла о картинке. BMP это картинка.

Где именно речь шла о BMP картинке? О ней по определению не могла идти речь, т.к. такого BMP файла не может существовать в принципе. Хранить можно просто сырой растр к примеру.

Сообщение от locm Можно ли создать картинку функцией CreateCompatibleBitmap или подобной размером миллион на миллион точек используя виртуальную память о которой вы пишите?

Функции GDI/GDI+ не поддерживают работу с такими изображениями, но можно просто работать с областью около 4 ГБ за раз. Для этого в CreateDIBSection есть параметры hSection и offset в который и передается такой большой файл-отображение, и меняя offset можно изменять окно в котором происходит отрисовка. Тоже самое справедливо и для GDI+.

0

Сообщение от The trick В моем случае пока рабочий набор не будет исчерпан - хард вообще не подключится

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

Сообщение от The trick в твоем с записью в файл хард будет постоянно юзаться. В чем выгода?

Откуда такой вывод, что постоянно? Об этом не писал, а писал о последовательной отработке задачи.
Хаотичное обращение ко всему пространству не сделает выгоду, система этого автоматом не поймёт,
выгоду можно сделать только правильной архитектурой софта. Вот про что пишу. Про то, что когда
приходит время скидывания на хард(если его не дерёт что-то ещё), лучше иметь то, что пишет крупные
блоки, чем то, что тупо колбасится. А за счёт чего это будет достигнуто - думать программисту.
Это нетривиальная задача. Можно решать её средствами системы и получать хард резеты с потерей
всех своих данных, а можно подумать как конкретную задачу решить лучше.
Опять же у меня нет таких задач и все эти пространные рассуждения тут выглядят не особо здраво,
типа завести 100 Гигабайт не знамо зачем, как читаться с них данные будут никто не знает, а нужны
ли они вообще или лучше подумать об оптимизации, как сделать так чтобы их не заводить.

Сообщение от The trick при использование свопа - только при необходимости + минуя всякие буфера.

Буферы и сделали чтобы ускорять. Так что это больше проблема, чем польза.
Для свопов вообще люди отводят отдельные диски и заводят FAT разделы.
Но чаще покупают оперативу, чтобы это перестало быть проблемой.

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

А маппинг файл что прочитать не может кто угодно? Выше было заверение, что это одно и то же.
Хотя я с ним не совсем согласен. И всё же разница есть. В одном случае система должна
думать какие процессы подкачивать\скидывать (т.к. они одновременно обращаются к памяти)
и ставить приоритеты, в другом - просто голые страницы памяти, о которых ничего нельзя сказать.
По поводу безопасности - всякий чит софт тоже память читает и пишет легко, те кто хочет что
то потырить - сделает это менее заметным способом чем драконить файл подкачки, юзер сразу
увидит что за прога там лопатит через какой-нть Anvir Task Manager.

Добавлено через 17 минут

Сообщение от The trick Где именно речь шла о BMP картинке?

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

0

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

Тоже самое справедливо и для твоего подхода, только тут все будет ужасно изначально, т.к. рабочий набор вообще не используется а данные пишутся/читаются хаотично. Разница адресов вообще не влияет на маппинг, там подгружаются страницы. Ты можешь обратиться к 0-байту файла и к последнему - будут подгружены только 2 страницы.

Сообщение от Quiet Snow Откуда такой вывод, что постоянно?

Оттуда, что ты сам об этом написал:

Сообщение от Quiet Snow Т.е. выходит что все эти вещи, если они нужны - нужно делать руками. А если так, то наверное, собственная реализация с простым открытием файла для своих алгоритмов - будет быстрее, т.е. загрузить под объём оперативы, обсчитать кусок, выгрузить и т.п., примерно как мы работали с VESA в реальном режиме или EMS памятью давным давно, кусками.

Сообщение от Quiet Snow Вот про что пишу. Про то, что когда приходит время скидывания на хард(если его не дерёт что-то ещё), лучше иметь то, что пишет крупные блоки, чем то, что тупо колбасится. А за счёт чего это будет достигнуто - думать программисту.

Ничего не понял.

Сообщение от Quiet Snow Буферы и сделали чтобы ускорять. Так что это больше проблема, чем польза. Для свопов вообще люди отводят отдельные диски и заводят FAT разделы. Но чаще покупают оперативу, чтобы это перестало быть проблемой.

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

Сообщение от Quiet Snow А маппинг файл что прочитать не может кто угодно?

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

Сообщение от Quiet Snow Выше было заверение, что это одно и то же.

Нет я такого не говорил, я говорил что это почти одно и тоже.

Сообщение от Quiet Snow По поводу безопасности - всякий чит софт тоже память читает и пишет легко, те кто хочет что то потырить - сделает это менее заметным способом чем драконить файл подкачки, юзер сразу увидит что за прога там лопатит через какой-нть Anvir Task Manager.

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

Сообщение от Quiet Snow ТС там чё-то лабзал со своими фрактало подобными штуками.

Первое упоминание о большой картинке (миллион на миллион) не относилось к файлу BMP, и соответствующая дискуссия тоже. Файл BMP сам по себе не способен вместить в себя такую картинку.

0

Сообщение от The trick У меня при выкидывании страницы в своп - происходит выгрузка ее целиком минуя всякие буфера.

Да я понял что оно фигачит сразу 4k секторами, проще сказать создай 100ГБ файл на обычном харде,
какой-нибудь старой баракуде на 160 Гигов, и обращайся по случайным адресам этого "массива"
запись чтение, запись чтение, сэмулируй худший сценарий. Понимаешь какая скорость чтения будет?
В реальности такое не редкость.

Сообщение от The trick Ничего не понял.

VESA и EMS были лишь для примера "оконности" этой передачи. Полагаю ты уже понял про что пишу.
Приводил в пример браузеры, очень популярный софт. Все знают как они себя ведут в подобных условиях.
Обычно когда начинается своппинг, ещё 3-5 вкладок(если на компе мало оперативы, допустим 4Гб)
и пользоваться невозможно совсем. Это обычная ситуация и её легко смоделировать, у всех есть
старые ноуты или бесхозные коры дуо\пеньки.

Сообщение от The trick и другие чужие приложения начнут скидывать в системный своп данные, где их можно забрать.

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

Сообщение от The trick которая не нужна и не только не ускоряет, а замедляет доступ.

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

Добавлено через 15 минут

Сообщение от The trick Тоже самое справедливо и для твоего подхода

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

Сообщение от The trick Ты можешь обратиться к 0-байту файла и к последнему - будут подгружены только 2 страницы.

Прекрасно понимаю, про что говоришь.
Можешь да, разумеется, но когда заводишь 100ГБ данных под видом массива, очевидно заводишь
их с какой-либо целью, например с целью использовать этот объём в достаточной мере.

0

Сообщение от Quiet Snow Да я понял что оно фигачит сразу 4k секторами, проще сказать создай 100ГБ файл на обычном харде, какой-нибудь старой баракуде на 160 Гигов, и обращайся по случайным адресам этого "массива" запись чтение, запись чтение, сэмулируй худший сценарий. Понимаешь какая скорость чтения будет? В реальности такое не редкость.

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

Сообщение от Quiet Snow VESA и EMS были лишь для примера "оконности" этой передачи. Полагаю ты уже понял про что пишу. Приводил в пример браузеры, очень популярный софт. Все знают как они себя ведут в подобных условиях. Обычно когда начинается своппинг, ещё 3-5 вкладок(если на компе мало оперативы, допустим 4Гб) и пользоваться невозможно совсем. Это обычная ситуация и её легко смоделировать, у всех есть старые ноуты или бесхозные коры дуо\пеньки.

Ну так свопинг других приложений происходит в системный файл подкачки когда не хватает RAM. Просто не делай так чтобы другим приложениям не хватало RAM. Я уже скинул пример где ограничиваю рабочий набор своему процессу - другие приложения не страдают.

Сообщение от Quiet Snow Эти накладные расходы в сотые доли наносекунд не стоят нашего времени, чтобы их обсуждать.

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

Добавлено через 7 минут

Сообщение от Quiet Snow Абсолютно верно, если дерьмово сделать - будут те же самые проблемы.

Ну так это справедливо и для файл-маппинга. Только файл маппинг пишет данные по требованию + прозрачно (программист просто пишет в память, может работать с указателями и т.п.). К примеру нужно мне равномерно по всему 100ГБ АП изменить данные - мне требуется только пиать/читать и если RAM хватает мой хард вообще не будет тронут. При твоем подходе придется равномерно бегать по файлу, читать порцию, изменять кусочек, писать обратно.

Сообщение от Quiet Snow Можешь да, разумеется, но когда заводишь 100ГБ данных под видом массива, очевидно заводишь их с какой-либо целью, например с целью использовать этот объём в достаточной мере.

Я завожу именно память, а память может быть какой-нибудь огромной базой данных. Мне нужно быстренько по заголовку пройтись и найти нужные данные, другое мне не нужно, оно и не будет загружено вообще.

0

Сообщение от The trick Ну попробуй прочитать память какого-нибудь современного защищенного АВ, или к примеру ядерную память без соответствующих прав.

При чём тут это? Не программирую ядро системы, я прикладник.

Сообщение от The trick Только у меня это чтение/запись происходят только тогда когда нужно, у тебя всегда.

Дело не в том что "всегда", дело в том "как?"
Как раз могу организовать в программе буфер и даже некое подобие этого маппинга причём с более умным
алгоритмом, если хорошо сесть и заморочиться. А озвученный тобой механизм, после записи
этого самого ворксета начнёт выгружать одно и догружать другое и сам бог не увидит как он
это будет делать. В когда соотношение памяти станет раза в 1.5 меньше чем этот файл, оно уйдёт
в глубокий своп и уже молчу про хаотичное дёргание 100 Гб. Конечно это худший сценарий, но
оно недалеко от истины, просто потому что если у тебя заполнена вся доступная оператива,
любой загрузке крупного блока(допустим на вкладку с сайтом) будет следовать выгрузка,
выгрузка чего - ты не знаешь, что в бошку системе взбредёт то и выгрузит, может частично
кусками выгрузить, а потом чтобы это обратно вернуть придётся устраивать расколбас головке
диска. Блин эту проблему же легко понять. Я тут уже несколько страниц распинаюсь.

Сообщение от The trick Ну это ты беспокоишься о хардах, я тебе просто привожу пример того что твой подход ни быстрее, ни лучше.

Подход корректной организации архитектуры всегда лучше.

0

Сообщение от Quiet Snow При чём тут это? Не программирую ядро системы, я прикладник.

При том что ты пишешь:

Сообщение от Quiet Snow те кто хочет что то потырить - сделает это менее заметным способом чем драконить файл подкачки

Сообщение от Quiet Snow А озвученный тобой механизм, после записи этого самого ворксета начнёт выгружать одно и догружать другое и сам бог не увидит как он это будет делать.

Он это будет делать вполне детерминировано. Какую страницу ты запросишь - такую и загрузит. Умнее ты никак не сделаешь.

Сообщение от Quiet Snow Конечно это худший сценарий, но оно недалеко от истины, просто потому что если у тебя заполнена вся доступная оператива, любой загрузке крупного блока(допустим на вкладку с сайтом) будет следовать выгрузка, выгрузка чего - ты не знаешь, что в бошку системе взбредёт то и выгрузит, может частично кусками выгрузить, а потом чтобы это обратно вернуть придётся устраивать расколбас головке диска. Блин эту проблему же легко понять. Я тут уже несколько страниц распинаюсь.

Ты мне вообще о чем-то своем пишешь. Я тебе пишу про маппинги, ты мне про своп других приложений и браузера - на фига? Оставь в покое другие приложения, мы их не трогаем и своп не трогаем, мы работаем с маппингом.

Сообщение от Quiet Snow Подход корректной организации архитектуры всегда лучше.

Ты его так и не привел. Не спорю что правильная архитектура это хорошо, только при чем тут маппинги.

0