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

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

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

0

Сообщение от Замабувараев Ну при ReadFile

При чем тут ReadFile? Загрузчик НЕ читает исполняемый файл диска всякими ReadFile.

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

Сообщение от The trick Запусти 100 экземпляров блокнотов.

Загрузчик НЕ читает исполняемый файл диска всякими ReadFile.

0

Сообщение от Pro_grammer Отображение файла, чтение файла, копирование файла - у всех один и тот же недостаток, если это с HDD в RAM, а именно ёрзание головок диска над поверхностью магнитного диска, что очень замедляет процесс. Мне кажется это и хотел сказать Quiet Snow, не более того.

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

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

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

Сообщение от Pro_grammer При чем тут ReadFile? Загрузчик НЕ читает исполняемый файл диска всякими ReadFile.

Потому-что Quiet Snow предложил метод ручного чтения/записи в файл которое подразумевает под собой использование ReadFile в том или ином виде.

Добавлено через 4 секунды

Сообщение от Pro_grammer Отображение файла, чтение файла, копирование файла - у всех один и тот же недостаток, если это с HDD в RAM, а именно ёрзание головок диска над поверхностью магнитного диска, что очень замедляет процесс. Мне кажется это и хотел сказать Quiet Snow, не более того.

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

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

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

Сообщение от Pro_grammer При чем тут ReadFile? Загрузчик НЕ читает исполняемый файл диска всякими ReadFile.

Потому-что Quiet Snow предложил метод ручного чтения/записи в файл которое подразумевает под собой использование ReadFile в том или ином виде.

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

Сообщение от Pro_grammer Загрузчик НЕ читает исполняемый файл диска всякими ReadFile.

При чем тут это? EXE файл парсится, он в любом случае будет прочитан из физического файла. Только ты читал что я написал про 100 блокнотов и 100 открытий одного файла?

0

Сообщение от The trick Все 100 экземпляров будут ссылаться на туже самую память.

Я ведь всё проверяю!
До запуска см. память 2.8 :

После запуска 1 экземпляра память не изменилась, не делаю скрин, поверь на слово.
После запуска 100 экз см память


Ну?

0

Если запустить 100 Калькуляторов, то память скушает ещё больше - 4.1
Это если будешь мне писать, что память выросла из за открытого в Блокноте "111.txt", Калькулятором я файл не открывал

0

Pro_grammer, я тебе говорю про физическую память которую занимает образ, т.е то что является маппингом. Вот exe файл и библиотеки в подавляющем большинстве ссылаются на одну и ту же память. Но в приложении помимо маппинга есть ещё и другая память типа стеки, структуры окон и т.п. Если не веришь мне, почитай мсдн, если и они тебя не переубедят возьми какой-нибудь сканер памяти и посмотри сколько один блокнот съедает виртуальной памяти а затем умножь на 100.

0

Сообщение от The trick Если не веришь мне

Я глазам верю. И теперь представь, что RAM у меня кончилась, и все эти калькуляторы и блокноты ломанулись в pagefile.sys, который на HDD, заёрзали головками
Это если он есть. А если нет, то Винда мило так скажет, "Закройте одно или несколько приложений, я не могу вам выделить память сама, как завещал великий Русинович!"

0

Сообщение от Замабувараев Нет, он создаёт отображение файла в память.

Сообщение от Замабувараев Второй момент: как вы при ReadFile сделаете разделяемую между процессами память? Например, код DLL разделяется между всеми процессами, которые её используют, что позволяет не загружать один и тот же код во все процессы, а использовать общую память.

Не ReadFile конечно, думаю там всё сложнее, чем просто создать отображение и "откинуться на спинку
кресла пока windows...".
Как это реализовано, не знаю, известно только, что в ядре системы возможностей больше.
Кстати выше читали, за больше чем 5 часов ничего само по себе выгружено из 2-х гигабайт не было,
этот процесс вообще не трогал(не переключался на него), терпеливо ждал.

Сообщение от The trick Потому-что Quiet Snow предложил метод ручного чтения/записи в файл которое подразумевает под собой использование ReadFile в том или ином виде.

