Victor_VG
Tracker Mod | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
zivstack
Вы ошибаетесь принимая размер программы на диске за используемый ей объём оперативной памяти ЭВМ - это разные, а главное не связанные между собой понятия. Программа может быть неограниченно большой, но написанной с применением динамической загрузки фрагментов кода (оверлеем) и занимать небольшой объём памяти - её резидентная часть будет подгружать в специальное оверлейное окно нужные сегменты по мере работы. Например так устроены IBM OS/360 SVC Type 2 и 4 - эти модули ядра имеют встроенный резидентный модуль который подгружает в небольшое по размеру окно (1 Kb) оверлейные страницы что позволяет использовать достаточно объёмный код с меньшими требованиями к объёму ОЗУ, а не оверлейные SVC Type 1 и 3 полностью грузятся в ОЗУ. Зато компактность в памяти оверлейной структуры оборачивается необходимостью постоянного чтения в ОЗУ новых страниц кода по мере исполнения предыдущих и меньшей производительностью чем обычной структуры в которой весь необходимый алгоритму код сразу загружается в ОЗУ.
Так же требования к ОЗУ зависят и от принципа организации работы программы - повторно-входовая (реенфлешная) которая может изменять свою копию в ОЗУ в период исполнения, но восстанавливает её первоначальный вид перед завершением алгоритма и в каждый момент времени допускает использование загруженной копии только одним заданием, или параллельно-входовая (реентерабельная) допускающая одновременное использование одной загруженной копии не ограниченным числом задач, но не допускающая изменений загруженной копии в процессе исполнения, но допускающая наличие динамически изменяемого в рабочих буферах кода. При необходимости динамического изменения исполняемого кода реентерабельная программа копирует свои изменяемые фрагменты в выделяемые ОС буфера в ОЗУ и по мере исполнения своего алгоритма освобождают их.
Самая эффективная из всех существующих структур это реентерабельная, но она и самая ресурсо-затратная, а значит даже если у нас будет компактный во внешней памяти машинный код, но программа размером R используется N задач под каждую из которых требуется буфер размером М ей потребуется N*M+R ячеек памяти зато в ОЗУ у нас будет только одна её копия которой пользуются все, реенфлешная значительно экономнее R+M но либо пока одна задача использует загруженный образ остальные ждут его освобождения, либо каждая использует его собственную копию в ОЗУ, и меньше всего ОЗУ использует оверлейной имеющей размер резидентного модуля К и размер оверлейного окна W и буфер управления оверлеем В - K+2W+B так как обычно для снижения негативного эффекта медленной внешней памяти используется схема с двумя динамически переключаемыми окнами - в одном идёт исполнение загруженной страницы, а в другое подгружается следующая.
А суммарные требования к размеру ОЗУ нужной программам и ОС определяются арифметической суммой используемых ими объёмов памяти, и если у нас будет установлено меньше физического ОЗУ чем эта величина, то часть задач будет ждать освобождения ресурсов, а значит суммарная производительность ЭВМ снизится и среднее время решения задач возрастёт.
И у вас возникла именно такая ситуация - хост ОС требует для своей работы некий минимум ОЗУ, вы устанавливаете прикладную программу требующую свой объём ОЗУ, но она обрабатывает объёмные данные, а значит ей нужна память для их хранения, но объём установленной в машине памяти ограничен и много меньше суммарно необходимого, что и вызывает проблемы.
И в такой ситуации есть только одно решение - установка дополнительных модулей ОЗУ. А как оценить эти требования? Довольно просто - мы с вами учтём, что основная ОС исполняет прикладную задачу (в нашем случае VB), а сколько ОЗУ требуется ОС мы знаем - примерно это её минимальные системные требования делённые пополам, для программы мы так же знаем что ей нужно минимум от ... ОЗУ, и мы смотрим какую задачу она будет решать? - запускать другую копию ОС, но и та будет выполнять какие-то прикладные программы ибо нам не интересно просто видеть её рабочее окно пока она стоит и ждёт наших приказов что ей делать - так мы можем и на рисунок любоваться. Хорошо, берём требуемые цифры из характеристик нашей математики, суммируем и видим что нам минимально нужно. Сможем обеспечить больше? Лучше, нет придётся дольше ждать получения результатов счёта.
И как видите ничего сложного тут нет, просто мы подошли к задаче не от абстрактных цифр, а от понимания её природы, ну а дальше простая арифметика да и мы видим чего нам ждать от нашей установки и как при необходимости сократить время получения конечного результата...
----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti |
|
Хотя да, нонче говорят думать и учится грех смертный, а Митрофанушки из "Горя от ума" в особом почёте.