- posedanto de du. La unua estas por laboro (Bruna Universitato) kaj la dua, pli lastatempa, - (Virginia Teknika Universitato). La Dijkstra Premio estas donita por laboro, kies signifo kaj influo estas videblaj dum almenaŭ dek jaroj kaj Maurice estas evidente unu el la plej famaj specialistoj en la fako. Li nuntempe laboras kiel profesoro en Brown University kaj havas multajn atingojn kiuj estas paragrafo longa. Li nuntempe esploras blokĉenon en la kunteksto de klasika distribuita komputado.
Antaŭe, Maurice jam venis al Rusio por SPTCC () kaj faris bonegan renkontiĝon de la JUG.ru Java programkomunumo en Sankt-Peterburgo ().
Ĉi tiu habrapost estas bonega intervjuo kun Maurice Herlihy. Ĝi diskutas la sekvajn temojn:
- Interago inter akademio kaj industrio;
- Fundamento por Blockchain-Esplorado;
- De kie venas novaj ideoj? La influo de populareco;
- PhD sub la inspektado de Barbara Liskov;
- La mondo atendas multkern;
- Nova mondo alportas novajn problemojn. NVM, NUMA kaj arkitekturo-piratado;
- Kompililoj vs procesoroj, RISC vs CISC, komuna memoro vs mesaĝ-pasado;
- La arto skribi delikatan multfadenan kodon;
- Kiel instrui studentojn skribi kompleksan multfadenan kodon;
- Nova eldono de la libro "La Arto de Multiprocesora Programado";
- Kiel transakcia memoro estis inventita;
- Kial indas fari esploradon en la kampo de distribuita komputado;
- Ĉu la evoluo de algoritmoj ĉesis, kaj kiel pluiri;
- Laboru ĉe Brown University;
- La diferenco inter esplorado en universitato kaj ene de korporacio;
- Hidro kaj SPTDC.
La intervjuo estas farita de:
Vitalij Aksenov — nuntempe, postdoktorino ĉe IST Aŭstrio kaj dungito de la Departemento pri Komputilaj Teknologioj ĉe ITMO-Universitato. Faras esploradon en la kampo de teorio kaj praktiko de konkurencivaj datumstrukturoj. Antaŭ ol labori pri IST, li ricevis sian PhD de Paris Diderot University kaj ITMO University sub la inspektado de profesoro Peter Kuznetsov.
Aleksej Fedorov - Produktanto ĉe JUG Ru Group, rusa kompanio, kiu organizas konferencojn por programistoj. Alexey partoprenis en la preparado de pli ol 50 konferencoj, kaj lia vivresumo inkluzivas ĉion de la pozicio de evoluinĝeniero ĉe Oracle (JCK, Java Platform Group) ĝis la pozicio de programisto ĉe Odnoklassniki.
Vladimir Sitnikov - Inĝeniero ĉe Netcracker. Dek jaroj da laboro pri la rendimento kaj skaleblo de NetCracker OS, programaro uzata de teleentreprenistoj por aŭtomatigi procezojn pri administrado de retaj kaj retaj ekipaĵoj. Interesas pri agado de problemoj pri Java kaj Oracle Database. Aŭtoro de pli ol dekduo agado-plibonigoj en la oficiala PostgreSQL JDBC-ŝoforo.
Interago inter akademio kaj industrio
Alexey: Maurice, vi laboris en akademia medio dum tre longa tempo kaj la unua demando estas la interago inter la akademia kaj industria sferoj. Ĉu vi povus paroli pri kiel la interagoj inter ili ŝanĝiĝis lastatempe? Kio okazis antaŭ 20-30 jaroj kaj kio okazas nun?
Maurice: Mi ĉiam provis labori proksime kun komercaj kompanioj, ĉar ili havas interesajn problemojn. Ili, kutime, ne tre interesiĝas nek pri publikigo de siaj rezultoj nek pri detalaj klarigoj pri siaj problemoj al la monda komunumo. Ili interesiĝas nur pri solvi ĉi tiujn problemojn. Mi laboris por tiaj kompanioj dum kelka tempo. Mi pasigis kvin jarojn laborante plentempe en esplorlaboratorio ĉe Digital Equipment Corporation, kiu antaŭe estis granda komputila kompanio. Mi laboris unu tagon semajne ĉe Sun, ĉe Mikrosofto, ĉe Oracle, kaj iom laboris ĉe Fejsbuko. Nun mi iros en sabata forpermeso (profesoro en usona universitato rajtas preni tian forpermeson dum jaro proksimume unufoje en ses jaroj) kaj laboros en , ĉi tio estas kompanio pri kripta monero en Bostono. Kunlabori proksime kun kompanioj ĉiam estis plezuro, ĉar tiel oni lernas pri novaj kaj interesaj aferoj. Vi eĉ eble estos la unua aŭ dua persono, kiu publikigas artikolon pri elektita temo, anstataŭ labori pri pliigo plibonigo de solvoj al problemoj, pri kiuj ĉiuj aliaj jam laboras.
Alexey: Ĉu vi povas rakonti al ni pli detale kiel tio okazas?
Maurice: Kompreneble. Vi scias, kiam mi laboris ĉe la Digital Equipment Corporation, mi kaj Elliot Moss, ni inventis transakcian memoron. Estis tre fruktodona periodo, kiam ĉiuj komencis interesiĝi pri informa teknologio. Paralelismo, inkluzive, kvankam plurkernaj sistemoj ankoraŭ ne ekzistis. Dum la tagoj Sun kaj Oracle, mi multe laboris pri paralelaj datumstrukturoj. Ĉe Facebook mi laboris pri ilia blokĉena projekto, pri kiu mi ne povas paroli, sed mi esperas, ke ĝi baldaŭ publikiĝos. Venontjare, ĉe Algorand, mi laboros en esplorgrupo studanta inteligentajn kontraktojn.
Alexey: Blockchain fariĝis tre populara temo en la lastaj jaroj. Ĉu ĉi tio helpos vian esploradon? Eble ĝi faciligos akiri subvenciojn aŭ havigi aliron al rimedoj de kompanioj funkciantaj en la industrio?
Maurice: Mi jam ricevis malgrandan subvencion de la Fondaĵo Ethereum. La populareco de blokĉeno estas tre helpema por inspiri studentojn labori en ĉi tiu kampo. Ili tre interesiĝas pri ĝi kaj ekscitiĝas partopreni, sed foje ili ne rimarkas, ke la esploro, kiu ekstere sonas ekscita, rezultas impliki vere malfacilan laboron. Tamen, mi tre ĝojas uzi ĉi tiun tutan mistikon ĉirkaŭ blokoĉeno por helpi altiri studentojn.
Sed tio ne estas ĉio. Mi estas en la konsila komisiono de pluraj blokĉenaj noventreprenoj. Kelkaj el ili eble sukcesos, kelkaj el ili eble ne, sed ĉiam estas tre interese vidi iliajn ideojn, studi ilin kaj konsili homojn. La plej ekscita afero estas kiam vi avertas homojn ne fari ion. Multaj aferoj unue ŝajnas bona ideo, sed ĉu vere?
Fundamento por Blockchain-Esplorado
Vitaly: Iuj homoj pensas, ke la estonteco kuŝas kun la blokĉeno kaj ĝiaj algoritmoj. Kaj aliaj homoj diras, ke ĝi estas nur alia veziko. Ĉu vi povas dividi vian opinion pri ĉi tiu afero?
Maurice: Multo de tio, kio okazas en la blokĉena mondo, estas malĝusta, iuj estas nur fraŭdo, multe estas trotaksita. Tamen, mi pensas, ke ekzistas solida scienca bazo por ĉi tiuj studoj. La fakto, ke la blokĉena mondo estas plena de ideologiaj diferencoj, montras la nivelon de ekscito kaj dediĉo. Aliflanke, ĉi tio ne estas precipe utila por scienca esplorado. Nun, se vi publikigas artikolon, kiu parolas pri la mankoj de aparta algoritmo, la rezulta reago ne ĉiam estas plene scienca. Ofte homoj forĵetas siajn emociojn. Mi pensas, ke ĉi tiu speco de ekscito en ĉi tiu areo povas ŝajni alloga al iuj, sed fine de la tago, estas realaj sciencaj kaj inĝenieraj aferoj, kiujn oni devas trakti. Estas multe da Komputado ĉi tie.
Vitaly: Do vi provas meti la fundamenton por esploro pri blokĉeno, ĉu ne?
Maurice: Mi provas meti la fundamenton por solida, science kaj matematike solida disciplino. Kaj parto de la problemo estas, ke foje vi devas kontraŭdiri kelkajn el la tro severaj pozicioj de aliaj homoj kaj ignori ilin. Foje homoj demandas kial mi laboras en areo, kie interesiĝas nur teroristoj kaj narkotistoj. Tia reago estas same sensenca kiel la konduto de sekvantoj, kiuj blinde ripetas viajn vortojn. Mi pensas, ke la vero estas ie en la mezo. Blokoĉeno havos profundan efikon al socio kaj la tutmonda ekonomio. Sed ĉi tio verŝajne ne okazos danke al moderna teknologio. Modernaj teknologioj disvolviĝos kaj tio, kio estos nomata blokĉeno estonte, fariĝos tre grava. Ĝi eble eĉ ne aspektas kiel modernaj blokĉenoj, tio estas malferma demando.
Se homoj inventas novajn teknologiojn, ili daŭre nomos ĝin blokĉeno. Mi volas diri, same kiel la hodiaŭa Fortran havas nenion komunan kun la Fortran lingvo de la 1960-aj jaroj, sed ĉiuj daŭre nomas ĝin Fortran. Same por UNIX. Kio estas nomata "blokĉeno" ankoraŭ faros sian revolucion. Sed mi dubas, ke ĉi tiu nova blokĉeno estos io ajn kiel tio, kion ĉiuj ĝuas uzi hodiaŭ.
De kie venas novaj ideoj? Efiko de populareco
Alexey: Ĉu la populareco de blokĉeno kondukis al novaj rezultoj el scienca vidpunkto? Pli da interago, pli da studentoj, pli da kompanioj en la areo. Ĉu jam ekzistas rezultoj de ĉi tiu pliiĝo de populareco?
Maurice: Mi interesiĝis pri tio, kiam iu transdonis al mi oficialan flugfolion por firmao, kiu ĵus kolektis sufiĉe multe da mono. Ĝi skribis pri , kun kiu mi estas pli ol konata. Kio estis skribita en la flugfolio estis klare teknike malĝusta. La homoj, kiuj verkis ĉion ĉi, ne vere komprenis la modelon malantaŭ la problemo... kaj tamen ĉi tiu firmao kolektis multe da mono. Poste, la kompanio trankvile anstataŭigis ĉi tiun flugfolion per multe pli ĝusta versio - kaj mi ne diros, kia estis la nomo de ĉi tiu kompanio. Ili ankoraŭ estas ĉirkaŭe kaj fartas tre bone. Ĉi tiu okazaĵo konvinkis min, ke unue, blokĉeno estas simple formo de distribuita komputado. Due, la enira sojlo (almenaŭ tiam, antaŭ kvar jaroj) estis sufiĉe malalta. La homoj laborantaj en tiu ĉi kampo estis tre energiaj kaj inteligentaj, sed ili ne legis sciencajn artikolojn. Ili provis reinventi konatajn aferojn kaj faris ĝin malbone. Hodiaŭ la dramo malpliiĝis.
Alexey: Ĉi tio estas tre interesa, ĉar antaŭ kelkaj jaroj ni havis alian tendencon. Ĝi estas iom kiel antaŭa evoluado, kiam retumilo-bazitaj antaŭfinaj programistoj reinventis tutajn teknologiojn, kiuj jam estis popularaj en la malantaŭa fino: konstrui sistemojn, kontinuan integriĝon, aferojn tiajn.
Maurice: Mi konsentas. Sed tio ne estas surpriza, ĉar vere trarompaj ideoj ĉiam venas de ekster la establita komunumo. Establitaj esploristoj, precipe establitaj akademiuloj, verŝajne ne faros ion vere pioniran. Estas facile verki artikolon por la sekva konferenco pri kiel vi iomete plibonigis la rezultojn de via pasinta laboro. Iru al konferenco, kunvenu kun amikoj, parolu pri la samaj aferoj. Kaj la homoj, kiuj eksplodas kun rompaj ideoj, preskaŭ ĉiam venas de ekstere. Ili ne konas la regulojn, ili ne konas la lingvon, sed tamen... Se vi estas ene de establita komunumo, mi konsilas vin atenti pri novaj aferoj, pri io, kio ne kongruas en la ĝenerala bildo. Iasence oni povas provi kombini eksterajn pli fluidajn evoluojn kun metodoj, kiujn ni jam komprenas. Unue, provu establi sciencan bazon, kaj poste ŝanĝu ĝin por ke ĝi estu aplikata al novaj trarompaj ideoj. Mi pensas, ke tiu blokĉeno estas bonega por esti freŝa, interrompa ideo.
Alexey: Kial vi pensas, ke tio okazas? Ĉar homoj "ekstere" ne havas specifajn barojn proprajn al la komunumo?
Maurice: Estas ŝablono okazanta ĉi tie. Se vi legis la historion de la impresionistoj en pentrarto kaj arto ĝenerale, tiam iam famaj artistoj malakceptis impresionismon. Ili diris, ke ĝi estas iom infaneca. Generacio poste, tiu antaŭe malaprobita arta ĝenro iĝis la normo. Kion mi vidas en mia kampo: la inventintoj de blokĉeno ne interesiĝis pri potenco, pri pliigado de publikigadoj kaj citaĵo-indekso, ili nur volis fari ion bonan. Kaj do ili sidiĝis kaj komencis fari ĝin. Al ili mankis certa kvanto da teknika profundo, sed tio estas riparebla. Estas multe pli malfacile elpensi novajn kreajn ideojn ol korekti kaj plifortigi nesufiĉe maturajn. Dank' al ĉi tiuj inventistoj, mi nun havas ion por fari!
Alexey: Ĉi tio similas al la diferenco inter noventreprenoj kaj heredaj projektoj. Ni heredas multajn limojn de pensado, barojn, specialajn postulojn, ktp.
Maurice: Bona analogio estas distribuita komputado. Pensu pri blokĉeno kvazaŭ ĝi estus starto kaj distribuita komputado kiel granda, establita kompanio. Distribuita komputado estas en la procezo de esti akirita kaj kunfandita kun blokĉeno.
PhD sub la inspektado de Barbara Liskov
Vitaly: Ni ankoraŭ havas multajn demandojn! Ni esploris vian fonon kaj trovis interesan fakton pri via doktoreco. Jes, tio estis antaŭ longa tempo, sed ĝi ŝajnas esti grava temo. Vi ricevis vian doktorecon sub la gvido de vi mem ! Barbara estas tre konata en la programlingva komunumo, kaj tre konata persono ĝenerale. Estas logike, ke via esplorado estis en la kampo de programlingvoj. Kiel vi ŝanĝis al paralela komputado? Kial vi decidis ŝanĝi la temon?
Maurice: Tiutempe, Barbara kaj ŝia grupo nur rigardis distribuitan komputadon, kio estis tre nova ideo. Estis ankaŭ tiuj kiuj diris ke distribuita komputado estas sensencaĵo kaj ke komputiloj komunikiĝi inter si estas sencela. Unu el la temoj traktitaj en distribuita komputado kiu distingas ĝin de alcentrigita komputiko estas faŭltoleremo. Post multe da esplorado, ni decidis, ke distribuita komputika programlingvo bezonas havi ion similan al atomaj transakcioj ĉar vi neniam povas esti certa, ke fora voko sukcesos. Post kiam vi havas transakciojn, ŝprucas la problemo de samtempa administrado. Tiam estis multe da laboro por akiri tre paralelajn transakciajn datumstrukturojn. Poste, kiam mi diplomiĝis, mi iris al kaj komencis serĉi temon por prilabori. Okazis al mi, ke komputado transiris de unuopaj komputiloj al retoj de komputiloj. Plurprocesoroj estus natura daŭrigo de progreso - la vorto "multkerno" ankoraŭ ne ekzistis. Mi pensis: kio estas la ekvivalento de atomaj transakcioj por plurkerna sistemo? Certe ne regulaj transakcioj ĉar ili estas tro grandaj kaj pezaj. Kaj jen kiel mi elpensis la ideon kaj jen kiel mi elpensis la tutan atendon-liberan sinkronigon. Ĉi tio estis provo respondi la demandon pri kio estas la analogo de atomaj transakcioj por multprocesora sistemo kun komuna memoro. Unuavide, ĉi tiu verko povas aspekti tute alia, sed fakte ĝi estas daŭrigo de la sama temo.
La mondo atendas multkernajn
Vitaly: Vi menciis, ke tiam estis tre malmultaj plurkernaj komputiloj, ĉu ne?
Maurice: Ili simple ne estis tie. Ekzistis pluraj tielnomitaj simetriaj multprocesoroj, kiuj estis baze konektitaj al la sama buso. Ĉi tio ne funkciis tre bone ĉar ĉiufoje kiam nova firmao kreus ion similan, Intel liberigus ununuran procesoron kiu estis pli bona ol la multprocesoro.
Alexey: Ĉu ĉi tio ne signifas, ke en tiuj antikvaj tempoj temis pli pri teoria studo?
Maurice: Ĝi ne estis teoria studo, sed prefere konjekta studo. Ĉio ĉi ne temis pri laboro kun multaj teoremoj; prefere, ni prezentis hipotezojn pri arkitekturo kiu ne ekzistis tiutempe. Por tio estas esploro! Neniu kompanio farus ion tian; ĉio estis io de la malproksima estonteco. Fakte, tiel estis ĝis 2004, kiam aperis veraj multkernaj procesoroj. Ĉar procesoroj trovarmiĝas, vi povas fari la procesoron eĉ pli malgranda, sed vi ne povas fari ĝin pli rapida. Pro tio, estis transiro al plurkernaj arkitekturoj. Kaj tiam tio signifis ke subite ekzistis uzo por ĉiuj konceptoj kiujn ni evoluigis en la pasinteco.
Alexey: Kial vi opinias, ke multkernaj procesoroj aperis nur en la XNUMX-aj jaroj? Kial do estas tiel malfrue?
Maurice: Ĉi tio estas pro aparataj limigoj. Intel, AMD kaj aliaj kompanioj tre kapablas pliigi procesoran rapidecon. Kiam iam la procesoroj fariĝis sufiĉe malgrandaj, ke ili ne plu povis pliigi la horloĝan rapidon ĉar la procesoroj ekbrulis. Vi povas fari ilin pli malgrandaj, sed ne pli rapide. Kio estas en ilia povo - anstataŭ tre malgranda procesoro, ili povas konveni ok, dek ses aŭ tridek du procesorojn en la sama volumeno de la kazo, kie antaŭe nur unu povis konveni. Nun vi havas multfadenan kaj rapidan komunikadon inter ili ĉar ili dividas kaŝmemorojn. Sed vi ne povas devigi ilin kuri pli rapide - estas tre specifa rapidlimo. Ili daŭre pliboniĝas iom post iom, sed ne tiom multe plu. La leĝoj de fiziko staris en la vojo de plibonigoj.
Nova mondo alportas novajn problemojn. NUMA, NVM kaj arkitekturo-piratado
Alexey: Sonas tre racia. Kun novaj multkernaj procesoroj venis novaj problemoj. Ĉu vi kaj viaj kolegoj atendis ĉi tiujn problemojn? Eble vi studis ilin anticipe? En teoriaj studoj ofte ne estas tre facile antaŭdiri tiajn aferojn. Kiam problemoj okazis, kiel ili renkontis viajn atendojn kaj viajn kolegojn? Aŭ ĉu ili estis tute novaj, kaj vi kaj viaj kolegoj devis pasigi multe da tempo solvante problemojn kiel ili aperis?
Vitaly: Mi aldonos al la demando de Alexey: ĉu vi ĝuste antaŭdiris la procesoran arkitekturon dum vi studis la teorion?
Maurice: Ne 100%. Sed mi pensas, ke miaj kolegoj kaj mi faris bonan laboron antaŭdiri multi-kernojn kun komuna memoro. Mi pensas, ke ni ĝuste antaŭdiris la malfacilaĵojn por disvolvi paralelajn datumstrukturojn, kiuj funkcias sen seruroj. Tiaj datumstrukturoj estis gravaj por multaj aplikoj, kvankam ne ĉiuj, sed ofte, kion vi vere bezonas, estas ne-ŝlosa datumstrukturo. Kiam ni inventis ilin, multaj argumentis, ke tio estas sensencaĵo, ke ĉio funkcias bone kun seruroj. Ni antaŭdiris sufiĉe bone, ke estos pretaj solvoj por multaj programaj problemoj kaj datumstrukturaj problemoj. Estis ankaŭ pli kompleksaj problemoj, kiel ekz - neegala aliro al memoro. Fakte, ili eĉ ne estis pripensitaj ĝis multkernaj procesoroj estis inventitaj ĉar ili estis tro specifaj. La esplorkomunumo laboris pri demandoj, kiuj estis ĝenerale antaŭvideblaj. Iuj aparataj problemoj asociitaj kun specifaj arkitekturoj devis atendi en la flugiloj - fakte, la apero de ĉi tiuj arkitekturoj. Ekzemple, neniu vere laboris pri GPU-specifaj datumstrukturoj ĉar GPU-oj ne ekzistis tiam. Kvankam multe da laboro estis farita , tiuj algoritmoj estis pretaj por uzo tuj kiam taŭga aparataro iĝis havebla. Tamen, estas neeble antaŭvidi ĉion.
Alexey: Se mi bone komprenas, NUMA estas ia kompromiso inter kosto, rendimento kaj iuj aliaj aferoj. Ĉu iuj ideoj, kial NUMA aperis tiel malfrue?
Maurice: Mi pensas, ke NUMA ekzistas pro problemoj kun la aparataro uzata por produkti memoron: ju pli malproksime estas la komponantoj, des pli malrapidas aliri ilin. Aliflanke, la dua valoro de tiu abstraktado estas memorunuformeco. Do unu el la karakterizaĵoj de paralela komputado estas ke ĉiuj abstraktaĵoj estas iomete rompitaj. Se aliro estus perfekte unuforma, ĉiu memoro estus egaldistanca, sed tio estas ekonomie, kaj eble eĉ fizike, neebla. Tial ĉi tiu konflikto ekestas. Se vi skribas vian programon kvazaŭ memoro estus unuforma, tiam ĝi plej verŝajne estos ĝusta. En la senco, ke ĝi ne donos malĝustajn respondojn. Sed ŝia agado ankaŭ ne kaptos la stelojn de la ĉielo. Same, se vi skribas Sen kompreno de la kaŝmemoro-hierarkio, la blokado mem estos ĝusta, sed vi povas forgesi pri rendimento. Iasence, oni devas skribi programojn, kiuj vivas super tre simpla abstraktado, sed oni devas superruzi la homojn, kiuj donis al vi tiun abstraktadon: oni devas scii, ke sub la abstraktado estas ia hierarkio de memoro, ke ekzistas buso inter vi kaj ĉi tiu memoro, ktp. Tiel, ekzistas iu konflikto inter individue utilaj abstraktaĵoj, kiu kondukas nin al tre konkretaj kaj pragmataj problemoj.
Vitalij: Kio pri la estonteco? Ĉu vi povas antaŭdiri kiel la procesoroj evoluos poste? Estas ideo, ke unu el la respondoj estas transakcia memoro. Vi verŝajne havas ion alian en stoko.
Maurice: Estas kelkaj gravaj defioj antaŭen. Unu estas, ke kohera memoro estas mirinda abstraktaĵo, sed ĝi komencas rompiĝi en specialaj kazoj. Do, ekzemple, NUMA estas vivanta ekzemplo de io, kie vi povas daŭre ŝajnigi, ke unuforma memoro ekzistas. Efektive ne, produktiveco ploros vin. En iu momento, arkitektoj devos forlasi la ideon de ununura memorarkitekturo; vi ne povas ŝajnigi eterne. Oni bezonos novajn programajn modelojn, kiuj estas sufiĉe facile uzeblaj kaj sufiĉe potencaj por ke la subesta aparataro efike. Ĉi tio estas tre malfacila kompromiso, ĉar se vi montras al programistoj la arkitekturon, kiu efektive estas uzata en la aparataro, ili freneziĝos. Ĝi estas tro komplika kaj ne portebla. Se vi prezentas interfacon tro simplan, la rendimento estos malbona. Tiel, multaj tre malfacilaj kompromisoj devos esti faritaj por disponigi utilajn programajn modelojn aplikeblajn al vere grandaj multkernaj procesoroj. Mi ne certas, ke iu ajn krom specialisto kapablas programi sur 2000-kerna komputilo. Kaj krom se vi faras tre fakan aŭ sciencan komputadon aŭ kriptografion aŭ ion similan - ankoraŭ tute ne estas klare kiel fari ĝin ĝuste.
Alia simila areo estas specialecaj arkitekturoj. Grafikaj akceliloj ekzistas delonge, sed ili fariĝis ia klasika ekzemplo pri kiel vi povas preni specialan specon de komputado kaj ruli ĝin sur dediĉita blato. Ĉi tio aldonas siajn proprajn defiojn: kiel vi komunikas kun tia aparato, kiel vi programas ĝin. Mi lastatempe laboris pri problemoj en la areo . Vi prenas malgrandan procesoron kaj gluas ĝin al grandega peco da memoro tiel ke la memoro funkcias kun L1-kaŝmemorrapideco kaj tiam komunikas kun aparato kiel – la procesoro estas okupata ŝarĝante novajn taskojn en vian memorkernon. Dezajni datumstrukturojn kaj komunikajn protokolojn por ĉi tia afero estas alia interesa ekzemplo. Do kutimaj procesoroj kaj aparataro daŭre vidos plibonigojn dum sufiĉe da tempo.
Alexey: Kio pri nevolatila memoro ()?
Maurice: Ho, tio estas alia bonega ekzemplo! NVM multe ŝanĝos la manieron kiel ni rigardas aferojn kiel datumstrukturojn. Nevolatila memoro, iusence, promesas vere akceli aferojn. Sed ĝi ne plifaciligos la vivon ĉar la plej multaj procesoroj, kaŝmemoroj kaj registroj ankoraŭ estas volatilaj. Kiam vi komencas post kraŝo, via stato kaj la stato de via memoro ne estos ĝuste la sama kiel antaŭ la kraŝo. Mi estas tre dankema al la homoj laborantaj pri NVM - estos multe por esploristoj por fari dum longa tempo provante eltrovi korektajn kondiĉojn. Komputiloj estas ĝustaj se ili povas postvivi kraŝon en kiu la enhavo de kaŝmemoroj kaj registroj estas perditaj, sed la ĉefmemoro restas sendifekta.
Kompililoj kontraŭ procesoroj, RISC kontraŭ CISC, komuna memoro kontraŭ mesaĝo-pasado
Vladimir: Kion vi opinias pri la dilemo "kompiloj kontraŭ procesoroj" el instrukcia vidpunkto? Mi klarigu por tiuj, kiuj ne scias: se ni iras al distordita memoro aŭ al io simila, ni povus uzi tre simplan aron de komandoj kaj peti la kompililon generi kompleksan kodon kiu povas utiligi la novajn avantaĝojn. Aŭ ni povas iri la alian vojon: efektivigi kompleksajn instrukciojn kaj peti la procesoron reordigi la instrukciojn kaj fari aliajn manipuladojn kun ili. Kion vi pensas pri tio?
Maurice: Mi ja ne havas respondon al tiu demando. Ĉi tiu debato daŭras dum kvar jardekoj. Estis tempo, kiam inter aro da komandoj kaj civitaj militoj estis batalitaj per aro da komandoj. Por tempeto, la RISC-homoj venkis, sed tiam Intel rekonstruis siajn motorojn tiel ke reduktita aro de instrukciaĵo estis uzita interne, kaj la plena aro estis eksportita ekstere. Ĉi tio verŝajne estas temo en kiu ĉiu nova generacio devas trovi siajn proprajn kompromisojn kaj fari siajn proprajn decidojn. Estas tre malfacile antaŭdiri, kiu el ĉi tiuj aferoj estos pli bonaj. Do ĉiu antaŭdiro, kiun mi faros, estos vera por certa tempo, kaj poste denove malvera por iom da tempo, kaj poste denove vera.
Alexey: Kiom ofta estas por la industrio, ke iuj ideoj gajnas dum pluraj jardekoj kaj perdas en la venontaj? Ĉu ekzistas aliaj ekzemploj de tiaj periodaj ŝanĝoj?
Maurice: Pri la temo de distribuita komputado, estas homoj kiuj kredas je kaj homoj kiuj kredas je . Komence, en distribuita komputado, paralela komputado signifas mesaĝ-pasadon. Tiam iu malkovris, ke estas multe pli facile programi kun komuna memoro. La kontraŭa flanko diris, ke komuna memoro estas tro komplika, ĉar ĝi postulas serurojn kaj similajn, do indas translokiĝi al lingvoj, kie nenio krom mesaĝo-pasado simple ekzistas. Iu rigardis kio eliris el ĉi tio kaj diris: "Ve, ĉi tiu mesaĝa efektivigo similas al komuna memoro, ĉar vi kreas multe da ĉi tiuj etaj moduloj, ili sendas mesaĝojn unu al la alia, kaj ili ĉiuj. "Ni faru pli bonan komunan memordatumbazon!" Ĉio ĉi estas ripetita denove kaj denove, kaj estas neeble diri, ke unu el la partioj certe pravas. Unu el la flankoj ĉiam regos ĉar tuj kiam unu el ili preskaŭ venkas, homoj denove kaj denove inventas manierojn plibonigi la alian.
La Arto de Skribi Brittle Multithreaded Kodo
Alexey: Ĉi tio estas tre interesa. Ekzemple, kiam ni skribas kodon, negrave kia programlingvo, ni kutime devas krei abstraktaĵojn kiel ĉelojn, kiujn oni povas legi kaj skribi. Sed fakte, je iu fizika nivelo, ĉi tio povas aspekti kiel sendi mesaĝon per aparatara buso inter malsamaj komputiloj kaj aliaj aparatoj. Montriĝas, ke laboro okazas ĉe ambaŭ niveloj de abstraktado samtempe.
Maurice: Estas absolute vero, ke komuna memoro estas konstruita sur mesaĝo-pasado - busoj, kaŝmemoroj, ktp. Sed estas malfacile skribi programojn uzante mesaĝ-pasadon, do la aparataro intence mensogas, ŝajnigante, ke vi havas ian unuforman memoron. Ĉi tio faciligos al vi verki simplajn, ĝustajn programojn antaŭ ol la rendimento komencas malboniĝi. Tiam vi diros: ŝajnas, ke estas tempo amikiĝi kun la kaŝmemoro. Kaj tiam vi komencas zorgi pri la loko de la kaŝmemoro, kaj de tie ĝi iras. Iasence, vi hakas la abstraktadon: vi scias, ke ĝi ne estas nur plata, unuforma memoro, kaj vi uzos tiun scion por skribi kaŝmemor-amikajn programojn. Jen kion vi devos fari en realaj problemoj. Ĉi tiu konflikto inter la dolĉa, simpla, bela abstraktaĵo, kiun vi ricevis kaj la terure kompleksa efektivigo de la subesta aparataro estas kie ĉiu faros sian propran kompromison. Mi havas libron pri multprocesoroj kaj sinkronigado, kaj iam mi verkis ĉapitron pri datumstrukturoj en java.util.concurrent. Se vi rigardas ilin, aferoj kiel Ĉi tiuj estas mirindaj artaĵoj. (Noto de la redaktoro: Tiuj, kiuj konas la Javan lingvon, devus almenaŭ rigardi la efektivigon Samtempa SkipListMap, vi povas rigardi la ligilojn ĉe и ). Sed el mia vidpunkto, estus nerespondece montri ilin al studentoj, ĉar tia datumstrukturo estas kvazaŭ ulo en cirko kuranta sur ŝnuro super ursfosejo. Se vi ŝanĝas eĉ unu malgrandan detalon, la tuta strukturo kolapsos. Ĉi tiu kodo estas tre rapida kaj eleganta nur ĉar ĝi estas skribita perfekte, sed la plej eta ŝanĝo kondukos al kompleta fiasko. Se mi donos ĉi tiun kodon kiel ekzemplon al studentoj, ili tuj diros: ankaŭ mi povas fari tion! Kaj tiam iu aviadilo kraŝos aŭ nuklea reaktoro eksplodos, kaj mi estos kulpa doni al ili tro da informoj en la malĝusta tempo.
Alexey: Kiam mi estis iom pli juna, multfoje mi provis studi la fontkodon de Doug Lee, ekzemple, java.util.concurrent, ĉar ĝi estas malferma fonto, estas tre facile trovi kaj provi kompreni kio okazas tie. Ĝi ne rezultis tre bone: ofte, estas tute neklare kial Doug decidis fari ion tiel kiam ĉiuj aliaj faras ĝin alimaniere. Kiel vi klarigas ĉi tiujn aferojn al viaj studentoj? Ĉu ekzistas aparta ĝusta maniero priskribi specifajn detalojn de ĝisosta algoritmo, ekzemple? Kiel vi faras ĉi tion?
Maurice: Instruistoj de desegno havas kliŝon, kiun ili unue memoras: se vi volas desegni kiel Picasso, vi unue devas lerni kiel desegni simplajn realismajn bildojn, kaj nur kiam vi konas la regulojn, vi povas komenci malobei ilin. Se vi komencas tuj malobeante la regulojn, vi finiĝas en malordo. Unue, mi instruas studentojn kiel skribi simplan, ĝustan kodon sen zorgi pri rendimento. Kion mi diras estas, ke estas kompleksaj tempoproblemoj kaŝatendas ĉi tie, do ne zorgu pri kaŝmemoroj, ne zorgu pri memormodeloj, nur certigu, ke ĉio funkcias ĝuste. Ĉi tio jam estas sufiĉe malfacila: moderna programado ne estas facila en si mem, precipe por novaj studentoj. Kaj kiam ili havas intuicion pri kiel skribi la ĝustajn programojn, mi diras: rigardu ĉi tiujn du realigojn de spinlock: unu estas tre malrapida, kaj la dua ankaŭ ne tre, sed pli bona. Tamen, matematike la du algoritmoj estas la samaj. Fakte, unu el ili uzas kaŝmemoron. Unu el ili funkcias per loke konservitaj datumoj, kaj la alia plurfoje faras operaciojn trans la buso. Vi ne povas skribi efikan kodon se vi ne komprenas kio ĝi estas, kaj ne scias kiel rompi la abstraktadon kaj rigardi la suban strukturon. Sed vi ne povos tuj komenci fari ĉi tion. Estas homoj, kiuj tuj komencas fari tion kaj kredas je sia propra genio, kutime ĝi finiĝas malbone ĉar ili ne komprenas la principojn. Neniu desegnas kiel Picasso aŭ skribas programojn kiel Doug Lee ĵus el la universitato en sia unua semajno. Necesas jaroj por atingi ĉi tiun nivelon de scio.
Alexey: Montriĝas, ke vi dividas la problemon en du partojn: la unua estas ĝusteco, la dua estas rendimento?
Maurice: Ĝuste. Kaj, ĝuste en tiu ordo. Parto de la problemo estas, ke novaj studentoj ne komprenas, ke ĝusteco estas malfacile atingi. Unuavide oni diras: ĉi tio evidente estas ĝusta, restas nur plirapidigi ĝin. Do foje mi rakontas al ili pri komence malĝusta algoritmo kvazaŭ ĝi estus ĝusta.
Kiel instrui studentojn skribi kompleksan multfadenan kodon
Alexey: Nur por vidi ĉu ili povas senti la kaptaĵon?
Maurice: Mi ĉiam avertas anticipe, ke foje mi proponos malĝustajn algoritmojn. Vi ne devus trompi homojn. Mi proponas, ke ili prenu la informojn kun salo. Se mi diras ion kaj diras: "rigardu, ĉi tio evidente estas ĝusta" - ĉi tio estas signalo, ke ie ili provas trompi vin, kaj vi devus komenci demandi. Poste, mi provas instigi studentojn daŭre demandi demandojn, kaj poste mi sugestas, "Kio okazos se ni lasos aferojn kiel ili estas?" Kaj ili tuj vidas la eraron. Sed konvinki studentojn, ke ili devas zorgi pri ĝusteco, estas multe pli malfacila ol ŝajnas unuavide. Multaj el ĉi tiuj studentoj venas kun programado sperto en mezlernejo, kelkaj akiris laborpostenojn kaj faris programadon tie, kaj ili ĉiuj estas plenaj de fido. Ĉi tio estas io kiel la armeo: vi unue devas ŝanĝi ilian humoron por konvinki ilin pacience alproksimiĝi al solvado de problemoj, kiuj aperas. Aŭ eble estas kiel budhismaj monaĥoj: unue ili lernas rezoni pri ĝusteco, kaj post kiam ili komprenas la manierojn rezoni pri ĝusteco, ili rajtas transiri la sekvan nivelon kaj komenci zorgi pri agado.
Alexey: Tio estas, foje vi montras al studentoj nelaborajn ekzemplojn, danke al kiuj vi ricevas reagojn montrante ĉu ili komprenas la esencon de la problemo, ĉu ili povas trovi la malĝustan kodon kaj la malĝustan rezulton. Do, ĉu studentoj kutime ĝojigas aŭ malĝojigas vin?
Maurice: Studentoj preskaŭ ĉiam trovas la eraron eventuale. Se ili serĉas tro malrapide, mi faras gvidajn demandojn, kaj ĉi tie estas grave kompreni, ke se vi neniam trompas ilin, ili komencos senpense percepti viajn vortojn kiel la finfinan veron. Tiam ili enuiĝos kaj ekdormos legante Fejsbukon sur sia tekkomputilo dum klaso. Sed kiam vi anticipe diras al ili, ke ili estos trompitaj, kaj ili aspektos stultaj, se ili ne sentas ruzon, ili fariĝas multe pli viglaj. Ĉi tio estas bona laŭ malsamaj manieroj. Mi ŝatus, ke studentoj ne nur pridubus sian komprenon pri la afero, sed ankaŭ pridubu la aŭtoritaton de la instruisto. La ideo estas, ke studento povas iam ajn levi la manon kaj diri: Mi pensas, ke tio, kion vi ĵus diris, estas malĝusta. Ĝi estas grava lerna ilo. Mi ne volas, ke iu el la studentoj sidu kaj silente pensu al si: ĉio ĉi ŝajnas tute sensencaĵo, sed levi la manon estas tro timiga, kaj ĉiuokaze, li estas profesoro, do ĉio, kion li diras, estas la vero. Tial, se ili anticipe estas avertitaj, ke ne ĉio rakontita estas nepre vera, ili havas instigon pli atenti la materialon. Mi klarigas, ke estas bone levi vian manon kaj demandi demandojn. Via demando povas soni stulta aŭ naiva, sed tiel ofte aperas la plej bonaj demandoj.
Alexey: Tre interese. Kutime homoj havas ian psikologian baron, kiu ne permesas al ili fari demandon al profesoro. Precipe se estas multaj homoj en la ĉambro, kaj ĉiuj timas, ke diskuti pri via stulta demando prenos la tutan tempon de ĉi tiuj homoj. Ĉu ekzistas lertaĵoj por trakti ĉi tion?
Maurice: Mi ofte haltas kaj faras klasikajn demandojn. Ĉu aserto estus ĝusta, aŭ kiel ili solvus la diskutan problemon. Ĉi tio estas ŝlosila ago, precipe ĉe la komenco de leciono, kiam homoj embarasas diri eĉ la plej malgrandan aferon. Vi demandas al la studentoj kaj diras nenion plu. Estas silento, ĉiuj iom streĉiĝas, la streĉiĝo kreskas, tiam subite iu ne eltenas, rompiĝas kaj diras la respondon. Jen kiel oni turnas la situacion: daŭre silenti fariĝas pli malfacila kaj maloportuna ol respondi! Ĉi tio estas norma pedagogia lertaĵo. Ĉiu instruisto en la mondo devus scii kiel fari tion.
Alexey: Nun ni havas bonegan titolon por ĉi tiu intervjuo: "estas pli facile respondi ol silenti."
Vitalij: Lasu min demandi denove. Vi laboras pri topologiaj pruvoj. Kiel vi eĉ okupiĝis pri tio, ĉar distribuita komputado kaj topologio estas tute malsamaj aferoj!
Maurice: Tie estas kaŝita rilato. Kiam mi estis studento studante matematikon, mi studis puran matematikon. Mi ne havis realan intereson pri komputiloj ĝis miaj studoj finiĝis kaj mi trovis min antaŭ la urĝa bezono serĉi laboron. Kiel studento mi studis algebran topologion. Multajn jarojn poste, laborante pri problemo vokis , mi uzis grafikaĵojn por modeligi la problemon kaj, kiel ŝajnis tiutempe, mi trovis solvon. Vi nur devis sidiĝi kaj ĉirkaŭiri la grafon. Provu trovi taŭgan respondon en ĉi tiu grafikaĵo. Sed mia algoritmo ne funkciis: montriĝis, ke li kuros ronde por ĉiam. Bedaŭrinde, ĉio ĉi ne povus esti klarigita en la formala lingvo de grafteorio - tiu kiun ĉiuj komputikistoj konas. Kaj tiam mi memoris, ke antaŭ multaj jaroj, reen en topologiaj klasoj, ni uzis la koncepton , kiu estas ĝeneraligo de grafeoj al pli altaj dimensioj. Tiam mi demandis min: kio okazus, se ni reformulus la problemon laŭ simplaj kompleksoj? Ĉi tio fariĝis la ŝlosila momento. Uzante pli potencan formalismon, la problemo subite fariĝas multe pli simpla. Homoj batalis kontraŭ ĝi dum longa tempo, uzante grafeojn, sed ili nenion povis fari. Kaj eĉ nun ili ne povas - la ĝusta respondo montriĝis ne algoritmo, sed pruvo de la malebleco solvi la problemon. Tio estas, tia algoritmo simple ne ekzistas. Sed bazite aŭ sur simpligaj kompleksoj aŭ sur aferoj kiujn homoj ŝajnigis ne konsideri simpligajn kompleksojn. Nur ĉar vi nomas ion novan nomon, ĝi ne perdas sian esencon.
Vitaly: Montriĝas, ke vi estis nur bonŝanca?
Maurice: Krom sorto, ĝi ankaŭ estas volonteco. Ĉi tio signifas, ke vi ne forgesu la "senutilajn" aferojn, kiujn vi lernis pli frue. Ju pli senutilaj aferoj vi lernas, des pli da ideoj vi povas ĉerpi kiam vi alfrontas novan problemon. Tia intuicia kongruo de ŝablonoj gravas ĉar... Ni faru tion, ĉi tio estas ĉeno: komence mi malkovris, ke la grafikaĵoj tute ne funkciis aŭ tute ne funkciis, ĝi rememorigis min pri io el la eventoj de ok. antaŭ jaroj kaj miaj studentaj jaroj, kiam ni studis ĉiujn ĉi simplajn kompleksojn. Ĉi tio siavice permesis al mi trovi mian malnovan topologian lernolibron kaj reŝarĝi ĝin en mian kapon. Sed se ne estus tiu malnova scio, mi neniam estus progresinta en la solvado de la origina problemo.
Nova eldono de la libro "La Arto de Multiprocesora Programado"
Aleksej: Vi diris kelkajn vortojn pri via libro. Verŝajne ne estas la plej malbona sekreto, ke vi skribis la plej faman libron de la mondo pri multfadenado, . Ĝi jam aĝas proksimume 11 jarojn kaj ekde tiam ĝi nur estis liberigita . Ĉu estos dua eldono?
Maurice: Estas bone, ke vi demandis! Ĝi estos tre baldaŭ, post tri monatoj aŭ pli. Estas du pliaj aŭtoroj, ni aldonis multe pli da materialo, plibonigis la sekcion pri fork/kunigo paralelismo, verkis sekcion pri MapReduce, aldonis multajn novajn aferojn kaj forĵetis nenecesajn aferojn - ion, kio estis tre interesa en la momento de la skribado. la unua eldono, sed ne plu ekzistas hodiaŭ. La rezulto estis tre serioze reviziita libro.
Alexey: Ĉio jam estas farita, restas nur liberigi ĝin?
Maurice: Kelkaj ĉapitroj ankoraŭ bezonas iom da laboro. Nia eldonejo (kiu mi pensas jam malamas nin) ankoraŭ provas transdoni la mesaĝon, ke ni devus labori pli rapide. Ni multe postrestas. Teorie, ni povintus fari ĉi tiun libron kelkajn jarojn pli frue.
Aleksej: Ĉu ajna ŝanco ricevi novan version de la libro antaŭ Kristnasko?
Maurice: Jen nia celo! Sed mi antaŭdiris venkon tiom da fojoj, ke neniu plu kredas min. Vi verŝajne ankaŭ ne tro fidi min pri ĉi tiu afero.
Alexey: Ĉiukaze, ĉi tio estas mirinda novaĵo. Mi tre ŝatis la unuan eldonon de la libro. Vi povus diri, ke mi estas fervorulo.
Maurice: Mi esperas, ke la nova eldono estos inda je via fervora entuziasmo, dankon!
Kiel Transakcia Memoro Estis Inventita
Vitaly: La sekva demando temas pri transakcia memoro. Laŭ mia kompreno, vi estas pioniro en tiu ĉi fako, vi elpensis ĝin en tempo, kiam neniu pensis pri tiaj aferoj. Kial vi decidis translokiĝi en ĉi tiun kampon? Kial transakcioj ŝajnis gravaj al vi? Ĉu vi pensis, ke iam ili estos efektivigitaj en aparataro?
Maurice: Mi scias pri transakcioj ekde miaj diplomiĝintaj esplortagoj.
Vitaly: Jes, sed ĉi tiuj estas malsamaj transakcioj!
Maurice: Mi laboris kun Elliott Moss pri senbloka rubkolekto. Nia problemo estis, ke ni volis atome ŝanĝi kelkajn vortojn en memoro kaj tiam la algoritmoj fariĝus tre simplaj, kaj almenaŭ kelkaj el ili fariĝus pli efikaj. Uzanta por havigita de la paralela arkitekturo, eblas fari ion, sed ĝi estas tre malefika kaj malbela ĉar vi devus trakti tavolojn de nerekteco. Mi volas ŝanĝi memorvortojn kaj mi devas ŝanĝi ĉar mi povas ŝanĝi nur unu montrilon, do ili devas montri al ia dosieruja strukturo. Ni parolis pri kiom bonege estus se ni povus ŝanĝi la aparataron tiel ke ĝi povus fari samtempan registradon. Elliott ŝajnas rimarki ĉi tion: se vi rigardas kaŝmemorkoherecajn protokolojn, ili jam provizas la plej grandan parton de la bezonata funkcieco. En optimisma transakcio, la kaŝmemoro-kohereca protokolo rimarkos, ke ekzistas tempkonflikto kaj la kaŝmemoro fariĝos . Kio okazas se vi spekulative ruligas transakcion sur via kaŝmemoro kaj uzas la koherajn protokolajn mekanismojn por detekti konfliktojn? Konjekta hardvararkitekturo estis facile dezajnebla. Do ni skribis tiun pri transakcia memoro. Samtempe, la firmao por kiu mi laboris, Digital Equipment Corporation, kreis novan 64-bitan procesoron nomitan Alpha. Do mi iris kaj faris prezenton al la Alpha disvolva grupo pri nia mirinda transakcia memoro kaj ili demandis: Kiom da pliaj enspezoj ricevus nia kompanio se ni aldonus ĉion ĉi rekte al la procesoro? Kaj mi tute ne havis respondon al ĉi tio, ĉar mi estas teknologo, mi ne estas merkatika specialisto. Mi vere havis nenion por respondi. Ili ne estis tre impresitaj, ke mi nenion sciis.
Vitalij: Miliardoj! Nur diru miliardoj!
Maurice: Jes, tion mi devus diri. Nun, en la epoko de noventreprenoj kaj ĉio, mi scias kiel verki komercan planon. Ke vi povas mensogi iomete pri la grandeco de via ebla profito. Sed en tiuj tagoj ĝi ŝajnis naiva, do mi nur diris: "Mi ne scias." Se vi rigardas la historion de la publikigado pri transakcia memoro, vi rimarkos, ke post jaro estis pluraj referencoj al ĝi, kaj tiam dum ĉirkaŭ dek jaroj neniu citis ĉi tiun artikolon. La citaĵoj aperis ĉirkaŭ 2004, kiam aperis veraj plurkernoj. Kiam homoj malkovris, ke skribi paralelan kodon povas gajni monon, komenciĝis novaj esploroj. Ravi Rajwar , kiu iel enkondukis la koncepton de transakcia memoro al la ĉeftendenco. (Noto de la redaktoro: Ekzistas dua versio de ĉi tiu artikolo, publikigita en 2010 kaj libere havebla ). Subite homoj ekkomprenis ĝuste kiel ĉio ĉi povas esti uzata, kiel tradiciaj algoritmoj kun seruroj povus esti akcelitaj. Bona ekzemplo de io, kio en la pasinteco ŝajnis kiel nur interesa akademia problemo. Kaj jes, se vi tiam demandus min, ĉu mi pensis, ke ĉio ĉi estos grava estonte, mi estus dirinta: kompreneble, sed kiam ĝuste ne estas klara. Eble post 50 jaroj? En la praktiko, tio rezultis esti nur jardeko. Estas tre agrable kiam oni faras ion kaj post nur dek jaroj homoj rimarkas tion.
Kial indas fari esploradon en la kampo de distribuita komputado
Vitaly: Se ni parolas pri novaj esploroj, kion vi konsilus al legantoj - distribuita komputado aŭ plurkerna kaj kial?
Maurice: Nuntempe estas facile akiri multkernan procesoron, sed estas pli malfacile starigi veran distribuitan sistemon. Mi komencis labori pri ili ĉar mi volis fari ion malsaman ol mia doktora tezo. Jen la konsilo, kiun mi ĉiam donas al novaj studentoj: ne skribu daŭrigon de via disertaĵo—provu iri en novan direkton. Kaj ankaŭ, multithreading estas facila. Mi povas eksperimenti per mia propra forko funkcianta sur mia tekokomputilo sen eliri el la lito. Sed se mi subite volus krei veran distribuitan sistemon, mi devus fari multe da laboro, allogi studentojn ktp. Mi estas maldiligenta kaj preferus labori pri multkerna. Eksperimenti sur plurkernaj sistemoj ankaŭ estas pli facila ol fari eksperimentojn pri distribuitaj sistemoj, ĉar eĉ en stulta distribua sistemo estas tro da faktoroj, kiujn oni devas kontroli.
Vitaly: Kion vi faras nun, esplorante blokĉenon? Kiujn artikolojn vi unue atentu?
Maurice: Lastatempe aperis , kiun mi verkis kune kun mia studento, Vikram Saraf, precipe por prelego ĉe en Parizo antaŭ tri semajnoj. Ĉi tio estas artikolo pri praktikaj distribuitaj sistemoj, en kiu ni proponas fari Ethereum multfadena. Nuntempe, inteligentaj kontraktoj (kodo kiu funkcias sur la blokĉeno) estas ekzekutitaj sinsekve. Ni skribis artikolon pli frue, kiu parolis pri maniero uzi spekulajn transakciojn por akceli la procezon. Ni prenis multajn ideojn de programara transakcia memoro kaj diris, ke se vi faros ĉi tiujn ideojn parto de la virtuala maŝino de Etherium, tiam ĉio funkcios pli rapide. Sed por tio necesas, ke ne ekzistas datumkonfliktoj en la kontraktoj. Kaj tiam ni supozis, ke en la reala vivo vere ne ekzistas tiaj konfliktoj. Sed ni ne havis manieron ekscii. Tiam okazis al ni, ke ni havis preskaŭ jardekon da reala kontrakthistorio sur niaj manoj, do ni forĵetis la blokĉenon de Ethereum kaj demandis nin: kio okazus se ĉi tiuj historiaj rekordoj estus ekzekutitaj paralele? Ni trovis gravan pliiĝon de rapideco. En la fruaj tagoj de Ethereum, la rapideco multe pliiĝis, sed hodiaŭ ĉio estas iom pli komplika, ĉar estas malpli da kontraktoj kaj la probablo de konfliktoj pri datumoj, kiuj postulas seriigon, fariĝis pli alta. Sed ĉio ĉi estas eksperimenta laboro kun realaj historiaj datumoj. La agrabla afero pri la blokĉeno estas, ke ĝi memoras ĉion eterne, do ni povas reiri en la tempo kaj studi kio estus okazinta se ni uzus malsamajn algoritmojn por ruli la kodon. Kiel homoj en la pasinteco ŝatus nian novan ideon? Tia esploro estas multe pli facila kaj pli ĝuebla por fari, ĉar ekzistas afero, kiu kontrolas ĉion kaj registras ĉion. Ĉi tio jam estas io pli simila al sociologio ol al la evoluo de algoritmoj.
Ĉu la evoluo de algoritmoj ĉesis kaj kiel pluiri?
Vitaly: Tempo por la lasta teoria demando! Ĉu ĝi sentas, ke progreso en konkurencivaj datumstrukturoj malpliiĝas ĉiujare? Ĉu vi pensas, ke ni atingis altebenaĵon en nia kompreno de datumstrukturoj aŭ estos iuj gravaj plibonigoj? Eble ekzistas iuj lertaj ideoj, kiuj povas tute ŝanĝi ĉion?
Maurice: Ni eble atingis altebenaĵon en datumstrukturoj por tradiciaj arkitekturoj. Sed datumstrukturoj por novaj arkitekturoj daŭre estas tre promesplena areo. Se vi volas krei datumstrukturojn por, ekzemple, aparataj akceliloj, tiam la datumstrukturoj por GPU estas tre malsamaj de la datumstrukturoj por CPU. Kiam vi disvolvas datumstrukturojn por blokĉenoj, vi devas haŝi pecojn de datumoj kaj poste meti ilin en ion similan , por malhelpi falsigon. Okazis pliiĝo de agado en ĉi tiu areo lastatempe, kun multaj farantaj tre bonan laboron. Sed mi pensas, kio okazos, ke novaj arkitekturoj kaj novaj aplikoj kondukos al novaj datumstrukturoj. Heredaĵoj kaj tradicia arkitekturo - eble ne plu estas multe da loko por esplorado. Sed se vi foriras de la batita vojo kaj rigardos preter la randoj, vi vidos frenezajn aferojn, kiujn la ĉeftendenco ne prenas serioze - tie ĉiuj ekscitaj aferoj vere okazas.
Vitaly: Tial, por esti tre fama esploristo, mi devis inventi mian propran arkitekturon :)
Maurice: Vi povas "ŝteli" la novan arkitekturon de iu alia - ŝajnas multe pli facile!
Laborante ĉe Brown University
Vitaly: Ĉu vi povus rakonti al ni pli pri kie vi laboras? Ne multe estas konata pri li en la kunteksto de informa teknologio. Malpli ol pri MIT, ekzemple.
Maurice: Brown University estas unu el la plej malnovaj universitatoj en Usono. Mi pensas, ke nur Harvard estas iom pli aĝa. Bruna estas parto de la tn , kiu estas kolekto de ok plej malnovaj universitatoj. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pensilvanio, Princeton. Ĝi estas kvazaŭ malnova, malgranda kaj iom aristokrata universitato. La ĉefa fokuso estas sur liberala arta edukado. Ĝi ne provas esti kiel MIT, MIT estas tre specialigita kaj teknika. Brown estas bonega loko por studi Rusan Literaturon aŭ Klasikan Grekan, kaj kompreneble, Komputiko. Ĝi temigas ampleksan edukadon. Plej multaj el niaj studentoj iras al Fejsbuko, Apple, Guglo - do mi pensas, ke niaj studentoj ne havas problemojn trovi laboron en la industrio. Mi iris labori ĉe Brown ĉar mi antaŭe laboris ĉe Digital Equipment Corporation en Bostono. Ĉi tio estis firmao, kiu inventis multajn interesajn aferojn, sed neis la gravecon de personaj komputiloj. Firmao kun malfacila sorto, kies fondintoj iam estis junaj revoluciuloj, ili lernis nenion kaj forgesis nenion, kaj tial ili turnis sin de revoluciuloj al reakciuloj ene de proksimume dekduo jaroj. Ili ŝatis ŝerci, ke personaj komputiloj apartenas al la garaĝo — forlasita garaĝo, kompreneble. Estas sufiĉe evidente, ke ili estis detruitaj de pli flekseblaj kompanioj. Kiam evidentiĝis, ke la kompanio havas problemojn, mi telefonis al mia amiko en Brown, kiu estas ĉirkaŭ unu horo ekster Bostono. Mi ne volis forlasi Bostonon tiutempe ĉar ne estis multaj malfermaĵoj en aliaj universitatoj. Ĉi tio estis tempo, kiam ne estis tiom da laboroj en Komputika Scienco kiel nun. Kaj Brown havis malfermon, mi ne devis movi mian hejmon, mi ne devis movi mian familion, kaj mi tre amas vivi en Bostono! Tiel mi decidis iri al Brown. Mi ŝatas ĝin. La studentoj estas mirindaj, do mi eĉ neniam provis iri aliloken. Dum mia ŝabatjaro, mi laboris ĉe Microsoft dum jaro, iris al Technion en Ĥajfo dum jaro, kaj nun mi estos ĉe Algorand. Mi havas multajn kolegojn ĉie kaj tial la fizika loko de niaj klasĉambroj ne estas tiom grava. Sed la plej grava afero estas la studentoj, ili estas la plej bonaj ĉi tie. Mi neniam provis iri aliloken ĉar mi estas sufiĉe feliĉa ĉi tie.
Tamen malgraŭ la famo de Brown en Usono, li estas surprize nekonata eksterlande. Kiel vi vidas, mi nun faras ĉion eblan por korekti ĉi tiun staton.
Diferenco inter esplorado en universitato kaj ene de korporacio
Vitaly: Bone, la sekva demando temas pri Cifereca Ekipaĵo. Vi estis tie kiel esploristo. Kio estas la diferenco inter labori en la R&D-sekcio de granda firmao kaj labori en universitato? Kio estas la avantaĝoj kaj malavantaĝoj?
Maurice: Dum dudek jaroj mi laboris ĉe Microsoft, laboris proksime kun dungitoj de Sun Microsystems, Oracle, Facebook, kaj nun Algorand. Surbaze de ĉio ĉi, mi volas diri, ke eblas fari unuaklasan esploron kaj en kompanioj kaj en universitatoj. La grava diferenco estas, ke en kompanio vi laboras kun kolegoj. Se mi subite havas ideon pri projekto, kiu ankoraŭ ne ekzistas, mi devas konvinki miajn kunulojn, ke tio estas bona ideo. Se mi estas ĉe Brown, tiam mi povas diri al miaj lernantoj: ni laboru pri kontraŭgravito! Ili aŭ foriros al iu alia aŭ alprenos projekton. Jes, mi devos trovi financadon, mi devos skribi subvenciopeton, ktp. Ĉiukaze ĉiam estos multaj studentoj, kaj vi povos fari decidojn unuflanke. Sed en universitato vi plej verŝajne ne laboros kun homoj de via nivelo. En la mondo de industria esplorado, vi unue devas konvinki ĉiujn, ke via projekto valoras surpreni. Mi povas nenion mendi al iu ajn. Kaj ambaŭ ĉi tiuj labormanieroj estas valoraj, ĉar se vi laboras pri io vere freneza kaj viaj kolegoj estas malfacile konvinkigeblaj, estas pli facile konvinki diplomiĝajn studentojn – precipe se vi pagas ilin. Se vi laboras pri io, kio postulas multan sperton kaj profundan kompetentecon, tiam vi bezonas kolegojn, kiuj povas diri "ne, okazas, ke mi komprenas en ĉi tiu areo kaj via ideo estas malbona, ĝi ne funkcios." Ĉi tio estas tre utila koncerne perdon de tempo. Ankaŭ, se en industriaj laboratorioj vi pasigas multe da tempo skribante raportojn, tiam en universitato vi pasigas ĉi tiun tempon provante trovi monon. Se mi volas, ke studentoj povu iri ien, mi devas trovi la monon por ĝi aliloke. Kaj ju pli grava via pozicio en la universitato, des pli da tempo vi devas elspezi kolekti monon. Do nun vi scias, por kio mi laboras - profesia almozulo! Kiel unu el tiuj monaĥoj, kiu ĉirkaŭpromenas kun oferplato. Ĝenerale, ĉi tiuj du agadoj kompletigas unu la alian. Tial mi provas vivi kaj teni miajn piedojn sur la tero en ambaŭ mondoj.
Vitaly: Ŝajnas, ke konvinki firmaon estas pli malfacila ol konvinki aliajn sciencistojn.
Maurice: Pli malfacila, kaj multe pli. Krome, en malsamaj areoj ĝi estas malsama: iuj faras plenskalan esploradon, dum aliaj fokusiĝas al sia temo. Se mi irus al Mikrosofto aŭ Fejsbuko kaj dirus: ni faru kontraŭgravitan, ili apenaŭ aprezus ĝin. Sed se mi dirus ĝuste la samon al miaj diplomiĝaj studentoj, ili plej verŝajne eklaborus tuj, kvankam nun mi havus problemojn - ja mi bezonas trovi monon por tio. Sed dum vi volas fari ion, kio kongruas kun la celoj de la kompanio, tiu kompanio povas esti tre bona loko por esplori.
Hidro kaj SPTDC
Vitaly: Miaj demandoj finiĝas, do ni iom parolu pri la venonta vojaĝo al Rusio.
Maurice: Jes, mi antaŭĝojas reveni al Peterburgo.
Alexey: Mi estas honorita havi vin kun ni ĉi-jare. Jen via dua fojo en Peterburgo, ĉu ne?
Maurice: Jam la tria!
Alexey: Mi komprenas, sed – certe la dua. Lastan fojon oni vokis la lernejon , ni nun ŝanĝis unu literon (C al D, Samtempa al Distribuita) por emfazi ke ekzistas pli da areoj rilataj specife al distribuita komputado ĉi-jare. Ĉu vi povas diri kelkajn vortojn pri viaj raportoj ĉe la Lernejo kaj ?
Maurice: En la Lernejo mi volas paroli pri la bazaĵoj de blokĉeno kaj kion vi povas fari per ĝi. Mi ŝatus montri, ke blokĉenoj tre similas al la multfadena programado, kiun ni konas, sed kun siaj propraj nuancoj, kaj ĉi tiuj diferencoj estas grave kompreni. Se vi eraras en regula TTT-aplikaĵo, ĝi estas nur ĝena. Se vi skribas bugan kodon en financa aplikaĵo, iu certe ŝtelos vian tutan monon. Ĉi tiuj estas tute malsamaj niveloj de respondeco kaj sekvoj. Mi parolos iomete pri pruvo de laboro, pri inteligentaj kontraktoj, pri transakcioj inter malsamaj blokĉenoj.
Apud mi laboros aliaj parolantoj, kiuj ankaŭ havas ion por diri pri blokĉeno, kaj ni konsentis kunordigi unu kun la alia por ke niaj rakontoj bone kongruu. Sed por la inĝenieristika raporto, mi volas diri al larĝa publiko kompreneblan klarigon pri kial vi ne devus kredi ĉion, kion vi aŭdas pri blokĉenoj, kial blokĉenoj estas bonega kampo, kiel ĝi kongruas kun aliaj konataj ideoj, kaj kial ni kuraĝe rigardi. al la estonteco.
Alexey: Krome, mi volas diri, ke tio ne okazos en la formato de renkontiĝo aŭ uzantgrupo, kiel ĝi estis antaŭ du jaroj. Ni decidis okazigi malgrandan konferencon apud la lernejo. La kialo estas, ke post komunikado kun Petro Kuznetsov, ni konstatis, ke la lernejo estas limigita al nur cent, eble 120 homoj. Samtempe, estas multaj inĝenieroj, kiuj volas komuniki kun vi, ĉeesti prezentojn kaj ĝenerale interesiĝas pri la temo. Tial ni kreis novan konferencon . Cetere, iuj ideoj kial Hydra?
Maurice: Ĉar estos sep parolantoj? Kaj iliaj kapoj povas esti detranĉitaj, kaj novaj parolantoj kreskos anstataŭ ilia loko?
Alexey: Bonega ideo por kreskigi novajn parolantojn. Sed fakte, estas rakonto ĉi tie. Memoru la legendon de Odiseo, kie li devis navigi inter ? Hidro estas io kiel Karibdo. La rakonto estas, ke iam mi parolis en konferenco kaj parolis pri multfadenado. Ekzistis nur du trakoj ĉe tiu konferenco. Komence de la raporto, mi diris al la ĉeestantoj en la salono, ke ili nun havas elekton inter Skilo kaj Karibdo. Mia spiritbesto estas Charybdis ĉar Charybdis havas multajn kapojn kaj mia temo estas multfadena. Tiel aperas la nomoj de konferencoj.
Ĉiukaze, ni elĉerpigis demandojn kaj tempon. Do, dankon, amikoj, pro bonega intervjuo, kaj ĝis revido ĉe SPTDC School and Hydra 2019!
Vi povas daŭrigi vian konversacion kun Maurice ĉe la Hydra 2019-konferenco, kiu okazos la 11-12-an de julio 2019 en Sankt-Peterburgo. Li venos kun raporto . Biletoj estas aĉeteblaj .
fonto: www.habr.com