[ezup]

CDC 6200

По скорости БЭСМ-6 в те годы тоже была уже не фонтан, за время с 1960 года компьютеры ушли далеко вперед, пришлось искать решение и этой проблемы. СССР второй раз проглотил гордость и пошел просить продать ему еще и CDC 6600. Здесь КоКом уже уперся рогом, причем обидели они не только Союз, ни один CDC 6600 не был поставлен никому за пределами США, отказали даже Франции. Только в 1972 году КоКом разрешил (и то под своим строгим надзором) установить в Дубне младшую версию CDC 6200, которая была в 1975 (уже устаревшая после выхода Cray-1) проапгрейжена до многопроцессорной 6500, а флагман – 6600, так и остался чисто американским монстром.

Вот как вспоминает об этом Г. Ососков (Газета «Дубна», № 21 (3759) от 27 мая 2005 года)

В 1967 году в рамках контракта на закупку ЭВМ CDC-1604 я был послан в ФРГ вместе с инженерами А. Карловым и В. Миролюбовым для обучения в европейском центре фирмы CDC во Франкфурте-на-Майне. После изучения операционной системы ЭВМ и программирования на языке фортран я еще два месяца стажировался в работе оператора CDC-1604 в Ганновере. В итоге год проработал старшим математиком CDC-1604 после установки этой ЭВМ в ЛВТА и вдобавок выучил разговорный английский. В 1969–1970 и 1973 гг. в ЦЕРН занимался изучением системы программ управления и калибровки сканирующего автомата Spiral Reader, аналогичного тому, что разрабатывался в ЛВТА. В 1972 году вместе с заместителем директора ЛВТА Г. И. Забиякиным мы были в двухнедельной командировке в США по приглашению фирмы CDC. Посетили ВЦ БНЛ, участвовали в конференции пользователей CDC в Дулусе, посетили штаб-квартиру CDC и завод, где производились новейшие в то время ЭВМ CDC-7600, в Миннеаполисе, а также вычислительные центры университета Беркли и Ливерморской лаборатории, оснащенные машинами фирмы CDC. В том числе нам показали и знаменитую в то время ЭВМ CDC-Star. На меня, однако, наибольшее впечатление произвели возможности компьютерной сети CYBERNET, объединившей для одновременной работы в пакетном режиме 49 машин фирмы CDC по всей Америке.
Большинство пользовательских докладов на конференции в Дулусе было посвящено обсуждению возможностей и недостатков работы этой сети. Сейчас, 30 лет спустя, такие возможности кажутся обычными, но в то время это выглядело достаточно фантастично. Главной целью поездки было заключение контрактов на покупку ЭВМ CDC-6200 в обход печально известного соглашения КОКОМ, направленного на запрет поставки в соцстраны новейших компьютерных технологий. Согласившись на постоянную инспекцию КОКОМ в Дубне, дирекция ЛВТА в 1972 году добилась разрешения на покупку CDC-6200. Такие машины серии 6000 относились к мощным вычислителям, для них существовало много прикладных программ в библиотеке ЦЕРН, и, хотя 6200 была уже достаточно устаревшей, но такая покупка позволила ЛВТА в 1974 году развить машину до CDC-6400, а на следующий год и до многопроцессорной CDC-6500. Вместе с БЭСМ-6 это резко увеличило вычислительные мощности ОИЯИ, дало возможность создать разветвленную терминальную сеть и запустить фортранные станции.

Самое забавное в этой истории то, что машины с индексом CDC 6200 никогда не существовало в природе! Она не была выпущена компанией CDC и не встречается ни в одном западном источнике!

Что же это такое?

Очень просто – компания Крэя нуждалась в новых партнерах, бизнес – это хорошо, но CoCom ни в какую не соглашался поставить Советам даже младший суперкомпьютер – 6500. Тогда инженеры CDC демонтировали с него один процессор, сделали прочий даунгрейд и получили уникальный огрызок – CDC 6200 специально для СССР в единственном экземпляре. Огрызок им продать разрешили, а через несколько лет, когда линейка устарела и была снята с производства, CoCom разрешил прикрутить процессор обратно.

Аналогичная история повторилась затем с CDC 7600 и Cray-1, купить их не удалось, а попытка создать клон в виде «Электроника СС БИС» феноменально провалилась, зато удалось легально купить еще два CDC, модели попроще, CYBER 170 и 172.

CYBER 172 был закуплен в 1975 году для Гидрометцентра СССР и успешно работал там до 1996 года. Вообще, изучение климата было чрезвычайно важно для СССР в связи с огромной площадью страны и потребностями судоходства и землепользования, так что в Гидрометцентре стояли одни из самых мощных машин Союза, не уступающие Дубне и Арзамасу-16, причем обычно использовалось сразу несколько машин. Первой ЭВМ для метеорологов стала М-20, отработавшая там с 1959 по 1962 год, ее выкинули спустя всего три года, и неудивительно.

Вспоминает директор ГВЦ Владимир Анципович, работавший там более 40 лет:

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

Ее сменили М-220, затем М-222 и «Весна», довольно экзотический большой компьютер, производительностью 300 KIPS, созданный в 1965 году в КБ промышленной автоматики Минрадиопрома (как видите, несмотря на БЭСМ-6, прочие министерства продолжали увлечено играть в зоопарк архитектур).

Эта машина проработала в Гидрометцентре до 1972 года, параллельно с вершиной чисто советских мейнфреймов – «Минск-32». Также с 1968 года по 1985 там работала и БЭСМ-6.

CYBER-172 был в ГВЦ первым иностранцем (именно для метеорологов в 1975 хотели купить CDC 7600, но обломались об CoCom), и с него началось доминирование западных суперкомпьютеров в советской метеорологии. Вообще, их хотели купить два, но CoCom и тут подложил свинью, решили, что два таких для СССР слишком жирно.

