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

[ALV00]

Да нет же. Прогресс идет в сторону переноса нагрузки на софтвер. Если вспомнить все мини и микро пошедшие в те времена, то там это тоже было заметно.

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

Ну эволюция софта это отдельная тема. Речь идет о железе. Оно постоянно усложняется. Сейчас вся периферия умная стала, со своими контроллерами. Некоторая даже понимает языки высокого уровня, принтеры, например. Все становится более абстрактным, автономным, асинхронным.

[ALV00]

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

А как же самые популярные персоналки от IBM? Неудивительно, что там как раз железо много чего делало. Контроллер клавиатуры, контроллер прерываний, аппаратный знакогенератор, DMA, аппаратный таймер. Поэтому юзабилити его было высоким. Можно было молотить по клавишам с любой скоростью и символы не пропадали, потому что за это отдельная железяка отвечала. Кстати, как с этим было в БЭСМ?

[Dmitry67]

А кто расскажет от себя про Эльбрус? Вики читал, интересна отсебятина )

[StrangerR]

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

А как же самые популярные персоналки от IBM? Неудивительно, что там как раз железо много чего делало. Контроллер клавиатуры, контроллер прерываний, аппаратный знакогенератор, DMA, аппаратный таймер. Поэтому юзабилити его было высоким. Можно было молотить по клавишам с любой скоростью и символы не пропадали, потому что за это отдельная железяка отвечала. Кстати, как с этим было в БЭСМ?

Да так же, ничего не пропадало. ДМА там было, для блоковых устройств.

А Эльбрус... ой, это отдельная тема. Вокруг него столько анекдотов из жизни, что хоть падай. Язык высокого уровня назывался Автокод Эль-76 (или Эльбрус, но кажется именно Эль-76). Причина - ну военные написали в ТЗ что _нужен автокод_, на компе вообще не быо языка ассемблера, ну авторы и сделали паскле-подобный язык но назвать пришлось Автокод. Левая и Правая стойки управления вводом выводом (левая и правая, чтобы ставить можно было к стенке), размеры - ну в длину метров по моему 6, в толщину с метр, в высоту 2 метра, контроллер ввода - вывода назывался. Процессор Передачи Данных - блин, со странным языком управления, который народ программировал накатав макросы на Бэмше по названиям команд ПДД - запускали этот код на бэмше, он генеорил код для бэсма, запускали код на бэсме, он генерил код для ПДД.

В общем, Эльбрус-1 это было нечто. Дело в том что Мельникова и его команду отодвинули аппаратными играми, и придвинули Бурцева, того самого который автор ЭВМ для ПВО с лентами под потолком и лесенкой к ним. Он и сотворил это убожество, точнее архитектурно оно было интереснвым но исполнение - полным убожищем, куда там ЕС до него. Потом уже сотворили Эльбрус-2 который хотя бы технически уже смотрелся сносно и контроллеры ввода вывода загнали из 10 метрового шкафа в не очнеь большую (всего в пару раков размером) стойку. Но там были архитектурные заморочки. Слово 72 бита включая таги. В нем 64 бита информации и 8 тагов. Вопрос - а на диск как писать будем, с тегами или без? Если без то как же подкачка-откачка. Если с тегами то как же с записью для переноса на другие платформы и как же быть с секьюрити при чтении - что делать с тегами если читаем постороннюю ленты. В общем там было очень много непродуманного. При мне Валера Бардин рассказывал, как на семинаре у Бабаяна задавал ехидные вопросы
- Бабаян: у нас впервые реализована динамическая загрузка библиотек
- Валера: ну вообще то она была реализована еще в Бэсм-4, в ИС-22 подсистеме.

Ну и так во всем. Умная команда но решившая все сделать инновационным способом и потому словившая все грабли что только можно было словить. На аппаратном уровне - микросхемы с водяным охлаждением. Вопрос - а что бывает если холодную пластину поместить на воздух? Ответ - она отпотеет. Поэтому залы приходилось кондиционировать особым образом. Ну и так далее и тому подобное. Там по требования вояк прикрутили как раз те самые ИБМ совместиыме терминалы, и их как же все матерились (на Эльбрус-1КБ кажется уже можно было нормальные видеотоны подключать). История про апгрейд фирмваре методом 10 тыс перепаек паяльнитком тоже оттуда же.

[Dmitry67]

А что означали тэги?

[StrangerR]

Тип данных в слове. Команда, строка, ссылка, целое, плавающее, и так далее (я не уверен в точном смысле). Вы просто читали переменную A, если там сидела ссылка на функцию, то вызывалась функция, а если целое то вам выдавалось это целое. И так далее.

http://oboguev.livejournal.com/1365372.html

