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

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

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

0

Сообщение от The trick Только файл маппинг пишет данные по требованию + прозрачно

А выгружает тоже прозрачно?

Сообщение от The trick К примеру нужно мне равномерно по всему 100ГБ АП изменить данные - мне требуется только пиать/читать и если RAM хватает мой хард вообще не будет тронут.

Ну как он не будет тронут, где ты будешь хранить 100Гб информации?
Её же надо хранить, если ты её пишешь Подумай ё маё...

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

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

Сообщение от The trick Ну это ты беспокоишься о хардах

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

0

Сообщение от The trick Функции GDI/GDI+ не поддерживают работу с такими изображениями

Но ведь именно о картинке шла речь Как нарисовать 40 соприкасающихся окружностей?
Если виртуальная память не позволяет работать с большой картинкой, то смысл ее обсуждать?

1

Сообщение от locm Но ведь именно о картинке шла речь

А PNG, ЖИпег или TIFF почему не рассматриваются? Это не картинки?

0

Сообщение от Замабувараев А PNG, ЖИпег или TIFF почему не рассматриваются?

Можете создать одну из перечисленных типов картинок размером миллион на миллион точек, нарисовать на ней фрактал и сохранить в файл?

1

Сообщение от The trick Умнее ты никак не сделаешь.

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

Сообщение от The trick Какую страницу ты запросишь - такую и загрузит.

То про что говоришь лишь уменьшает объёмы работы с диском, в случае когда работа идёт
с одними и теми же адресами. Но оно не учитывает то, как диск будет рваться на части,
когда запросы пойдут на разные адреса. SSD в этом плане хорош, но его ресурс конечен
и большая их часть - дешёвые на 120 гигов. Заняв объём в 100 гигов, мы сознательно
лишим диск приличного ресурса.

Сообщение от The trick только при чем тут маппинги

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

Сообщение от Замабувараев А PNG, ЖИпег или TIFF почему не рассматриваются? Это не картинки?

PNG - сильно долго энкодится, Jpeg вроде побыстрее, но не сильно. Можно по потокам раскидать.
Для хранения - в самый раз. Как один из вариантов оптимизации критически важного ресурса задачи.

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

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

1000000 * 1000000 = 1 000 000 000 000 пикселей = 931,322 Гб, если на пиксель по 1 байту

Это страшные объёмы. Я обычно пол дня это просто форматирую.

0

Сообщение от Quiet Snow 1000000 * 1000000 = 1 000 000 000 000 пикселей = 931,322 Гб, если на пиксель по 1 байту

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

1

Сообщение от Quiet Snow А выгружает тоже прозрачно?

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

Сообщение от Quiet Snow Ну как он не будет тронут, где ты будешь хранить 100Гб информации? Её же надо хранить, если ты её пишешь Подумай ё маё...

Я тебя не понимаю. Есть 100ГБ область памяти, нужно к примеру через каждый ГБ записать 1000 байт данных. Я пишу. Файл не будет тронут. Вопросы?

Сообщение от Quiet Snow Конечно беспокоюсь, я сам на хардах и не собираюсь с них слезать.

Ну а почему тебя тогда не смущает накладные расходы с буферизацией?
Вот тебе небольшая информация про маппинги:

One advantage to using MMF I/O is that the system performs all data transfers for it in 4K pages of data. Internally all pages of memory are managed by the virtual-memory manager (VMM). It decides when a page should be paged to disk, which pages are to be freed for use by other applications, and how many pages each application can have out of the entire allotment of physical memory. Since the VMM performs all disk I/O in the same manner—reading or writing memory one page at a time—it has been optimized to make it as fast as possible. Limiting the disk read and write instructions to sequences of 4K pages means that several smaller reads or writes are effectively cached into one larger operation, reducing the number of times the hard disk read/write head moves. Reading and writing pages of memory at a time is sometimes referred to as paging and is common to virtual-memory management operating systems. Another advantage to using MMF I/O is that all of the actual I/O interaction now occurs in RAM in the form of standard memory addressing. Meanwhile, disk paging occurs periodically in the background, transparent to the application. While no gain in performance is observed when using MMFs for simply reading a file into RAM, other disk transactions can benefit immensely. Say, for example, an application implements a flat-file database file structure, where the database consists of hundreds of sequential records. Accessing a record within the file is simply a matter of determining the record's location (a byte offset within the file) and reading the data from the file. Then, for every update, the record must be written to the file in order to save the change. For larger records, it may be advantageous to read only part of the record into memory at a time as needed. Unfortunately, though, each time a new part of the record is needed, another file read is required. The MMF approach works a little differently. When the record is first accessed, the entire 4K page(s) of memory containing the record is read into memory. All subsequent accesses to that record deal directly with the page(s) of memory in RAM. No disk I/O is required or enforced until the file is later closed or flushed.

