Narodziny sowieckiego systemu obrony przeciwrakietowej. Za i przeciw BESM-6
CDC 6200
Pod względem szybkości BESM-6 w tamtych latach też nie był już fontanną, od 1960 roku komputery poszły daleko do przodu i musiałem szukać rozwiązania tego problemu. ZSRR po raz drugi przełknął dumę i poszedł poprosić o sprzedaż również CDC 6600. Tutaj KoKom już odpoczął i obraził nie tylko Unię, ani jednego CDC 6600 nie dostarczono nikomu poza USA, nawet Francji odmówiono. Dopiero w 1972 roku KoKom zezwolił (a nawet wtedy pod jego ścisłym nadzorem) na zainstalowanie w Dubnej młodszej wersji CDC 6200, którą w 1975 roku zmodernizowano do wieloprocesorowego 1 (już przestarzałego po wydaniu Cray-6500) flagowy 6600 pozostał czysto amerykańskim potworem.
Oto jak wspomina to G. Ososkov (Gazeta „Dubna”, nr 21 (3759) z 27 maja 2005 r.)
W 1967 roku w ramach kontraktu na zakup komputera CDC-1604 zostałem wysłany do Niemiec wraz z inżynierami A. Karlovem i V. Mirolyubovem na studia w Centrum Europejskim CDC we Frankfurcie nad Menem. Po przestudiowaniu systemu operacyjnego komputera i programowania w języku Fortran spędziłem kolejne dwa miesiące na stażu jako operator CDC-1604 w Hanowerze. W rezultacie pracował przez rok jako starszy matematyk w CDC-1604 po zainstalowaniu tego komputera w LVTA, a ponadto nauczył się mówionego angielskiego. W latach 1969-1970 i 1973 W CERN studiował system programów sterujących i kalibracyjnych dla maszyny skanującej Spiral Reader, podobny do opracowanego w LVTA. W 1972 r. wraz z zastępcą dyrektora LVTA G. I. Zabiyakinem byliśmy w dwutygodniowej podróży służbowej do USA na zaproszenie CDC. Odwiedziliśmy BNL Computing Center, wzięliśmy udział w konferencji użytkowników CDC w Dulusie, odwiedziliśmy siedzibę CDC oraz fabrykę, w której w tym czasie produkowano najnowsze komputery CDC-7600 w Minneapolis, a także centra obliczeniowe Uniwersytetu w Berkeley i Laboratorium Livermore, wyposażone w maszyny CDC. Między innymi pokazano nam znany wówczas komputer CDC-Star. Jednak największe wrażenie zrobiły na mnie możliwości sieci komputerowej CYBERNET, która połączyła 49 maszyn CDC w całej Ameryce do jednoczesnej pracy w trybie wsadowym.
Większość prezentacji użytkowników na konferencji Dulus była poświęcona omówieniu możliwości i wad tej sieci. Teraz, 30 lat później, takie możliwości wydają się powszechne, ale wtedy wyglądało to całkiem fantastycznie. Głównym celem wyjazdu było zawarcie umów na zakup komputerów CDC-6200, z pominięciem głośnej umowy COCOM, której celem było zakazanie dostaw najnowszych technologii komputerowych do krajów socjalistycznych. Wyrażając zgodę na stałą inspekcję przez COCOM w Dubnej, Dyrekcja LVTA w 1972 r. uzyskała zgodę na zakup CDC-6200. Takie maszyny z serii 6000 były potężnymi komputerami, w bibliotece CERN było wiele programów użytkowych do nich i chociaż 6200 był już dość przestarzały, taki zakup pozwolił LVTA w 1974 roku rozwinąć maszynę do CDC-6400, oraz w następnym roku na wieloprocesorowy CDC-6500. Wraz z BESM-6, to radykalnie zwiększyło moc obliczeniową ZIBJ, umożliwiło stworzenie rozległej sieci terminali i uruchomienie stacji fortran.
Większość prezentacji użytkowników na konferencji Dulus była poświęcona omówieniu możliwości i wad tej sieci. Teraz, 30 lat później, takie możliwości wydają się powszechne, ale wtedy wyglądało to całkiem fantastycznie. Głównym celem wyjazdu było zawarcie umów na zakup komputerów CDC-6200, z pominięciem głośnej umowy COCOM, której celem było zakazanie dostaw najnowszych technologii komputerowych do krajów socjalistycznych. Wyrażając zgodę na stałą inspekcję przez COCOM w Dubnej, Dyrekcja LVTA w 1972 r. uzyskała zgodę na zakup CDC-6200. Takie maszyny z serii 6000 były potężnymi komputerami, w bibliotece CERN było wiele programów użytkowych do nich i chociaż 6200 był już dość przestarzały, taki zakup pozwolił LVTA w 1974 roku rozwinąć maszynę do CDC-6400, oraz w następnym roku na wieloprocesorowy CDC-6500. Wraz z BESM-6, to radykalnie zwiększyło moc obliczeniową ZIBJ, umożliwiło stworzenie rozległej sieci terminali i uruchomienie stacji fortran.
Najzabawniejsza rzecz w tym Historie fakt, że maszyna z indeksem CDC 6200 nigdy nie istniała w naturze! Nie został wydany przez CDC i nie można go znaleźć w żadnym zachodnim źródle!
Co to jest?
To bardzo proste - firma Cray'a potrzebowała nowych partnerów, interes idzie dobrze, ale CoCom nie zgodził się na dostarczenie Sowietom nawet młodszego superkomputera - 6500. Następnie inżynierowie CDC zdemontowali z niego jeden procesor, dokonali kolejnego downgrade'u i otrzymali unikalny odcinek - CDC 6200 specjalnie dla ZSRR w jednym egzemplarzu. Pozwolono im sprzedać odcinek, a kilka lat później, gdy linia była przestarzała i przerwana, CoCom pozwolił na ponowne przykręcenie procesora.
Podobna historia powtórzyła się potem z CDC 7600 i Cray-1, nie udało im się kupić, a próba stworzenia klona w postaci „Electronics SS BIS” nie powiodła się fenomenalnie, ale udało im się legalnie kupić jeszcze dwa CDC, prostsze modele , CYBER 170 i 172.
CYBER 172 został zakupiony w 1975 roku dla Centrum Hydrometeorologicznego ZSRR i działał tam z powodzeniem do 1996 roku. Generalnie badanie klimatu było dla ZSRR niezwykle ważne ze względu na rozległy obszar kraju oraz potrzeby żeglugi i zagospodarowania terenu, dzięki czemu Centrum Hydrometeorologiczne posiadało jedną z najpotężniejszych maszyn Związku, a nie gorszy od Dubnej i Arzamas-16, a zwykle używano kilku maszyn jednocześnie. Pierwszym komputerem dla meteorologów był M-20, który pracował tam od 1959 do 1962, został wyrzucony po zaledwie trzech latach i nic dziwnego.
Dyrektor Głównego Centrum Komputerowego Władimir Antsipowicz, który pracował tam przez ponad 40 lat, wspomina:
Musieliśmy osiągnąć niezawodne działanie schematów technologicznych przy minimalnym wymaganym czasie ciągłego liczenia co najmniej jednej godziny, podczas gdy np. dla M-20 paszport MTBF wynosił tylko piętnaście minut.
Zastąpił go M-220, potem M-222 i Vesna, dość egzotyczny duży komputer o pojemności 300 KIPS, stworzony w 1965 roku w Biurze Projektowym Automatyki Przemysłowej Ministerstwa Przemysłu Radiowego (jak widać, pomimo BESM-6, inne ministerstwa nadal entuzjastycznie bawiły się architekturą zoo).
Maszyna ta pracowała w Centrum Hydrometeorologicznym do 1972 roku, równolegle ze szczytowym osiągnięciem czysto radzieckich maszyn głównych – Mińsk-32. Również w latach 1968-1985 pracował tam BESM-6.
CYBER-172 był pierwszym obcokrajowcem w Głównym Ośrodku Obliczeniowym (to dla meteorologów w 1975 roku chcieli kupić CDC 7600, ale zerwali z CoComem) i od tego zaczęła się dominacja zachodnich superkomputerów w sowieckiej meteorologii. Generalnie chcieli kupić dwa z nich, ale CoCom też tu posadził świnię, uznali, że dwa z nich są za grube dla ZSRR.
Oczywiście były tam EU 1060 i 1066, a także IBM 3033 - najnowszy zamiennik linii S/370, wydany w 1979 roku, jednak za spisek nazywał się Hitachi (jednak jest zabłocona historia - czy nasza kupił swojego licencjonowanego klona od Hitachi, czyli oryginalnego IBM, ale nazwali go, że dla większej tajemnicy, w każdym razie maszyna Hitachi 3033 nie istnieje w naturze, jest tylko Hitachi HITAC M-220 lub IBM 3033) .
W 1992 roku chcieli już dostarczyć cierpliwego Elbrusa-2, ale nagle CoCom zatwierdził sprzedaż do Rosji najpotężniejszego Cray Y-MP, który jest około 30 razy lepszy od Elbrusa. Omawiając wszystkie szczegóły - instalacja przesunęła się na 1996 rok i wypadła już z Thor 500 Cray Y-MP.
Ten potwór pracował w MCK nieprzerwanie przez 10 lat, aż do 2006 roku, kiedy to zginął bezpiecznie na posterunku wojskowym. Wynika to w dużej mierze z faktu, że trzy lata po instalacji, ze względów finansowych, musiałem dalej korzystać z Cray Y-MP bez wsparcia producenta. Antsypowicz mówi:
Przez osiem lat działania przeszliśmy przez wszystkie węzły komputera, starając się, aby działał ze względu na nadmiarowość projektu, ale ostatecznie nawet ukryte rezerwy nie wystarczyły: kompleks się zatrzymał.
Potem pojawiły się dwa klastry – SGI Alltix 4700 (11 Tflops 832 Intel Itanium 2 9140M) oraz SGI Alltix ICE (16 Tflops, nieznana liczba Intel Xeon E5440), a w 2019 roku władze rozwiodły się na nowy klaster od Craya – XC40.
CYBER 170 został zakupiony w 1976 roku dla laboratorium LNIVT Akademii Nauk ZSRR w Lian, obecnie SPII RAS. Los samochodu Centrum Hydrometeorologicznego jest nieznany autorowi i na własne oczy widział pozostałości samochodu LIAN w budynku SPII RAS na Wyspie Wasiljewskiej, trudno się tam dostać, ale nie jest to niemożliwe, pracownicy są bardzo przyjaźni i jeśli wcześniej zadzwonisz i wyrazisz zgodę, z przyjemnością obiorą krótką wycieczkę, więc osoby mieszkające w Petersburgu mają szansę dotknąć historii.
CDC CYBER-170 z SPII RAS, a raczej jego pozostałości. Zdjęcie autora.
Aby rozwiązać problem braku mocy obliczeniowej, do 1973 roku Mielnikow opracował tzw. sprzęt interfejsowy, kompleks AS-6, w rzeczywistości złożony przełącznik programowalny z dodatkową pamięcią i koprocesorami, co pozwala na połączenie kilku BESM-6 i przekształcenie ich w klaster ze współdzieloną pamięcią RAM. W sumie wykonano 8 zestawów.
pytania
Musimy odpowiedzieć na dwa pytania.
Po pierwsze, dlaczego architektura systemu BESM-6 okazała się tak nieudana?
Po drugie – jakie były jego mocne strony i dlaczego była tak zarośnięta mitami i legendami?
Zacznijmy od tego, że Lebiediew początkowo zaprojektował swoje pierwsze maszyny do bardzo konkretnych celów - konkretnie do rozwiązywania układów równań różniczkowych (czyli obliczania trajektorii pocisków czy modelowania reakcji jądrowych). Rozumiał, jak budować takie komputery, ponieważ sam był wybitnym inżynierem elektrykiem i twórcą komputerów analogowych do modelowania tych samych równań różniczkowych.
W przeciwieństwie do Eckerta, Wilksa, Amdalla – Lebedev nie był do końca informatykiem, nie miał odpowiedniego nastawienia, a tym bardziej nie był programistą, jego jedyna próba stworzenia autokodu zakończyła się tym, że nikt nie wykorzystał tego horroru. Dlatego Lebiediew nie wyobrażał sobie dokładnie problemów użytkowników swoich maszyn, zbudował, choć formalnie i uniwersalne, ale w duchu raczej kalkulatory jednozadaniowe, dobrze przystosowane do rozwiązywania różnych systemów i słabo do wszystkiego innego.
Nawiasem mówiąc, był to wspólny problem dla wszystkich w ITMiVT: nadal mogli tworzyć maszyny dla naukowców rakietowych, ale naprawdę uniwersalny komputer był już z wielkim trudem. Burtsev w końcu miał te same problemy z Elbrusem, biorąc za podstawę system bankowy Burroughs i próbując przekształcić go w komputer sterujący obroną przeciwrakietową. Przynajmniej tak się okazało, ale nie wyszedł też udany superkomputer ogólnego przeznaczenia dla naukowców z Elbrusa.
CDC produkowało maszyny do systemów sterowania i obliczeń naukowych, natomiast IBM produkował maszyny dla biznesu, głównie do systemów finansowo-księgowych. Są to zasadniczo różne obszary zastosowań, które odcisnęły swoje piętno na architekturze. BESM-6 osiągnął absolutny poziom w tym podziale.
Zacznijmy od faktu, który już się tutaj ujawnił. Nie miał arytmetyki liczb całkowitych. Ogólnie. Wcale tak nie było.
Był w CDC 1604 i był bardzo zaawansowany, ale Lebiediew wyrzucił go z BESM-6, dlaczego?
Bo przez całe życie budował jednozadaniowe kruszarki równań różniczkowych (monotask – w tym sensie, że zgodnie z jego logiką były one po prostu uruchamiane kosztem systemu różnych rozbieżności, i więcej – nie były specjalnie używane) i liczby całkowite arytmetyka nie jest tam potrzebna. W efekcie, w obliczu trudności z połączeniem rzeczywistego i całego ALU, po prostu wyrzucił całość, uznając, że w razie nagłej potrzeby, naśladują ją z prawdziwą.
Dlaczego w ogóle potrzebujemy arytmetyki liczb całkowitych?
Odpowiedź jest prosta - do manipulowania adresami w pamięci RAM. Jak już zrozumiałeś, zarówno CDC-1604, jak i BESM-6 były maszynami z sumatorem (czyli we współczesnej terminologii miały tylko dwa rejestry, z których jeden jest dedykowany - akumulator, w którym wykonywane były wszystkie akcje). Częściowo jest to podobne do architektury stosu, którą można obecnie znaleźć w Forth i Javie.
Problem w tym, że przy takiej organizacji ALU musi ciągle coś ładować/rozładowywać do pamięci, a to wymaga rejestrów indeksów i zaawansowanej arytmetyki indeksów, która pozwala manipulować adresami w pamięci RAM.
Nawiasem mówiąc, w BESM-6 i CDC pojawiła się pewna niedogodność - głębia bitowa rejestrów indeksowych nie pasowała do rozmiaru słowa (!) A do rozmiaru rejestru akumulatorowego, a nawet nie była jego wielokrotnością (15 i 48 bitów), co nadal było normalne według standardów z lat 1959-1960, ale przeciągnięcie takiego archaizmu do 1968 to już ciemność.
Tak więc, oczywiście, maszyny z sumatorami dość rozwinęły arytmetykę liczb całkowitych właśnie ze względu na potrzebę ładowania czegoś z pamięci RAM lub wrzucania do niej w każdym cyklu zegara, podczas gdy Lebiediew zignorował tę cechę CDC. W efekcie każde obliczenie adresu wymagało emulacji na rzeczywistym procesorze, co nie wpłynęło pozytywnie ani na szybkość pracy, ani na wygodę programowania.
Kolejnym bardzo poważnym problemem BESM-6 były peryferia.
Po pierwsze, jak już powiedzieliśmy, Mielnikow porzucił procesory kanałowe i wyjaśnił to w ten sposób:
Przyjęty w maszynie BESM-6 sposób sprzęgania urządzeń zewnętrznych został poddany największym atakom krytyków tej maszyny. Rzeczywiście, podłączenie dowolnego nowego urządzenia wymaga pewnych ulepszeń inżynieryjnych w urządzeniu sterującym urządzeniem zewnętrznym, a użytkownik, który zdołał zdobyć dowolne „niestandardowe” urządzenie, doświadcza dużych trudności z jego podłączeniem. Wydaje się, że nie ma uzasadnienia dla takiej decyzji, zwłaszcza że do czasu opracowania BESM-6 IBM wdrożył standardowy interfejs, który w dużej mierze eliminował problem podłączania nowych urządzeń i zastępowania niektórych innymi.
Jeśli jednak dobrze się zastanowisz lub po prostu porównasz koszt i ilość sprzętu potrzebnego do wdrożenia interfejsu z urządzeniami zewnętrznymi w obu przypadkach, to decyzje podjęte w BESM-6 mogą nie być takie złe. W rzeczywistości każde urządzenie zewnętrzne do standardowego interfejsu zawiera kontroler lub jest podłączone do tego bardzo drogiego i złożonego urządzenia, które zapewnia standardowe wyjście do kanałów multipleksowych lub selektorów. Jeśli zsumujemy koszty dodatkowego sprzętu i zajmowanego przez niego miejsca, wymaganego przy podłączaniu urządzeń przez standardowy interfejs, okazuje się, że system BESM-6 jest wielokrotnie tańszy. Innymi słowy, scentralizowane urządzenie sterujące BESM-6 jest kilkakrotnie tańsze niż koszt sterowników dla standardowego zestawu zewnętrznych urządzeń pamięciowych i wejściowych/wyjściowych maszyn tej samej klasy.
Jednak w wielu modelach maszyn IBM wprowadzono tzw. zintegrowany adapter plików, który pozwala podłączyć dyskowe urządzenie magazynujące do komputera bez użycia standardowego kanału i kontrolera. W tym fakcie można dostrzec pewną analogię z przyjętym w BESM-6 racjonalnym sposobem łączenia urządzeń.
Jeśli jednak dobrze się zastanowisz lub po prostu porównasz koszt i ilość sprzętu potrzebnego do wdrożenia interfejsu z urządzeniami zewnętrznymi w obu przypadkach, to decyzje podjęte w BESM-6 mogą nie być takie złe. W rzeczywistości każde urządzenie zewnętrzne do standardowego interfejsu zawiera kontroler lub jest podłączone do tego bardzo drogiego i złożonego urządzenia, które zapewnia standardowe wyjście do kanałów multipleksowych lub selektorów. Jeśli zsumujemy koszty dodatkowego sprzętu i zajmowanego przez niego miejsca, wymaganego przy podłączaniu urządzeń przez standardowy interfejs, okazuje się, że system BESM-6 jest wielokrotnie tańszy. Innymi słowy, scentralizowane urządzenie sterujące BESM-6 jest kilkakrotnie tańsze niż koszt sterowników dla standardowego zestawu zewnętrznych urządzeń pamięciowych i wejściowych/wyjściowych maszyn tej samej klasy.
Jednak w wielu modelach maszyn IBM wprowadzono tzw. zintegrowany adapter plików, który pozwala podłączyć dyskowe urządzenie magazynujące do komputera bez użycia standardowego kanału i kontrolera. W tym fakcie można dostrzec pewną analogię z przyjętym w BESM-6 racjonalnym sposobem łączenia urządzeń.
W tłumaczeniu na zwykły język okazuje się, że aby zaimplementować rozsądną pracę z koprocesorami kanałowymi, tak jak w S/360, nie mieliśmy wystarczającej ilości pieniędzy i chęci Lebiediewa, który fanatycznie sprzeciwiał się wprowadzeniu koprocesorów do swoich maszyn (poprawka Pomysł wyszedł z czasów lamp, kiedy dodatkowe kilka tysięcy lamp radzieckiej jakości oczywiście nie poprawiłoby niezawodności, a gra nie była warta świeczki, Burtsev wepchnął procesory kanałowe do 5E26, co znacznie zwiększyło jego wydajność, w rzeczywistości już bardzo chory Lebiediew, który wtedy nie był zdolny do architektury).
Generalnie praca z kanałami często była dla naszych programistów zbyt dezorientująca, stąd mity o wyższości BESM-6 pod tym względem nad serialem unijnym. Biorąc pod uwagę ich niski poziom umiejętności czytania, ogromne problemy z jakością pierwszych klonów UE i prawie całkowity brak samouczków, dokumentacji, przykładowych programów, łatek itp. Oczywiście praca z tak złożoną rzeczą jak kanały może być piekłem w porównaniu z implementacja I/O w BESM-6, prosta jak filcowy but. Stąd liczne mity o niezwykle postępowej architekturze.
Jednocześnie wiele osób myli różne poziomy architektury – architekturę systemu dowodzenia i systemową, która opisuje m.in. fizyczne połączenie peryferiów itp. Wszystko było w porządku z architekturą systemu w BESM- 6 - maszyny można było połączyć w sieć, klastrować do 8 komputerów, można było podłączyć do 128 terminali, w tym zdalnych, kontroler dysków klastrowych (każda maszyna klastrowa ma dostęp do każdego dysku) itp. wszystkie zachodnie komputery tej klasy ).
Zabawnym paradoksem jest fakt, że wiele udanych rozwiązań technicznych zrodziło się z prób przezwyciężenia nędzy rodzimej bazy żywiołów.
Na przykład progresywna technologia nagrywania na podwójną taśmę (nawet jeśli blok ma błędy, ale w dwóch różnych miejscach będzie składany z kawałków i odczytywany normalnie) pojawiła się jako odpowiedź na obrzydliwą jakość sowieckiej taśmy, która zaczęła kruszą się dosłownie po dwóch lub trzech uruchomieniach – w UE, po IBM, takiego mechanizmu nie było, w efekcie powstał mit o zawodności ich podsystemu nagrywania taśmowego w porównaniu z BESM.
W tym samym czasie jako napęd magnetyczny nie były używane progresywne dyski twarde, ale przestarzały bęben magnetyczny, podczas gdy kontrolery dysków pojawiły się dopiero w 1974 roku, po skopiowaniu ich ze sterowników starożytnych mainframe'ów General Electric (do tego czasu tak przestarzałych, że CoCom oficjalnie dopuścił ich sprzedaż na potrzeby KIAE i ITEP, nieoficjalnie - rozebrane na przydatne części zamienne do BESM-6).
Ogólnie można napisać osobną książkę o okropnościach czysto sowieckich peryferii, a także o ich jakości. W dyskusji o BESM-6 w czasopiśmie 1500py470.dziennik na żywo, jeden z programistów, który z nią pracował, pozostawił takie wspomnienia o tym:
Przypadkowo wszedł do twojej rozmowy. W BESM-6 pracował przez 17 lat. Były dwie maszyny nr 135 i nr 335... Przynajmniej wiecie, że jednym ze standardowych narzędzi do testowania i diagnozowania błędów w działaniu maszyny, zwłaszcza z błędem pływającym, był młotek, w postaci ciężki metalowy walec (wszystko karbowane, aby nie wyślizgiwał się z ręki podczas gwintowania) z wymiennymi ebonitowymi końcówkami po obu stronach (zmieniały się w miarę zużywania się). Nasze samochody są wyłączane raz w roku. Łatwo zgadnąć - 31 grudnia. Tak więc po ich włączeniu wszyscy je klikali. Pamięć (jest to 8 podwójnych szafek) o łącznej pojemności 128x6Kb (nie liczyła dwóch bitów sterujących), tj. e. mniej niż 1 Mb, a obszar zajmował 60–80 m, a nawet więcej. Pracowaliśmy pod systemem DISPAK OS, w trybie wsadowym procesor przetwarzał 5–10 zadań (w zależności od tego, ile zadanie zjadało), system CRAB był stale dostępny… Następnie 16 kostek ferrytów zostało zastąpionych jednym stojakiem wykonanym na Baza elementów EC EMW (przynajmniej część wtedy była korzyść z UE). Nikt nie zauważył, że częstotliwość taktowania w różnych źródłach wskazuje inaczej, gdzie jest 9 MHz, a gdzie 10 MHz? Opracowali go na 10, ale podstawa elementów nas zawiodła, zrobili 9,1 MHz. Można powiedzieć o wiele więcej. Połączone dwie maszyny na wspólnych dyskach (najpierw 7,5 MB, potem 29 MB każdy dysk, dyski wymienne). Jest 16 takich napędów. Wykonaliśmy sieć terminali poprzez centralę lokalną, dzierżawiliśmy łącza do 500 metrów. Terminale były alfanumeryczne, za najlepszy uznano Videoton-340 (Węgry kupiły licencję od IBM na przestarzały model). Jeszcze lepsze były Videoton VDT 52100 na procesorach Intel 8080. Jednym z największych problemów były bębny magnetyczne. Jeśli pominiesz szczegóły, jest to bardzo podobne do działania dysku twardego, ale głowice są stałe, a są ich setki (nie pamiętam dokładnie). Całe hemoroidy polegają na tym, że szczeliny w nich są ustawiane ręcznie na każdej głowie w stanie zimnym, a po rozgrzaniu tego urządzenia nie można tego zrobić - podczas przyspieszania zwiększone wibracje i powierzchnia podniesiona (a ważyła 200-250 kilogramów zatem w trybie pracy wszedł na kilka godzin i schładzał się przez prawie dzień). Jeśli jest wyłączony, nie możesz uruchomić gorącego, musisz poczekać, aż ostygnie. Dlatego też pozbyliśmy się ich, instalując pamięć firmy Electronics. Zamiast 16 rolek - 8 pudełek, jeden stojak. W jednej 6-metrowej hali bez problemu umieszczono dwa BESM-200, do którego podłączono ploter graficzny Digi. Praktycznie porzucili taśmy magnetyczne, przełączając się na dyski i instalując oprogramowanie ARFA (archiwalny system plików). Do pobierania programów napisanych w Fortranie podłączyliśmy komputer, zainstalowaliśmy Kermit. Użytkownicy otrzymywali teksty swoich programów na dyskietce... Do 1975 r. trzeba było wyprodukować nową maszynę tej linii, biorąc pod uwagę niedociągnięcia: 15 cyfr w części adresowej to ślepy zaułek, baza elementów jest całkowicie przestarzała , o ATsPU, UPDC, ML itp. na peryferiach i nie ma nic do powiedzenia, HORROR! Zużycie energii jest oburzające! Nie możesz od razu przypomnieć sobie wszystkich niedociągnięć, tak jest najlepiej. Ale lutowali i montowali w zakładzie CAM, w krzywych, czasem trzeźwych kurnikach. Po nich nastawierze uruchomili go na dwa miesiące.
G. N. Tentyukova, szef sektora OMOED LVTA, wspomina (tygodnik ZIBJ „Dubna” nr 34 (4325) z 11 sierpnia 2016 r., „Kiedy maszyny były duże”):
Prawdopodobnie nie znalazłeś pierwszego urządzenia do wprowadzania kart perforowanych na BESM-6? Teraz powiem ci, jak to działało. Umieszczasz talię. Włączasz to. Powoli: ciu-ciu-ciu... Nagle: tra-ta-ta! Cztery karty... Oznacza to, że musisz wyciągnąć talię, policzyć cztery karty z tego, co minęło, położyć je na początku reszty talii - i ponownie nacisnąć start. Valya Nikitina powiedziała, że podczas jakiegoś międzynarodowego spotkania (właśnie wprowadzono BESM-6), Govorun przyprowadził obcokrajowców do maszynowni, by chwalić się, jakie mamy centrum komputerowe. A Valya, jakby celowo, położyła dużą talię. Cóż, co zamierzasz zrobić! „Cztery karty”, „cztery karty”… Valya wstaje, rumieni się. Cóż, nic, obcokrajowcy to uprzejmi ludzie: obserwowali, jak Valya wchodzi na karty i wychodzi. Valya mówi: prawie spaliłem się ze wstydu! Co możesz zrobić? Nie jesteśmy winni.
Jeśli chcesz, możesz znaleźć tak wiele takich wspomnień, że żaden artykuł nie może pomieścić.
Nawet sami pracownicy ZIBJ pisali w gazecie „Dubna” w 1990 roku (kiedy już można było się nie wstydzić:
Sprzęt był stale ulepszany. Grupie operatorów na czele z V. V. Fedorinem i I. A. Emelinem, oprócz zapewnienia nieprzerwanej pracy, udało się podwoić pamięć maszyny i wyposażyć ją w najlepsze na owe czasy urządzenia peryferyjne. Wejście na karty dziurkacza i magnetofon CDC, terminale węgierskie, magnetofony i dyski bułgarskie, polska drukarka, japoński ploter – nigdzie nie znajdziesz bardziej zróżnicowanej floty urządzeń zewnętrznych. To zoo zwróciło uwagę na długotrwały problem technologii domowych: nasi ludzie są wykwalifikowani, ale przemysł nie!
Ogólnie rzecz biorąc, normalna praca na BESM-6 stała się możliwa około 15 lat po wydaniu maszyny - kiedy to najbardziej przenikliwi towarzysze, którzy mieli największy nacisk (jak naukowcy z Dubnej) wyrzucili do śmieci wszystkie peryferia z samego BESM (a jednocześnie z UE było znacznie lepiej, ale w porównaniu z importem - monstrualny złom) i dostarczali wszystko, co amerykańskie, japońskie i niemieckie (w najgorszym - polskie lub węgierskie).
Ponadto pożądane było uaktualnienie pamięci, przykręcenie normalnych zacisków piekielnymi kulami (w najgorszym przypadku z UE) i samodzielne napisanie ogromnego stosu oprogramowania, od tłumaczy po system operacyjny. Wtedy mogły pozostać ciepłe wspomnienia pracy z BESM-6.
Generalnie przez wszystkie lata istnienia Związku kategorycznie nie opanowano w nim prostego pomysłu - klientowi zależy na produkcie gotowym, a nie surowym półfabrykacie, który trzeba latami wykańczać. Wyobraź sobie sytuację - NSA otrzymuje zamówiony przez siebie CDC 6600 za dziesięć milionów dolarów, komputer przybywa bez urządzeń peryferyjnych (lub z takim, z którym nie można pracować, a jeśli to możliwe, to musisz go podłączyć na sześć miesięcy za pomocą lutownicy żelazne i znane magiczne słowa), bez sensownego systemu operacyjnego, bez kompilatorów i z całkowicie szalonym asemblerem.
A panowie, kryptografowie muszą wykonać wszystkie prace uruchomieniowe własnymi rękami i na własny koszt, napisać oprogramowanie i ogólnie pracować normalnie z maszyną za 10 lat, zanim to samo - bądź cierpliwy. Dla każdej firmy typu rynkowego taki trik byłby ostatnim w ich pracy, niezadowolony klient nie przyjdzie po raz drugi. W gospodarce planowej nie było wyboru, jako klasa - cokolwiek partia raczyła dać, to zjeść.
Mit wydajności
Jeśli chodzi o wydajność, istnieje mit, że BESM-6 był niesamowicie potężny, prawie na poziomie CDC 6600. Deklarowana wydajność BESM-6 to 1 MIPS. W rzeczywistości ta informacja jest zasadniczo nie do utrzymania, ponieważ czas wykonania poleceń może różnić się o rząd wielkości.
Na przykład teoretyczna prędkość działania samego urządzenia mnożnikowego (MD) mogła rzeczywiście osiągnąć wartości 1–1,3 MIPS, podczas gdy praktyczna prędkość, gdy MU intensywnie korzystała z pamięci w procesie, nie przekraczała 0,5–0,8 MIPS . Polecenia podziału działały z prędkością 0,15-0,3 MIPS, natomiast polecenia ze zwrotem danych z AU do CU (UI, MOD itp.) mogły w ogóle wydać cokolwiek, bo czekały na wykonanie 5 zespoły (4 z LHC i 1 z PR). W tym przypadku cykl pamięci BESM-6 wynosi 2 µs, co oznacza, że instrukcje, które czytają operand, którego nie ma w BRZ, mogą w najgorszym przypadku uzyskać +2 µs do czasu wykonania.
W 1992 roku, przed wycofaniem z eksploatacji BESM-6, pracownicy Ośrodka Badawczo-Rozwojowego porównali jego wydajność w liczeniu kombinacji mostków z procesorami 286 (implementacja AMD, przetaktowana do 16 MHz, w porównaniu ze standardem 12) i zgodnie z ich zapewnieniami otrzymali w przybliżeniu równe liczby. Wydajność AMD 286 przekroczyła 2,6 MIPS, ale nie wiemy, z której wersji BESM-6 (najprawdopodobniej Elbrus-1K2 na IC jest znacznie potężniejszy od oryginału).
Książka „Od mikroprocesorów do komputerów osobistych” (Cheremnykh S. V., Giglavy A. V., Polyak Yu. E., 1988, Radio i komunikacja) zawiera przykłady benchmarku (dodawanie i mnożenie tablic w cyklu) w różnych językach dla różnych maszyn i biorąc pod uwagę czas ich wykonania. Zgodnie z tą informacją czas wykonania testu wynosił (w zależności od języka) od 0,08 do 0,23 s dla BESM-6 i od 0,11 do 0,38 s dla EU 1055M, 0,45 s dla DVK (procesor MS 1201.02) i 0,37 s dla PC/ AT z procesorem 16 MHz.
Wszystkie te dane są bardzo sprzeczne, a przy braku działającego BESM-6 nie będzie możliwe poznanie prawdy, jednak zauważamy, że średni wynik w przypadkowym problemie w żadnym przypadku nie przekracza 0,8–1,5 MIPS .
Zauważ, że tę prędkość osiągnął IBM 7030 Stretch osiem lat wcześniej, legendarny CDC 6600 potwierdził ponad 3 MIPS 4 lata wcześniej, a starszy S/360 wyprodukował ten sam 0,8–1 MIPS kilka lat wcześniej.
Widzimy więc, że BESM-6 z pewnością znalazłby się wśród rekordzistów świata w latach 1959-1960, ale jak na rok 1968 jego parametry nie przedstawiały nic nadprzyrodzonego i były na poziomie standardu typowego mainframe, a nawet w połowie dekady . Na poziomie ówczesnych europejskich samochodów (Siemens, Bull, Olivetti) BESM-6 wyglądał normalnie, nie porównując go z CDC (które były najmocniejszymi samochodami tamtych czasów). S/360 nie wypadły gorzej – na obliczeniach naukowych, a znacznie lepiej – na finansowych.
Tu nie ma się czym dziwić.
Jak powiedzieliśmy, BESM-6 nie posiadał obsługi arytmetyki liczb całkowitych, co oznacza, że wszelkie polecenia arytmetyczne były wykonywane na prawdziwym sumatorze, a teraz wyobraź sobie przyjemność obliczania adresów poprzez emulację arytmetyki liczb całkowitych prawie w każdym takcie zegara – maszyna nie jest register, ale przedpotopowy , z sumatorem, w wyniku czego liczby muszą być stale przenoszone z pamięci RAM do pamięci RAM. Doprowadziło to do tego, że nawet w najlepszym przypadku odczyt wymagał 3 cykli, dodawania - 5 cykli (średnio - 11, w najgorszym - 280), mnożenia - 15 cykli (średnio - 18,5, a w najgorszym - 162). ), podział trwał średnio 50 cykli. W rezultacie programy nie tylko działały wolniej niż mogły, ale także zajmowały więcej miejsca.
Wspomina o tym również V. V. Przyjałkowski w swojej recenzji:
Badania przeprowadzone w IPM Akademii Nauk ZSRR wykazały, że programy kompilowane dla IBM S/360 wymagają 1,5–3 razy mniej pamięci niż programy BESM-6, Vesna, M-20.
Jeśli mówimy o wydajności w liczbach według popularnego wówczas testu Whetstone, BESM-6 zyskał około 0,3-0,4 miliona operacji z pojedynczą precyzją na sekundę, co było na poziomie przeciętnych modeli IBM.
Kolejnym problemem była całkowita nieprzewidywalność czasu. To samo polecenie mogło zostać wykonane dla czasów, które różniły się dosłownie o rząd wielkości! Według współczesnych standardów to koszmar, a według standardów lat 1970. niewiele lepiej.
W każdym systemie instrukcji, począwszy od lat sześćdziesiątych, wiadomo z góry, ile cykli zajmie ta lub inna akcja, a te czasy są określone we wszystkich podręcznikach dla niskopoziomowych programistów. Z drugiej strony Lebiediew w ogóle nie rozumiał, dlaczego potrzebna jest przynajmniej jakaś przewidywalność i nawet nie próbował tego osiągnąć.
W rezultacie w BESM-6 czas wykonania różni się w zależności od zjawisk losowych, nie tylko tych oczywistych - na przykład, czy adres jest uwzględniony w pobieraniu wstępnym, czy nie, ale nawet od wartości operandów.
Nie wiadomo, w odniesieniu do którego konkurenta Lebiediew powiedział przypisywaną mu frazę: „Tak, prędkość twojej maszyny jest wyższa niż moja, ale biorąc pod uwagę niską niezawodność, nadal nie będzie miała czasu na obliczenie zadania między dwoma awariami! ”, Ale wielu interpretuje to jako dowód super niezawodności BESM-6.
Na świecie było tylko jedno miejsce, w którym mogła zmierzyć się z CDC 6500 w uczciwej walce – ośrodek badań jądrowych w Dubnej. Oto wynik ich bitwy: mieli ten sam roczny plan w godzinach pracy - nominalnie 6000, ale w rzeczywistości BESM-6 przepracował 1979 godzin w 6910 roku, a CDC 7440 godzin. Najważniejsze są inne liczby - na maszynie Lebiediewa przetworzono 75 tysięcy zadań, na CDC - prawie 200 tysięcy ...
Na temat architektury systemu BESM-6 krąży kilka uporczywych mitów, jednym z nich jest obecność pamięci wirtualnej.
Ta koncepcja została po raz pierwszy zastosowana w Atlasie, a także zaimplementowano pamięć asocjacyjną w celu określenia obecności wymaganej strony pamięci wirtualnej w pamięci RAM.
Dlaczego to, co było w BESM-6, nie jest?
Obsługa pamięci wirtualnej umożliwia adresowanie większej ilości pamięci niż faktycznie zainstalowana na maszynie. W BESM-6, w wersji z potrojoną pamięcią RAM, wszystko było na odwrót – w maszynie było więcej pamięci fizycznej niż można było zaadresować! Faktem jest, że mając 128 ksw pamięci, musieliśmy z nim pracować przez 15-bitowe adresy (starsze z CDC 1604). Ze względu na całkowicie sprzeczną koncepcję „zachować format adresu zgodny z CDC 1604, ale potroić pamięć”, wprowadzono specjalną kulę – 32 tzw. rejestr rejestracyjny. Przed uzyskaniem dostępu do pamięci rzeczywistej adres wykonania został podzielony na dwie części po 5 + 10 bitów. Wysoka część została zinterpretowana jako numer rejestru domowego, z którego wzięto 7 bitów fizycznego numeru strony i razem z 10 najmniej znaczącymi bitami adresu tworzyły 17-bitowy adres fizyczny. Lebiediew z dumą nazwał ten reżim „pamięcią wirtualną”.
W Atlasie adres był pierwotnie 24-bitowy, a adresując poza pamięć rzeczywistą, nadzorca zamieniał stronę z odpowiednim adresem wirtualnym w pamięci RAM z bębna, podobnie jak dzieje się to teraz przy stronicowaniu z dysku.
Nawiasem mówiąc, podobny problem z adresowaniem istniał w BESM/BESM-2/M-20/BESM-4, ale tam wszystko było jeszcze bardziej zaniedbane. Lebiediew użył w nich swojego ukochanego trzyadresowego systemu poleceń w formacie KOP | A1 | A2 | A3, gdzie COP to kod operacji, adresy A1–A3.
Dlaczego tak bardzo karcimy tę zasadę, na zewnątrz wszystko jest piękne?
Faktem jest, że każdy adres mógł odnosić się do maksymalnie 4096 słów, nie mieścił się już w szynie, która była już zaporowo szeroka, ponieważ trzeba było przez nią przepchnąć trzy takie adresy i kod operacji. Ale nawet pierwszy BESM miał więcej pamięci!
Jak się z nią skontaktować?
Aby wykorzystać całą ilość pamięci RAM, podzielono ją na tzw. "kostki", przedrostki tych kostek zostały wprowadzone do adresowania. Adresowanie pośrednie nie było jeszcze wtedy otwarte (przynajmniej w ITMiVT), więc programiści pisali samomodyfikujący się kod, zmieniając adresy A1, A2, A3 w komendach w ruchu (co z mniej więcej punktu widzenia współczesne zasady programowania, to brudny hack i skandaliczna perwersja, więc nawet wirusy starają się nie pisać, chyba że jest to absolutnie konieczne, ale w BESM był to normalny tryb działania).
Dodatkowym problemem była notoryczna praca z urządzeniami zewnętrznymi, Lebiediew rozwiązał ją tak surowo, jak to możliwe na swoich oryginalnych komputerach - po prostu przez zakodowanie wszystkich połączeń bezpośrednio w sprzęcie, pomimo faktu, że nie było już wystarczającej liczby poleceń. Nie było żadnych prób abstrahowania od urządzeń, co ponownie sugeruje, że był równie doskonałym inżynierem elektrykiem, co wadliwym architektem systemowym. Wynika z tego, że, dzięki Bogu, CDC zostało przyjęte jako prototyp dla BESM-6. Lebiediew rozumiał (czasami) granice swoich kompetencji i nie odważył się opracować od podstaw superkomputera o wymaganym poziomie całkowicie od podstaw według własnego rodzaju fantazji.
Kolejny mit architektoniczny
Kolejny mit architektoniczny związany jest z przenośnikiem, mówią, że BESM-6 była pierwszą maszyną na świecie, na której genialny Lebiediew zbudował swój „rurociąg wodny”, o czym relacjonował na konferencji w Darmstadt, a ciasni Europejczycy doświadczyli szok i przerażenie.
W rzeczywistości idea przenośnika została wyrażona przez Konrada Zuse i zaimplementowana w prymitywnej dwustopniowej formie w Z3. W 1949 próbował opatentować jego implementację w Z4, ale, co zaskakujące, patent został spowolniony aż do połowy lat 1960., mimo że IBM był patronem Zuse.
Podobne pomysły pojawiły się w powietrzu na początku lat pięćdziesiątych, myśleli o nich zarówno Lebiediew, jak i Ramejew, o których dyskutowano na seminariach MPEI. W 1950 roku Wielka Brytania pilnie potrzebowała ogromnego niezamieszkałego terenu do testów nuklearnych. broń. Na szczęście znaleźli taki kawałek ziemi i nazwano go Australią.
W efekcie zawarto umowę partnerską – testowanie stron w zamian za dostęp do nowoczesnych technologii. W ten sposób powstał Australian Weapons Research Establishment (WRE wymyśliło wiele rzeczy, na przykład w 1957 roku stworzyli samą „czarną skrzynkę” dla samolotów).
Specjalnie dla WRE brytyjska firma Elliott Brothers opracowała komputer Elliott model 403 (często nazywany WREDAC). Ta maszyna do produkcji rur weszła do produkcji w 1955 roku i była wyposażona w dwustopniowy przenośnik podobny do patentu Zuse.
Zauważamy, że ani idee Zuse, ani Lebiediewa nie należą do prawdziwego przenośnika we współczesnym znaczeniu tego słowa. Ich „potok” zakładał jedynie połączenie dwóch przeciwnie skierowanych operacji - arytmetyczno-logicznej w procesorze i pobranie kolejnego operandu z pamięci RAM.
Ten przenośnik wiąże się z obecnością zaawansowanego urządzenia sterującego, które działa na zupełnie innej zasadzie. Równoległość na poziomie instrukcji w rzeczywistym potoku oznacza nakładanie się co najmniej trzech operacji na instrukcjach - pobierania, dekodowania i wykonywania, w tym celu konieczne jest zaimplementowanie dość złożonego mechanizmu przewidywania gałęzi warunkowych.
Rurociąg w tym znaczeniu został po raz pierwszy opisany w pracy Donalda Bruce'a Gilliesa, wybitnego kanadyjskiego matematyka i informatyka, który pracował na Uniwersytecie Illinois nad projektem superkomputera ILLIAC II. Była to niezwykle postępowa maszyna, ale jej rozwój zakończył się dopiero w 1962 roku, a cała dokumentacja i zasady działania zostały określone w otwartych pracach naukowych już w latach 1957-1958. i nie opatentowany, twórcy Stretch pożyczyli od nich schemat przenośnika, ale formalnie udało im się wypuścić swój samochód trzy lata wcześniej.
W tym samym 1959 roku, lampowy potwór Kitowa M-100 został wykonany w jednym egzemplarzu, o którym już pisaliśmy, praktycznie nie ma informacji o jego architekturze, niezawodnie wiadomo, że miał architekturę Harvarda i procesor potokowy, ale w jakim stopniu mógł wykonywać programy ogólnego przeznaczenia i jakiego rodzaju był przenośnikiem, nie wiadomo.
Klasyczne jak to jest. BESM-6 w swoim naturalnym środowisku, Hala Turbin ZIBJ, Dubna (fot. https://ramlamyammambam.livejournal.com/). W tym samym czasie w ZIBJ pracowały dwa BESM-4, CDC 1604, CDC 6500, trzy EC-1040, EC-1060, EC-1010, EC-1061 i Robotron KRS-4201. Pod względem liczby instalacji był to najprawdopodobniej najpotężniejszy i największy ośrodek wystawienniczy w ZSRR.
Potok BESM-6 był szpiegowany przez CDC-6600, tylko w Cray każdy procesor miał 10 niezależnych bloków, które mogły wykonywać instrukcje z potoku równolegle, dlatego maszyna ta jest uważana za pierwszy procesor superskalarny na świecie.
Jeszcze bardziej zaawansowane architektury to CDC 7600, stworzony w 1969 roku, oraz IBM System/360 model 91 (1967), który wykorzystywał wszystkie nowoczesne funkcje potoku, w tym wykonywanie spekulacyjne i zmianę nazwy rejestru.
O wiele bardziej prymitywny obwód z sumatorem w BESM-6 nie mógłby mieć potoku we współczesnym znaczeniu tego słowa, podobnie jak pamięć wirtualna. Samo ALU nie było potokowe - gdyby procesor pomnożył dwie liczby, nie mógł zrobić nic innego, chociaż w tym samym czasie można było pobrać kolejną instrukcję. Tak więc wdrożenie „rurociągu” tutaj było przestarzałe o 15 lat, podobnie jak praca Zuse, Rameeva i Elliota.
Ostatnie złudzenie
Ostatnim nieporozumieniem na temat „kolosalnych innowacji” BESM-6 jest obecność w nim pamięci podręcznej.
W rzeczywistości nie było pamięci podręcznej we współczesnym znaczeniu tego słowa, pełnoprawna pamięć podręczna pojawiła się tylko w serii IBM System / 360 model 85 w tym samym 1967 roku.
Pamięć podręczna osoby zdrowej składa się z zestawu wpisów w ultraszybkiej pamięci RAM (zwykle statycznej), każdy wpis jest powiązany z blokiem danych, który jest kopią tego bloku w konwencjonalnej pamięci RAM. Każdy wpis ma identyfikator (często nazywany tagiem), który określa zgodność między elementami danych w pamięci podręcznej a ich odpowiednikami w pamięci głównej. Jeśli w pamięci podręcznej zostanie znaleziony wpis o identyfikatorze zgodnym z identyfikatorem żądanego elementu, używane są elementy z pamięci podręcznej. Nazywa się to trafieniem w pamięci podręcznej. Jeśli wpis zawierający żądany element danych nie zostanie znaleziony w pamięci podręcznej, jest on odczytywany z pamięci głównej do pamięci podręcznej i staje się dostępny dla kolejnych dostępów. Nazywa się to chybieniem pamięci podręcznej.
W BESM-6 zamiast tego modelu były tylko cztery tzw. rejestry bufora liczbowego (BRCh), w których słowa były odczytywane z pamięci, aby później mógł szybciej uzyskać do nich dostęp ALU. Podobnie było 8 (znowu dziwna asymetria) rejestrów bufora zapisu (BRZ), w których umieszczano numer przed zapisaniem do pamięci. Adres, pod którym operand powinien być wpisany, był przechowywany w tzw. BAZ (rejestr buforowy adresu zapisu). Jeśli później okazało się, że adres wykonania pokrywał się z jednym z adresów w BAZ/BAS, operand został pobrany z BRZ/BRCh, a nie z pamięci. To cała „skrzynka” w Besmovsky.
I wreszcie, ostatecznym złudzeniem jest pomysł, że BESM-6 był prekursorem architektury RISC.
Oczywiście w BESM-6 nie ma zbyt wielu poleceń, raczej mało, ale to jedyny parametr, w którym jest podobny do RISC. Jednak pełnoprawny procesor RISC: ma mały zestaw prostych instrukcji, ogromną liczbę RON (rejestrów ogólnego przeznaczenia), opracowany schemat ich zmiany nazwy, instrukcje elementarne oraz przewidywalną i standardową szybkość wykonywania dowolnego z nich - 1–2 cykle.
Jeśli przeczytałeś ten artykuł do tego momentu, już wiesz, że BESM-6 przeleciał tutaj pod każdym względem, z wyjątkiem liczby drużyn.
Jak już powiedzieliśmy, wszystko było smutne z oprogramowaniem w BESM-6.
Został dostarczony tylko z prekursorem systemu operacyjnego Dispatcher-68 opracowanego przez ITMiVT, który umożliwiał jedynie wsadowe uruchamianie zadań i przydzielanie im zasobów. Autokod Lebiediewa został zaproponowany jako język, który został natychmiast porzucony przez wszystkich odpowiednich ludzi. Jak już wspomnieliśmy, była nadzieja, że będzie możliwe natychmiastowe uruchomienie całej gamy oprogramowania z CDC 6 na BESM-1604, ale to się nie zmaterializowało. W efekcie każda grupa naukowa zaczęła gorączkowo wycinać dla siebie różne implementacje języków i systemów operacyjnych, oczywiście niekompatybilnych ze sobą.
Najfajniejszy z nich był sam system monitorów Dubna – zresztą nie wystarczyły mu siły ZSRR, trzeba było połączyć Niemców z NRD, Węgrów, a nawet Mongołów – cały Międzynarodowy Komitet JINR.
W jego ramach można było ponownie wybrać skradzione kompilatory Fortran i Algol-60, znacznie później niż LISP i Pascal, ale wszystko to kosztem piekielnych wysiłków. Algol-60 został pierwotnie stworzony w Centrum Komputerowym Akademii Nauk ZSRR w Laboratorium Programowania pod kierunkiem V.M. Kurochkina, najpierw dla BESM-2, później przeniesiony do BESM-6 (dla BESM-4 było co najmniej 3 różne kompilatory z Algolem-60, nie mniej niż 2 różne asemblery, Dubninsky i Bayakovsky oraz kompilator z oryginalnego języka Epsilon - to takie typowe zoo), i jak wielu mówiło, pozostał dla niej jedynym tłumaczem z popularnego język.
Kłopot polegał na tym, że w 1964 roku wyszła nowa specyfikacja językowa, zwykle nazywana (po ostatnim roku przyjęcia standardu) Algol-68, której Kuroczkin już nie opanował. Tłumacz Algol-68 z CDC 1604 działał krzywo, co przerwało uruchomienie wielu programów CERN, na które liczyli nasi fizycy w Dubnej.
W Europie Algol-68 był przez długi czas używany przez Brytyjski Królewski Komitet ds. Komunikacji i Radaru.
W ZSRR istniały grupy robocze dla rozwoju Algol-68 (na przykład Nowosybirsk pod kierownictwem akademika Andrieja Pietrowicza Erszowa, Leningrad pod kierownictwem Andrieja Nikołajewicza Terekowa, Moskwa pod kierownictwem Aleksandra Nikołajewicza Masłowa i Michaiła Ruwimowicza Lewinsona ). Na Leningradzkim Uniwersytecie Państwowym powstał kompilator i potężny system programowania w Algolu-68, ale… już dla komputera UE, który działał przez wiele lat (swoją drogą, dlatego UE pojawiła się w Dubnej, dla ze względu na rozwinięte peryferia oraz ze względu na ilość oprogramowania i kompilatorów, które nie są dostępne dla BESM-6 lub działają niepoprawnie).
Tylko zdjęcie referencyjne - instalacja dwóch BESM-6 jednocześnie w Centrum Obliczeniowym Moskiewskiego Uniwersytetu Państwowego (zdjęcie http://www.besm-6.su)
Wiele programów pojawiło się po zapoznaniu się z zagranicznymi kodami źródłowymi, na przykład wspomniany już N.N. Govorun z LVT JINAT, po podróży służbowej do CERN, wykorzystując wydruki maszynowe z CDC 3200 wykonane w ich centrum komputerowym, zaimplementowane na BESM-6 Fortran i bibliotek standardowych programów, sześć BESM -6 zostało przekazanych do NRD, a ich programiści z ZIBJ, po wyjeździe do ojczyzny, stworzyli własną wersję asemblera, Fortran-GDR i Algol-GDR (działał 20–30%). szybciej niż krajowe).
Z. F. Bochkova, G. N. Ezerov, V. M. Michelev pod kierunkiem V. S. Shtarkmana z IPM. Keldysh (po podróży służbowej do IBM) opracował autokod BEMSh, ponieważ oryginalny autokod MG Czajkowskiego, oparty na mnemonikach samego Lebiediewa, był zasadniczo dwuliterowy i całkowicie nielogiczny i nieczytelny, co spowodowało wiele niekompatybilnych zmian.
System plików BESM-6 nigdy nie został napisany i dokończony do końca, generalnie każdemu ośrodkowi naukowemu udało się napisać coś własnego ze szkodą dla wszystkiego innego. W Czelabińsku była archiwizacja na taśmach, w Dubnej - ludzkim języku do opisywania zadań i Fortran-NRD i Algol-NRD, w VMK MGU - LISP i DISPAK.
Dokumentacja do BESM-6 była osobnym świętem. Wyobraź sobie, że jesteś zwykłym doktorantem lub młodszym pracownikiem naukowym, który przyszedł do pracy z wydziału, powiedzmy, matematyki. I zaproponowano ci zagłębienie się w TO. Aby tak jakościowy opis maszyny dla użytkowników końcowych, ci użytkownicy w USA spalili Cray'a na stosie z instrukcji.
Oczywiście zarówno oryginalny OS/360, jak i IBM miały problem, ale bardzo szybko naprawiły sytuację, podczas gdy w ZSRR bałagan z tysiącami bibliotek napisanych w różnym czasie przez kogokolwiek i niekompatybilnych ze sobą nigdy nie został w ogóle rozwiązany. obszary, w których sprawa nie dotyczyła bezpośredniego kopiowania oprogramowania dla UE.
Wszystko, z czego fani BESM-6 są tak dumni - słynne OS ND-70, Dubna, DISPAK itp. zostały opracowane dopiero w połowie lat 1970-tych. Dzięki firmie DISPAK w 1972 roku udało im się wreszcie podłączyć dyski twarde ze sterownikami przejętymi z General Electric do BESM-6, wcześniej pracowano z archaicznym bębnem, pierwotnie z początku lat pięćdziesiątych.
Maszyny IBM pracują z dyskami od 1956 roku - to kwestia „zaawansowanej architektury” BESM-6. Jeden bęben miał pojemność 16 kg (192 kilobajty) i ważył pół tony. Bębny można dołączyć maksymalnie do 4 sztuk. W tym samym czasie zwykłe dyski twarde IBM miały pojemność 5 megabajtów, a duże - 30 megabajtów. Zauważ, że BESM-6 w Dubnej miał pewne różnice sprzętowe, od parzystości znaków w liniach terminala do bitów adresu fizycznego w rejestrach.
W rezultacie Dubna OS nie uruchamiał się na maszynach z więcej niż 4 kostkami pamięci, ponieważ dodatkowe bity adresu fizycznego są wykorzystywane przez dyspozytora do własnych celów. Generalnie wyjaśnia to, dlaczego Dubna nie była popularna w innych miejscach.
Ogólnie rzecz biorąc, ludzie, którzy są daleko od zachodniego projektowania komputerów, często nie mogą zrozumieć, że najważniejszą rzeczą w samochodzie nie jest sprzęt, ale oprogramowanie. Pod gotową maszyną nie są zapisywane programy. Maszyna jest stworzona w taki sposób, aby wygodnie było pisać dla niej programy, a jeszcze lepiej - korzystać z istniejących przy minimalnych zmianach. Niestety, nawet na Zachodzie nie wszyscy rozumieli istotę tego prostego aksjomatu.
Fred Brooks, jeden z czołowych deweloperów Stretcha, sformułował to bardzo jasno - projektowanie dowolnej architektury komputerowej powinno zaczynać się od zebrania wymagań użytkownika, a nie od osobistej przemyślanej decyzji konkretnego architekta systemu i jego osobistej, unikalnej wizji tego, co maszyna powinna się okazać.
Nie ludzie dla komputera, ale komputer dla ludzi.
Drugim krokiem jest sformułowanie projektu systemu dowodzenia, który najlepiej usatysfakcjonuje użytkowników końcowych (a dla architekta systemu użytkownicy końcowi to programiści niskiego poziomu, którzy stworzą całe oprogramowanie dla zwykłych śmiertelników), a dopiero potem opracowywane są konkretne rozwiązania obwodów zaczynać.
Do perfekcji opanowały ten cykl dwie firmy – IBM, która ucząc się od Stretcha i stworzyła świetnego S/360, oraz Burroughs, która podobnie rozwinęła nie mniej świetną serię B5000 (tu mówimy o masowych maszynach komercyjnych, CDC i Cray podobnie stworzyły naukowe superkomputery - zbierają aplikacje i wymagania naukowców i starają się je jak najlepiej zaspokoić).
W rezultacie komputery mainframe z serii Z są nadal kompatybilne z maszynami z lat 1960. XX wieku, branża bankowa ma miliardy linii kodu napisanego w języku Kennedy'ego COBOL, a IBM i Burroughs (w wcieleniu UNISYS) są jedynymi producentami komputerów mainframe, którzy się ujawnili. XIX wieku, kiedy powstały, w XXI wieku.
W ZSRR ten aksjomat, niestety, nie został zrealizowany (w ogóle ze słowa), biorąc pod uwagę fakt, że w 1960 roku mieliśmy ITMiVT jako monopolistę porównywalnego z IBM. Ten sam Yuditsky zaprojektował Almaza do specyficznych wymagań systemu obrony przeciwrakietowej (a następnie GRU), a jego potencjalni użytkownicy byli zachwyceni prototypowymi modelami maszyny, chociaż nie pozwolili mu wypuścić serii. W ITMiVT wszystko było inne, domyślnie wierzono, że genialny Lebiediew wie lepiej od ciebie jakiego komputera potrzebujesz, jest profesjonalistą, więc żyj z systemem dowodzenia i architekturą, którą zrodził.
Osoby dobrze obeznane z nowoczesnymi technologiami nie dadzą się źle zrozumieć lub zniesmaczyć znajomością np. szczegółów implementacji zarządzania pamięcią w S/360. Znajomość cech programowania niskopoziomowego w BESM-6 często szokuje współczesnych programistów. Tak naprawdę dziadkom wcale nie było łatwiej, więc oprogramowanie dla BESM-6 pisano bardzo długo, bardzo długo, aż do jego śmierci w latach 1990-tych.
Niektóre wdrożenia zakończyły się sukcesem, inne nie, wszystko to było dziełem odmiennych instytutów badawczych i ośrodków badawczych, niejako rozsianych po całym kraju. Mit o jakości i ilości oprogramowania dla BESM-6 wynikał w dużej mierze z tego, że po pierwsze wydano ich prawie 400 (łącznie z modyfikacjami), co było nieprawdopodobne jak na standardy Unii, prawie każdego większego ośrodka naukowego i po drugie, były nitowane przez 6 lat i używane przez 20 lat.
W rezultacie naukowcy, ludzie są dalecy od głupoty, w tym czasie mogli narodzić się całkiem sporo tolerowanych programów. Oczywiście istniały też duże teoretyczne szkoły programowania (ogólnie najmocniejsi radzieccy programiści, szanowani na całym świecie jako teoretycy informatyki, byli ludźmi, którzy przybyli tam z matematyki, poczynając od Lapunowa i Szura-Bura).
Opracowano teoretyczne zasady budowania systemów operacyjnych i kompilatorów, pisano artykuły, broniono rozpraw, tworzono szkoły naukowe. Wszystko to było oczywiście godne zarówno ilości, jak i jakości.
Jedynym problemem było to, że doskonała nauka akademicka siedziała w swojej wieży z kości słoniowej, pomagając w przełomowych osiągnięciach, takich jak DISPAK, Dubna i ND-70, ale kraj potrzebował dziesiątek tysięcy programistów, a nie tylko dziesiątek programistów akademickich. Nie mieliśmy z nimi problemów, ale ze zwykłymi enkoderami...
W następnym artykule zakończymy rozważania na temat tego przełomowego rozwoju krajowego.
To be continued ...
informacja