Jaroslave Согласен, более того, сам хотел продолжить разговор. Ваш стиль мышления мне нравится и вас бы в нам группу когда мы в создавали массово-параллельные вычислительные комплексы в середине 80-х. Но это сейчас не главное, а интереснее иное - а почему это решение неудачное?
Давайте смотреть - каналов доступа к памяти у нас сколько? Обычно один, значит вся нагрузка I/O ляжет на него. Вот и давайте смотреть смысл того что мы имеем. А имеем мы следующее: верхняя граница физически доступного 32-х битным процессам ОЗУ определяется не лицензией, а тем, как чипсет распределит адреса I/O устройств, но т.к. для 32-х битных процессов доступно только 32 бита адреса, что и даст нам адресное пространство в 232=4 Гб на которое в архитектуре с совмещённым адресным пространством, а в ЦП х86 использована она, мы должны отобразить всё - и адреса оборудования и адреса ОЗУ. В других ЦП, к примеру nVAX, Alpha AXP, DEC F-11/J-11, AMD Am29xx, IBM 360/370, БЭСМ-6, Эльбрус-1/2 используется иная архитектура - с разделёнными адресами памяти и I/O. Вот там мы с вами можем использовать всю ёмкость ОЗУ для работы, и ограничения характерного для архитектур с общим адресным пространством мы не увидим. Да, часть адресов мы с вами выделим под системные нужды, но доступный для прикладных задач объём памяти для той же математики станет больше.
Так что с эти я думаю мы разобрались, поехали дальше. Давайте с моделью памяти разбираться. Что, зачем и что делает?
Вот тут у нас и возникает иерархическая модель памяти, эдакое дерево: самый верхний уровень - быстрая память работающая на скорости АЛУ (Арифметика-Логического Устройства - именно оно непосредственно выполняет операции над данными), но т.к. данные имеют небольшой разброс адресов относительно адреса текущей машинной команды, то объём этой сверхбыстрой памяти можно сделать не столь большим - лишнее. Пошли дальше смотреть. Нам нужно расположить в памяти исполняемый код и обрабатываемые данные. Значит нужна оперативная память объёмом достаточным для их размещения, и достаточно быстрая чтобы АЛУ не простаивало в то время когда данные в СОЗУ будут обработаны, а потому мы ставим столько ОЗУ сколько нужно, а верхний предел его объёма накладывается разрядностью адресной шины ЦП. Но если небольшие задачи полностью размещаются в ОЗУ, то большие нет. Как быть? Увеличить объём ОЗУ мы конечно можем, но ведь у нас ограничена разрядность адресной шины, значит нужно искать решение. И оно есть - сегментная адресация. Принцип прост - адресное пространство делится на блоки адресуемые по двум координатам - адресу сегмента и смещению внутри него. Всё, задача решена, а управление выбором сегментов ложится на ОС, в то время как программа может использовать объём памяти больший чем ограничен шиной, но в пределах возможностей адресации ЦП как системы.
Я в 89-м решал такую задачу для 32-х битных ЦП DEC F-11/J-11 - у них 22-х битная адресная шина, а надо было адресовать не четыре, а тридцать два Мб памяти. Что делать? А у этих ЦП адресное пространство разделённое, значит можно организовать сегментную адресацию через младшие адреса шины ввода-вывода, но нужна дополнительная логика адресной дешифрации. Сделал, не проблема, и задача была решена одной ПЛМ и несколькими корпусами серии 74ABT, ну а нашим программистам пришлось попотеть привыкая к мысли о том, что память адресуется через пространство ввода/вывода. Ворчали, и крепко, но привыкли.
Машинка сия после лет пятнадцать над шариком в космосе крутилась.
Надо было - решили задачу.
Смотрим дальше, вроде с ОЗУ разобрались, но если у нас задача выходит за его размеры как тут быть? А просто - смотрим а каким временем мы располагаем? И исходя из этого делим код на фрагменты и те, к которым нужно минимальное время доступа поместим в СОЗУ, другие в ОЗУ, а третьи, к которым мы можем увеличить время доступа вынесем в более ёмкую, но более медленную внешнюю память. Главное соблюдение условия "Основной ресурс ЭВМ это время АЛУ, и его потери нужно исключить", значит решаем задачу баланса "Потери времени АЛУ, соотношение времени доступа и скорости памяти".
Вопрос - а при чём тут своп? Очень просто - это область внешней памяти в которую мы копируем те фрагменты ОЗУ которые в данный момент не используются АЛУ или данные в которых сейчас нельзя обработать, либо там код ждёт данные чтобы освободить место для того кода и данных которые сейчас нужны для АЛУ. Но, т.к. это пространство для ненужных фрагментов ОЗУ, то смысла помещать его там нет, это не увеличит производительность ЭВМ, а наоборот, снизит её производительность из-за того, что часть пропускной способности ОЗУ будет задействована на обслуживание бессмысленной перекачки фрагментов памяти.
Ладно, с подкачкой понятно, с временными каталогами? Может их туда закинуть? С ними проще, там вроде интенсивность процессов ввода-вывода не велика, объекты там просто хранятся какое-то время, но к ним не нужна высокая скорость доступа, т.к. в большинстве своём это либо резервные копии, либо служебные данные ОС выполняющие роль флажков для обработчиков событий. Но ведь эти данные занимают ОЗУ, и для обращения к ним используется тот же канал памяти, но если интенсивность этих обращений не велика, то она частично нивелирует его влияние на производительность системы в целом при условии что эти данные расположены вне границ адресного пространства доступного прикладным программам, но доступ со стороны средств ОС к ним нужен, значит нужен некий инструмент трансляции адресов. Если у нас используется архитектура с разделением адресных пространств, тут всё ясно - адресацию такого логического тома можно сделать через пространство I/O, а если совмещённое адресное пространство? Что это даст? А это приведёт уже к падению производительности системы в целом поскольку мы ограничены сверху нижней границей адресного пространства портов ввода-вывода оборудования, а так же требованиями к памяти ОС и приложений, и в такой ситуации наличие задействованного под каталог для хранения временных данных (попросту системного мусора) адресного пространства приводит к необходимости вытеснения большего числа фрагментов памяти в файл подкачки скорость доступа к которому ниже, а при его отсутствии к ограничению возможности комплекса по работе с ресурсоёмкими приложениями. Но в обоих случаях производительность ЭВМ как комплекса в целом снижается.
Решение об использовании части оперативной памяти в качестве электронного диска принимает пользователь, но с учётом того, что было сказано выше относительно производительности ЭВМ. А что касается показаний бенчмарков скорости чтения/записи при оценке скоростей ОЗУ и других типов памяти, то с учётом произведённого выше анализа они не объективны и показывают скорость чтения-записи ОЗУ, а главное что применяемая в них модель тестирования не совпадает с моделью работы ОС и приложений с памятью, а потому их нельзя использовать для оценки производительности комплекса т.к. эти данные дают ложную оценку быстродействия системы.