0

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

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

Сообщение от The trick One advantage to using MMF I/O is that the system performs all data transfers for it in 4K pages of data. Internally all pages of memory are managed by the virtual-memory manager (VMM). It decides when a page should be paged to disk, which pages are to be freed for use by other applications, and how many pages each application can have out of the entire allotment of physical memory. Since the VMM performs all disk I/O in the same manner—reading or writing memory one page at a time—it has been optimized to make it as fast as possible. Limiting the disk read and write instructions to sequences of 4K pages means that several smaller reads or writes are effectively cached into one larger operation, reducing the number of times the hard disk read/write head moves. Reading and writing pages of memory at a time is sometimes referred to as paging and is common to virtual-memory management operating systems. Another advantage to using MMF I/O is that all of the actual I/O interaction now occurs in RAM in the form of standard memory addressing. Meanwhile, disk paging occurs periodically in the background, transparent to the application. While no gain in performance is observed when using MMFs for simply reading a file into RAM, other disk transactions can benefit immensely. Say, for example, an application implements a flat-file database file structure, where the database consists of hundreds of sequential records. Accessing a record within the file is simply a matter of determining the record's location (a byte offset within the file) and reading the data from the file. Then, for every update, the record must be written to the file in order to save the change. For larger records, it may be advantageous to read only part of the record into memory at a time as needed. Unfortunately, though, each time a new part of the record is needed, another file read is required. The MMF approach works a little differently. When the record is first accessed, the entire 4K page(s) of memory containing the record is read into memory. All subsequent accesses to that record deal directly with the page(s) of memory in RAM. No disk I/O is required or enforced until the file is later closed or flushed.

Тут враньё по поводу качества оптимизации. Эта роль возложена на драйвер диска и его аппаратный контроллер
и этого, мягко говоря, не хватает. Проверяется банально, запусти свой своп на диске C:\ запусти архиватор,
чтобы он распаковывал гигабайт 10 с диска C:\ на диск C:\ чтобы там было много файлов, например half-life 2 распакуй
там тысяч 50 файлов))). Сначала запусти по отдельности то и то, и потом запусти вместе оба процесса.
Увидишь разницу во времени. Эта разница и есть те огромные накладные расходы про которые пишу.

Сообщение от The trick Я тебя не понимаю. Есть 100ГБ область памяти, нужно к примеру через каждый ГБ записать 1000 байт данных. Я пишу. Файл не будет тронут. Вопросы?

Вопросы следующие:
1) А если запись, рандомом по всему массиву?
2) А если 0, 4096, 8192, 12228 и так до конца, тоже запись, потом смещаемся на единицу и опять до конца?
3) Последовательный прогон записи, а потом обращения в начало записи, в конец записи, в начало записи,
в конец записи.

И всё это на каком-нибудь двухъядернике на 2000\XP со стареньким диском.

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

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

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

0

Сообщение от locm Но ведь именно о картинке шла речь Как нарисовать 40 соприкасающихся окружностей? Если виртуальная память не позволяет работать с большой картинкой, то смысл ее обсуждать?

О картинке, но не о BMP файле. Картинка может быть в любом формате, в самом простом случае RAW. Виртуальная память как раз-таки и позволяет.

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

Да. Уже даже написал как, средствами GDI, GDI+ это делается легко.

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