[zVlad]

Вот только вопрос, стоит ли называть VAX мейнфреймом? У меня вакс стоял на столе, размером с современную PC

Дeло вовсе не в размерах, а в принципах работы и целевом назначении. ИБМ мэйнфраме сразу позиционировались как устройства для централизованной, комплексной нагрузки. Первые МФ занимали залы, нынче это один юнит (или два если используется гетерогенная архитектура). Есть эмуляторы МФ на лаптопах, функционально идентичные полноценному МФ. Качество, надежность, производительность конечно не те, но для целей разработки ПО вполне себе МФ.

[zVlad]

Кстати, на Vax Vms в мое время не было threads, только "большие" процессы. Может потом доделали.

На МФ не было и нет threads, но есть деление на "большие" и "маленькие" процессы. A threads в ПС и Юникс серверах это не прогресc, а способ затыкание некоторых дыр в архитектуре. Дыр, которых не было и нет у МФ, и возможно на VAX (последние я не знаю толком, поэтому лишь предполагаю).

[zVlad]

....Мой контраргумент состит в том, что все зависит от точки зрения и что выделенный для этой задачи БЭСМ (не важно статически или динамически) из кластера выглядит для остальных не меньшей системой и не в пример более гибкой и универсальной. Кстати, у канала в МФ был тогда прямой доступ в память (что-то типа DMA)?

Это DMA что-то типа того что имеется в архитектуре MF, причем имеется с тех пор когда такого термина DMA прост и не было еще. Для МФ прямой доступ к памяти каналов, а позже и всех процессоров был и естью частью принципов его работы. Многозадачность в IBM mainframe понимается в том смысле что когда задача обратившаяся к вводу-выводу становится не активной CPU может переключиться на другую задачу и ему в это ничто не мешает, типа того что память недоступна.
В конфигурации современного МФ может быть до 101-го (число взятое практически с потолка, на самом деле процессоров для 101 цпу-шного МФ больше будет), и сотни каналов ввода-вывода.

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

Кластер у МФ имеет теже свойства, только не для одной задачи, а если хотите для всей ИТ инфраструктуры скажем предприятия, компании и т.п.. Такие кластера главным образом создают не для масштабируемости (поскольку маштабируемость даже одного МФ настолько широка что привлечение многих МФ совершенно не необходимо), а для сервисабилиты, т.е. возможности останавливать узлы один за другим для сервиса главным образом ОС, а не железа и если таковой требуется.

... но можно рассмотреть аппаратный кластер, где все ресурсы одинаково доступны всем процессорам. В таком случае, чисто программно, можно виртуализировать функцию ввода/вывода с выделением для этого (статически или динамически) конкретного процессора и это будет выглядеть для остальных задач в системе как не менее интеллектуальный контроллер ("канал").

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

Чем это принципиально отличается от сервера виртуальных машин в той или иной современной реализации? Хотите сказать только-только догнали МФ? Ну да, но догнали же...
Однако мы отклонились от темы. Насколько я помню здесь сравниваюст IBM 360 и БЭСМ в момент их противостояния.

Это принципиально отличается от сервера виртуальных машин. Начнем с того что виртуальные машины на МФ работают с 1972-го года (а виртуальные машины на Intel serverax и RISC это начало 2000-x, т.е. отстование почти 30 лет. Причем VM на МФ на месте все время не стоял конечно. Так что догнать это не возможно просто.). Но этот подход серьезно уступает тому что позволяет z/OS. При этом z/OS с подсистемами в нем можно рассматривать как сервер виртуальных машин с одной стороны, а с другой стороны, благодоря WLM (Work Load Manager) вся эта сосвокупность ВМ может управлятся из единого центра для достижения общих целей (targets). В случае кластера (SysPlex) работает для всех узлов в комплексе. А в случае гетерогенной архитектуры WLM управляет не только OS на MF, но и Windows, Юникс на блэйд центре(ах).

[zVlad]

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

А как же самые популярные персоналки от IBM? Неудивительно, что там как раз железо много чего делало. Контроллер клавиатуры, контроллер прерываний, аппаратный знакогенератор, DMA, аппаратный таймер. Поэтому юзабилити его было высоким. Можно было молотить по клавишам с любой скоростью и символы не пропадали, потому что за это отдельная железяка отвечала. Кстати, как с этим было в БЭСМ?

Все верно, и все это IBM понимал из своего опыта разработки и использования MF. На машинах IBM PS/2 был и так называемый micro-channel - подобие канала MF.
В нынешних IBM-вских RISC севрерах много заимствований от MF. CPU MF и CPU для AIX (RISC) серверов разрабатывается совместно, у них единая база, но все таки есть и много различий, просто CPU для AIX не имеет таких требований как CPU для MF.