Не нужно говорить за меня, предложил вместо механизма виртуальной памяти разрабатывать
собственные решения. Вот что предоожил. Меня утрированно назвали лохом и требуют доказательств.
Как их дам если: 1) нет задачи 2) то что попадёт под задачу - это вычисления над якобы большим
объёмом данных 100Гб, 2Тб и дальше и полюбому непросто реализуется, для чего нужны ещё и технические
возможности, а про время на тестирование вообще молчу. 3) Та задача что есть от геха, он её сам
не сформулирует и её тут тоже никто делать не будет, а тем более нахаляву 4) Одним циклом, который
читает\пишет данные последовательно не доказать состоятельность или наоборот моих тезисов,
это слишком простой сценарий софта, мало где так будет.

Сообщение от The trick Другого не было.

Ё маё хард резет от человека, прождавшего безрезультатно час\два\три это не решение проблемы. Вообще ни разу.

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

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

Сообщение от The trick Ты опять про этот своп с браузером. Оставь его в покое.

Всмысле? Если это равноценные вещи, тот же механизм, та же попытка вылезти за пределы оперативы
и те же результаты и я даже предложил равноценные идеальные условия - чистую систему, где ничего не мешало бы.
Отличнейший тест кейз который все вопросы с HDD расставит по местам. Только в реальной
пользовательской задаче. И эти средства уже есть их не надо реализовывать, достаточно просто
запустить и проверить.
Если я несу бред, тогда зачем было вводить меня в такое заблуждение, что это сходные вещи.
Мужики вы уже сами определитесь тогда. Иногда офигеваю. Сам вот не пытаюсь доказать ничью
неправоту просто ради какой-то движухи.

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

0

Сообщение от Замабувараев Вы думали, что загрузчик читает исполняемый файл диска всякими ReadFile? Нет, он создаёт отображение файла в память.

Сообщение от Pro_grammer Загрузчик НЕ читает исполняемый файл диска всякими ReadFile.

Я так и говорил.

0

Pro_grammer, ну и что ты этим мне хочешь сказать? Ты теперь как Квит будешь про своп писать? Ты думаешь я не знаю как он работает или что? Я тебе написал чем маппинг отличается от чтения из файла. Вот тебе карта виртуального АП того же блокнота:

Как можешь видеть память состоит из разных типов регионов. По твоей логике 100 экземпляров займут 117МБ (это используемая виртуальная память всего процесса) * 100 = 11.7ГБ, но ты у себя видишь что это не так. Как такое может быть по твоей логике?

0

Сообщение от The trick Как такое может быть по твоей логике?

Я ни чего не утверждаю, крое того, что вижу. И я вижу, что реально 1 приложение занимает место намного меньше, чем 100.
Да, меньше, чем х100, но это сути дела не меняет:

Сообщение от The trick Все 100 экземпляров будут ссылаться на туже самую память.

Не ту же самую. ОПРОВЕРГНУТО!

0

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

Ты предложил использовать:

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

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

Сообщение от Quiet Snow 1) нет задачи 2) то что попадёт под задачу - это вычисления над якобы большим объёмом данных 100Гб, 2Тб и дальше и полюбому непросто реализуется, для чего нужны ещё и технические возможности, а про время на тестирование вообще молчу. 3) Та задача что есть от геха, он её сам не сформулирует и её тут тоже никто делать не будет, а тем более нахаляву 4) Одним циклом, который читает\пишет данные последовательно не доказать состоятельность или наоборот моих тезисов, это слишком простой сценарий софта, мало где так будет.

Да ты возьми свои задачи которые ты писал мне. Ты пару постов назад писал "возьми тут байт запиши, через 4096 и т.д.". Ты мне говоришь что файл-маппинг тут отстой, у меня есть лучше решение. Так покажи/объясни чем оно лучше. Ты критикуешь одно, а взамен вода. Все.

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

Нет такого, не нужно придумывать.

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

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