Ну так и выгружай маппинги хоть по 10ГБ сразу. В чем проблема? По-твоему как работает тоже самое чтение/запись в файл в винде? В большинстве случаях файл кешируется и куски файла также отображаются в память. Даже приведу цитату из книги Руссиновича:

Если VACB указатель для считываемой части файла пуст, CcCopyRead создает VACB, резервируя в виртуальном адресном пространстве диспетчера кэша 256 килобайтное представление, и проецирует на это представление указанную порцию файла (с помощью MmMapViewInSystemCache).

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

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

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

Ну никто не говорил что это решение всех вопросов. У нас есть конкретная задача.

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

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

Ну что в этом случае поделать? Не понимаешь, изучай. Мне предельно ясно все.

Сообщение от Quiet Snow Тут враньё по поводу качества оптимизации. Эта роль возложена на драйвер диска и его аппаратный контроллер и этого, мягко говоря, не хватает. Проверяется банально, запусти свой своп на диске C:\ запусти архиватор, чтобы он распаковывал гигабайт 10 с диска C:\ на диск C:\ чтобы там было много файлов, например half-life 2 распакуй там тысяч 50 файлов))). Сначала запусти по отдельности то и то, и потом запусти вместе оба процесса. Увидишь разницу во времени. Эта разница и есть те огромные накладные расходы про которые пишу.

Даже не буду отвечать на это. Можешь и дальше отрицать как и Pro_grammer, вещи от этого другими не станут.

Сообщение от Quiet Snow Вопросы следующие: 1) А если запись, рандомом по всему массиву? 2) А если 0, 4096, 8192, 12228 и так до конца, тоже запись, потом смещаемся на единицу и опять до конца? 3) Последовательный прогон записи, а потом обращения в начало записи, в конец записи, в начало записи, в конец записи.

1) Страницы будут подгружаться по мере надобности, при нехватки рабочего набора, давно неиспользуемые страницы будут выгружены в файл-маппинг;
2) Страницы будут подгружаться по мере надобности, при нехватки рабочего набора, давно неиспользуемые страницы будут выгружены в файл-маппинг;
3) Страницы будут подгружаться по мере надобности, при нехватки рабочего набора, давно неиспользуемые страницы будут выгружены в файл-маппинг;
Намного больше действий и манипуляций с диском будет происходить если все это делать через обычный файловый ввод/вывод. Так что тут никаких преимуществ твой способ также не имеет.

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

Ну да, ну да. Придумывать костыли со "своей архитектурой" которую никто не видел, а слышал только ее название - не геморно.

0

Сообщение от The trick Ну да, ну да. Придумывать костыли со "своей архитектурой" которую никто не видел, а слышал только ее название - не геморно.

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

Сообщение от The trick Даже не буду отвечать на это.

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

А я вот отвечу.
1) После заполнения рабочего набора, начнётся выгрузка и загрузка, и т.к. система не экстрасенс,
она будет делать именно то, что ты пишешь "подгружаться по мере надобности", просто надобность
будет постоянная и 100Гб не влезет ни в какой кэш ни в аппаратный ни в системный.
2) Можно долго предполагать, что пользователю вдруг потребовался массив в 100Гб ради того чтобы
едва ли по нему пробежаться. Но это не так. Если даже взять то что обсуждают тут. Огромный BMP файл,
он организован построчно, и если его потребуется заполнять попиксельно в разных местах - будет всё то,
про что пишу. Если представить энкодер, который с такими задачами мол справится, мы получаем
жуткую картину, он читает много файлов картинок, из которых лепили общую, так вот мало того что,
каждый файл будет дёргать диск, так ещё это и большая фрагментация, а учитывая все эти стандартные
8x8 блоки, осознаем что для блока придётся прочитать 8 строк(а они могут быть[и будут] очень большими),
далее сработает кэш по всем ост. болокам, потом ещё 8 строк, и так до тех пор пока память не будет
забита, после чего начнётся жопа. Диск будет колбаситься между загрузкой исходника, выгрузкой строк,
загрузкой новых (причём по одной и это будет жёстко) и соотв. сохранением файла тоже немаленького
на тот же диск.
3) После заполнения оперативной памяти будет то, что ты нам показал в своей проге, ровно до того
момента, когда начнутся не особо предсказуемые обращения и если адреса этих обращений будут сильно
разниться не образуя предсказуемую структуру - начнётся расколбас головки диска.

