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

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

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

0

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

Не нужно съезжать с темы. Замабувараев написал что загрузчик проецирует исполняемый файл в память. Я также написал:

Сообщение от The trick Есть разница. Запусти 100 экземпляров блокнотов. Все 100 экземпляров будут ссылаться на туже самую память. Открой 100 раз файл в разных прогах и считай с него данные в буфера - получишь 100 разных буферов.

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

Сообщение от Pro_grammer Перефразируй в соответствии с реальностью, тогда и спора не будет.

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

0

Сообщение от Pro_grammer Перефразируй в соответствии с реальностью, тогда и спора не будет.

Покажите сколько всего памяти занимает один блокнот.

0

Сообщение от Замабувараев Покажите сколько всего памяти занимает один блокнот.

Как нарисовать 40 соприкасающихся окружностей?

0

Сообщение от Pro_grammer Как нарисовать 40 соприкасающихся окружностей?

Не понял, где там написано сколько всего памяти занимает один блокнот. Или 2,8 гигабайта — это один блокнот занимает?

0

Сообщение от Quiet Snow При хаотичном доступе да особо никак. Только собирать запросы в пачку и сбрасывать на диск. Но не по 4k, а нормальными кусками. С запросами по чтению делать также.

Что значит собирать в пачку и сбрасывать на диск? Ну никакого преимущества это не даст. К примеру нужно тебе разметить огромный файл через каждый ГБ, и будешь ты туда-сюда по МБ кидать. В чем преимущество? При использовании маппинга система только 100 - 4 килобайтных куска раскидает. В твоем случае придется раскидывать "нормальными кусками", опять тормоза и излишняя нагрузка на хард + неоправданное уменьшение ресурса SSD.

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

Так принцип должен быть такой чтобы это было выгоднее использовать чем маппинги. А если выгоды нет то смысл?

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

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

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

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

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

И как ты будешь проверять обращения? Каждое обращение к блоку будешь тестировать? Ненужный оверхед. В Windows уже есть такой механизм который поддерживается на уровне железа.

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

Это изобретение велосипеда, ручная отрисовка и т.п. Как выглядит алгоритм с моей стороны.
1. Создаем файл нужного размера;
2 (а). Создаем DIB-секцию в которую передаем файл-маппинг созданного выше файла, где указываем какую часть файла мы будем использовать (к примеру 1000000 * 100 пикселей);
2 (б). Создаем GDI+ битмап в который передаем наш файл-маппинг и часть файла которую будем использовать;
3. Рисуем обычными GDI / GDI+ функциями на нужном регионе;
4. По завершении отрисовки, сбрасываем целый блок на диск, и переходим к п. 1 пока весь файл не будет обработан.

Все. Задача решена.

Сообщение от Quiet Snow Писал же про разграничение чтения\записи и работу с кусками данных, существенно превышающими 4 килобайта.

Какая разница? Ну если тебе так хочется выгружай хоть по 1ГБ куски в чем проблема? Я же скинул функцию, там указывай нужный размер для выгрузки и все.

0

Сообщение от Замабувараев где там написано сколько всего памяти занимает один блокнот.

ПО-русски написано. См. внимательно.
Ещё одно наблюдение. На диске Калькулятор.exe занимает 25Кб. Значит сто копий 25*100 = 2.5МБ
Т.е. если нужно перекинуть 100 раз Калькулятор с HDD, то это 2.5МБ информации.
Но в памяти 100 Калькуляторов занимают 4.1ГБ - 2.8ГБ = 1.3ГБ
1300МБ / 2.5МБ = 520
Итого, в вашей отражённой памяти с моего HDD в DDR4 в 250 раз больше занято памяти, чем взято на исходном HDD!

0

Сообщение от Pro_grammer ПО-русски написано. См. внимательно. Ещё одно наблюдение. На диске Калькулятор.exe занимает 25Кб. Значит сто копий 25*100 = 2.5МБ Т.е. если нужно перекинуть 100 раз Калькулятор с HDD, то это 2.5МБ информации. Но в памяти 100 Калькуляторов занимают 4.1ГБ - 2.8ГБ = 1.3ГБ 1300МБ / 2.5МБ = 520 Итого, в вашей отражённой памяти с моего HDD в DDR4 в 250 раз больше занято памяти, чем взято на исходном HDD!

0

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

А твою не отправит? Или оператива на твой маппинг из воздуха возьмётся? Жжёшь!

Сообщение от The trick Что значит собирать в пачку и сбрасывать на диск? Ну никакого преимущества это не даст.

После этого можно дальше ничего не писать. Ты думаешь, что оно всё попадёт в кеш драйвера, либо в аппаратный.
Вся эта мелочёвка. А на какой-нибудь старой машине с XP, да не дай бог с одним ядром будет всё иначе.
Там местами даже DMA не пашут нормально(на всех, которые мне попадались не пашут) и запросы
к дискам попросту останавливают всю систему, пока диск не ответит. Не видел такого ни разу?
На современных машинах даже отголоски этого чувствуются, когда HDD.