Естественно, там стояли и ЕС 1060 и 1066, а также IBM 3033 – новейшая замена линейки S/370, вышел в 1979 году, правда, для конспирации его называли Hitachi (впрочем, там мутная история – то ли наши купили его лицензионный клон от Hitachi, то ли оригинальный IBM, но обозвали так в целях большей таинственности, во всяком случае, машина «Hitachi 3033» в природе не существует, имеется лишь Hitachi HITAC M-220 или IBM 3033).

В 1992 году уже хотели поставить многострадальный «Эльбрус-2», но тут внезапно CoCom одобрил продажу России мощнейшего Cray Y-MP, превосходящего «Эльбрус» примерно в 30 раз. Пока обсуждали все подробности – установка сдвинулась на 1996 год и из Тор 500 Cray Y-MP уже выпал.

Этот монстр проработал в ГВЦ 10 лет непрерывно, до 2006 года, когда благополучно скончался на боевом посту. Во многом это связано с тем, что спустя три года после установки по финансовым причинам пришлось продолжать использование Cray Y-MP без поддержки со стороны производителя. Рассказывает Анцыпович:

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

Затем появились два кластера – SGI Alltix 4700 (11 Тфлопс 832 Intel Itanium 2 9140М) и SGI Alltix ICE (16 Тфлопс, неизвестное число Intel Xeon E5440), а в 2019 власть раскошелилась на новый кластер от Cray – XC40.

CYBER 170 был куплен в 1976 году для лаборатории ЛНИВЦ АН СССР при ЛИАН, ныне СПИИ РАН. Судьба машины Гидрометцентра автору неизвестна, а останки машины ЛИАН он видел своими глазами в здании СПИИ РАН на Васильевском острове, попасть туда сложно, но не невозможно, сотрудники отличаются большим дружелюбием и, если заранее созваниваться и договариваться – с удовольствием проведут небольшую экскурсию, так что у живущих в СПб есть хороший шанс прикоснуться к истории.

CDC CYBER-170 из СПИИ РАН, точнее его останки. Фото автора.

Для решения проблемы с недостатком вычислительной мощности к 1973 году Мельников разработал т. н. аппаратуру сопряжения, комплекс АС-6, фактически сложный программируемый коммутатор с дополнительной памятью и сопроцессорами, позволяющий объединять несколько БЭСМ-6 и превращать их в кластер с разделяемой ОЗУ. Всего было изготовлено 8 комплектов.

Вопросы


Нам осталось ответить на два вопроса.

Во-первых, чем же была так неудачна системная архитектура БЭСМ-6?

Во-вторых – какие она имела сильные стороны и почему настолько обросла мифами и легендами?

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

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

Кстати, это была общая проблема всех в ИТМиВТ: машины для ракетчиков они еще могли создать, а вот подлинно универсальную ЭВМ – уже с огромным трудом. Бурцев в итоге поимел тех же проблем с «Эльбрусом», взяв за основу вообще банковский мейнфрейм Burroughs и попытавшись переделать его в управляющий компьютер ПРО. Это худо-бедно получилось, а вот удачный суперкомпьютер общего назначения для ученых из «Эльбруса» тоже не вышел.

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

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

В CDC 1604 была, и очень развитая, а из БЭСМ-6 Лебедев ее выбросил, почему?

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

А зачем вообще нужна целочисленная арифметика?

Ответ простой – для манипуляции с адресами в ОЗУ. Как вы уже поняли – и CDC-1604 и БЭСМ-6 были машинами с сумматором (то есть в современной терминологии имели всего два регистра, из которых один выделенный – аккумулятор, в котором и производили все действия). Отчасти это похоже на стековую архитектуру, которую сейчас можно встретить в языках Forth и Java.

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

Кстати, в БЭСМ-6 и CDC было определенное неудобство – разрядность индексных регистров не совпадала с размером слова (!) и размером регистра аккумулятора и даже была некратна ему (15 и 48 бит), что по меркам 1959–1060 годов еще было нормально, но тянуть такую архаику в 1968 год – это уже мрак.

Так вот, естественно, что машины с сумматорами имели довольно развитую целочисленную арифметику именно в силу необходимости каждый такт загружать что-то из ОЗУ или скидывать в нее, Лебедев же эту особенность CDC проигнорировал. В результате каждое вычисление адресов требовало эмуляции на вещественном процессоре, что не влияло позитивно ни на скорость работы, ни на удобство программирования.

Еще одной очень серьезной проблемой БЭСМ-6 стала периферия.

Во-первых, как мы уже говорили, Мельников отказался от канальных процессоров и пояснял это так:

Способ сопряжения внешних устройств, принятый в машине БЭСМ-6, подвергался наибольшим нападкам со стороны критиков этой машины. Действительно, подключение всякого нового устройства требует определенных инженерных доработок в устройстве управления внешними устройствами, и пользователь, сумевший заполучить в свои руки какое-либо «нестандартное» устройство, испытывает большие затруднения с его подсоединением. Кажется, что такому решению нет оправданий, тем более что к моменту разработки БЭСМ-6 фирмой IBM был реализован стандартный интерфейс, снимавший в значительной степени проблему подключения новых устройств и замену одних другими.
Но если внимательно подумать или просто сравнить по стоимости и объему оборудование, необходимое для реализации сопряжения с внешними устройствами в том и другом случае, то решения, принятые в БЭСМ-6, могут оказаться не столь плохими. В самом деле, каждое внешнее устройство для обеспечения стандартного сопряжения имеет в своем составе контроллер или подключено к этому весьма дорогому и сложному устройству, обеспечивающему стандартный выход на мультиплексный или селекторный каналы. Если просуммировать затраты на дополнительное оборудование и занимаемые им площади, необходимые при подключении устройств по стандартному интерфейсу, то окажется, что система БЭСМ-6 многократно экономнее. Иными словами, централизованное устройство управления БЭСМ-6 в несколько раз дешевле, чем стоимость контроллеров стандартного набора внешних запоминающих и вводных/выводных устройств машин аналогичного класса.
Впрочем, в ряде моделей машин IBM был введен так называемый интегрированный адаптер файла, позволяющий подключить к вычислительной машине дисковое запоминающее устройство без использования стандартного канала и контроллера. В этом факте можно усмотреть некоторую аналогию с рациональным способом подключения устройств, принятым в БЭСМ-6.

