Hex Editor Neo - [1] :: Программы :: Компьютерный форум Ru.Board

Jaroslave

Согласен, более того, сам хотел продолжить разговор. Ваш стиль мышления мне нравится и вас бы в нам группу когда мы в создавали массово-параллельные вычислительные комплексы в середине 80-х. Но это сейчас не главное, а интереснее иное - а почему это решение неудачное?

Давайте смотреть - каналов доступа к памяти у нас сколько? Обычно один, значит вся нагрузка I/O ляжет на него. Вот и давайте смотреть смысл того что мы имеем. А имеем мы следующее: верхняя граница физически доступного 32-х битным процессам ОЗУ определяется не лицензией, а тем, как чипсет распределит адреса I/O устройств, но т.к. для 32-х битных процессов доступно только 32 бита адреса, что и даст нам адресное пространство в 2³²=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, а если совмещённое адресное пространство? Что это даст? А это приведёт уже к падению производительности системы в целом поскольку мы ограничены сверху нижней границей адресного пространства портов ввода-вывода оборудования, а так же требованиями к памяти ОС и приложений, и в такой ситуации наличие задействованного под каталог для хранения временных данных (попросту системного мусора) адресного пространства приводит к необходимости вытеснения большего числа фрагментов памяти в файл подкачки скорость доступа к которому ниже, а при его отсутствии к ограничению возможности комплекса по работе с ресурсоёмкими приложениями. Но в обоих случаях производительность ЭВМ как комплекса в целом снижается.

Решение об использовании части оперативной памяти в качестве электронного диска принимает пользователь, но с учётом того, что было сказано выше относительно производительности ЭВМ. А что касается показаний бенчмарков скорости чтения/записи при оценке скоростей ОЗУ и других типов памяти, то с учётом произведённого выше анализа они не объективны и показывают скорость чтения-записи ОЗУ, а главное что применяемая в них модель тестирования не совпадает с моделью работы ОС и приложений с памятью, а потому их нельзя использовать для оценки производительности комплекса т.к. эти данные дают ложную оценку быстродействия системы.

----------
Жив курилка! (Р. Ролан, "Кола Брюньон")
Xeon E5 2697v2/C602/128 GB PC3-14900L/GTX 1660 Ti, Xeon E5-2697v2/C602J/128 Gb PC3-14900L/GTX 1660 Ti

Вы очень точно описали модель возможного использования памяти но справедливого для компьютеров порядка ~ 10 летней давности. Вся ваша модель основана на одном постулате что быстрой ОЗУ у нас критично мало. По сути вы описали схему работы NT4-5 с памятью, но эти ОС вышли последняя XP в 2003 году. При сегодняшних скоростях и объеме, причем и каналов доступа давно как минимум 2 одновременно на чтение и запись, DDR уже давно повсеместно применяется, мы получаем возможность отойти от вашей модели и пытаться более эффективно использовать сегодняшний объем ОЗУ.
Ограничение ОС по работе с объемом ОЗУ именно связанно с лицензированием. Я ведь не говорю что именно прямой адресации, для нее действительно 4Гб для процессора в режиме 32 предел. Но вы сами описали давно используемый прием сегментной адресации, таже EMS в DOS, и NT32bit с удовольствием работают с объемом ОЗУ в 128ГБ. Мелкософт их называет Server interprase x86 и хочет за нее совсем другие деньги, это чистый воды маркетинг, потому в обычной XP32 она удалила поддержку больших объемов памяти. Кроме того в 32-битной NT максимальный размер файла подкачки равен 16 Тб.
Это возможно потому что NT использует виртуальное выделение памяти, следовательно механизм для использования большего чем возможно при прямой адресации объема памяти имеется изначально.

Дальше давайте рассмотрим момент когда у нас ОЗУ больше чем программа 32 битная может получить в свое управление. Виртуально ана может получить хоть 16 Tб, а вот реальной ОЗУ система больше 2 Гб или максимум 3ГБ если программа скомпилирована с флагом large_address получить не может, следовательно свободную память к которой программа в любом случае не получит доступа можно использовать для ускорения работы самой программы или системы. Создав RAMDISK и поместив на него часто используемые данные. Кроме того используя своп если он необходим приложению поскольку 2ГБ ОЗУ ее может не устроить и она может просить больше виртуальной памяти то тут как раз может получится момент когда в свап фаил будут помешаться данные которые потребуются уже на следующем запросе данных, т.е. по сути в своп буду помещаться не редко используемые данные а из за ограничения системой в 2 ГБ в своп могут попадать текущие необходимые для расчетов данные.
Дальше момент если своп находится на каком либо магнитном источнике то сильно скажется на быстродействие дефрагментация в нутри самого свап файла и доступ к одному сегменту виртуальной памяти может сильно замедлятся из за физ.ограничений для магнитных носителей, поскольку он будет разбит на многие фрагменты. Тут выгодно могут помочь SSD но они имеют свой недостаток, ограниченное кол-во циклов чтения-запись что при использовании их как носители свап-файла приведет к быстрому их износу.

Отсюда видно что использование излишек ОЗУ в качестве RAM диска и помещении на него данных используемых для частого чтения-записи и свап-файла может значительно ускорить работу всей системы и прикладной программы в частности. Просто из опыта использования скажу что не надо проводить никаких тестов чтоб найти разницу с RAMdisk и без, потому что она видна на глаз и выражается в разах а не процентах. А так же чисто из опыта, программное обеспечение даже ресурсоемкие для крупных вычислений нагружающие систему расчетами на часы и дни обходятся 2ГБ ОЗУ и как правило не имеют флаг large_address и не просят больше виртуальной памяти. Потому свап всегда пустой не используется, точней в нем всегда 8 мегов занято системой и все, так же иногда система начинала увеличивать сам фаил свопа хотя использование его не растет, все теже системные 8 мегобайт в нем лежат. По этому я и вообще отключил при том что как я писал раньше при загрузки происходит глюк, искать причину которого мне не интересно. Для того чтобы при синем окне смерти система выполнила малый дамп памяти достаточно было держать на ramdisk свап-фаил на 32 мегабайта.
Сам мини-дамп естественно сохранялся на системном диске являющимся обычным магнитным хардом.

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

Модерирует : gyra, Maz
Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7