Миф: как IBM победил БЭСМ

[zVlad]

oткрывает что никакой "современной полностью виртуальной памаыти" там не было. Была виртуальная адресация памяти и только. Иначе говоря размер виртуальной памяти совпадал с размером реальной памяти.

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

Совершенно верно. Системы с виртуальной памятью больше реальной только и имеют смысл для многопользовательских применений.

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

Тут не в моем согласии дело. Просто так обстоят дела на самом деле.

Пользовательская программа может запросить много памяти, но использовать лишь часть ее. В системах с виртуальной памятью (в современном, общепринятом понимании) это не вызывает проблем поскольку страницы виртуальной памяти материализуются не в момент запроса а в момент актуального обрашения к ним. Поэтому в z/OS параметр REGION, который изначально имел смысл величины необходимой для программы памяти может быть закодирован как REGION=0M (или 0K, 0G и т.п.) что на деле означает дать столько памяти сколько понадобится. Такая возможность естественно стала доступной с имплементацией виртуальной памяти.

Есть еще параметр "рабочий набор", или "Work Set". Это размер памяти реально использованной за некий период времени до текущего момента. Используется планировщиком для оценки количества процессов которое можно позволить диспетчировать на CPU не вызывая излишнего страничного обмена. Параметр динамичный и для одного и того выполнения программы (процесса) может быть разным в разное время.

[oshibka_residenta]

. А вот с возможностью для одного процесса пользовать больше памяти, чем физически есть в системе, можно разве что затормозить всю систему в ноль и убить внешние носители.

Это, конечно, не так. OS - это сервис. Не дело OS решать за меня. А то дело дойдет до того, что мне в ресторане официанты начнут указывать сколько еды заказывать ( салат и суп вы уже взяли, мы решили, что брать второе для вас не имеет смысла - это замедлит пищеварение).
Если пользовательский хочет больше памяти - надо ее дать. Может у меня структуры данных не влазят в память. То что там что-то замедлится - ну вот когда замедлится, то пусть прикладные инженеры и разбираются что и как оптимизировать.

[iDesperado]

Это, конечно, не так. OS - это сервис. Не дело OS решать за меня. А то дело дойдет до того, что мне в ресторане официанты начнут указывать сколько еды заказывать ( салат и суп вы уже взяли, мы решили, что брать второе для вас не имеет смысла - это замедлит пищеварение).
Если пользовательский хочет больше памяти - надо ее дать. Может у меня структуры данных не влазят в память. То что там что-то замедлится - ну вот когда замедлится, то пусть прикладные инженеры и разбираются что и как оптимизировать.

действительно безобразие. лентяи не реализовали своп на перфокарты

[oshibka_residenta]

действительно безобразие. лентяи не реализовали своп на перфокарты

Думаю, и на перфокарты можно сделать.

[helg]

. А вот с возможностью для одного процесса пользовать больше памяти, чем физически есть в системе, можно разве что затормозить всю систему в ноль и убить внешние носители.

Это, конечно, не так. OS - это сервис. Не дело OS решать за меня. А то дело дойдет до того, что мне в ресторане официанты начнут указывать сколько еды заказывать ( салат и суп вы уже взяли, мы решили, что брать второе для вас не имеет смысла - это замедлит пищеварение).
Если пользовательский хочет больше памяти - надо ее дать. Может у меня структуры данных не влазят в память. То что там что-то замедлится - ну вот когда замедлится, то пусть прикладные инженеры и разбираются что и как оптимизировать.

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

В аналогии с едой. Вы регулярно заказываете пиццу и платите 20. А тут заказали две, надеясь заплатить 40. А вам вместо этого выкатили счёт в 10,000.

[ARARAT.]

Я вот сейчас и работаю на дочке VAX OpenVMS, т.е. тот самый МФ который вы обсуждаете...

[zVlad]

Я вот сейчас и работаю на дочке VAX OpenVMS, т.е. тот самый МФ который вы обсуждаете...

Нет, не тот самый. Мэйнфрэйм - это специфически IBM-ский термин. Была там у них такая главная рама, которую они по английски называли main frame. Кроме того этот термин стал отражать любые системы построенные не по распределенному, а по централизованному принципу построения. И по аналогии с IBM mainframe их стали тоже так называть, но это не правильно, правильно их называть централизованные системы. Тогда в этот термин попадут и Vax-ы и IBM mainframe и будет меньше путаницы.

Спасибо за понимание.

[ARARAT.]

Я вот сейчас и работаю на дочке VAX OpenVMS, т.е. тот самый МФ который вы обсуждаете...

Нет, не тот самый. Мэйнфрэйм - это специфически IBM-цкий термин. Была там у них такая главная рама, которую они по английски называли main frame. Кроме того этот термин стал отражать любые системы построенные не по распределенному, а по централизованному принципу построения. И по аналогии с IBM mainframe их стали тоже так называть, но это не правильно, правильно их называть централизованные системы. Тогда в этот термин попадут и Vax-ы и IBM mainframe и будет меньше путаницы.