Сообщение от Quiet Snow Всмысле? Если это равноценные вещи, тот же механизм, та же попытка вылезти за пределы оперативы и те же результаты и я даже предложил равноценные идеальные условия - чистую систему, где ничего не мешало бы. Отличнейший тест кейз который все вопросы с HDD расставит по местам. Только в реальной пользовательской задаче. И эти средства уже есть их не надо реализовывать, достаточно просто запустить и проверить. Если я несу бред, тогда зачем было вводить меня в такое заблуждение, что это сходные вещи. Мужики вы уже сами определитесь тогда. Иногда офигеваю. Сам вот не пытаюсь доказать ничью неправоту просто ради какой-то движухи. Ну дискутируйте тогда сами, не полезу в эти вещи, но дурака строить из меня не надо.

Ты читай что ты процитировал, только полностью. Про системный своп я с тобой не дискутирую! Оставь его в покое! Я уже 3-й раз пишу об этом, неужели не понятно?

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

Сообщение от Pro_grammer И я вижу, что реально 1 приложение занимает место намного меньше, чем 100.

А почему оно занимает меньше места в RAM чем оно занимает виртуальной памяти? Подумай головой.

Сообщение от Pro_grammer Не ту же самую. ОПРОВЕРГНУТО!

НЕ ОПРОВЕРГНУТО!

0

Реально 1 приложение занимает в памяти место намного меньше, чем 100.
Это неопровержимый факт.
Значит это:

Сообщение от The trick Все 100 экземпляров будут ссылаться на туже самую память.

не верно.

0

Сообщение от Pro_grammer Реально 1 приложение занимает в памяти место намного меньше, чем 100.

Уточните, какую память у приложения вы имеете ввиду: Private Bytes, Working Set или Virtual Size?

0

Pro_grammer, ты подумай почему оно занимает места меньше, ещё раз говорю. И ты поймёшь что пишешь ерунду. Ответ под спойлером.

0

Сообщение от The trick Ты мне говоришь что файл-маппинг тут отстой, у меня есть лучше решение. Так покажи/объясни чем оно лучше. Ты критикуешь одно, а взамен вода. Все.

Вообще не критикую.
Не говорил что во всех этих случаях есть лучшее решение, лишь указал на проблематику вопроса.
Эти варианты были призваны показать проблематику, реальную. Что работа с диском это задница,
а не лофа и сказка.
Скорость записи на диск в среднем 100Мб/с, в идеале при дефрагментированном, а так обычно 70-80,
а если год не дефражить упадёт ниже полтинника. А если две проги вдруг начали драть диск, то
попросту не дождёшься их выполнения, если там лопатятся большие данные. И проблемой станет даже
открыть диспетчер. Он может минут 5 открываться, без шуток, резет проще сделать и перезагрузиться.
Скорость записи хаотичных данных по всему диску - это вообще жесть, а ты упираешься рогом
делая вид, что этого произойти не может и эта чудо фича мол спасёт от этого, что все задачи будут
работать со скоростью чтения большого куска. Нет не будут, будет работать только часть задач
и то что поддаётся предикции.
Но и худший случай тоже нужно учесть. Не ты ли меня этим пенял, когда мужики начали мне
писать про мою прогу, что она не сожрала какой-то бред который ей подсунули. Худший случай
- ещё бы! Т.е. один худший случай нужно учесть? А другой нет? Все мои примеры об этом.
Докажи, покажи. Хоспаде... Доказать что? Выдумать сложную задачу, потратить годы на реализацию?
Да ну вас нафиг... я привёл косвенные факторы, этого достаточно. Я тут уже задолбался всем
всё доказывать и показывать. На слово никто не верит. Слово вообще уже потеряло свою
значимость даже если это, блин, правда.

Сообщение от Pro_grammer и все эти калькуляторы и блокноты ломанулись в pagefile.sys, который на HDD, заёрзали головками

Заёрзали хорошее слово))) правильное

0

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

