Nașterea apărării antirachetă sovietice. Pro și contra BESM-6
CDC 6200
În ceea ce privește viteza, BESM-6 în acei ani nu mai era nici o fântână, din 1960 computerele au mers mult înainte și a trebuit să caut o soluție la această problemă. URSS și-a înghițit mândria pentru a doua oară și a mers să ceară să-i vândă și CDC 6600. Aici KoKom și-a odihnit deja cornul și au jignit nu numai Uniunea, nici un singur CDC 6600 nu a fost livrat nimănui din afara SUA, chiar şi Franţa a fost refuzată. Abia în 1972, KoKom a permis (și apoi sub stricta sa supraveghere) să instaleze în Dubna versiunea junior a CDC 6200, care a fost actualizată la multiprocesorul 1975 în 1 (deja depășită după lansarea Cray-6500) și flagship-ul 6600 a rămas un monstru pur american.
Iată cum își amintește G. Ososkov acest lucru (Ziarul „Dubna”, nr. 21 (3759) din 27 mai 2005)
Cele mai multe dintre prezentările utilizatorilor de la conferința Dulus au fost dedicate discuției despre oportunitățile și dezavantajele acestei rețele. Acum, 30 de ani mai târziu, astfel de posibilități par comune, dar la momentul respectiv arăta destul de fantastic. Scopul principal al călătoriei a fost încheierea de contracte de cumpărare a calculatoarelor CDC-6200, ocolind notoriul acord COCOM care vizează interzicerea furnizării celor mai noi tehnologii informatice către țările socialiste. Acceptând o inspecție permanentă de către COCOM în Dubna, Direcția LVTA în 1972 a obținut permisiunea de a cumpăra CDC-6200. Astfel de mașini din seria 6000 aparțineau unor computere puternice, existau multe programe de aplicație pentru ele în biblioteca CERN și, deși 6200 era deja destul de depășit, o astfel de achiziție a permis LVTA în 1974 să dezvolte mașina la CDC-6400, iar anul următor la un multiprocesor CDC-6500. Împreună cu BESM-6, aceasta a crescut dramatic puterea de calcul a JINR, a făcut posibilă crearea unei rețele extinse de terminale și lansarea stațiilor Fortran.
Cel mai amuzant lucru la asta povestiri faptul că o mașină cu indicele CDC 6200 nu a existat niciodată în natură! Nu a fost lansat de CDC și nu se găsește în nicio sursă occidentală!
Ce este asta?
Este foarte simplu - compania lui Cray avea nevoie de noi parteneri, afacerile sunt bune, dar CoCom nu a fost de acord să furnizeze sovieticilor nici măcar un supercomputer junior - 6500. Apoi inginerii CDC au demontat un procesor de pe acesta, au făcut un alt downgrade și au primit un stub unic - CDC 6200 special pentru URSS într-un singur exemplar. Li s-a permis să vândă stub-ul, iar câțiva ani mai târziu, când linia a fost depășită și a fost întreruptă, CoCom a permis ca procesorul să fie înșurubat.
O poveste similară repetată apoi cu CDC 7600 și Cray-1, nu au reușit să cumpere, iar încercarea de a crea o clonă sub formă de „Electronics SS BIS” a eșuat fenomenal, dar au reușit să cumpere legal încă două CDC-uri, modele mai simple. , CYBER 170 și 172.
CYBER 172 a fost achiziționat în 1975 pentru Centrul Hidrometeorologic al URSS și a funcționat acolo cu succes până în 1996. În general, studiul climei a fost extrem de important pentru URSS datorită suprafeței vaste a țării și nevoilor de transport maritim și de utilizare a terenurilor, astfel încât Centrul Hidrometeorologic avea una dintre cele mai puternice mașini ale Uniunii, nu inferior lui Dubna și Arzamas-16 și, de obicei, se foloseau mai multe mașini deodată. Primul computer pentru meteorologi a fost M-20, care a funcționat acolo din 1959 până în 1962, a fost aruncat după doar trei ani și nu e de mirare.
Directorul Centrului Principal de Calculatoare Vladimir Antsipovich, care a lucrat acolo de peste 40 de ani, își amintește:
A fost înlocuit cu M-220, apoi cu M-222 și Vesna, un computer destul de exotic cu o capacitate de 300 KIPS, creat în 1965 la Biroul de Proiectare a Automatizării Industriale al Ministerului Industriei Radio (după cum puteți vedea, în ciuda BESM-6, alte ministere au continuat să joace cu entuziasm arhitecturile grădinii zoologice).
Această mașină a funcționat la Centrul Hidrometeorologic până în 1972, în paralel cu vârful mainframe-urilor pur sovietice - Minsk-32. De asemenea, din 1968 până în 1985, BESM-6 a mai lucrat acolo.
CYBER-172 a fost primul străin din MCC (pentru meteorologi, în 1975, au vrut să cumpere un CDC 7600, dar s-au întrerupt de CoCom), iar dominația supercalculatoarelor occidentale în meteorologia sovietică a început odată cu aceasta. În general, au vrut să cumpere două dintre ele, dar CoCom a plantat și aici un porc, au decis că două dintre acestea sunt prea grase pentru URSS.
Desigur, au existat atât UE 1060, cât și 1066, precum și IBM 3033 - cel mai recent înlocuitor pentru linia S / 370, lansat în 1979, cu toate acestea, pentru conspirație a fost numit Hitachi (totuși, există o poveste tulbure - dacă ai noștri și-au cumpărat clona cu licență de la Hitachi, sau IBM original, dar au numit-o că, de dragul unui secret mai mare, în orice caz, mașina Hitachi 3033 nu există în natură, există doar Hitachi HITAC M-220 sau IBM 3033. ).
În 1992, doreau deja să livreze Elbrus-2 îndelungat, dar apoi dintr-o dată CoCom a aprobat vânzarea către Rusia a celui mai puternic Cray Y-MP, care este de aproximativ 30 de ori mai mare decât Elbrus. În timp ce discutam toate detaliile - instalația s-a mutat în 1996 și a căzut deja din Thor 500 Cray Y-MP.
Acest monstru a lucrat în MCC timp de 10 ani continuu, până în 2006, când a murit în siguranță la un post militar. Acest lucru se datorează în mare măsură faptului că la trei ani de la instalare, din motive financiare, a trebuit să continui să folosesc Cray Y-MP fără suport din partea producătorului. Antsypovich spune:
Apoi au apărut două clustere - SGI Alltix 4700 (11 Tflops 832 Intel Itanium 2 9140M) și SGI Alltix ICE (16 Tflops, un număr necunoscut de Intel Xeon E5440), iar în 2019 autoritățile au optat pentru un nou cluster de la Cray - XC40.
CYBER 170 a fost achiziționat în 1976 pentru laboratorul LNIVT-urilor Academiei de Științe a URSS de la Lian, acum SPII RAS. Soarta mașinii Centrului Hidrometeorologic este necunoscută de autor și a văzut rămășițele mașinii LIAN cu ochii săi în clădirea SPII RAS de pe insula Vasilyevsky, este dificil să ajungi acolo, dar nu imposibil, angajații sunt foarte prietenoși și, dacă suni și ești de acord în prealabil, vor fi bucuroși să ofere un scurt tur, astfel încât cei care locuiesc în Sankt Petersburg au șanse mari să atingă istoria.
Pentru a rezolva problema cu lipsa puterii de calcul, până în 1973 Melnikov a dezvoltat așa-numitul. echipamente de interfață, complexul AS-6, de fapt un comutator programabil complex cu memorie suplimentară și coprocesoare, care vă permite să combinați mai multe BESM-6 și să le transformați într-un cluster cu RAM partajată. Au fost realizate în total 8 seturi.
întrebări
Avem două întrebări la care să răspundem.
În primul rând, de ce arhitectura sistemului BESM-6 a fost atât de nereușită?
În al doilea rând - care au fost punctele sale forte și de ce a fost atât de plin de mituri și legende?
Să începem cu faptul că Lebedev și-a proiectat inițial primele mașini în scopuri foarte specifice - în special pentru rezolvarea sistemelor de ecuații diferențiale (adică calcularea traiectoriei rachetelor sau modelarea reacțiilor nucleare). El a înțeles cum să construiască astfel de computere, deoarece el însuși a fost un remarcabil inginer electric și dezvoltator de calculatoare analogice pentru modelarea acelorași ecuații diferențiale.
Spre deosebire de Eckert, Wilks, Amdalla - Lebedev nu era tocmai un informatician, nu avea mentalitatea adecvată și, cu atât mai mult, nu era programator, singura sa încercare de a crea un autocod s-a încheiat cu faptul că nimeni nu a folosit această groază. Prin urmare, Lebedev nu și-a imaginat îndeaproape problemele utilizatorilor mașinilor sale, el a construit, deși formal și universal, dar în spirit mai degrabă calculatoare monosarcini, bine adaptate la rezolvarea sistemelor de difurs și prost la orice altceva.
Apropo, aceasta a fost o problemă comună pentru toată lumea din ITMiVT: puteau încă să creeze mașini pentru oamenii de știință în rachete, dar un computer cu adevărat universal era deja cu mare dificultate. Burtsev a avut în cele din urmă aceleași probleme cu Elbrus, luând ca bază mainframe-ul bancar Burroughs și încercând să-l transforme într-un computer de control al apărării antirachetă. Cel puțin, s-a dovedit, dar nici un supercomputer de uz general de succes pentru oamenii de știință din Elbrus nu a apărut.
CDC a făcut mașini pentru sisteme de control și calcul științific, în timp ce IBM a făcut mașini pentru afaceri, în principal pentru sisteme financiare și contabile. Acestea sunt domenii de aplicare fundamental diferite și și-au pus amprenta asupra arhitecturii. BESM-6 a atins nivelul absolut în această divizie.
Să începem cu un fapt care a apărut deja aici. Nu avea aritmetică întregi. În general. Nu a fost deloc.
Era în CDC 1604 și era foarte avansat, dar Lebedev l-a aruncat din BESM-6, de ce?
Pentru că toată viața a construit zdrobitoare monotasking de ecuații diferențiale (monotasking - în sensul că, conform logicii sale, ele au fost pur și simplu lansate în detrimentul unui sistem de diferite difuri, și mai mult - nu erau folosite în mod deosebit), și întregi nu este nevoie de aritmetica acolo. Drept urmare, confruntat cu dificultățile de a combina realul și întregul ALU, a aruncat pur și simplu întregul, hotărând că în cazul în care cineva are nevoie brusc de el, să-l emuleze cu unul real.
De ce avem nevoie de aritmetica întregi?
Răspunsul este simplu - pentru manipularea adreselor din RAM. După cum ați înțeles deja, atât CDC-1604, cât și BESM-6 erau mașini cu sumator (adică, în terminologia modernă, aveau doar două registre, dintre care unul a fost alocat - un acumulator în care au fost efectuate toate acțiunile). În parte, aceasta este similară cu arhitectura de stivă găsită în prezent în Forth și Java.
Problema este că, cu o astfel de organizare, ALU-ul trebuie să încarce / să descarce constant ceva în memorie, iar acest lucru necesită registre de index și aritmetică avansată de index care vă permite să manipulați adresele din RAM.
Apropo, a existat un anumit inconvenient în BESM-6 și CDC - lungimea cuvântului din registrele de index nu a coincis cu dimensiunea cuvântului (!) Și dimensiunea registrului acumulatorului și nici măcar nu a fost un multiplu al acestuia ( 15 și 48 de biți), ceea ce era încă normal pentru standardele din 1959-1960, dar să trageți un astfel de arhaism în 1968 este deja întuneric.
Așadar, firește, mașinile cu sumatori aveau destul de dezvoltată aritmetica întregului tocmai din cauza necesității de a încărca ceva din RAM sau de a-l arunca în el în fiecare ciclu de ceas, în timp ce Lebedev a ignorat această caracteristică a CDC. Ca urmare, fiecare calcul de adresă a necesitat emulare pe un procesor real, care nu a afectat pozitiv nici viteza de lucru, nici comoditatea programării.
O altă problemă foarte serioasă a BESM-6 a fost periferia.
În primul rând, după cum am spus deja, Melnikov a abandonat procesoarele de canal și a explicat astfel:
Dar dacă te gândești cu atenție sau pur și simplu compari costul și volumul echipamentului necesar pentru implementarea interfeței cu dispozitivele externe în ambele cazuri, atunci deciziile luate în BESM-6 s-ar putea să nu fie atât de proaste. De fapt, fiecare dispozitiv extern pentru interfața standard include un controler sau este conectat la acest dispozitiv foarte scump și complex care oferă o ieșire standard către canale multiplex sau selectoare. Dacă însumăm costurile echipamentelor suplimentare și spațiul ocupat de acesta, necesar la conectarea dispozitivelor printr-o interfață standard, se dovedește că sistemul BESM-6 este de multe ori mai economic. Cu alte cuvinte, dispozitivul de control centralizat BESM-6 este de câteva ori mai ieftin decât costul controlerelor pentru un set standard de dispozitive externe de stocare și intrare/ieșire ale mașinilor din aceeași clasă.
Cu toate acestea, într-un număr de modele de mașini IBM, a fost introdus așa-numitul adaptor de fișiere integrat, care vă permite să conectați un dispozitiv de stocare pe disc la un computer fără a utiliza un canal și un controler standard. În acest fapt, se poate observa o analogie cu modul rațional de conectare a dispozitivelor adoptat în BESM-6.
Tradus în limbaj obișnuit, se dovedește următorul lucru - pentru a implementa o muncă sănătoasă cu coprocesoare de canal, ca în S / 360, nu aveam destui bani și dorința lui Lebedev, care s-a opus fanatic introducerii coprocesoarelor în mașinile sale (o remediere). Ideea rămasă din zilele tubului, când încă câteva mii de lămpi de calitate sovietică nu ar fi, evident, îmbunătățit fiabilitatea, iar jocul nu a meritat lumânarea, Burtsev a împins procesoarele de canal în 5E26, ceea ce și-a crescut dramatic performanța, de fapt, în urmă. deja foarte bolnav Lebedev, care atunci nu era la înălțime de arhitectură).
În general, lucrul cu canale a fost adesea prea confuz pentru programatorii noștri, de unde și miturile despre superioritatea BESM-6 în acest sens față de serialele UE. Având în vedere alfabetizarea lor scăzută, problemele uriașe de calitate cu primele clone din UE și absența aproape completă a tutorialelor, documentației, programe mostre, patch-uri etc., desigur, lucrul cu un lucru atât de complex precum canalele ar putea fi un iad în comparație cu implementare I/O în BESM-6, simplu ca o cizmă de pâslă. De aici și numeroasele mituri despre arhitectura incredibil de progresivă.
În același timp, mulți oameni confundă diferite niveluri de arhitectură - arhitectura sistemului de comandă și arhitectura sistemului, care descrie, printre altele, conexiunea fizică a perifericelor etc. Totul a fost în regulă cu arhitectura sistemului din BESM- 6 - mașinile puteau fi conectate în rețea, grupate până la 8 computere, era posibil să se conecteze până la 128 de terminale, inclusiv cele de la distanță, un controler de disc cluster (fiecare mașină cluster are acces la fiecare disc), etc. toate computerele occidentale din această clasă ).
Un paradox amuzant este faptul că multe soluții tehnice de succes s-au născut din încercările de a depăși mizeriile elementului intern de bază.
De exemplu, tehnologia progresivă a înregistrării pe bandă dublă (chiar dacă un bloc are erori, dar în două locuri diferite, va fi asamblat din bucăți și va fi citit în mod normal) a apărut ca răspuns la calitatea dezgustătoare a casetei sovietice, care a început să fie se prăbușește literalmente după două sau trei rulări - în UE , după IBM, nu a existat un astfel de mecanism, ca urmare, a apărut un mit despre nefiabilitatea subsistemului lor de înregistrare pe bandă în comparație cu BESM.
În același timp, nu hard disk-urile progresive au fost folosite ca unitate magnetică, ci un tambur magnetic învechit, în timp ce controlerele pentru discuri au apărut abia în 1974, după ce au fost copiate de pe controlerele vechilor mainframe General Electric (în acel moment atât de depășite încât CoCom a permis vânzarea lor oficial pentru nevoile KIAE și ITEP, neoficial - demontate în piese de schimb utile pentru BESM-6).
În general, se poate scrie o carte separată despre ororile periferiei pur sovietice, precum și despre calitatea acesteia. Într-o discuție despre BESM-6 în jurnal 1500py470.livejournal, unul dintre programatorii care a lucrat cu ea a lăsat astfel de amintiri despre asta:
G. N. Tentyukova, șeful sectorului OMOED al LVTA, își amintește (săptămânalul JINR „Dubna” nr. 34 (4325) din 11 august 2016, „Când mașinile erau mari”):
Dacă doriți, puteți găsi atât de multe astfel de amintiri încât nici un articol nu le poate găzdui.
Chiar și angajații JINR înșiși au scris în ziarul „Dubna” în 1990 (când era deja posibil să nu fie timid:
În general, a devenit posibil să se lucreze normal pe BESM-6 la aproximativ 15 ani de la lansarea mașinii - când tovarășii cei mai pătrunzători care aveau cele mai puternice conexiuni (precum oamenii de știință din Dubna) au aruncat la coș toată periferia BESM-ului însuși. (și în același timp din UE, era mult mai bine, dar în comparație cu importurile - fier vechi monstruos) și au furnizat totul american, japonez și german (în cel mai rău caz - polonez sau ungur).
În plus, era de dorit să facem upgrade de memorie, să fixăm terminalele normale cu cârje infernale (în cel mai rău caz - din UE) și să scriem noi înșine o grămadă uriașă de software, de la traducători la OS. Atunci ar putea rămâne amintiri calde de lucru cu BESM-6.
În general, în toți anii de existență a Uniunii, o idee simplă a fost categoric nestăpânită în ea - clientul dorește un produs finit, și nu un semifabricat brut care trebuie finisat ani de zile. Imaginați-vă situația - NSA primește CDC 6600 comandat de ei pentru zece milioane de dolari, computerul ajunge fără periferice (sau cu unul cu care este imposibil de lucrat și, dacă este posibil, trebuie să îl conectați cu un fier de lipit și magie cunoscută). cuvinte timp de șase luni), fără sistem de operare sensibil, fără compilatoare și cu un asamblator complet nebun.
Și domnilor, criptografii trebuie să facă toate lucrările de punere în funcțiune cu propriile mâini și pe cheltuiala lor, să scrie software și, în general, să lucreze normal cu mașina în 10 ani, înainte de aceeași - aveți răbdare. Pentru orice companie de tip piata, un astfel de truc ar fi ultimul din munca lor, un client nemultumit nu va veni a doua oara. În economia planificată, nu a fost de ales, ca clasă - orice s-a demnat partidul să dea, apoi să mănânce.
Mitul performanței
În ceea ce privește performanța, există un mit conform căruia BESM-6 a fost incredibil de puternic, aproape la nivelul CDC 6600. Performanța declarată a BESM-6 este de 1 MIPS. În realitate, aceste informații sunt fundamental de nesuportat, deoarece timpul de execuție al comenzilor poate diferi cu un ordin de mărime.
De exemplu, viteza teoretică de funcționare a unui dispozitiv multiplicator (MD) ar putea atinge cu adevărat valori de 1–1,3 MIPS, în timp ce viteza practică, atunci când MU a accesat intens memoria în proces, nu a depășit 0,5–0,8 MIPS. . Comenzile de divizare au funcționat cu o viteză de 0,15–0,3 MIPS, în timp ce comenzile cu returnarea datelor de la AU la CU (UI, MOD etc.) puteau emite orice, deoarece așteptau executarea a 5. echipe (4 de la LHC și 1 de la PR). În acest caz, ciclul de memorie BESM-6 este de 2 µs, adică instrucțiunile care citesc un operand care nu se află în BRZ ar putea, în cel mai rău caz, să obțină +2 µs la timpul lor de execuție.
În 1992, înainte de a scoate din funcțiune BESM-6, angajații Centrului de Cercetare și Dezvoltare au comparat performanța acestuia în numărarea combinațiilor de punte cu 286 de procesoare (implementarea AMD, overclockată la 16 MHz, față de standardul 12) și, potrivit acestora, au primit aproximativ numere egale. Performanța lui AMD 286 a depășit 2,6 MIPS, dar nu știm ce versiune de BESM-6 (cel mai probabil, Elbrus-1K2, pe IC este mult mai puternică decât originalul) au folosit.
În cartea „De la microprocesoare la computerele personale” (Cheremnykh S. V., Giglavy A. V., Polyak Yu. E., 1988, Radio și comunicare), exemple de referință (adăugarea și multiplicarea matricelor într-un ciclu) sunt date în diferite limbi pentru diferite mașini și având în vedere timpul de execuție a acestora. Conform acestor informații, timpul de execuție a testului a fost (în funcție de limbă) de la 0,08 la 0,23 s pentru BESM-6 și de la 0,11 la 0,38 s pentru EU 1055M, 0,45 s pentru DVK (procesor MS 1201.02) și 0,37 s pentru PC/ AT cu procesor de 16 MHz.
Toate aceste date sunt foarte contradictorii și, în absența unui BESM-6 funcțional, nu va fi posibil să aflăm adevărul, totuși, observăm că rezultatul mediu într-o problemă aleatorie nu depășește în orice caz 0,8–1,5 MIPS. .
Rețineți că această viteză a fost atinsă de IBM 7030 Stretch cu opt ani mai devreme, legendarul CDC 6600 a confirmat mai mult de 3 MIPS cu 4 ani mai devreme, iar vechiul S/360 a produs același 0,8–1 MIPS cu câțiva ani mai devreme.
Astfel, vedem că BESM-6 s-ar număra cu siguranță printre deținătorii recordurilor mondiale în 1959–1960, dar pentru 1968 parametrii săi nu reprezentau nimic supranatural și erau la nivelul standardului pentru un mainframe tipic și chiar la mijlocul deceniului. . La nivelul mașinilor europene de atunci (Siemens, Bull, Olivetti), BESM-6 arăta normal, fără a fi comparat cu CDC (care erau cele mai puternice mașini ale epocii). S / 360 nu au fost mai proaste - la calculele științifice și semnificativ mai bune - la cele financiare.
Nu este nimic de surprins aici.
După cum am spus, BESM-6 nu avea suport pentru aritmetica întregi, ceea ce înseamnă că orice comenzi aritmetice au fost efectuate pe un sumator real, iar acum imaginați-vă plăcerea de a calcula adrese prin emularea aritmeticii întregi aproape în fiecare ciclu - mașina nu este registru , dar antediluvian , cu un sumator, ca urmare, numerele trebuie conduse constant din RAM în RAM. Acest lucru a condus la faptul că, chiar și în cel mai bun caz, citirea necesită 3 cicluri, adăugare - 5 cicluri (în medie - 11, în cel mai rău - 280), înmulțire - 15 cicluri (în medie - 18,5 și în cel mai rău - 162). ), divizia a durat în medie 50 de cicluri. Ca rezultat, programele nu numai că au rulat mai lent decât ar putea, dar au ocupat și mai mult spațiu.
V. V. Przyjalkowski menționează și acest lucru în recenzia sa:
Dacă vorbim despre performanța în cifre conform popularului test Whetstone de atunci, BESM-6 a câștigat aproximativ 0,3–0,4 milioane de operațiuni cu o singură precizie pe secundă, ceea ce a fost la nivelul modelelor IBM medii.
O altă problemă a fost imprevizibilitatea completă a timpului. Aceeași comandă ar putea fi executată pentru timpi care diferă literalmente cu un ordin de mărime! După standardele moderne, acesta este un coșmar, iar după standardele anilor 1970 - nu mult mai bine.
În orice sistem de instrucțiuni, începând cu anii 1960, se știe dinainte exact câte cicluri vor lua cutare sau cutare acțiune, iar aceste timpi sunt prescrise în toate manualele pentru programatorii de nivel scăzut. Lebedev, pe de altă parte, nu a înțeles deloc de ce era nevoie de cel puțin un fel de predictibilitate și nici măcar nu a încercat să o atingă.
Drept urmare, în BESM-6, timpul de execuție variază în funcție de fenomene aleatorii, nu doar de cele evidente - de exemplu, dacă o adresă este inclusă sau nu în prefetch, ci chiar și de valoarea operanzilor.
Nu se știe în legătură cu care concurent Lebedev a spus fraza care i-a fost atribuită: „Da, viteza mașinii tale este mai mare decât a mea, dar având în vedere fiabilitatea scăzută, încă nu va avea timp să calculeze sarcina între două defecțiuni! ”, Dar mulți îl interpretează, ca dovadă a super-fiabilității BESM-6.
A existat un singur loc în lume în care să poată înfrunta CDC 6500 într-o luptă corectă - centrul de cercetare nucleară din Dubna. Iată rezultatul bătăliei lor: au avut același plan anual în orele de muncă - nominal 6000, dar în realitate BESM-6 a lucrat 1979 ore în 6910, iar CDC 7440 ore. Cel mai important lucru se află în alte cifre - 75 de mii de sarcini au fost procesate pe mașina lui Lebedev, pe CDC - aproape 200 de mii ...
Există mai multe mituri persistente despre arhitectura sistemului BESM-6, unul dintre ele este prezența memoriei virtuale.
Acest concept a fost pentru prima dată încorporat în Atlas și a fost implementată și o memorie asociativă pentru a determina prezența paginii necesare de memorie virtuală în RAM.
De ce nu este ceea ce era în BESM-6?
Suportul pentru memoria virtuală face posibilă adresarea mai multă memorie decât este instalată efectiv pe mașină. Pe BESM-6, în versiunea cu RAM triplat, totul a fost invers - era mai multă memorie fizică disponibilă pe mașină decât putea fi abordată! Cert este că, având 128 kwords de memorie, a trebuit să lucrăm cu ea prin adrese de 15 biți (moștenire de la CDC 1604). Datorită conceptului absolut contradictoriu de „păstrați formatul de adresă compatibil cu CDC 1604, dar triplă memoria”, a fost introdusă o cârjă specială - așa-numita 32. registrul de înregistrare. Înainte de a accesa memoria reală, adresa de execuție a fost împărțită în două părți de 5 + 10 biți. Partea înaltă a fost interpretată ca numărul de registru de acasă, din care au fost preluați cei 7 biți ai numărului fizic al paginii și, împreună cu cei 10 biți mai puțin semnificativi ai adresei, au alcătuit o adresă fizică de 17 biți. Lebedev a numit cu mândrie acest regim „memorie virtuală”.
În Atlas, adresa era inițial pe 24 de biți, iar atunci când se adresează dincolo de memoria reală, supervizorul schimba pagina cu adresa virtuală corespunzătoare din RAM din tambur, la fel ca ceea ce se întâmplă acum când paginile sunt schimbate de pe disc.
Apropo, o problemă similară cu adresarea a existat în BESM/BESM-2/M-20/BESM-4, dar totul a fost și mai neglijat acolo. În ele, Lebedev și-a folosit iubitul său sistem de comenzi cu trei adrese în format KOP | A1 | A2 | A3, unde COP este codul operațiunii, adresele A1–A3.
De ce certam atât de mult acest principiu, în exterior totul este frumos?
Cert este că fiecare adresă se putea referi la maximum 4096 de cuvinte, nu mai încapea în magistrală, care era deja prohibitiv de largă, pentru că prin ea trebuiau împinse trei astfel de adrese și un cod de operare. Dar chiar și primul BESM a avut mai multă memorie!
Cum sa o contactez?
Pentru a utiliza întreaga cantitate de RAM, aceasta a fost împărțită în așa-numitele. „cuburi”, au fost introduse prefixe ale acestor cuburi pentru adresare. Adresarea indirectă nu era încă deschisă la acel moment (în ITMiVT, cel puțin), așa că programatorii au scris cod auto-modificabil, schimbând adresele A1, A2, A3 în comenzi din mers (care, din punct de vedere mai mult sau mai puțin). principiile moderne de programare, este un hack murdar și o perversiune scandaloasă, așa că chiar și virușii încearcă să nu scrie decât dacă este absolut necesar, dar în BESM era un mod obișnuit de operare).
O problemă suplimentară a fost munca notorie cu dispozitivele externe, Lebedev a rezolvat-o cât mai dur posibil în mașinile sale originale - pur și simplu prin codificarea tare a tuturor apelurilor direct în hardware, în ciuda faptului că nu existau deja suficiente comenzi. Nu au existat încercări de abstracție de la dispozitive, ceea ce indică din nou că el a fost un inginer electrician la fel de excelent pe cât a fost un arhitect de sistem cu defecte. De aici rezultă că, slavă Domnului, CDC a fost luat ca prototip pentru BESM-6. Lebedev a înțeles limitele competenței sale (uneori) și nu a îndrăznit să dezvolte un supercomputer la nivelul cerut complet de la zero pe propriul său tip de fantezie.
Următorul mit arhitectural
Următorul mit arhitectural este legat de transportor, spun ei, BESM-6 a fost prima mașină din lume pe care ingeniosul Lebedev și-a construit „conducta de apă”, despre care a raportat-o la o conferință la Darmstadt, iar europenii cu mintea îngustă au experimentat-o. șoc și uimire.
În realitate, ideea transportorului a fost exprimată de Konrad Zuse și implementată într-o formă primitivă în două etape în Z3. În 1949, a încercat să breveteze implementarea sa în Z4, dar, în mod surprinzător, brevetul a fost suspendat până la mijlocul anilor 1960, în ciuda faptului că IBM era patronul lui Zuse.
Idei similare au fost în aer la începutul anilor 1950, atât Lebedev, cât și Rameev s-au gândit la ele și au fost discutate la seminariile MPEI. În 1946, Marea Britanie avea nevoie urgentă de o uriașă bucată de pământ nelocuită pentru teste nucleare. arme. Din fericire, au găsit o astfel de bucată de pământ și se numea Australia.
Ca urmare, a fost încheiat un acord de parteneriat - site-uri de testare în schimbul accesului la tehnologii moderne. Așa a fost înființat Australian Weapons Research Establishment (WRE, a inventat o mulțime de lucruri, de exemplu, în 1957 au creat chiar „cutia neagră” pentru avioane).
În special pentru WRE, compania britanică Elliott Brothers a dezvoltat computerul Elliott model 403 (denumit adesea WREDAC). Această mașină cu tuburi a intrat în producție în 1955 și avea un transportor în două trepte similar brevetului lui Zuse.
Remarcăm că nici ideile lui Zuse, nici ale lui Lebedev nu aparțin unui transportor real în sensul modern al cuvântului. „Conducta” lor presupunea doar combinația a două operații direcționate diferit - aritmetic-logic în procesor și preluarea următorului operand din RAM.
Acest transportor implică prezența unui dispozitiv de control avansat care funcționează pe un principiu complet diferit. Paralelismul la nivel de instrucțiuni într-o conductă reală înseamnă suprapunerea a cel puțin trei operațiuni pe instrucțiuni - preluare, decodare și execuție, pentru aceasta este necesară implementarea unui mecanism de predicție a ramurilor condiționate destul de complex.
Conducta în acest sens a fost descrisă pentru prima dată în lucrarea lui Donald Bruce Gillies, un eminent matematician și informatician canadian care a lucrat la Universitatea din Illinois la proiectul de supercomputer ILLIAC II. A fost o mașină incredibil de progresivă, dar dezvoltarea sa s-a încheiat abia în 1962, în timp ce toată documentația și principiile de funcționare au fost expuse în lucrări academice deschise încă din 1957-1958. și nebrevetată, dezvoltatorii Stretch au împrumutat de la ei schema de transport, dar au reușit oficial să-și lanseze mașina cu trei ani mai devreme.
În același 1959, monstrul tubular al lui Kitov M-100 a fost realizat într-o singură copie, despre care am scris deja, practic nu există informații despre arhitectura sa, se știe în mod sigur că avea o arhitectură Harvard și un procesor pipeline, dar pentru În ce măsură ar putea executa programe de uz general și ce fel de transportor era nu este cunoscută.
Conducta BESM-6 a fost spionată de CDC-6600, doar în Cray fiecare procesor avea 10 blocuri independente care puteau executa în paralel instrucțiuni din conductă, motiv pentru care această mașină este considerată primul procesor superscalar din lume.
Arhitecturile și mai avansate au fost CDC 7600, creat în 1969, și IBM System/360 model 91 (1967), care a folosit toate caracteristicile moderne ale conductei, inclusiv execuția speculativă și redenumirea registrului.
O schemă mult mai primitivă cu un sumator în BESM-6 nu ar putea avea o conductă în sensul modern al cuvântului, la fel ca memoria virtuală. ALU în sine nu a fost canalizat - dacă procesorul înmulțea două numere, nu putea face nimic altceva, deși în același timp putea fi preluată următoarea instrucțiune. Deci implementarea „conductei” aici a fost depășită de 15 ani, similar lucrării lui Zuse, Rameev și Elliot.
Ultima amăgire
Ultima concepție greșită despre „inovațiile colosale” ale BESM-6 este prezența unei memorie cache în acesta.
De fapt, nu a existat un cache în sensul modern al cuvântului; un cache cu drepturi depline a apărut doar în seria IBM System / 360 model 85 în același 1967.
Cache-ul persoanei sănătoase constă dintr-un set de intrări în RAM ultra-rapidă (de obicei statică), fiecare intrare asociată cu un bloc de date, care este o copie a acelui bloc în RAM convențională. Fiecare intrare are un identificator (numit adesea etichetă) care definește corespondența dintre elementele de date din cache și omologii lor din memoria principală. Dacă o intrare este găsită în cache cu un ID care se potrivește cu ID-ul articolului solicitat, atunci elementele din cache sunt utilizate. Aceasta se numește hit cache. Dacă o intrare care conține elementul de date solicitat nu este găsită în cache, atunci este citită din memoria principală în cache și devine disponibilă pentru accesări ulterioare. Aceasta se numește o pierdere de cache.
În BESM-6, în locul acestui model, au existat doar patru așa-numite. registrele tampon numerice (BRch), în care cuvintele erau citite din memorie, astfel încât ulterior să poată fi accesate mai rapid de către ALU. În mod similar, au existat 8 (din nou o asimetrie ciudată) registre tampon de scriere (BRZ) în care numărul a fost plasat înainte de a fi scris în memorie. Adresa la care ar trebui să fie scris operandul a fost stocată în așa-numitul. BAZ (registru tampon al adresei înregistrării). Dacă ulterior s-a dovedit că adresa de execuție a coincis cu una dintre adresele din BAZ/BAS, operandul a fost preluat din BRZ/BRCH, și nu din memorie. Asta este întreaga „cache” din Besmovsky.
Și, în sfârșit, amăgirea finală este ideea că BESM-6 a fost un precursor al arhitecturii RISC.
Desigur, nu există prea multe comenzi în BESM-6, mai degrabă puține, dar acesta este singurul parametru în care este similar cu RISC. Cu toate acestea, un procesor RISC cu drepturi depline: are un set mic de instrucțiuni simple, un număr mare de RON (registre de uz general), o schemă dezvoltată pentru redenumirea lor, instrucțiuni elementare și o viteză de execuție previzibilă și standard a oricăruia dintre ele - 1-2 cicluri.
Dacă ați citit articolul până în acest moment, înțelegeți deja că BESM-6 a zburat pe aici din toate punctele de vedere, cu excepția numărului de echipe.
După cum am spus deja, totul a fost trist cu software-ul din BESM-6.
A fost furnizat doar cu precursorul sistemului de operare Dispatcher-68 dezvoltat de ITMiVT, care a permis doar lansarea în lot a sarcinilor și alocarea de resurse acestora. Autocodul lui Lebedev a fost propus ca limbaj, care a fost imediat abandonat de toți oamenii adecvati. După cum am menționat deja, speranța a fost că va fi posibilă lansarea imediată a întregii game de software de la CDC 6 pe BESM-1604, dar nu s-a materializat. Ca urmare, fiecare grup științific a început să-și taie cu febril diverse implementări ale limbilor și sistemelor de operare, desigur, incompatibile între ele.
Cel mai tare dintre ei a fost același sistem de monitorizare Dubna - în plus, forțele URSS nu erau suficiente pentru asta, germanii din RDG, maghiarii și chiar mongolii trebuiau conectați - întregul comitet internațional al JINR.
Sub ea, a fost posibil să se aleagă din nou compilatoarele Fortran și Algol-60 furate, mult mai târziu decât LISP și Pascal, dar toate acestea cu prețul unor eforturi infernale. Algol-60 a fost creat inițial la Centrul de Calculatoare al Academiei de Științe a URSS în Laboratorul de Programare sub conducerea lui V. M. Kurochkin, mai întâi pentru BESM-2, ulterior portat pe BESM-6 (pentru BESM-4 au existat cel puțin 3 compilatoare diferite cu Algol-60, nu mai puțin de 2 asamblatori diferiți, Dubninsky și Bayakovsky și un compilator din limbajul original Epsilon - aceasta este o grădină zoologică atât de tipică) și, după cum au spus mulți, el a rămas pentru ea singurul traducător dintr-un popular limbaj care nu a fost încurcat.
Problema a fost că în 1964 a apărut o nouă specificație de limbă, numită de obicei (după ultimul an a fost adoptat standardul) Algol-68, pe care Kurochkin nu o mai stăpânește. Traducătorul Algol-68 de la CDC 1604 a lucrat strâmb, ceea ce a întrerupt lansarea multor programe CERN pe care se bazau fizicienii noștri din Dubna.
În Europa, Algol-68 a fost folosit de mult timp de către Comitetul Regal Britanic pentru Comunicații și Radar.
În URSS, au existat grupuri de lucru pentru dezvoltarea Algol-68 (de exemplu, Novosibirsk sub conducerea academicianului Andrei Petrovici Ershov, Leningrad sub conducerea lui Andrei Nikolaevici Terekhov, Moscova sub conducerea lui Alexander Nikolaevici Maslov și Mihail Ruvimovici Levinson ). Un compilator și un sistem de programare puternic pe Algol-68 au fost create la Universitatea de Stat din Leningrad, dar ... deja pentru computerul UE, care a fost operat de mulți ani (apropo, acesta este motivul pentru care UE a apărut și la Dubna, pentru de dragul unei periferii dezvoltate și de dragul numărului de software și compilatoare care nu sunt disponibile pentru BESM-6 sau funcționează incorect).
Multe programe au apărut după ce s-au familiarizat cu coduri sursă străine, de exemplu, deja menționatul N. N. Govorun de la LVT JINAT, după o călătorie de afaceri la CERN, pe baza tipăririlor mașinii de la CDC 3200 realizate în centrul lor de calcul, implementat pe BESM-6 Fortran și biblioteci de programe standard, șase BESM -6 au fost predate RDG, iar programatorii lor de la JINR, plecând în patria lor, și-au creat propria versiune a asamblatorului, Fortran-GDR și Algol-GDR (care a funcționat 20-30). % mai rapid decât cei domestici).
Z. F. Bochkova, G. N. Ezerov, V. M. Mikhelev sub conducerea lui V. S. Shtarkman de la IPM. Keldysh (după călătoria sa de afaceri la IBM) a dezvoltat autocodul BEMSh, deoarece autocodul original al lui M. G. Ceaikovski, bazat pe mnemonicii lui Lebedev însuși, era fundamental de două litere și absolut ilogic și ilizibil, ceea ce a dat naștere la multe modificări incompatibile.
Sistemul de fișiere BESM-6 nu a fost niciodată scris și completat până la capăt; în general, fiecare centru științific a reușit să scrie ceva propriu în detrimentul tuturor celorlalte. În Chelyabinsk a existat arhivare pe benzi, în Dubna - limbajul uman pentru descrierea sarcinilor și Fortran-GDR, și Algol-GDR, la VMK MGU - LISP și DISPAK.
Desigur, atât OS/360 original, cât și IBM au avut o problemă, dar au corectat situația extrem de rapid, în timp ce în URSS mizeria cu mii de biblioteci scrise în momente diferite de oricine și incompatibile între ele nu a fost niciodată rezolvată în toate. zone , în care cazul nu se referea la copierea directă a software-ului pentru UE.
Tot ceea ce fanii BESM-6 sunt atât de mândri - celebrele OS ND-70, Dubna, DISPAK etc., au fost dezvoltate abia la mijlocul anilor 1970. Datorită DISPAK, în 1972 au reușit în sfârșit să conecteze hard disk-uri cu controlere preluate de la General Electric la BESM-6, înainte ca oamenii să lucreze cu o tobă arhaică, originară de la începutul anilor 1950.
Mașinile IBM lucrează cu discuri din 1956 - aceasta este întrebarea „arhitecturii avansate” a BESM-6. O tobă avea o capacitate de 16 kilograme (192 kiloocteți) și cântărea jumătate de tonă. Tamburele pot fi atașate la maximum 4 bucăți. În același timp, hard disk-urile IBM obișnuite aveau o capacitate de 5 megaocteți, iar cele mari - 30 megaocteți. Rețineți că BESM-6 din Dubna a avut unele diferențe hardware, variind de la paritatea caracterelor în liniile terminale la biții de adresă fizică în registre.
Drept urmare, sistemul de operare Dubna nu a pornit pe mașini cu mai mult de 4 cuburi de memorie, deoarece biții suplimentari ai adresei fizice sunt folosiți de către dispecer în scopuri proprii. În general, acest lucru explică de ce Dubna nu a fost popular în alte locuri.
În general, oamenii care sunt departe de designul computerelor occidentale nu pot înțelege adesea că principalul lucru într-o mașină nu este hardware-ul, ci software-ul. Nu programele sunt scrise sub mașina terminată. Mașina este creată în așa fel încât ar fi convenabil să scrieți programe pentru ea și chiar mai bine - să le folosiți pe cele existente cu modificări minime. Din păcate, nici în Occident, nu toată lumea a înțeles esența acestei simple axiome.
Fred Brooks, unul dintre cei mai importanți dezvoltatori ai Stretch, a formulat acest lucru foarte clar - proiectarea oricărei arhitecturi de computer ar trebui să înceapă cu colectarea cerințelor utilizatorului și nu cu shiza personală atentă a unui anumit arhitect de sistem și viziunea sa personală unică a ceea ce mașina ar trebui să se dovedească a fi.
Nu oameni pentru un computer, ci un computer pentru oameni.
Al doilea pas este formularea unui proiect de sistem de comandă care să satisfacă cel mai bine utilizatorii finali (și pentru un arhitect de sistem, utilizatorii finali sunt programatori de nivel scăzut, care vor crea tot software-ul pentru muritorii obișnuiți), și abia apoi se dezvoltă soluții specifice de circuit. ÎNCEPE.
Acest ciclu a fost stăpânit la perfecțiune de două companii - IBM, care a învățat de la Stretch și a creat marele S/360, și Burroughs, care a dezvoltat în mod similar seria B5000, nu mai puțin grozavă (aici vorbim despre mașini comerciale de masă, CDC și Cray în mod similar). au creat supercalculatoare științifice - colectând aplicații și cerințe ale oamenilor de știință și încercând să le satisfacă cât mai mult posibil).
Drept urmare, mainframe-urile din seria Z sunt încă compatibile cu mașinile din anii 1960, industria bancară are miliarde de linii de cod scrise în COBOL al lui Kennedy, iar IBM și Burroughs (în încarnarea UNISYS) sunt singurii producători de mainframe care au ieșit. al secolului al XIX-lea, când au fost fondate, în secolul al XXI-lea.
În URSS, această axiomă, din păcate, nu a fost realizată (din cuvânt, deloc), ținând cont de faptul că până în 1960 îl aveam pe ITMiVT ca monopolist comparabil cu IBM. Același Yuditsky a proiectat Almaz-ul conform cerințelor specifice ale sistemului de apărare antirachetă (și apoi GRU), iar potențialii săi utilizatori au fost încântați de modelele prototip ale mașinii, deși nu l-au lăsat să lanseze seria. În ITMiVT totul era diferit, implicit se credea că geniatul Lebedev știa mai bine decât tine ce fel de computer ai nevoie, este un profesionist, așa că trăiește cu sistemul de comandă și arhitectura pe care a dat naștere.
Oamenii care sunt bine familiarizați cu tehnologiile moderne nu sunt înțeleși greșit sau dezgustați de familiaritatea, de exemplu, cu detaliile implementării managementului memoriei în S/360. Cunoașterea caracteristicilor programării la nivel scăzut în BESM-6 șochează adesea programatorii moderni. De fapt, pentru bunici nu a fost mai ușor, așa că software-ul pentru BESM-6 a fost scris mult timp, foarte mult timp, până la moartea sa în anii 1990.
Unele implementări au avut succes, altele nu atât de mult, toate acestea au fost realizate prin eforturile unor institute de cercetare și centre de cercetare disparate, răspândindu-se cumva în toată țara în moduri diferite. Mitul despre calitatea și cantitatea de software pentru BESM-6 a apărut în mare parte din faptul că, în primul rând, au fost lansate aproape 400 dintre ele (inclusiv modificări), ceea ce a fost incredibil pentru standardele Uniunii, aproape fiecare centru științific major și în al doilea rând, au fost nituite timp de 6 de ani și folosite timp de 20 de ani.
Drept urmare, oamenii de știință, oamenii sunt departe de a fi proști, în acest timp au reușit să dea naștere la o mulțime de programe tolerabile. Desigur, existau și școli teoretice mari de programare (în general, programatorii sovietici de maximă putere, respectați în întreaga lume ca teoreticieni ai informaticii, erau oameni care veneau acolo de la matematică, începând cu Lyapunov și Shura-Bur).
Au fost dezvoltate principii teoretice pentru construirea sistemelor de operare și compilatoare, au fost scrise articole, au fost susținute disertații, au fost create școli științifice. Toate acestea au fost, desigur, demne atât de cantitate, cât și de calitate.
Singura problemă a fost că știința academică excelentă stătea în turnul său de fildeș, ajutând cu dezvoltări importante precum DISPAK, Dubna și ND-70, dar țara avea nevoie de zeci de mii de programatori și nu doar de zeci de academicieni în programare. Nu am avut probleme cu ele, dar cu codificatoarele obișnuite...
În următorul articol, ne vom finaliza considerația asupra acestei dezvoltări interne emblematice.
Pentru a fi continuat ...
informații