Сообщение от The trick Придумывать костыли со "своей архитектурой" которую никто не видел, а слышал только ее название - не геморно.

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

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

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

Сообщение от The trick У нас есть конкретная задача.

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

Сообщение от The trick Ну что в этом случае поделать? Не понимаешь, изучай. Мне предельно ясно все.

Ну мне тоже всё ясно. Чудес то не бывает. Виртуальная память не панацея.
Штука для специфических узконаправленных задач, БД, HEX редакторы и сходный софт.
Где надо сильно не шурша по памяти, быстро переместиться и записать\считать кусок.

0

Сообщение от Quiet Snow Штука для специфических узконаправленных задач

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

0

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

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

Что это меняет на физическом уровне? Есть HDD с файлом, есть DDR4 без файла.
Как отображает без физического прочтения файла?

0

Сообщение от Pro_grammer без физического прочтения файла

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

0

Сообщение от Замабувараев как вы при ReadFile сделаете разделяемую между процессами память?

А с чего вы взяли что exe читается ReadFile?

0

Сообщение от Pro_grammer А с чего вы взяли что exe читается ReadFile?

Я так не считаю.
Более того, Я только что объяснил, как исполняемый код попадает в память на выполнение.

0

Сообщение от Замабувараев Я так не считаю.

Тогда откуда у вас взялся этот вопрос?

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

0

Сообщение от Pro_grammer Тогда откуда у вас взялся этот вопрос?

Потому что Я разместил по разным углам два типа попадание байтов в память: через отображение и через ReadFile.

0

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

Для чего? Вроде это был ваш ответ Quiet Snow, но он не упомянул ReadFile.
Вы пытаетесь навязать ему неверное мнение, чтобы потом его разоблачить?

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

0

Сообщение от Pro_grammer чтобы потом его разоблачить?

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

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

Сообщение от Pro_grammer ёрзание головок диска над поверхностью магнитного диска, что очень замедляет процесс

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

0

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

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

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

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

Сообщение от Quiet Snow Геморно конечно, страшный гемор, просто от этого будет толк.

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

Сообщение от Quiet Snow Ты говорил что маппинг и подкачка работают одинаково, хорошо, мой пример с браузером идеально подходит, берём комп с 2 гигами оперативы, обычным HDD небольшого размера, ставим файл подкачки 16 Гб(для верности) и открываем 70-80 вкладок полностью забитых миниатюрами картинок, прям листаем каждую вкладку до конца, чтобы как можно больше миниатюр попало в память(само собой аппаратное ускорение должно быть отключено чтобы видеопамять не участвовала). Можно это делать на голой чистой винде, без софта в тепличных условиях, чтобы не дай бог ничего не помешало. И когда активно пойдёт своп, продолжать работать. Вот тогда то реалии и застигнут в расплох эту идеологию. Мне интересно сколько вкладок у тебя получится открыть и можно ли будет назвать это действо "работой" за компом, к моменту полного заполнения виртуальной памяти, да даже половины.

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

Сообщение от Quiet Snow Проблеме уже не один и даже не два десятка лет, а люди не видели.

Все знают о недостатках/преимуществах свопинга. Давай оставим эту тему. Я с тобой обсуждаю не это.

Сообщение от Quiet Snow это мы так обсуждаем просто.

Ну это вы с locm'ом мне тут про картинки пишите. Я вообще изначально писал про лимиты ВП и пример сделал касательно лимитов.

Сообщение от Quiet Snow Виртуальная память не панацея.

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

Сообщение от Pro_grammer Что это меняет на физическом уровне? Есть HDD с файлом, есть DDR4 без файла. Как отображает без физического прочтения файла?

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

0