Спасибо за понимание.

Блин, вы на самом деле уже придираетесь, я просто по приколу высказался...

[Palych]

Нет, не тот самый. Мэйнфрэйм - это специфически IBM-цкий термин. Была там у них такая главная рама, которую они по английски называли main frame.

Кстати, как-то наткнулся на неожиданное значение этого слова:
http://en.wikipedia.org/wiki/Main_distribution_frame

In telephony, a main distribution frame (MDF or main frame) is a signal distribution frame for connecting equipment (inside plant) to cables and subscriber carrier equipment (outside plant).

[Oleg-NY]

Такую структуру я не постесняюсь назвать системой. А набор интерфэйсов типа "байт туда байт сюда" системой называться не может.

ИМХО, тут, вообще говоря, вы не совсем правы. Точнее вы абсолютно правы если рассматривать только один процессор, но выше упоминалось, что архитектура БЭСМ изначально кластерная, а раз так, то все то же самое (разделение ролей) можно реализовать в более гибком виде и всего-то нужно, правильно написать ОС. Простая масштабируемость по-любому лучше, чем спец. устройства для того, еще более спец. для другого... Так, что кластеры это - всем системам система!

[Dmitry67]

Я вот сейчас и работаю на дочке VAX OpenVMS, т.е. тот самый МФ который вы обсуждаете...

Они живы???

[Dmitry67]

Такую структуру я не постесняюсь назвать системой. А набор интерфэйсов типа "байт туда байт сюда" системой называться не может.

На самом деле вы оба правы
Действительно, никакого геройства в выковыривании плат из более умного устройства для подключения к тупому интерфейсу нет
С другой стороны, СМ aka PDP11 работала с терминалами по принципу "байт туда байт сюда", и к нагрузки процессора это давало крохи, тормоза тым были в чем угодно, только не в этом. Более того, учитывая WYSIWYG editors, которые рисуют чтото после каждого нажатия на клавишу, интеллектуальность и вовсе бесмысленна.

[zVlad]

Я вот сейчас и работаю на дочке VAX OpenVMS, т.е. тот самый МФ который вы обсуждаете...

Нет, не тот самый. Мэйнфрэйм - это специфически IBM-цкий термин. Была там у них такая главная рама, которую они по английски называли main frame. Кроме того этот термин стал отражать любые системы построенные не по распределенному, а по централизованному принципу построения. И по аналогии с IBM mainframe их стали тоже так называть, но это не правильно, правильно их называть централизованные системы. Тогда в этот термин попадут и Vax-ы и IBM mainframe и будет меньше путаницы.

Спасибо за понимание.

Блин, вы на самом деле уже придираетесь, я просто по приколу высказался...

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

[zVlad]

Такую структуру я не постесняюсь назвать системой. А набор интерфэйсов типа "байт туда байт сюда" системой называться не может.

ИМХО, тут, вообще говоря, вы не совсем правы. Точнее вы абсолютно правы если рассматривать только один процессор, но выше упоминалось, что архитектура БЭСМ изначально кластерная, а раз так, то все то же самое (разделение ролей) можно реализовать в более гибком виде и всего-то нужно, правильно написать ОС. Простая масштабируемость по-любому лучше, чем спец. устройства для того, еще более спец. для другого... Так, что кластеры это - всем системам система!

Строго говоря не с самого начала. Да и называлось это не кластер, а многомашинный комплекс - “Эльбрус-1-К2”.

Про разделение ролей не понял намека. А спец устройства вовсе не мешают масштабировать. И в самом деле, общее поле дисков в ИБМ архитектуре было реализованно с самых ранних шагов (я подозревают даже это было в еще до-мэйнфрэймовкое время). Устройства управления, как правило, имели больше одного входа для подключения к каналу. Таким образом имелась возможность подключать одну и ту же дисковую подсистему к более одного канала. Позже поялись так называемые директоры, сегодня их называют свитчи. Директоры позволяли подключать все каналы всех MF с одной стороны и все устройства с другой позволяя тем самым строить сколь угодно сложные конфигурации. Директора могли соединяться друг с другом на каких угодно расстояниях, тем самым и географически распределенные конфигурации имеют место быть в IBM MF, причем это все было лет 25 назад, а то и больше.

[Oleg-NY]

Строго говоря не с самого начала. Да и называлось это не кластер, а многомашинный комплекс - “Эльбрус-1-К2”.

Про разделение ролей не понял намека. А спец устройства вовсе не мешают масштабировать.

Сразу признаюсь, что я скорее теоретизирую тут, ибо родился (как программист) чуть позже, чем умер БЭСМ...

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