Сообщение от The trick Какая разница? Ну если тебе так хочется выгружай хоть по 1ГБ куски в чем проблема?

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

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

Это примерный план. Но думаю, тестировать обращение к блокам и не нужно, это я ляпнул, не особо подумав,
т.к. были заведены соотв. структуры в итоге алгоритм обозначит, в каких блоках, что должно быть, просто берём
и фигачим. Грубо говоря задача оптимизирована и решена чисто алгоритмически. И отработает,
скорее всего, намного быстрее, чем озвученный способ с дефолтным маппингом, по принципу массива
как показывал Замабувараев. Про GDI и GDI+ совместно с маппингами вообще ничего сказать не могу,
не баловался, может там вообще страшная жопа, тут сугубо тестировать надо, особенно на таких объёмах,
новые винды вообще дерьмово работают с GDI, может легко оказаться, что софт быстрее в плане линий
и кружочков.

Сообщение от The trick Так принцип должен быть такой чтобы это было выгоднее использовать чем маппинги. А если выгоды нет то смысл?

Выгода есть, и где она зарыта озвучил.

Сообщение от The trick Все. Задача решена.

Да шикарно. Осталось понять зачем геху файл. И почему просто не сделать массив примитивов
и не выводить их с прокруткой мышкой. Эврика...)))

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

Сообщение от Pro_grammer Итого, в вашей отражённой памяти с моего HDD в DDR4 в 250 раз больше занято памяти, чем взято на исходном HDD!

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

0

Сообщение от Quiet Snow А твою не отправит? Или оператива на твой маппинг из воздуха возьмётся? Жжёшь!

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

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

Что ты мне рассказываешь? Мне не нужно об этом рассказывать.Ты ответь на вопрос который я задал, а ты как всегда ушел от ответа.

Сообщение от Quiet Snow DOS многому учит, экономить, выискивать любые средства, чтобы сделать с минимальными затратами ресурсов.

Судя по тому что ты написал это не так.

Сообщение от Quiet Snow И отработает, скорее всего, намного быстрее, чем озвученный способ с дефолтным маппингом

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

Сообщение от Quiet Snow Выгода есть, и где она зарыта озвучил.

Странно это, читая твои посты нигде нельзя увидеть эти преимущества.

Добавлено через 10 минут
Кстати еще добавлю что данную задачу можно решить вообще без всяких ухищрений и выделений огромного количества виртуальной памяти, основываясь на том алгоритме что я написал, только вместо файл-маппинга использовать просто небольшой регион виртуальной памяти, отрисовывать в него также как я написал выше, сохранять в PNG в памяти маленький кусок изображения. После сохранения в PNG выдернуть IDAT чанк и добавить его в выходной файл. Поскольку PNG позволяет хранить множество IDAT чанков то файл в итоге будет правильным. Т.е. если касаться чисто того варианта что Замабувараев озвучил изначально, никаких терабайтов памяти не нужно (ну за исключением выходного файла который будет весить не терабайты, но все-равно много).

0

Сообщение от The trick Когда ты делаешь какой-либо утверждение то оно должно быть основано на чем-то кроме твоих слов и заблуждений

Ну тогда лучше ничего больше писать не буду. И так бошка болит. Напоретесь так напоретесь.

0

Написал небольшой тестовый проект по алгоритму который описал, правда рисует не фрактал, а просто окружности, но это неважно т.к. можно легко заменить, просто не хотелось тратить время еще на анализ и кластеризацию кусков.
Кстати GDI+ не поддерживает сохранение PNG больше 65535 пикселей, пришлось выбрать libpng. Удалось сделать изображение 100000 х 100000 пикселей (ушло около 15 минут) получился файл размером 187МБ:

, для изображния 1000000 х 1000000 уйдет в среднем где-то в 100 раз больше. Фотошоп так и не смог у меня отобразить этот файл, создал на SSD файл в 39ГБ, что-то писал туда-сюда, мне надоело ждать я прибил процесс. Основное время занимает сжатие в PNG - отрисовка идет довольно быстро, так что если использовать обычный raw то можно намного быстрее отрисовать. Программа не содержит проверок ошибок и т.п., только самые базовые. Для буфера выделяется около 500МБ и программа работает с таким куском. Для компиляции и работы нужен вот этот мой фикс для VB6 т.к. libpng С-либа.

Вложения

BigPicture.zip (148.6 Кб, 12 просмотров)

1

Сообщение от The trick Удалось сделать изображение 100000 х 100000 пикселей (ушло около 15 минут) получился файл размером 187МБ

Пример интересный, но в контексте Qbasic и DOS бессмысленная трата времени и ресурсов.
Вот так выглядит изображение в Qbasic
Вложение 1224964
PNG формат поддерживает 1 бит палитру. Экономия памяти существенная, приведу различия между 24 бит

и 1 бит


Для размера 10000х10000 пикс соотношение текущего объема памяти 12МБ против 286МБ

0

Pro_grammer, сделал 1bpp

Вложения

test.zip (937.0 Кб, 24 просмотров)

2