Переведя на обычный язык, получается следующее – реализовать вменяемую работу с сопроцессорами каналов, как в S/360, нам не хватило денег и желания Лебедева, который фанатично противился введению в свои машины сопроцессоров (идея фикс, оставшаяся с ламповых времен, когда дополнительные пара тысяч советского качества ламп явно не улучшили бы надежность, и овчинка не стоила выделки, Бурцев пропихнул канальные процессоры в 5Э26, чем резко поднял ее производительность, фактически за спиной уже сильно больного Лебедева, которому было тогда не до архитектуры).

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

При этом многие путают разные уровни архитектуры – архитектуру системы команд и системную, описывающую в т. ч. физическое подключение периферии и т. п. С системной архитектурой в БЭСМ-6 все как раз было очень неплохо – машины могли объединяться в сеть, к кластеру до 8 ЭВМ можно было подключить до 128 терминалов, в т. ч. удаленных, кластерный контролер дисков (каждая машина кластера имеет доступ к каждому диску) и т. д. (другое дело, что то же самое в это же время умели и почти все западные ЭВМ такого класса).

Забавным парадоксом является факт, что многие удачные технические решения родились из попыток преодолеть убогость отечественной элементной базы.

Например, прогрессивная технология двойной записи на ленту (даже если блок имеет ошибки, но в двух разных местах, то он соберётся из кусков и нормально прочитается) появилась как ответ на омерзительное качество советской ленты, начинавшей сыпаться буквально после двух-трех прогонов – в ЕС, вслед за IBM, такого механизма не было, в результате возник миф о ненадежности их подсистемы записи на ленты по сравнению с БЭСМ.

При этом в качестве магнитного накопителя использовали не прогрессивные жесткие диски, а устаревший магнитный барабан, контроллеры же для дисков появились только в 1974 году, после того как их скопировали с контроллеров древних мейнфреймов General Electric (к тому времени настолько устаревших, что КоКом без проблем разрешила их продажу официально для нужд КИАЭ и ИТЭФ, неофициально – разобрать на полезные запчасти для БЭСМ-6).

Вообще, об ужасах чисто советской периферии можно написать отдельную книгу, равно как и о ее качестве. В дискуссии о БЭСМ-6 в журнале 1500py470.livejournal, один из работавших с ней программистов оставил такие воспоминания по этому поводу:

Случайно забрел на вашу беседу. Проработал на БЭСМ-6 17 лет. Были две машины № 135 и № 335… Вы хотя бы знаете, что одним из штатных инструментов тестирования и диагностики ошибок работы машины, особенно при плавающей ошибке, был молоток, в виде увесистого металлического цилиндра (весь в насечках, чтобы не выскальзывал из руки при простукивании) со сменными эбонитовыми наконечниками с двух сторон (они менялись по мере износа). У нас машины выключались раз в год. Несложно догадаться – 31 декабря. Так вот, после включения их простукивали все. Память (это 8 сдвоенных шкафов) общей емкостью 128х6Kb (два контрольных разряда не считал), т. е. меньше 1 Мb, а площадь занимала 60–80 м, а то больше. Работали под ОС ДИСПАК, в пакетном режиме процессор обрабатывал 5–10 задач (зависит от того, сколько ест задача), постоянно висела в доступе система КРАБ… Впоследствии 16 кубов ферритов заменили на одну стойку, сделанную на элементной базе ЕС ЭМВ (хоть какая-то от ЕС польза была). Никто не обратил внимания, что тактовую частоту в разных источниках указывают разную, где 9 MГц, а где 10 МГц? Разрабатывали на 10, но элементная база подкачала, сделали 9,1 МГц. Много чего еще можно рассказать. Объединили две машины на общие диски (сначала 7,5 Мб, затем 29 Мб каждый накопитель, диски съемные). Таких дисководов 16. Сделали терминальную сеть через местную АТС, выделенные линии до 500 метров. Терминалы были алфавитно-цифровые, лучшими считались Videoton-340 (Венгрия купила лицензию у IBM на устаревшую модель). Еще лучше были Videoton VDT 52100 на процессорах Intel 8080. Одной из самых серьезных проблем были магнитные барабаны. Если опустить детали, то очень похож на работу HDD, но головки фиксированные, и их сотни (точно не помню). Весь геморрой в том, что зазоры в них выставляются на каждую головку вручную в холодном состоянии, а после того, как этот девайс нагрелся, этого делать нельзя – при разгоне повышенные вибрации и поверхность задиралась (а весил он килограмм 200–250, поэтому в рабочий режим входил несколько часов и остывал почти сутки). Если выключили, то запускать горячий нельзя, надо ждать, пока остынет. Так вот от них мы тоже избавились, поставив память от Электроники. Вместо 16 барабанов – 8 ящичков, одна стойка. Две БЭСМ-6 легко поставили в один зал 200 м, графопостроитель Digi graph подключили. Практически отказались от магнитных лент, перейдя на диски и поставив софт АРФА (архивно-файловая система). Для перекачки программ, написанных на Fortran, подключили РС, поставили Kermit. Пользователи получили свои тексты программ на дискете… К 1975 году нужно было выпускать новую машину этой линейки, учтя недостатки: 15 разрядов в адресной части – это тупик, элементная база полностью устарела, про АЦПУ, УПДК, МЛ и др. периферию и говорить нечего, УЖАС! Энергопотребление запредельное! Обо всех недостатках сразу и не упомнишь, это и к лучшему. А вот паяли и собирали на заводе САМ, криворукие, иногда трезвые, птушники. После них наладчики месяца два вводят ее в эксплуатацию. ВСЕ стойки полностью позванивают, ошибок монтажа – сотни.