[tengiz]

A threads в ПС и Юникс серверах это не прогресc, а способ затыкание некоторых дыр в архитектуре. Дыр, которых не было и нет у МФ, и возможно на VAX (последние я не знаю толком, поэтому лишь предполагаю).

А о каких дырах идет речь, уточните, если не сложно?

[Medium-rare]

О, потоки, то вовсе заговор затыкателей дыр. :-p

[Dmitry67]

A threads в ПС и Юникс серверах это не прогресc, а способ затыкание некоторых дыр в архитектуре. Дыр, которых не было и нет у МФ, и возможно на VAX (последние я не знаю толком, поэтому лишь предполагаю).

А о каких дырах идет речь, уточните, если не сложно?

Присоединяюсь к вопросу

Отсутствие threads приводило к тому что аппликации не могли перерисовывать экран в то время как они думали. Этот эффект был виден воочию на DECwindows, ну и разумеется все на Windows тоже прекрасно помнят такие программы на Windows 3.11, 95 и даже позже.

Сейчас, конечно, zVlad скажет что это не нужно (ну раз не было на IBM). Конечно, для алфавитно цифровых терминалов не нужно было
А для нормальной нужно.
А сейчас threads на z/OS конечно есть, в виртуалках

P.S.
Кстати меня всегда интересовал вопрос, является ли стандартный подход к перерисовке, основанный на threads, правильным в глобальном смысле. То есть чисто экономически это всегда делается так, но манипулирование всеми этими thread safe объектами это ходьба по минному полю, как голые malloc/free. Если запускать спутник, вероятно лучше набор "больших" процессов, обменивающихся сообщениями? С другой стороны я смотрю, threads вроде даже в Ada добавили...

[Palych]

Threads это как демократия: ужасная вещь, но к сожалению пока незаменимая.
Хотя попытки предпринимаются...

[zVlad]

A threads в ПС и Юникс серверах это не прогресc, а способ затыкание некоторых дыр в архитектуре. Дыр, которых не было и нет у МФ, и возможно на VAX (последние я не знаю толком, поэтому лишь предполагаю).

А о каких дырах идет речь, уточните, если не сложно?

Нет, конечно, не сложно, а для Вас, tengiz, это даже за честь можно признать.

Это swaping, или вытиснение задач называется. Для MF это, скажем так, легкая операция, раз-два и сделали, а вот для Intel и RISC архитектур это всегда была и видимо есть тяжелая операция. Вот и придумали threads - хардверную поддрежку. А МФ это не нужно проблемы такой нет и решение ее не нужно.
Но если копать глубже то можно узнать что до определенного времени на МФ основным блоком для управления задачами был TCB - Task Control Block, а потом, в эпоху Web приложений и remote access к DB2 появился облегченный SRB - Service Request Block - или ответ на вызов времени когда количество запросов к системе стало не прогнозируемым и неуправляемым.

Я по памяти пишу, могу в чем то быть и не совсем в точку, поскольку сам я программировал еще в до SRB и Web технологий временах. Но в общем и целом не могу я сильно ошибаться. Если хотите можем покопать вместе, глубже. Я критики не боюсь и могу запросто признавать свои ошибки. Ваш ход, если хотите.

Если коротко подитожить то то что решается аппаратными средства в виде threads на Intel и RISC на МФ решается программно. Парадокс до сих я был против програмных решений против аппатных а теперь получается наоборот. Но видимо так движутся звезды. Кстати, не исключено что SRB, да даже наверняка, имеет и хардверную поддержку, в виде команф CPU которые сокращают пути управления современными вызовами для IT.

S/360 я знал полностью и в целом, S/370 тоже знал хорошо и даже писал программы на Ассемблер без особого труда. Нынешний же МФ я знаю только по верхам, тем чтo совпaдают с тем что было и еще немного. Там столько всякого что надо быть очeнь узким специалистом чтобы это понимать (в последнем сeмействе MF добавилось около ста новых команд процессора). И таких, кто это понимает полностью, в мире - единицы. Не верите? Попробуйте сами.

[Palych]

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

[Dmitry67]

Сорри, zVlad, прочтите что такое threads

[zVlad]

A threads в ПС и Юникс серверах это не прогресc, а способ затыкание некоторых дыр в архитектуре. Дыр, которых не было и нет у МФ, и возможно на VAX (последние я не знаю толком, поэтому лишь предполагаю).

А о каких дырах идет речь, уточните, если не сложно?

Присоединяюсь к вопросу