Где я такое написал? Не нужно мне приписывать то чего я не говорил. Это ты утверждал что запись в файл напрямую будет лучше. Я же писал что маппинг не будет юзать диск пока этого не потребуется. Не веришь? Возьми и проверь. Но вы с Pro_grammer'ом уперлись рогом и пытаетесь мне доказать что-то о чем я либо не спорю с вами, либо о том в чем сами заблуждаетесь. По факту тут никто не опроверг ни одного моего высказывания.

Сообщение от Quiet Snow Но и худший случай тоже нужно учесть. Не ты ли меня этим пенял, когда мужики начали мне писать про мою прогу, что она не сожрала какой-то бред который ей подсунули. Худший случай - ещё бы! Т.е. один худший случай нужно учесть? А другой нет? Все мои примеры об этом.

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

Сообщение от Quiet Snow Докажи, покажи. Хоспаде... Доказать что? Выдумать сложную задачу, потратить годы на реализацию? Да ну вас нафиг... я привёл косвенные факторы, этого достаточно. Я тут уже задолбался всем всё доказывать и показывать. На слово никто не верит. Слово вообще уже потеряло свою значимость даже если это, блин, правда.

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

0

Сообщение от The trick Я же писал что маппинг не будет юзать диск пока этого не потребуется. Не веришь? Возьми и проверь.

Верю и даже краем копчика понимаю как оно работает. Я ж не идиот.

Сообщение от The trick Все началось с того что я написал что лимиты ВП намного больше чем RAM

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

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

В каком месте ерунда? Выход за лимиты оперативной памяти и типичная задача - браузер, это ерунда?
А ты не задумался почему они в этой задаче не сделали как пишешь? Это же логично? Там вроде и
предсказать вполне можно какие вкладки пользователь не сильно дёргает, чисто статистически, и
чисто логически можно предположить что то самое "удержание рабочего диапазона в оперативной памяти"
должно творить чудеса, но этого не происходит. Вместо этого пользователь получает жопу по истечению
оперативы. Комп зависает намертво.
И если запустить комп, на котором винду не переустанавливали лет 5, то можно опухнуть.
А всё просто - чудес не бывает, диск это диск, это соточка чтения\записи и в десятки раз меньше
при совместном доступе и ещё в разы меньше при чтении мелких фрагментов. Вот и все чудеса.
Но можно купить дешёвый SSD на 128 гигов и раздраконить его несколькими такими аллокациями по 100Гб.)))
Называется, выбирай лучшее решение... Нету его. Большие задачи - нужны большие мощности, а не этот анонизм.

0

Сообщение от Quiet Snow В каком месте ерунда?

В том что подход с ручной эмуляцией ВП через ручные файловые I/O ни чем не лучше, а даже хуже.

Сообщение от Quiet Snow И не спорил

Я и не писал что ты спорил насчет этого, я дальше написал о чем ты споришь.

0

Сообщение от The trick ты подумай почему

Зачем мне причины? Я говорю, что твоя фраза не верна. 100 одинаковых приложений занимают в памяти больше места чем 1 приложение.
Перефразируй в соответствии с реальностью, тогда и спора не будет.

0

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

Тебе нужен ответ на вопрос, как бы сделал маханизм обращения.
1) При хаотичном доступе да особо никак. Только собирать запросы в пачку и сбрасывать на диск.
Но не по 4k, а нормальными кусками. С запросами по чтению делать также. И тут не особо важна
статистика запросов, важно то, с какими данными идёт работа, как они организованы, их специфика,
чтобы использовать эту специфику для кеширования данных. И не менее важна организация своих
данных, чтобы их можно было быстро прочитать с диска. Суть организовать поочерёдный обмен с
диском, чтобы головка диска позиционировалась минимальное количество раз, скажем 5 раз в секунду,
а остальное время работала оператива и обсчёт данных.
Прогон по всему пространству если мы его завели для строго определённой цели - это неизбежно,
нужно это понимать. И путей оптимизации множество на самом деле. Жёсткий диск не единственный
аспект.
И конечно, не собирался принципиально эмулировать этот механизм, можно просто использовать сходный
принцип, говорил больше за то, чтобы решить задачу альтернативным способом, чтобы заточить
обработку данных под особенности железа(HDD).