Вспоминает начальник сектора ОМОЭД ЛВТА Г. Н. Тентюкова (еженедельник ОИЯИ «Дубна» № 34 (4325) от 11 августа 2016, «Когда машины были большими»):

Вы, наверное, не застали первое устройство ввода перфокарт на БЭСМ-6? Сейчас я вам расскажу, как оно работало. Ставишь колоду. Включаешь. Медленно: чух-чух-чух... Вдруг: тра-та-та! Четыре карты... Это значит, надо вытащить колоду, отсчитать четыре карты от того, что прошло, поставить в начало оставшейся части колоды – и снова нажать пуск. Валя Никитина рассказывала, что во время какого-то международного совещания (БЭСМ-6 только что ввели) Говорун привел в машинный зал иностранцев – похвастаться, какой у нас ВЦ. А Валя, как нарочно, большую колоду поставила. Ну что ты будешь делать! «Четыре карты», «четыре карты»… Валя стоит, краснеет. Ну, ничего, иностранцы народ вежливый: посмотрели, как Валя карты вводит и ушли. Валя говорит: я чуть со стыда не сгорела! А что поделаешь? Мы же не виноваты.

Таких воспоминаний при желании можно найти столько, что не вместит ни одна статья.

Даже сами работники ОИЯИ писали в газете «Дубна» в 1990 году (когда уже можно было не стесняться:

Постоянно шло совершенствование аппаратуры. Группа эксплуатационников под руководством В. В. Федорина и И. А. Емелина, кроме обеспечения бесперебойной работы, сумела удвоить память машины, оснастить ее лучшими по тем временам периферийными устройствами. Перфокарточный ввод и магнитофон фирмы CDC, венгерские терминалы, болгарские магнитофоны и диски, польский принтер, японский плоттер – более разнообразного парка внешних устройств не найдешь нигде. Этот зоопарк высветил застарелую беду отечественной техники: люди у нас умелые, а промышленность – нет!

В общем, нормально работать на БЭСМ-6 стало возможно примерно через 15 лет после выпуска машины – когда самые пробивные товарищи, обладавшие самым тяжелым блатом (как ученые Дубны) повыкидывали на помойку всю периферию от самой БЭСМ (и заодно и от ЕС, она была сильно лучше, но по сравнению с импортом – чудовищным металлоломом) и поставили все американское, японское и немецкое (на худой конец – польское или венгерское).

Кроме этого, было желательно проапгрейдить память, адскими костылями прикрутить нормальные терминалы (на худой конец – от ЕС) и написать самим огромную кучу софта, начиная от трансляторов и заканчивая ОС. Тогда о работе с БЭСМ-6 могли остаться теплые воспоминания.

Вообще, все годы существования Союза в нем категорически не была освоена простая идея – клиент хочет готовый продукт, а не сырой полуфабрикат, который надо допиливать годами. Представьте себе ситуацию – АНБ получает заказанный ими CDC 6600 за десять миллионов долларов, компьютер приезжает без периферии (или с такой, с которой работать невозможно, а если и возможно, то нужно ее полгода подключать с помощью паяльника и известных волшебных слов), без толковой ОС, без компиляторов и с совершенно невменяемым ассемблером.

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

Миф о производительности


Что же касается производительности, существует миф о том, что БЭСМ-6 была невероятно мощной, чуть ли не на уровне CDC 6600. Заявленная производительность БЭСМ-6 – 1 MIPS. В реальности эта информация принципиально несостоятельна, т. к. время выполнения команд могло отличаться на порядок.

Например, теоретическая скорость работы исключительно устройства умножения (УУ) могла действительно достигать значений 1–1,3 MIPS, при этом практическая скорость, когда УУ в процессе интенсивно обращалось к памяти, не превышала 0,5–0,8 MIPS. Команды деления работали со скоростью 0,15–0,3 MIPS, команды же с возвратом данных из АУ в УУ (УИ, МОД и т. п.) могли выдавать вообще все, что угодно, т. к. ждали выполнения 5-ти команд (4-х из БАК и 1 на ПР). При этом цикл памяти БЭСМ-6 равен 2 мкс, то есть, команды, считывающие операнд, которого нет в БРЗ, могли в худшем случае получить +2 мкс к своему времени выполнения.

В 1992 году сотрудники НИВЦ перед списанием БЭСМ-6 сравнивали ее производительность в подсчете бриджевых комбинаций с 286 процессором (реализация от AMD, разогнанная до 16 МГц, против штатных 12) и, по их заверениям, получали примерно равные числа. Производительность же AMD 286 превышала 2,6 MIPS, но мы не знаем, какую версию БЭСМ-6 (скорее всего, «Эльбрус-1К2», на ИС значительно мощнее оригинальной) они использовали.

В книге «От микропроцессоров к персональным ЭВМ» (Черемных C. В., Гиглавый А. В., Поляк Ю. Е., 1988, Радио и связь) приводятся примеры бенчмарка (сложение и умножение массивов в цикле) на разных языках для разных машин и дается время их выполнения. По этой информации, время исполнения теста составило (в зависимости от языка) от 0,08 до 0,23 с для БЭСМ-6 и от 0,11 до 0,38 с для ЕС 1055М, 0,45 с для ДВК (процессор МС 1201.02) и 0,37 с для PC/AT c 16 МГц процессором.

Все эти данные весьма противоречивы, а за неимением рабочей БЭСМ-6 правду выяснить уже не удастся, однако, отметим, что средний результат в случайной задаче в любом случае не превышает 0,8–1,5 MIPS.

Отметим, что такая скорость была достигнута IBM 7030 Stretch на восемь лет раньше, легендарный CDC 6600 подтверждаемо выдавал более 3 MIPS на 4 года раньше, а S/360 старших моделей выдавал те же 0,8–1 MIPS на пару лет раньше.

Таким образом, мы видим, что БЭСМ-6 определенно была бы в числе мировых рекордсменов в 1959–1960 гг., для 1968 же ее параметры не представляли ничего сверхъестественного и были на уровне, стандартном для типичного мейнфрейма, причем еще середины десятилетия. На уровне европейских машин того времени (Siemens, Bull, Olivetti) БЭСМ-6 выглядела нормально, при этом не выдерживая сравнения с CDC (которые были мощнейшими машинами эпохи). S/360 были не хуже – на научных расчетах, и существенно лучше – на финансовых.

Удивляться тут нечему.

Как мы и говорили, БЭСМ-6 не имела поддержки целочисленной арифметики, и значит, любые арифметические команды выполнялись на вещественном сумматоре, а теперь представьте себе удовольствие вычислять адреса через эмуляцию целочисленной арифметики едва ли не каждый такт – машина-то не регистровая, а допотопная, с сумматором, в итоге числа нужно постоянно гонять из ОЗУ в ОЗУ. Это приводило к тому, что даже в самом лучшем случае чтение требовало 3-х тактов, сложение – 5 тактов (в среднем – 11, в худшем – 280), умножение – 15 тактов (в среднем – 18,5, а в худшем – 162), деление в среднем занимало вообще 50 тактов. В результате, программы не только выполнялись медленнее, чем могли бы, но и занимали больше места.

Об этом упоминает и В. В. Пржиялковский в своем обзоре:

Проведенные в ИПМ АН СССР исследования показали, что программы, составленные для IBM S/360, требуют в 1,5–3 раза меньшего объема памяти, чем программы БЭСМ-6, «Весна», М-20».

Если же говорить о производительности в цифрах по популярному тогда тесту Whetstone, БЭСМ-6 набирала примерно 0,3–0,4 миллиона операций с одинарной точностью в секунду, что было на уровне средних моделей IBM.

Еще одной проблемой стала полная непредсказуемость работы по времени. Одна и та же команда могла исполняться за тайминги, отличавшиеся буквально на порядок! По современным меркам это кошмар, да и по меркам 1970-х – не сильно лучше.

В любой системе команд, начиная в 1960-х заранее точно известно, сколько тактов займет то или иное действие, и эти тайминги прописаны во всех руководствах для низкоуровневых программистов. Лебедев же вообще не понимал, зачем нужна хоть какая-то предсказуемость, и даже не старался ее добиться.

В результате в БЭСМ-6 время исполнения гуляет в зависимости от случайных явлений, не только от очевидных – например, попал или не попал адрес в предвыборку, но даже от значения операндов.

Неизвестно, по отношению к какому конкуренту произнес Лебедев приписываемую ему фразу: «Да, быстродействие вашей машины выше, чем у моей, но с учетом низкой надежности она все равно не успеет посчитать задачу в промежуток между двумя поломками!», но многие интерпретируют ее, как доказательство сверхнадежности БЭСМ-6.

Существовало единственное место в мире, где она могла сойтись в честном бою с CDC 6500 – исследовательский ядерный центр в Дубне. Вот результат их битвы: годовой план в часах работы у них совпадал – по 6000 номинально, но в реальности БЭСМ-6 отработала за 1979 год 6910 часов, а CDC 7440 часов. Самое же главное кроется в других цифрах – на машине Лебедева обработали 75 тысяч заданий, на CDC же – почти 200 тысяч…

Существует несколько устойчивых мифов о системной архитектуре БЭСМ-6, один из них – наличие виртуальной памяти.

Эта концепция была впервые воплощена в Atlas, причем там была реализована еще и ассоциативная память для определения присутствия требуемой страницы виртуальной памяти в ОЗУ.

Почему то, что было в БЭСМ-6, ею не является?

Поддержка виртуальной памяти дает возможность адресовать больший объём памяти, чем реально установлен на машине. На БЭСМ-6 в версии с утроенным объемом ОЗУ все было наоборот – физической памяти на машине было доступно больше, чем ее можно было адресовать! Дело в том, что, имея 128 килослов памяти, мы должны были работать с ней через 15-битные адреса (наследие от CDC 1604). Из-за абсолютно противоречивой концепции «сохранить совместимый с CDC 1604 формат адреса, но утроить память», был введен особый костыль – 32 т. н. регистра приписки. Перед обращением к реальной памяти, исполнительный адрес разбивался на две части 5+10 бит. Старшая часть трактовалась как номер регистра приписки, из которого брались 7 разрядов номера физической страницы, и вместе с 10 младшими разрядами адреса они составляли 17-битный физический адрес. Этот режим Лебедев гордо и назвал «виртуальной памятью».

В Atlas адрес изначально был 24-битным, и при попытке адресации за пределы реальной памяти супервизор подкачивал с барабана страницу с соответствующим виртуальным адресом в ОЗУ, примерно так, как это происходит сейчас при подкачке страниц с диска.

Кстати, аналогичная проблема с адресацией существовала и в БЭСМ/БЭСМ-2/М-20/БЭСМ-4, но там все было еще более запущено. В них Лебедев применил свою обожаемую трехадресную систему команд формата КОП | A1 | A2 | A3, где КОП – код операции, А1–А3 адреса.

Почему мы так ругаем этот принцип, внешне-то все красиво?

Дело в том, что каждый адрес мог ссылаться на максимум 4096 слов, больше не влезало в шину, которая и без того была запредельно широкой, ибо по ней надо было пропихнуть три таких адреса и код операции. Но даже первая БЭСМ имела памяти больше!

Как же к ней обратиться?

Для использования всего объема ОЗУ ее делили на т. н. «кубы», для адресации были введены префиксы этих кубов. Косвенная адресация тогда еще не была открыта (в ИТМиВТ, по крайней мере), поэтому программисты писали самомодифицирующийся код, на ходу меняя сложением адреса A1, A2, A3 в командах (что с точки зрения более-менее современных принципов программирования является грязным хаком и запредельным извращением, так даже вирусы стараются не писать без крайней нужды, в БЭСМ же это был штатный режим работы).

Дополнительной проблемой была пресловутая работа с внешними устройствами, Лебедев в своих оригинальных машинах решил ее максимально жестко – просто захардкодив все обращения прямо в железе, при том, что команд и без того не хватало. Никаких попыток абстракции от устройств не было, что говорит, опять же, о том, что электротехником он был настолько же превосходным, насколько ущербным системным архитектором. Отсюда следует и то, что, слава богу, в качестве прототипа БЭСМ-6 был взят CDC. Лебедев понимал пределы своей компетенции (иногда) и не дерзнул разработать суперкомпьютер требуемого уровня целиком с нуля на своей своеобразной фантазии.

Следующий архитектурный миф


Следующий архитектурный миф связан с конвейером, дескать, БЭСМ-6 была первой машиной в мире, на которой гениальный Лебедев построил свой «водопровод», о чем доложил на конференции в Дармштадте, и недалекие европейцы испытали шок и благоговение.

В реальности идея конвейера была высказана еще Конрадом Цузе и в примитивной двухстадийной форме реализована еще в Z3. В 1949 он попытался запатентовать ее реализацию в Z4, но вот удивительно – патент притормозили аж до середины 1960-х, при том что патроном фирмы Zuse была IBM.

Аналогичные идеи витали в воздухе в начале 1950-х, о них задумывался и Лебедев, и Рамеев, они обсуждались на семинарах МЭИ. В 1946 году Великобритании срочно понадобился огромный необитаемый кусок суши для испытаний ядерного оружия. По счастью, такой кусок суши у них нашелся, и назывался он Австралия.

В результате был заключен партнерский договор – испытательные полигоны в обмен на доступ к современным технологиям. Так было основано австралийское Научно-исследовательское учреждение по оружию (WRE, наизобретали много чего, например, в 1957 создали тот самый «черный ящик» для самолетов).

Специально для WRE британская компания Elliott Brothers разработала компьютер Elliott model 403 (часто именуемый WREDAC). Эта ламповая машина заработала в 1955 году и имела двухстадийный конвейер, аналогичный патенту Цузе.

Отметим, что к настоящему конвейеру в современном смысле слова ни идеи Цузе, ни Лебедева не относятся. В их «конвейере» предполагалось только совмещение двух разнонаправленных операций – арифметико-логической в процессоре и выборке следующего операнда из ОЗУ.

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

Конвейер в таком смысле слова был описан первым в работе Дональда Жиллеса (Donald Bruce Gillies), выдающегося канадского математика и компьютерного ученого, работавшего в Университете Иллинойса над проектом суперкомпьютера ILLIAC II. Это была невероятно прогрессивная машина, но ее разработка закончилась только в 1962 году, при этом вся документация и принципы работы были изложены в открытых академических статьях еще в 1957–1958 гг. и не запатентованы, разработчики Stretch позаимствовали схему конвейера из них, но формально успели выпустить свою машину на три года раньше.

В том же 1959 в единственном экземпляре был изготовлен ламповый монстр М-100 Китова, о котором мы уже писали, информации о его архитектуре практически нет, достоверно известно, что он имел гарвардскую архитектуру и конвейеризованный процессор, но насколько он мог выполнять программы общего назначения и что это был за конвейер – неизвестно.

Классика, как она есть. БЭСМ-6 в естественной среде обитания, машинный зал ОИЯИ, г. Дубна (фото https://ramlamyammambam.livejournal.com/). Одновременно с этим в ОИЯИ работали две БЭСМ-4, CDC 1604, CDC 6500, три ЕС-1040, ЕС-1060, ЕС-1010, ЕС-1061 и Robotron KRS-4201. По количеству инсталляций это был, скорее всего, самый мощный и большой ВЦ СССР.

Конвейер же БЭСМ-6 был подсмотрен у CDC-6600, только у Крэя каждый процессор имел 10 независимых блоков, которые могли исполнять инструкции из конвейера параллельно, потому эта машина и считается первым суперскалярным процессором в мире.

Еще более продвинутой архитектурой обладал CDC 7600, созданный в 1969 году, и IBM System/360 model 91 (1967), использующий все современные черты конвейера, в т. ч. спекулятивное исполнение и переименование регистров.

Куда более примитивная схема с сумматором в БЭСМ-6 так же не могла обладать конвейером в современном смысле слова, как и виртуальной памятью. Само АЛУ конвейеризовано не было – если процессор умножал два числа, более ничем он заниматься не мог, хотя в это же время и могла осуществляться выборка следующей команды. Так что реализация «конвейера» здесь была устаревшая на 15 лет, аналогичная работам Цузе, Рамеева и Elliot.

Последнее заблуждение


Последним заблуждением относительно «колоссальных инноваций» БЭСМ-6 является наличие в ней кэш-памяти.

На самом деле никакого кэша в современном смысле слова там не было, полноценный кэш появился только в серии IBM System/360 model 85 в том же 1967 году.

Кэш здорового человека состоит из набора записей в сверхбыстрой ОЗУ (обычно статической), каждая запись ассоциирована с блоком данных, которая является копией данного блока в обычной ОЗУ. Каждая запись имеет идентификатор (часто называемый тегом), определяющий соответствие между элементами данных в кэше и их копиями в основной памяти. Если в кэше найдена запись с идентификатором, совпадающим с идентификатором затребованного элемента данных, то используются элементы данных в кэше. Такой случай называется попаданием кэша. Если в кэше не найдена запись, содержащая затребованный элемент данных, то он читается из основной памяти в кэш и становится доступным для последующих обращений. Такой случай называется промахом кэша.

В БЭСМ-6 вместо этой модели были всего лишь четыре т. н. буферных регистра числа (БРЧ), куда считывались слова из памяти, чтобы потом к ним могло быстрее обратиться АЛУ. Аналогично, имелось 8 (снова странная асимметрия) буферных регистров записи (БРЗ), куда число помещалось перед записыванием в память. Адрес, куда должен быть записан операнд, сохранялся в т. н. БАЗ (буферном регистре адреса записи). Если в дальнейшем оказывалось, что исполнительный адрес совпадает с одним из адресов в БАЗ/БАС, операнд брался из БРЗ/БРЧ, а не из памяти. Вот и весь «кэш» по-бэсмовски.

Ну и наконец, финальным заблуждением является мысль о том, что БЭСМ-6 была предвестницей RISC-архитектуры.

Безусловно, в БЭСМ-6 не слишком много команд, скорее – мало, но это единственный параметр, по которому она похожа на RISC. Однако, полноценный RISC-процессор: имеет небольшой набор простых команд, огромное количество РОН (регистров общего назначения), развитую схему их переименования, элементарные команды и предсказуемую и стандартную скорость выполнения любой из них – 1–2 такта.

Если вы дочитали статью до этого момента – вы уже понимаете, что БЭСМ-6 пролетела тут по всем параметрам, кроме количества команд.

Как мы уже говорили – с софтом в БЭСМ-6 все было печально.

Поставлялась она только с предтечей ОС «Диспетчер-68» разработки ИТМиВТ, позволявшей разве что пакетный запуск задач и выделение им ресурсов. В качестве языка предлагался лебедевский автокод, от которого отказались сразу же все адекватные люди. Как мы уже упоминали, расчет был на то, что удастся сходу запустить на БЭСМ-6 весь массив софта от CDC 1604, но он не оправдался. В результате каждая научная группа лихорадочно принялась пилить под себя разнообразные реализации языков и операционных систем, понятное дело, не совместимых меж собой.

Крутейшей среди них стала та самая мониторная система «Дубна» – причем сил СССР на нее не хватило, пришлось подключать немцев из ГДР, венгров и даже монголов – весь международный комитет ОИЯИ.

Под нее удалось перековырять ворованные компиляторы Fortran и Algol-60, значительно позже LISP и Pascal, но все это ценой адовых усилий. Algol-60 изначально был создан в ВЦ АН СССР в Лаборатории программирования под руководством В. М. Курочкина, сначала для БЭСМ-2, позже портирован на БЭСМ-6 (для БЭСМ-4 существовало не менее 3 разных компиляторов с Algol-60, не менее 2 разных ассемблеров, дубнинский и Баяковского и компилятор с оригинального языка Эпсилон – вот такой типичный зоопарк), и как говорили многие, он остался для нее единственным некосячным транслятором с популярного языка.

Беда была в том, что в 1964 вышла новая спецификация языка, обычно называемая (по финальному году принятия стандарта) Algol-68, который Курочкин уже не осилил. Транслятор же Algol-68 от CDC 1604 работал криво, что обломало запуск многих CERN-программ, на которые рассчитывали наши физики в Дубне.

В Европе Algol-68 в течение длительного времени использовал Британский королевский комитет по связи и радиолокации.

В СССР существовали рабочие группы по разработкам на Algol-68 (например, новосибирская под руководством академика Андрея Петровича Ершова, ленинградская под руководством Андрея Николаевича Терехова, московские под руководством Александра Николаевича Маслова и Михаила Рувимовича Левинсона). В Ленинградском государственном университете был создан компилятор и мощная система программирования на Algol-68, но… уже для ЕС ЭВМ, эксплуатировавшаяся в течение многих лет (кстати, именно поэтому в т. ч. в Дубне появилась и ЕС, ради развитой периферии и ради огромного количества софта и компиляторов, недоступных для БЭСМ-6 или работающих некорректно).

Просто эталонное фото – инсталляция сразу двух БЭСМ-6 в ВЦ МГУ (фото http://www.besm-6.su)

Многие программы появились после ознакомления с зарубежными исходниками, например, уже упомянутый Н. Н. Говорун из ЛВТ ОИЯТ после командировки в CERN по машинным распечаткам с CDC 3200, сделанным в их ВЦ, реализовал на БЭСМ-6 Fortran и библиотеки стандартных программ, шесть БЭСМ-6 передали ГДР, и их программисты из ОИЯИ, поехав к себе на родину, сделали свою версию ассемблера, Fortran-ГДР и Algol-ГДР (работавшие на 20–30 % быстрее отечественных).

З. Ф. Бочкова, Г. Н. Езерова, В. М. Михелева под руководством В. С Штаркмана из ИПМ им. Келдыша (после его командировки в IBM) разработали автокод БЕМШ, т. к. изначальный автокод М. Г. Чайковского, основанный на мнемониках самого Лебедева, был принципиально двухбуквенным и абсолютно нелогичным и нечитаемым, что породило множество несовместимых переделок.

Файловая система БЭСМ-6 так никогда и не была написана и доделана до конца, вообще, в каждом научном центре удалось написать что-то свое в ущерб всему остальному. В Челябинске было архивирование на ленты, в Дубне – человеческий язык описания заданий и Fortran-ГДР, и Algol-ГДР, на ВМК МГУ – LISP и ДИСПАК.

Отдельным праздником была документация для БЭСМ-6. Представьте, что вы обыкновенный аспирант или м.н.с., пришедший на работу с факультета, скажем математики. И вам предлагают копаться в ЭТОМ. За такое качество описания машины для конечных пользователей, оные пользователи в США сожгли бы Крэя на костре из инструкций.

Безусловно, и с оригинальной OS/360, и у IBM вышла неувязка, но они исправили ситуацию чрезвычайно быстро, в СССР же бардак с тысячами библиотек, написанных в разное время кем попало и не совместимых между собой, так и не был разрешен во всех областях, где дело не касалось прямого копирования программного обеспечения для ЕС.

Все то, чем так гордятся фанаты БЭСМ-6 – знаменитые ОС НД-70, «Дубна», ДИСПАК и т. п., были разработаны лишь к середине 1970-х. Благодаря ДИСПАК в 1972 году к БЭСМ-6 осилили наконец-то подключить жёсткие диски с контроллерами, снятыми с General Electric, до того люди работали с архаичным барабаном, родом из начала 1950-х годов.

Машины IBM работали с дисками с 1956 года – это к вопросу о «передовой архитектуре» БЭСМ-6. Один барабан имел емкость 16 килослов (192 килобайта) и весил полтонны. Барабанов можно было прицепить 4 штуки максимум. При этом обычные жесткие диски IBM имели емкость 5 мегабайт, а большие – 30 мегабайт. Отметим, что БЭСМ-6 в Дубне имели некоторые аппаратные отличия, начиная от чётности символов в терминальных линиях и до битов физического адреса в регистрах.

В итоге ОС «Дубна» не заводилась на машинах больше, чем с 4 кубами памяти, потому что лишние биты физического адреса используются диспетчером для своих целей. В целом это объясняет, почему «Дубна» не была популярной в других местах.

Вообще люди, далекие от западного проектирования ЭВМ, часто не могут понять, что главное в машине – не железо, а софт. Не программы пишутся под готовую машину. Машина создается так, что бы под нее было удобно писать программы, а еще лучше – с минимальными изменениями использовать уже имеющиеся. К сожалению, даже на Западе далеко не все поняли суть этой простой аксиомы.

Предельно ясно сформулировал это Фред Брукс, один из ведущих разработчиков Stretch – проектирование любой архитектуры компьютера должно начинаться со сбора требований пользователей, а не персональной глубокомысленной шизы конкретного системного архитектора и его личного уникального видения, какая должна получиться машина.

Не люди для компьютера, а компьютер для людей.

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

В совершенстве этот цикл освоили две компании – IBM, научившаяся на Stretch и создавшая великую S/360, и Burroughs, аналогично разработавшая не менее великую серию B5000 (тут речь идет о массовых коммерческих машинах, CDC и Cray аналогично создавали научные суперкомпьютеры – собирая заявки и требования ученых и стараясь максимально их удовлетворить).

В результате мейнфреймы серии Z до сих пор совместимы с машинами 1960-х годов, в банковском секторе крутятся миллиарды строк кода, написанных на COBOL еще при Кеннеди, а IBM и Burroughs (в инкарнации UNISYS) стали единственными производителями мейнфреймов, шагнувшими из XIX века, когда они были основаны, в век XXI.

В СССР эта аксиома, увы, осознана не была (от слова совсем), с учетом того, что к 1960 году монополистом, сравнимым с IBM, у нас был ИТМиВТ. Тот же Юдицкий проектировал «Алмаз» под конкретные требования ПРО (а затем ГРУ), и его потенциальные пользователи были в восторге от макетных образцов машины, хотя выпустить серию ему так и не дали. В ИТМиВТ все было не так, по умолчанию считалось, что гениальный Лебедев лучше вас знает, какой компьютер вам нужен, он же профессионал, потому живите с той системой команд и архитектурой, которую он родил.

У людей, хорошо знакомых с современными технологиями, не вызывает непонимания или отвращения знакомство, например, с деталями реализации работы с памятью в S/360. Знакомство же с особенностями низкоуровневого программирования в БЭСМ-6 зачастую шокирует современных программистов. На самом деле дедам приходилось не легче, поэтому софт под БЭСМ-6 писался долго, очень долго, вплоть до ее кончины в 1990-х.

Какие-то реализации были удачны, какие-то – не очень, делалось все это усилиями разрозненных НИИ и научных центров, кое-как в разных вариантах расползаясь по всей стране. Миф о качестве и количестве софта под БЭСМ-6 возник во многом от того, что, во-первых, их было выпущено почти 400 (с учетом модификаций), что по меркам Союза было невероятно, своя БЭСМ-6 стояла почти в каждом крупном научном центре, во-вторых – их клепали 20 лет и использовали 40 лет.

В результате, ученые, люди далеко не глупые, за это время смогли родить довольно много сносных программ. Естественно, существовали и крупные теоретические школы программирования (вообще, советскими программистами максимальной силы, всемирно уважаемыми как теоретиками компьютерных наук, были люди, пришедшие туда из математики, начиная с Ляпунова и Шура-Бура).

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

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

В следующей статье мы завершим рассмотрение этой эпохальной отечественной разработки.

Продолжение следует…

Автор:

Алексей Ерёменко

Использованы фотографии:

https://www.computerhistory.org, http://www.besm-6.su, https://www.1500py470.livejournal.com