Отсутствие threads приводило к тому что аппликации не могли перерисовывать экран в то время как они думали. Этот эффект был виден воочию на DECwindows, ну и разумеется все на Windows тоже прекрасно помнят такие программы на Windows 3.11, 95 и даже позже.

Сейчас, конечно, zVlad скажет что это не нужно (ну раз не было на IBM). Конечно, для алфавитно цифровых терминалов не нужно было
А для нормальной нужно.
А сейчас threads на z/OS конечно есть, в виртуалках

P.S.
Кстати меня всегда интересовал вопрос, является ли стандартный подход к перерисовке, основанный на threads, правильным в глобальном смысле. То есть чисто экономически это всегда делается так, но манипулирование всеми этими thread safe объектами это ходьба по минному полю, как голые malloc/free. Если запускать спутник, вероятно лучше набор "больших" процессов, обменивающихся сообщениями? С другой стороны я смотрю, threads вроде даже в Ada добавили...

Мой ответ будет краток (на самом деле я тайпал длинный ответ но, либо я что-то нажал не то на моем лаптопе, либо "Привет" глюкнул, и, как это не редко бывает мой текст пропал, а переписывать я не люблю) и этот ответ состоит из одного ключевого слова - "GDDM" наберите его в Google и Вы все сами поймете.

Для тех кому лень делать поиск и читать я скажу что 3270 - это вовсе не только алфавитно-цифровой терминал, это семейство терминалов в котором были и графические устройства до того как появились ПК. Тем неменне я вовсе не считаю что надо делать здесь "back in USSR" и возвращаться к семейству 3270, но знать это надo всем кто хочет считаться грамотными специалистами по компютерам. И еще хороше бы знать что IBM придумали IBM PC как устройство эмулирующeе терминалы 3270 - все семейство, а не только алфавитно-цифровой вариант о котором только и знают выходцы из СССР, вроде тебя, Дима. Но получилось иначе... так уж получилось.

[zVlad]

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

А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?

[zVlad]

Сорри, zVlad, прочтите что такое threads

Дайте Вашу любимую ссылку - с удовольствием еще раз почитаю. Только не уверен что я узнаю что-то новое,но если узнаю обязательно Вам расскажу. OK?

[Palych]

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

А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?

Потому что это слово многозначное.

[zVlad]

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

А почему же тогда в списке параметров неких процессоров приводится число этих самых threads?

Потому что это слово многозначное.

Я привык к однозначным определениям. Многозначные я называю - лукавство, до тех пор пока мне не дадут однозначное определение.

[tengiz]

Это swaping, или вытиснение задач называется. Для MF это, скажем так, легкая операция, раз-два и сделали, а вот для Intel и RISC архитектур это всегда была и видимо есть тяжелая операция. Вот и придумали threads - хардверную поддрежку.

Я понял, что Вы имеете в виду. Я не уверен насчет конкретных процессоров, попадающих в категорию RISC, но для продукции Sun и для популярных ОС, работающих на интеле начиная с 386, такой проблемы нет. Переключение между "процессами" и "потоками" (или "нитями" или "легкими процессами") стоит примерно одинаково. Нужно, правда, иметь в виду, что в разных ОС смысл этих слов немного отличается, поэтому может быть путаница. Также у интел имеются аппаратные "недопотоки" (хотя называются они hyperthreads) причина появления которых - недозагруженность конвейеров физических процессоров (а теперь - ядер), при этом при подходящей загрузке это действительно дает выйгрыш. Но это не имело отношения к тяжести переключения "процессов" против переключения "потоков".

Чтобы еще усложнить дело, есть также "легкие потоки", в разных ОС называемые по-разному ("волокна"-fibers, user-more threads, etc.), вот они в чистом виде являются софтверными сущностями, которые не требуют особой аппаратной поддержки и действительно могут переключаться намного дешевле, чем настоящие "потоки" или "процессы" и единственная причина их существования - это избежать дорогого переключения между "настоящими потоками" внутри одного "процесса", однако программировать на них намного сложнее, чем на "настоящих потоках". Но если это делать с умом, выйгрыш по производительности можно получить очень даже материальный.

[Dmitry67]

Да, согласен, действительно слово столь многозначное что мы говорили о разных вещах.

Кстати, когда то попробовал в ms sql "fibers". Разницы не почувствовал, разве что перестали работать distributed transactions

[StrangerR]

Threads это как демократия: ужасная вещь, но к сожалению пока незаменимая.
Хотя попытки предпринимаются...

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

Все начиналось с процессов. Потом появилась общая память. Потом оказалось что можно иметь общим все кроме стека выполнения - треда. Потом по моему еще появились облегченные треды. В целом же все что можно сделать на тредах можно сделать и на процессах имея shared memory (можно и не имея но гемморнее).