2) При нехаотичном доступе - тут всё тоже самое, но гораздо предсказуемее, этот случай
ты описал и твоё решение не будет ничем лучше моего или решения любого другого человека.
Просто ты используешь механизм ОС, я бы просто писал тоже самое руками, разбил бы пространство
на несколько файлов, загрузил блок/посчитал/выгрузил и т.п. тоже большую часть делал
бы в оперетиве, нафиг мне драконить диск?

И вот задача геха, как её можно реализовать?
1) Картинка спрайт, допустим 100000 x 100000 пикселей. Дофига, да, Работаем.
2) гех рисует в монохроме, можно написать процедуры которые будут работать с конкретными битами,
т.о. поимеем в 8 раз больше пикселей.
3) Организация памяти, посмотрим сколко есть оперативы, заведём в оперативе строк столько, сколько
влезет в оперативу, разобъём всё изображение на такие блоки. Заведём структуру, в которой укажем
время последнего обращения и частоту обращений. Загрузка и выгрузка будет идти сразу целым блоком.
4) Посмотрим алгоритм рисования или что у него там, проанализируем можно ли разбить примитивы
по этим блокам. Например можно завести структуру с позициями и радиусами этих самых кругов,
прогон алгоритма в данном случае будет лишь заполнять эту структуру, сама отрисовка будет уже
по финалу. Далее, структуру равную кол-ву блоков, в которой хранить ID из первой структуры, заполнять
эту структуру сразу после добавления каждого примитива. Т.е. одна большая окружность может быть
повешена на несколько таких блоков. Далее работаем брезенхемом, т.к. тут только свои процедуры
привязать какую-то библиотеку скорее всего не получится из-за специфики задачи. Но вообще давным
давно товарищ rrrFer рассказывал про то как он писал плагины к Photoshop и мол там уже реализована
работа с огромными изображениями и доступны все инструменты данного софта. С этого, наверное,
стоило начать, но лучше этим закончить.

Хорошее решение, плохое решение, главное что простое, объясняется на пальцах, не дерёт диск
больше нужного. Сразу выдаёт готовый результат в виде файлов.
Можно потом дописать ещё утилиту, которая разобьёт эти блоки на квадраты равной величины,
пожмёт всё в jpeg\PNG\gif\Bmp(с RLE) картинки и сделать вьювер, по типа гугл мапса, который
будет на ходу подгружать. Я описал то, что сделать реально. Если мне кто заплатит, то сяду
и сделаю, сложно нет ничего, обычные жопочасы, но просто так конечно я не будут этой фигнёй
страдать))).
И если заметил, решение этой задачи мной разбито на много этапов, это называется динамическое
программирование. Можно и так. А не втупую "щас я заведу 10 терабайт, а потом буду огребать".

Сообщение от The trick В том что подход с ручной эмуляцией ВП через ручные файловые I/O ни чем не лучше, а даже хуже.

Писал же про разграничение чтения\записи и работу с кусками данных, существенно превышающими
4 килобайта. Да не всегда удастся безболезненно это сделать и не любую задачу заточить.
Именно к этому нужно сводить работу с HDD. А отдача системе на откуп напофиг ни к чему
хорошему не приведёт. Да может быть на компах с 16/32/64 гигами оперативы и хорошим SSD на борту
будет всё классно, но нужно учитывать, что есть конфигурации в десятки и сотни раз хуже
и на них действие втупую таким принципом будет фатально. И машина с 2 гигами это ещё ничего.
До нулевых долгое время сидел на компе с 64Мб памяти, 98 винда, мне это особенно запомнилось, после
выхода из какой-нибудь толстой проги система долго приходила в себя, восстанавливала так сказать
себя в памяти, этот самый механизм, который так и не претерпел никаких изменений.
А DOS бы просто послал меня с запуском собственно этих прог и понимаю, что это было бы не
самое худшее решение сказать честно человеку что "добавь ка ты оперативы брат, а потом дерзай",
тогда железо было конечно дорогое, сейчас с этим всё проще.

0