- el propietari de dos. El primer és per feina (Brown University) i la segona, més recent, - (Universitat Tecnològica de Virginia). El Premi Dijkstra s'atorga a obres la transcendència i la influència de les quals es noten des de fa almenys deu anys i, òbviament, Maurice és un dels especialistes més famosos en la matèria. Actualment és professor a la Universitat de Brown i té èxits de llargs paràgrafs. Ara es dedica a la investigació de blockchain en el context de la informàtica distribuïda clàssica.
Anteriorment, Maurice ja ha vingut a Rússia per a l'SPTCC () i va fer una excel·lent reunió de la comunitat de desenvolupadors Java de JUG.ru a Sant Petersburg ().
Aquest habrapost és una gran entrevista amb Maurice Herlihy. Es tracta dels temes següents:
- Interacció entre el món acadèmic i la indústria;
- Fundació per a la recerca de blockchain;
- D'on surten les idees innovadores? Influència de la popularitat;
- Doctorat sota la direcció de Barbara Liskov;
- El món està esperant multi-nucli;
- Nou món, nous problemes. NVM, NUMA i pirateria d'arquitectura;
- Compiladors vs CPU, RISC vs CISC, memòria compartida vs passatge de missatges;
- L'art d'escriure codi fràgil multifil;
- Com ensenyar als estudiants a escriure codi complex multifils;
- Nova edició del llibre "The Art of Multiprocessor Programming";
- Com es va inventar la memòria transaccional?
- Per què val la pena fer recerca en el camp de la computació distribuïda;
- S'ha aturat el desenvolupament d'algorismes i com viure;
- Treballar a la Universitat de Brown;
- La diferència entre la recerca universitària i corporativa;
- Hydra i SPTDC.
Les entrevistes les realitzen:
Vitali Aksenov — actualment és postdoctoral a IST Àustria i empleat del Departament de Tecnologies Informàtiques de la Universitat ITMO. Es dedica a la recerca en el camp de la teoria i la pràctica d'estructures de dades competitives. Abans d'incorporar-se a IST, va rebre el seu doctorat a la Universitat Diderot de París i a la Universitat ITMO amb el professor Petr Kuznetsov.
Alexei Fedorov és productor de JUG Ru Group, una empresa russa que organitza conferències per a desenvolupadors. Alexey va participar en la preparació de més de 50 conferències, i el seu currículum conté des de la posició d'enginyer de desenvolupament a Oracle (JCK, Java Platform Group) fins a la posició de desenvolupador a Odnoklassniki.
Vladimir Sitnikov és enginyer a Netcracker. Durant deu anys treballa en el rendiment i l'escalabilitat del sistema operatiu NetCracker, programari utilitzat pels operadors de telecomunicacions per automatitzar els processos de gestió d'equips de xarxa i xarxa. Interessat en problemes de rendiment de Java i Oracle Database. Autor de més d'una dotzena de millores de rendiment al controlador JDBC oficial de PostgreSQL.
Interacció entre el món acadèmic i la indústria
Alexey: Maurice, has estat treballant a l'acadèmia durant molt de temps i la primera pregunta és sobre la interacció entre l'acadèmia i la indústria. Ens pots explicar com han canviat les interaccions entre ells darrerament? Què va ser fa 20-30 anys i què està passant ara?
Maurice: Sempre he intentat treballar estretament amb empreses comercials perquè tenen reptes interessants. Per regla general, no estan molt interessats ni en publicar els seus resultats ni en les explicacions detallades dels seus problemes a la comunitat mundial. Només els interessa resoldre aquests problemes. Vaig treballar per a algunes d'aquestes empreses durant un temps. Vaig passar cinc anys treballant a temps complet en un laboratori d'investigació de Digital Equipment Corporation, que abans era una important empresa informàtica. Vaig treballar un dia a la setmana a Sun, a Microsoft, a Oracle, vaig treballar una mica a Facebook. Ara me'n sortiré d'un període sabàtic (un professor d'una universitat nord-americana pot prendre aquestes vacances durant un any aproximadament un cop cada sis anys) i treballaré a , aquesta és una empresa de criptomoneda a Boston. Treballar estretament amb les empreses sempre ha estat un plaer, perquè així s'aprèn coses noves i interessants. En general, pots ser la primera o la segona persona a publicar un article sobre un tema escollit, en lloc de millorar gradualment les solucions als problemes en els quals tothom ja està treballant.
Alexey: Ens pots explicar més sobre com passa això?
Maurice: Per descomptat. Ja sabeu, quan estava a Digital Equipment Corporation, jo i Elliot Moss, vam inventar la memòria transaccional. Va ser un període molt fructífer en què tothom va començar a interessar-se per les tecnologies de la informació. Concurrència inclosa, tot i que encara no existien sistemes multinucli. En els temps de Sun i Oracle, vaig treballar molt en estructures de dades paral·leles. A Facebook vaig estar involucrat en el seu projecte blockchain, del qual no puc parlar, però espero que es faci públic aviat. L'any que ve, a Algorand, treballaré en un equip d'investigació que estudiarà els contractes intel·ligents.
Alexey: En els últims anys, blockchain s'ha convertit en un tema molt popular. Ajudarà la teva investigació? Potser facilitarà l'obtenció de subvencions o l'accés als recursos de les empreses que operen en el sector?
Maurice: Ja he rebut una petita beca de la Fundació Ethereum. La popularitat de la cadena de blocs és molt útil per inspirar els estudiants a treballar en aquest camp. Hi estan molt interessats i contents de participar, però de vegades no s'adonen que una investigació que sembla temptadora a l'exterior resulta que implica un treball molt dur. No obstant això, estic molt content d'utilitzar tota aquesta mística al voltant de la cadena de blocs, que ajuda a atraure estudiants.
Però això no és tot. Estic al consell assessor de diverses startups de blockchain. Alguns poden tenir èxit, alguns no, però sempre és molt interessant veure les seves idees, estudiar-les i assessorar la gent. El més emocionant és quan avises a la gent que no faci res. Al principi moltes coses semblen una bona idea, però ho són realment?
Fundació per a la recerca de blockchain
Vitaly: Algunes persones pensen que la cadena de blocs i els seus algorismes són el futur. I altres persones diuen que només és una bombolla més. Pots compartir la teva opinió sobre aquest tema?
Maurice: Molt del que està passant al món de la cadena de blocs no funciona correctament, alguns són només estafes, moltes coses estan sobrevalorades. Tanmateix, crec que hi ha una base científica sòlida per a aquests estudis. El fet que el món blockchain estigui ple de divisions ideològiques mostra el nivell d'emoció i dedicació. D'altra banda, no és especialment beneficiós per a la investigació científica. Ara bé, si publiqueu un article que parla de les mancances d'un determinat algorisme, la reacció rebuda no sempre és del tot científica. Sovint la gent expressa les seves emocions. Crec que aquest bombo en aquesta àrea pot semblar atractiu per a alguns, però al final, hi ha qüestions científiques i d'enginyeria reals que encara no s'han abordat. Aquí hi ha molta informàtica.
Vitaliy: Així que estàs intentant establir les bases per a la investigació de blockchain, oi?
Maurice: Estic tractant de posar les bases d'una disciplina sòlida, científicament i matemàticament sòlida. I part del problema és que de vegades has de contradir algunes de les posicions massa dures d'altres persones, per ignorar-les. De vegades la gent es pregunta per què treballo en un camp que només interessa als terroristes i als narcotraficants. Aquesta reacció no té sentit com el comportament dels seguidors que repeteixen a cegues les teves paraules. Crec que la veritat està en algun lloc al mig. Blockchain encara no té un impacte profund en la societat i l'economia global. Però, probablement, això no passarà gràcies a la tecnologia moderna. Es desenvoluparan tecnologies modernes i el que s'anomenarà blockchain en el futur serà molt important. Potser ni tan sols semblarà blockchains moderns, aquesta és una pregunta oberta.
Si la gent inventa noves tecnologies, ho continuarà anomenant blockchain. Vull dir, igual que el Fortran actual no té res a veure amb la llengua Fortran dels anys 1960, però tothom l'anomena Fortran. El mateix per a UNIX. El que s'anomena "blockchain" encara no ha fet la seva revolució. Però dubto que aquesta nova cadena de blocs sigui com el que tothom li agrada utilitzar avui.
D'on surten les idees innovadores? Influència de la popularitat
Alexey: La popularitat de la cadena de blocs ha portat a nous resultats des del punt de vista científic? Més interacció, més estudiants, més empreses de la zona. Hi ha ja algun resultat d'aquest creixement de popularitat?
Maurice: Em vaig interessar en això quan algú em va lliurar un fullet oficial d'una empresa que acabava de recaptar molts diners. Ella va escriure sobre amb la qual estic més que familiaritzat. Escrit al fulletó era clarament tècnicament incorrecte. La gent que va escriure això no entenia realment el model darrere del problema... i, tanmateix, aquesta empresa va recaptar molts diners. Posteriorment, l'empresa va substituir en silenci aquest fulletó per una versió molt més correcta, i no diré quin era el nom d'aquesta empresa. Encara existeixen i ho estan fent molt bé. Aquest cas em va convèncer que, en primer lloc, blockchain és només una forma d'informàtica distribuïda. En segon lloc, el llindar d'entrada (aleshores, fa quatre anys) era força baix. Les persones que treballaven en aquesta àrea eren molt enèrgiques i intel·ligents, però no llegien articles científics. Van intentar reinventar coses conegudes i ho van fer malament. Avui el drama s'ha reduït.
Alexey: És molt interessant, perquè fa uns anys teníem una tendència diferent. És una mica com el desenvolupament del front-end, on els desenvolupadors d'interfícies del navegador van reinventar tecnologies senceres que ja eren populars al back-end en aquell moment: crear sistemes, integració contínua i coses com aquestes.
Maurice: Estic d'acord. Però això no és d'estranyar, perquè les idees realment innovadores sempre provenen de fora de la comunitat establerta. És poc probable que els investigadors establerts, especialment les autoritats del món acadèmic, facin res realment innovador. És fàcil escriure un informe per a la propera conferència sobre com heu millorat lleugerament els resultats del vostre treball anterior. Anar a una conferència, reunir-se amb amics, parlar de les mateixes coses. I la gent que irromp amb idees innovadores gairebé sempre ve de fora. No coneixen les regles, no saben l'idioma, però tot i així... Si ets dins d'una comunitat consolidada, t'aconsello que facis cas a les coses noves, a allò que no encaixa en el gran imatge. En cert sentit, es pot intentar combinar desenvolupaments externs més fluids amb tècniques que ja entenem. Com a primer pas, intenteu crear una base científica i després modificar-la perquè es pugui aplicar a noves idees innovadores. Crec que la cadena de blocs és ideal per al paper d'una idea innovadora.
Alexei: Per què creus que està passant això? Perquè la gent "fora" no té cap barrera específica inherent a la comunitat?
Maurice: Aquí hi ha un patró. Si llegiu la història dels impressionistes a la pintura i l'art en general, en un moment els artistes famosos van rebutjar l'impressionisme. Van dir que era una mena d'infantilisme. Una generació més tard, aquesta forma d'art abans rebutjada es va convertir en l'estàndard. El que veig en el meu camp: als inventors de la cadena de blocs no els interessava el poder, tancar publicacions i índex de citacions, només volien fer alguna cosa bona. I així es van asseure i van començar a fer-ho. Els faltava una certa profunditat tècnica, però això es pot arreglar. És molt més difícil plantejar noves idees creatives que corregir i amplificar les que no tenen prou maduresa. Gràcies a aquests inventors, ara tinc alguna cosa a fer!
Alexey: Això és similar a la diferència entre startups i projectes heretats. Heretem moltes limitacions de pensament, barreres, requisits especials, etc.
Maurice: Una bona analogia és la informàtica distribuïda. Penseu en blockchain com si fos una startup i informàtica distribuïda com una gran empresa establerta. La informàtica distribuïda està en procés de compra i fusió amb blockchain.
Doctorat sota Barbara Liskov
Vitaliy: Encara tenim moltes preguntes! Hem estat investigant la teva biografia i hem trobat un fet interessant sobre el teu doctorat. Sí, va ser fa molt de temps, però sembla que el tema és important. Has rebut el teu doctorat sota la supervisió de ! Barbara és molt coneguda a la comunitat de desenvolupament de llenguatges de programació i una persona molt famosa en general. És lògic que la teva recerca fos en el camp dels llenguatges de programació. Com vas passar a la informàtica paral·lela? Per què vas decidir canviar de tema?
Maurice: En aquell moment, la Barbara i el seu grup només miraven la informàtica distribuïda, que era una idea molt nova. També hi havia qui deia que la informàtica distribuïda és una tonteria, la comunicació entre ordinadors no té sentit. Una de les qüestions considerades en la informàtica distribuïda, que els distingeix de la informàtica centralitzada, és la tolerància a fallades. Després de moltes investigacions, vam decidir que en un llenguatge de programació per a la informàtica distribuïda, cal tenir alguna cosa com les transaccions atòmiques, perquè mai no es pot estar segur que una trucada remota tindrà èxit. Un cop tingueu transaccions, hi ha un problema de control de concurrència. Després hi va haver molta feina per obtenir estructures de dades transaccionals altament paral·leles. Després, quan em vaig graduar, vaig anar-hi i va començar a buscar un tema per treballar. Se'm va ocórrer que la informàtica havia passat d'ordinadors individuals a xarxes d'ordinadors. Una continuació natural del progrés serien els multiprocessadors: aleshores no existia la paraula "multi-core". Vaig pensar: quin és l'equivalent de transaccions atòmiques per a un sistema multi-nucli? Definitivament no transaccions ordinàries, perquè són massa grans i pesades. I així va ser com em va sorgir la idea i així va ser com em va sortir tota la sincronització sense espera. Va ser un intent de respondre a la pregunta de quin és l'anàleg de les transaccions atòmiques per a un sistema multiprocessador amb memòria compartida. A primera vista, aquesta obra pot semblar força diferent, però de fet és una continuació del mateix tema.
El món esperant multinucli
Vitaly: Has esmentat que hi havia molt pocs ordinadors multinucli en aquell moment, oi?
Maurice: Simplement no existien. Hi havia diversos multiprocessadors anomenats simètrics, que bàsicament estaven connectats al mateix bus. No va funcionar molt bé, perquè cada vegada que una nova empresa creava una cosa així, Intel llançava un únic processador que superava el multiprocessador.
Alexei: Això no vol dir que en aquells temps antics, era més un estudi teòric?
Maurice: No va ser un estudi teòric, sinó especulatiu. Tot això no es tractava de treballar amb molts teoremes, sinó que vam plantejar hipòtesis sobre l'arquitectura que no existia en aquell moment. Per això serveix la investigació! Cap empresa ho hauria fet, tot era quelcom d'un futur llunyà. De fet, això va ser fins l'any 2004, quan van aparèixer els autèntics processadors multinucli. A causa del fet que els processadors s'escalfen, podeu fer que el processador sigui encara més petit, però no ho podeu fer més ràpid. A causa d'això, hi va haver una transició a arquitectures multi-nucli. I aleshores va significar que, de sobte, hi havia un ús per a tots els conceptes que havíem desenvolupat en el passat.
Alexey: Per què creus que els processadors multinucli van aparèixer només als anys XNUMX? Aleshores, per què tan tard?
Maurice: Es deu a limitacions de maquinari. Intel, AMD i altres empreses són molt bones per augmentar la velocitat del processador. Quan en algun moment els processadors es van fer prou petits com per no poder augmentar més la velocitat del rellotge perquè els processadors començarien a esgotar-se. Podeu fer-los més petits, però no més ràpids. El que està al seu abast: en lloc d'un processador molt petit, hi caben vuit, setze o trenta-dos processadors al mateix volum de la caixa, on només hi cabia un. Ara teniu una comunicació múltiple i ràpida entre ells perquè comparteixen memòria cau. Però no pots fer-los córrer més ràpid: hi ha un límit de velocitat molt específic. Continuen millorant a poc a poc, però no tant. Les lleis de la física es van posar en el camí.
Nou món, nous problemes. NUMA, NVM i pirateria d'arquitectura
Alexei: Sona molt raonable. Amb els nous processadors multinucli van sorgir nous problemes. Vostè i els seus companys esperaven aquests problemes? Potser els heu estudiat per endavant? En estudis teòrics sovint no és molt fàcil predir aquestes coses. Quan es van produir problemes, fins a quin punt van satisfer les vostres expectatives i les dels vostres companys? O eren nous i tu i els teus companys vau haver de dedicar molt de temps a resoldre problemes a mesura que van sorgir?
Vitaliy: afegiré a la pregunta d'Alexei: vau predir correctament l'arquitectura dels processadors mentre estudiaves teoria?
Maurice: No tot al 100%. Però crec que els meus col·legues i jo vam fer una bona feina predint la memòria compartida multinucli. Crec que vam predir correctament les dificultats per dissenyar estructures de dades paral·leles que funcionin sense bloquejos. Aquestes estructures de dades han estat importants per a moltes aplicacions, encara que no per a totes, però sovint necessiteu una estructura de dades sense bloqueig. Quan els vam inventar, molts van argumentar que això és una tonteria, que tot funciona bé amb els panys. Vam preveure força bé que hi hauria solucions ja fetes per a molts problemes de programació i problemes d'estructura de dades. També hi havia problemes més complexos, com ara – Accés desigual a la memòria. De fet, ni tan sols es van considerar fins a la invenció dels processadors multinucli perquè eren massa específics. La comunitat investigadora va treballar en preguntes que generalment eren previsibles. Alguns problemes de maquinari associats a arquitectures específiques van haver d'esperar en les ales, de fet, l'aparició d'aquestes arquitectures. Per exemple, ningú va treballar realment en estructures de dades específiques de la GPU perquè aleshores la GPU no existia. Tot i que s'ha fet molta feina , aquests algorismes estaven preparats per utilitzar-se tan bon punt va aparèixer el maquinari adequat. Tanmateix, és impossible predir-ho tot.
Alexey: Si entenc bé, NUMA és una mena de compromís entre cost, rendiment i algunes altres coses. Alguna idea de per què NUMA va arribar tan tard?
Maurice: Crec que NUMA existeix a causa d'un problema amb el maquinari utilitzat per fer memòria: com més lluny estan els components, més lent s'hi accedeix. D'altra banda, el segon valor d'aquesta abstracció és la uniformitat de la memòria. Per tant, una de les característiques de la computació paral·lela és que totes les abstraccions estan lleugerament trencades. Si l'accés fos perfectament uniforme, tota la memòria seria equidistant, però això és econòmicament, i potser fins i tot físicament impossible. Així sorgeix aquest conflicte. Si escriviu el vostre programa com si la memòria fos uniforme, el més probable és que sigui correcte. En el sentit que no donarà respostes equivocades. Però l'actuació de les seves estrelles des del cel no agafarà. De la mateixa manera, si escrius sense entendre la jerarquia de la memòria cau, el bloqueig en si serà correcte, però us podeu oblidar del rendiment. En cert sentit, has d'escriure programes que visquin al damunt d'una abstracció molt senzilla, però has de superar la gent que t'ha fet aquesta abstracció: has de saber que sota l'abstracció hi ha una certa jerarquia de memòria, que hi ha un autobús entre tu i aquest record, etc. Així, hi ha un cert conflicte entre abstraccions que són útils per si soles, la qual cosa ens porta a problemes molt concrets i pragmàtics.
Vitaliy: Què passa amb el futur? Podeu predir com es desenvoluparan els processadors? Hi ha la idea que una de les respostes és la memòria transaccional. Segurament tens alguna cosa més en estoc.
Maurice: Hi ha un parell de grans reptes per davant. Una és que la memòria coherent és una abstracció meravellosa, però comença a trencar-se en casos especials. Així, per exemple, NUMA és un exemple viu d'alguna cosa on es pot seguir fingint que existeix una memòria uniforme. De fet, no, l'actuació et farà plorar. En algun moment, els arquitectes hauran d'abandonar la idea d'una arquitectura de memòria unificada, no es pot fingir per sempre. Es necessitaran nous models de programació que siguin prou fàcils d'utilitzar i prou potents per fer que el maquinari subjacent sigui eficient. Aquest és un compromís molt difícil, perquè si mostres als programadors l'arquitectura que s'utilitza realment al maquinari, es tornaran bojos. És massa complicat i no és portàtil. Si presenteu una interfície massa senzilla, el rendiment serà baix. Per tant, caldrà fer molts compromisos molt difícils per oferir models de programació útils aplicables a processadors multinúclis realment grans. No estic segur que ningú que no sigui un especialitzat estret sigui capaç de programar en un ordinador de 2000 nuclis. I tret que facis informàtica molt especialitzada o científica, criptografia o el que sigui, encara no està gens clar com fer-ho bé.
Una altra direcció similar són les arquitectures especialitzades. Els acceleradors gràfics existeixen des de fa molt de temps, però ja s'han convertit en un exemple clàssic de com es pot prendre un tipus de càlcul especialitzat i executar-lo en un xip dedicat. Això afegeix els seus propis reptes: com us comuniqueu amb aquest dispositiu, com el programeu. Recentment he treballat en tasques de camp . Agafeu un petit processador i l'enganxeu a una gran part de memòria perquè la memòria funcioni a la velocitat de la memòria cau L1 i, a continuació, es comuniqui amb un dispositiu com ara - el processador està ocupat carregant tasques noves al vostre nucli de memòria. El desenvolupament d'estructures de dades i protocols de comunicació per a aquest tipus de coses és un altre exemple interessant. Així, els processadors i el maquinari especialitzats estaran subjectes a millores durant força temps.
Alexey: Què passa amb la memòria no volàtil?)?
Maurice: Ah, aquest és un altre gran exemple! NVM canviarà molt la manera de veure coses com les estructures de dades. La memòria no volàtil, en cert sentit, promet accelerar realment les coses. Però no us facilitarà la vida, perquè la majoria de processadors, memòria cau i registres encara són volàtils. Quan engegueu després d'una fallada, el vostre estat i el vostre estat de memòria no seran exactament els mateixos que abans de la fallada. Estic molt agraït a les persones implicades en NVM: durant molt de temps, els investigadors tindran alguna cosa a fer, tractant d'esbrinar les condicions correctes. Els càlculs són correctes si poden sobreviure a un accident en què es perden els continguts de la memòria cau i els registres, però la memòria principal roman intacta.
Compiladors vs CPU, RISC vs CISC, memòria compartida vs passatge de missatges
Vladimir: Què en penseu del dilema entre compiladors i processadors pel que fa al conjunt d'instruccions? Per explicar-ho per als qui no estan en l'assignatura: si anem a la memòria desigual o alguna cosa així, podríem aplicar un conjunt d'instruccions molt senzilles i demanar al compilador que generi codi complex que pugui aprofitar els beneficis descoberts. O podem anar al contrari: implementar instruccions complexes i demanar al processador que reordena les instruccions i faci altres manipulacions amb elles. Què en penses?
Maurice: Realment no tinc una resposta a aquesta pregunta. Aquest debat porta quatre dècades. Hi va haver un temps entre conjunt d'ordres i les guerres civils eren lliurades per un conjunt d'equips. Durant un temps, la gent de RISC va guanyar, però després Intel va reconstruir els seus motors de manera que es va utilitzar un conjunt d'instruccions reduït a l'interior i el complet s'exportava a l'exterior. Potser aquest és un tema en què cada nova generació ha de trobar els seus propis compromisos i prendre les seves pròpies decisions. És molt difícil predir quina d'aquestes coses sortirà millor. Per tant, qualsevol predicció que faci serà certa durant un cert període de temps, i després tornarà a ser falsa durant un temps, i després tornarà a ser certa.
Alexey: Què tan comú és per a la indústria en general que algunes idees guanyin durant diverses dècades i perdin en les següents? Hi ha altres exemples d'aquests canvis periòdics?
Maurice: En el camp de la informàtica distribuïda, hi ha gent que hi creu i gent que hi creu . Originalment a la informàtica distribuïda, la informàtica paral·lela significa passar missatges. Aleshores algú va descobrir que la memòria compartida facilitava molt la programació. L'altra banda va dir que la memòria compartida és massa complicada, perquè necessiten panys i similars, per la qual cosa val la pena passar a idiomes on no hi ha res més que el pas de missatges. Algú va mirar el que en va sortir i va dir: "Uau, aquesta implementació de missatgeria s'assembla molt a la memòria compartida, perquè creeu molts, molts d'aquests petits mòduls, s'envien missatges entre ells i tots ells. , - millorem una base de dades de memòria compartida!". Tot això es repeteix una i altra vegada, i és impossible dir que una de les parts tingui una raó inequívoca. Un bàndol sempre dominarà, perquè tan bon punt un d'ells gairebé guanya, la gent una i altra vegada inventa maneres de millorar l'altre.
L'art d'escriure codi fràgil multifils
Alexei: Això és molt interessant. Per exemple, quan escrivim codi, independentment del llenguatge de programació, normalment hem de crear abstraccions com cel·les que es poden llegir i escriure. Però, de fet, en algun nivell físic, pot semblar enviar un missatge en un bus de maquinari entre diferents ordinadors i altres dispositius. Resulta que hi ha treball als dos nivells d'abstracció alhora.
Maurice: És absolutament cert que la memòria compartida es basa en el pas de missatges: busos, memòria cau, etc. Però és difícil escriure programes mitjançant el pas de missatges, de manera que el maquinari menteix deliberadament, fent veure que teniu algun tipus de memòria uniforme. Això us farà més fàcil escriure programes senzills i correctes abans que el rendiment comenci a baixar. Llavors dius: sembla que ha arribat el moment de fer amistat amb la memòria cau. I és llavors quan comences a preocupar-te per la ubicació de la memòria cau i ens n'anem. En cert sentit, estàs trencant l'abstracció: saps que no és només una memòria plana i uniforme, i utilitzaràs aquest coneixement per escriure programes compatibles amb la memòria cau. Això és el que has de fer en tasques reals. Aquest conflicte entre l'abstracció senzilla i agradable que se li va donar i la implementació terriblement complexa del maquinari subjacent és on cadascú fa el seu propi compromís. Tinc un llibre sobre multiprocessadors i sincronització, i un dia anava a escriure un capítol sobre estructures de dades a java.util.concurrent. Si els mireu, coses com Aquestes són obres d'art sorprenents. (Nota de l'editor: aquells que estiguin familiaritzats amb el llenguatge Java, almenys haurien de fer una ullada a la implementació ConcurrentSkipListMap, Podeu consultar els enllaços и ). Però, des del meu punt de vista, seria irresponsable mostrar-los als estudiants, perquè aquesta estructura de dades és una mena d'home en un circ, corrent amb una corda fluixa sobre un fossat d'ós. Si canvieu fins i tot un petit detall, tota l'estructura es col·lapsarà. Aquest codi és molt ràpid i elegant només perquè està perfectament escrit, però el més petit canvi portarà a un fracàs total. Si poso aquest codi com a exemple als estudiants, de seguida diran: jo també ho puc fer! I llavors algun avió s'estavellarà o un reactor nuclear explotarà, i serà culpa meva que no els hagi donat massa informació en el moment oportú.
Alexey: Quan era una mica més jove, moltes vegades vaig intentar estudiar el codi font de Doug Lee, per exemple, java.util.concurrent, com que és de codi obert, és molt fàcil trobar-lo i intentar entendre què hi passa. No va sortir gaire bé: sovint, no està del tot clar per què Doug va decidir fer alguna cosa d'aquesta manera, quan tots els altres ho fan de manera diferent. Com expliques aquestes coses als teus alumnes? Hi ha una manera correcta de descriure els detalls específics d'un algorisme dur, per exemple? Com ho fas?
Maurice: Els professors de dibuix tenen un tòpic que recorden primer: si vols dibuixar com Picasso, primer has d'aprendre a dibuixar dibuixos senzills i realistes, i només quan coneixes les regles pots començar a trencar-les. Si comenceu immediatament per trencar les regles, us fa un embolic. En primer lloc, ensenyo als estudiants a escriure codi senzill i correcte sense preocupar-me pel rendiment. Estic dient que hi ha problemes de temporització complexos a l'aguait aquí, així que no us preocupeu per la memòria cau, no us preocupeu pels models de memòria, només assegureu-vos que tot funcioni correctament. Ja és prou difícil: la programació moderna no és fàcil per si sola, especialment per als nous estudiants. I quan tenen una intuïció sobre com escriure programes correctes, dic: mira aquestes dues implementacions de spinlock: una és molt lenta, i la segona tampoc és molt bona, però ja millor. Tanmateix, matemàticament aquests dos algorismes són els mateixos. De fet, un d'ells utilitza la localitat de la memòria cau. Un d'ells gira sobre les dades emmagatzemades localment a la memòria cau i l'altre realitza repetidament operacions passant per l'autobús. No pots escriure codi eficient si no l'entens, si no saps com trencar l'abstracció i mirar l'estructura subjacent. Però no podràs començar a fer-ho de seguida. Hi ha gent que comença a fer això de seguida i creu en el seu propi geni, normalment acaba malament perquè no entenen els principis. Ningú dibuixa com Picasso ni escriu programes com Doug Lee, acabat de sortir de la universitat, en la seva primera setmana. Es necessiten anys per arribar a aquest nivell de coneixement.
Alexey: Resulta que divideixes el problema en dues parts: la primera és la correcció, la segona és el rendiment?
Maurice: Exactament. I, en aquest ordre. Una part del problema és que els estudiants nous no s'adonen que la correcció és difícil d'aconseguir. Diuen a primera vista: això és òbviament correcte, només queda accelerar-ho. Així que de vegades els parlo d'un algorisme inherentment incorrecte com si fos correcte.
Com ensenyar als estudiants a escriure codi complex multifils
Alexei: Només per veure si poden intuir el truc?
Maurice: Sempre t'adverteixo per endavant que de vegades trobaré algorismes equivocats. No hauries d'enganyar la gent. Suggereixo que siguin escèptics sobre la informació. Si dic alguna cosa i dic: "mira, això és òbviament correcte", això és un senyal que en algun lloc t'estan intentant enganyar i hauries de començar a fer preguntes. A continuació, intento animar els alumnes a seguir fent preguntes, i després pregunto: "què passa si ho deixem tot tal com està?". I de seguida veuen l'error. Però convèncer els estudiants que s'han de preocupar per la correcció és més difícil del que sembla a primera vista. Molts d'aquests estudiants vénen amb experiència en programació a l'institut, alguns ja han aconseguit feina i s'hi han programat, i tots estan plens d'autoconfiança. Això és una cosa militar: primer cal canviar la seva mentalitat per convèncer-los que abordin pacientment la solució dels problemes emergents. O potser és com els monjos budistes: primer aprenen a raonar sobre la correcció, i un cop entenen les maneres de raonar sobre la correcció, se'ls permet passar al següent nivell i començar a preocupar-se pel rendiment.
Alexey: És a dir, de vegades mostreu als estudiants exemples que no funcionen, gràcies als quals obteniu comentaris que mostren si entenen l'essència del problema, si poden trobar el codi incorrecte i el resultat incorrecte. Bé, com solen agradar o molestar els estudiants?
Maurice: Gairebé sempre els estudiants finalment troben l'error. Si busquen massa lentament, faig preguntes rellevants, i aquí és important entendre que si mai se'ls enganya, començaran a percebre sense pensar les teves paraules com la veritat definitiva. Després s'avorreixen i s'adormen llegint Facebook al seu ordinador portàtil durant la classe. Però quan els aviseu per endavant que seran estafats i que es veuran estúpids si no senten cap truc, es tornen molt més vigilants. Això és bo en molts aspectes. M'agradaria que els estudiants no només qüestionin la seva comprensió del tema, sinó que també qüestionin l'autoritat del professor. La idea és que l'alumne pugui aixecar la mà en qualsevol moment i dir: Crec que el que acabes de dir està malament. És una eina d'aprenentatge important. No vull que cap dels estudiants s'assegui i pensi en silenci: tot això sembla una ximpleria total, però fa massa por aixecar la mà i, de fet, és professor, així que tot el que diu és cert. Per tant, si se'ls adverteix amb antelació que no tot el que s'explica és necessàriament cert, tenen un al·licient per prestar més atenció al material. Declaro explícitament que aixecar la mà i fer preguntes està bé. La teva pregunta pot semblar ximple o ingènua, però sovint és així com sorgeixen les millors preguntes.
Alexei: Molt interessant. Normalment les persones tenen algun tipus de barrera psicològica que els impedeix fer una pregunta al professor. Sobretot si hi ha molta gent a la sala i tothom té por que discutir la teva pregunta estúpida ocupi el temps de tota aquesta gent. Hi ha trucs per fer front a això?
Maurice: Sovint m'aturo i faig les preguntes clàssiques. Qualsevol afirmació serà correcta o com solucionarien el problema que es discuteix? Aquest és un pas clau, sobretot a l'inici d'una sessió, quan a la gent li fa vergonya dir fins i tot el més petit. Feu una pregunta als alumnes i no dieu res més. Hi ha silenci, tothom es tensa una mica, la tensió creix, després, de cop, algú es trenca, es trenca i diu la resposta. Així que desplegueu la situació: es fa més difícil i incòmode callar que respondre! Aquest és un truc pedagògic estàndard. Tots els professors del món haurien de saber com fer-ho.
Alexey: Ara tenim un gran títol per a aquesta entrevista: "és més fàcil respondre que callar".
Vitaly: Deixa'm preguntar-te una cosa més. Esteu treballant en proves topològiques. Com us vau involucrar en això, perquè la computació distribuïda i la topologia són coses completament diferents!
Maurice: Allà hi ha una relació amagada. Quan era estudiant i estudiava matemàtiques, vaig estudiar matemàtiques pures. No vaig tenir cap interès real per la informàtica fins al final dels meus estudis i em vaig trobar amb la urgent necessitat de buscar feina. Com a estudiant, vaig estudiar topologia algebraica. Molts anys després, mentre treballava en un problema anomenat , vaig utilitzar gràfics per modelar el problema i, com semblava aleshores, vaig trobar una solució. Només calia seure i recórrer el gràfic. Intenta trobar una resposta adequada en aquest gràfic. Però el meu algorisme no va funcionar: va resultar que sempre córrer en cercles. Malauradament, res d'això es podria explicar en el llenguatge formal de la teoria de grafs, el llenguatge que tots els informàtics coneixen. I llavors vaig recordar que fa molts anys, fins i tot a les classes de topologia, vam fer servir el concepte , que és una generalització de gràfics a dimensions superiors. Aleshores em vaig preguntar: què passa si reformulam el problema en termes de complexos simplicials? Aquesta es va convertir en la clau. Mitjançant l'ús d'un formalisme més potent, el problema es fa de sobte molt més senzill. La gent va lluitar amb això durant molt de temps, utilitzant gràfics, però no van poder fer res. I fins i tot ara no poden: la resposta correcta no era l'algorisme, sinó la prova de la impossibilitat de resoldre el problema. És a dir, aquest algorisme simplement no existeix. Però es basa en complexos simplicials o en coses que la gent pretén no considerar complexos simplicials. Del fet que vas cridar alguna cosa amb un nom nou, no perd la seva essència.
Vitaliy: Resulta que vas tenir sort?
Maurice: A més de la sort, també ho és preparació. És a dir, no heu d'oblidar les coses "inútils" que heu après abans. Com més coses inútils aprengueu, més coneixements podreu extreure quan us trobeu amb un problema nou. Aquest tipus de concordança de patrons intuïtiva és important perquè... Diguem que és una cadena: al principi, vaig trobar que els gràfics no funcionaven del tot o no funcionaven gens, em recordava alguna cosa de fa vuit anys. i els anys d'estudiant quan vam estudiar tots aquests complexos senzills. Al seu torn, això em va permetre trobar el meu antic llibre de text de topologia i tornar-lo a carregar al meu cap. Però si no fos per aquest vell coneixement, mai no hauria avançat cap a la solució del problema original.
Nova edició de The Art of Multiprocessor Programming
Alexei: Vas dir unes paraules sobre el teu llibre. Probablement no sigui el secret més gran que hagis escrit el llibre més famós del món sobre multithreading, . Ja té uns 11 anys i des de llavors només va sortir . Hi haurà una segona edició?
Maurice: Està bé que ho hagis preguntat! Serà molt aviat, d'aquí a tres mesos aproximadament. Hi ha dos autors més, hem afegit molt més material, hem millorat la secció sobre el paral·lelisme fork / join, hem escrit una secció sobre MapReduce, hem afegit moltes coses noves i hem llençat les innecessàries, cosa que era molt interessant en el moment d'escriure. la primera edició, però ja no és avui. Va resultar ser un llibre revisat molt seriosament.
Alexei: Ja s'ha fet tot, només queda per alliberar?
Maurice: Encara cal treballar un parell de capítols. El nostre editor (crec que ja ens odia) encara intenta transmetre que hem de treballar més ràpid. Estem molt endarrerits. Teòricament, podríem haver fet aquest llibre un parell d'anys abans.
Alexey: Hi ha alguna possibilitat d'aconseguir una nova versió del llibre abans de Nadal?
Maurice: Aquest és el nostre objectiu! Però he pronosticat la victòria tantes vegades que ja ningú em creu. Probablement tampoc hauríeu de confiar massa en mi en aquest tema.
Alexei: En qualsevol cas, aquesta és una notícia fantàstica. M'ha agradat molt la primera edició del llibre. Es podria dir que sóc un fan.
Maurice: Espero que la nova edició sigui digna del vostre fervorós entusiasme, gràcies!
Com es va inventar la memòria transaccional
Vitaly: La següent pregunta és sobre la memòria transaccional. Pel que entenc, ets un pioner en aquest camp, te'l vas inventar en un moment en què ningú pensava en aquestes coses. Per què vas decidir traslladar-te a aquesta zona? Per què eren importants per a vostè les transaccions? Pensaves que algun dia es plasmaran en ferro?
Maurice: Conec les transaccions des dels meus estudis de postgrau.
Vitaliy: Sí, però aquestes són transaccions diferents!
Maurice: Vaig treballar amb Elliott Moss en la recollida d'escombraries sense bloqueig. El nostre problema era que volíem canviar atòmicament unes quantes paraules a la memòria i després els algorismes es tornarien molt simples, i almenys alguns es tornarien més eficients. Utilitzant per proporcionada per l'arquitectura paral·lela, és possible fer alguna cosa, però és molt ineficient i lleig perquè hauríeu de fer front a nivells d'indirecció. Vull canviar les paraules de memòria i he de canviar perquè només puc canviar un punter, de manera que han d'apuntar a algun tipus d'estructura de directori. Hem parlat del gran que seria si poguéssim canviar el maquinari perquè pogués gravar simultàniament. Elliot sembla haver notat això: si observeu els protocols de coherència de la memòria cau, ja proporcionen la major part de la funcionalitat necessària. En una transacció optimista, el protocol de coherència de la memòria cau notarà la presència d'un conflicte de temps i la memòria cau es convertirà en . Què passa si inicieu una transacció de manera especulativa a la vostra memòria cau i utilitzeu els mecanismes del protocol de coherència per detectar conflictes? L'arquitectura de maquinari especulativa era fàcil de dissenyar. Així que ho vam escriure sobre la memòria transaccional. Al mateix temps, l'empresa per a la qual treballava, Digital Equipment Corporation, estava construint un nou processador de 64 bits anomenat Alpha. Així que vaig anar a fer una presentació a l'equip de desenvolupament d'Alpha sobre la nostra meravellosa memòria transaccional, i em van preguntar: quins ingressos addicionals obtindrà la nostra empresa si posem tot això directament al processador? I no tenia absolutament cap resposta a això, perquè sóc tecnòleg, no sóc especialista en màrqueting. Realment no tenia res a dir. No els va impressionar molt que jo no sabia res.
Vitaly: Milers de milions! Només digues "milers de milions"!
Maurice: Sí, això és el que hauria d'haver dit. Ara, a l'era de les startups i tot això, sé com escriure un pla de negoci. Que podeu mentir una mica sobre la mida del benefici potencial. Però en aquells dies semblava ingenu, així que només vaig dir: "No ho sé". Si mireu l'historial de la publicació sobre la memòria transaccional, notareu que després d'un any hi havia diverses referències, i després durant uns deu anys ningú no va citar aquest article. Les cites van aparèixer cap al 2004, quan va néixer el veritable multi-nucli. Quan la gent va descobrir que escriure codi paral·lel podia guanyar diners, van començar noves investigacions. Ravi Rajwar , que d'alguna manera va introduir el corrent principal en el concepte de memòria transaccional. (Nota de l'editor: aquest article té una segona versió publicada el 2010 i està disponible gratuïtament ). De sobte, la gent es va adonar de com es pot utilitzar tot això exactament, de com poden accelerar els algorismes tradicionals amb panys. Un bon exemple d'una cosa que en el passat semblava un problema acadèmic interessant. I sí, si m'haguessis preguntat en aquell moment si pensava que tot això seria important en el futur, hauria dit: és clar, però quan exactament no està clar. Potser d'aquí a 50 anys? A la pràctica, va resultar ser només una dècada. És molt agradable quan fas alguna cosa, i en només deu anys la gent ho nota.
Per què val la pena fer recerca en el camp de la informàtica distribuïda
Vitaly: Si parlem de noves investigacions, què aconsellaríeu als lectors: informàtica distribuïda o multinucli i per què?
Maurice: És fàcil aconseguir un processador multinucli en aquests dies, però és més difícil configurar un veritable sistema distribuït. Vaig començar a treballar-hi perquè volia fer alguna cosa diferent del meu doctorat. Aquest és el consell que sempre dono als principiants: no escriviu una tesi de seguiment, intenteu anar en una nova direcció. A més, el multithreading és fàcil. Puc experimentar amb la meva pròpia forquilla funcionant amb un ordinador portàtil sense aixecar-me del llit. Però si de sobte volgués crear un veritable sistema distribuït, hauria de fer molta feina, atraure estudiants, etc. Sóc una persona mandrosa i preferiria treballar en multi-nucli. Experimentar amb sistemes multinucli també és més fàcil que experimentar amb sistemes distribuïts, perquè fins i tot en un sistema distribuït estúpid hi ha massa factors per controlar.
Vitaliy: Què estàs fent ara, investigant blockchain? A quins articles hauries de prestar atenció primer?
Maurice: Va aparèixer recentment que vaig escriure amb el meu alumne, Vikram Saraf, específicament per al a París fa tres setmanes. Aquest és un article sobre sistemes distribuïts útils en el qual proposem fer Ethereum multifil. Ara els contractes intel·ligents (codi que s'executa a la cadena de blocs) s'executen seqüencialment. Abans vam escriure un article que parlava d'una manera d'utilitzar transaccions especulatives per accelerar el procés. Vam agafar moltes idees de la memòria transaccional del programari i vam dir que si fas que aquestes idees formen part de la màquina virtual Etherium, tot funcionarà més ràpid. Però per a això és necessari que no hi hagi conflictes de dades en els contractes. I llavors vam suposar que a la vida real no hi ha conflictes d'aquest tipus. Però no hem tingut l'oportunitat d'esbrinar-ho. Aleshores se'ns va ocórrer que teníem gairebé deu anys d'història de contracte real a les nostres mans, així que vam descarregar la cadena de blocs d'Etherium i ens vam preguntar: què passaria si aquests registres històrics funcionessin en paral·lel? Hem trobat un augment significatiu de la velocitat. En els primers temps d'Etherium, la velocitat va augmentar molt, però avui tot és una mica més complicat, perquè hi ha menys contractes i la probabilitat de conflictes per dades que requereixen serialització ha augmentat. Però tot això és un treball experimental amb dades històriques reals. El més bo de blockchain és que ho recorda tot per sempre, de manera que podeu tornar enrere en el temps i estudiar què passaria si féssim servir altres algorismes per executar el codi. Com li hauria agradat a la gent del passat la nostra nova idea. És molt més fàcil i més agradable fer aquesta investigació, perquè hi ha una cosa que ho controla tot i ho registra tot. Això ja s'assembla més a la sociologia que al desenvolupament d'algorismes.
S'ha aturat el desenvolupament d'algoritmes i com viure
Vitaly: És hora de l'última pregunta teòrica! Sembla que els avenços en les estructures de dades competitives es redueixen cada any? Creus que hem arribat a un altiplà en la nostra comprensió de les estructures de dades, o hi haurà algunes millores importants? Potser hi ha idees intel·ligents que ho poden canviar completament?
Maurice: Potser hem arribat a un altiplà en estructures de dades per a arquitectures tradicionals. Però les estructures de dades per a noves arquitectures segueixen sent una àrea molt prometedora. Si voleu crear estructures de dades per, per exemple, acceleradors de maquinari, les estructures de dades de la GPU són molt diferents de les estructures de dades de la CPU. Quan dissenyeu estructures de dades per a cadenes de blocs, heu de triturar peces de dades i després posar-les en alguna cosa així , per evitar la falsificació. Darrerament hi ha hagut un augment d'activitat en aquest àmbit, molts estan fent una molt bona feina. Però crec que el que passarà és que noves arquitectures i noves aplicacions donaran lloc a noves estructures de dades. Aplicacions més antigues i arquitectura tradicional: potser ja no hi ha gaire espai per a la recerca. Però si sortiu dels camins trillats i mireu per sobre de la vora, veureu coses boges que el corrent principal no es pren seriosament; aquí és on realment succeeixen totes les coses emocionants.
Vitaly: Per tant, per ser un investigador molt famós, vaig haver d'inventar la meva pròpia arquitectura 🙂
Maurice: Pots "robar" la nova arquitectura d'una altra persona, sembla molt més fàcil!
Treballa a la Universitat de Brown
Vitaliy: Ens podries dir més sobre en què treballes? No se sap gaire d'ell en el context de les tecnologies de la informació. Menys que sobre el MIT, per exemple.
Maurice: Brown University és una de les universitats més antigues dels Estats Units. Crec que només Harvard és una mica més gran. Brown forma part de l'anomenat , que és una col·lecció de vuit universitats més antigues. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Aquesta és una mena d'universitat antiga, petita i una mica aristocràtica. El focus se centra en l'educació en arts liberals. No és tractar de ser com el MIT, el MIT és molt especialitzat i tècnic. Brown és un lloc fantàstic per estudiar literatura russa o grec clàssic i, per descomptat, informàtica. Se centra en l'educació integral. La majoria dels nostres estudiants van a Facebook, Apple, Google, així que crec que els nostres estudiants no tenen cap problema per trobar feina al sector. Vaig anar a treballar a Brown perquè abans treballava a Digital Equipment Corporation a Boston. Va ser una empresa que va inventar moltes coses interessants, però va negar la importància dels ordinadors personals. Una empresa amb un destí difícil, els fundadors de la qual abans van ser joves revolucionaris, no van aprendre res i no van oblidar res, i per tant van passar de revolucionaris a reaccionaris en una dècada aproximadament. Els agradava fer broma que els ordinadors personals pertanyien a un garatge, un garatge abandonat, és clar. És força obvi que van ser destruïts per empreses més flexibles. Quan va quedar clar que l'empresa tenia problemes, vaig trucar al meu amic de Brown, que es troba a una hora de Boston. En aquell moment no volia marxar de Boston, perquè altres universitats no tenien moltes places vacants. Era una època en què no hi havia tantes vacants en l'àmbit de la informàtica com ara. I Brown tenia feina, no em vaig haver de mudar de casa, no vaig haver de traslladar la meva família i m'agrada molt viure a Boston! Així que vaig prendre la decisió d'anar a Brown. M'agrada. Els estudiants són fantàstics, així que ni tan sols vaig intentar anar a un altre lloc. En un any sabàtic, vaig treballar a Microsoft durant un any, vaig anar a Technion a Haifa durant un any i ara estaré a Algorand. Tinc molts companys per tot arreu i per tant la ubicació física de les nostres aules no és tan important. Però el més important són els estudiants, aquí són els millors. Mai he intentat anar a cap altre lloc, perquè aquí sóc molt feliç.
No obstant això, malgrat la fama de Brown als Estats Units, és sorprenentment desconegut a l'estranger. Com podeu veure, ara estic fent tot el possible per corregir aquest estat de coses.
La diferència entre la recerca universitària i corporativa
Vitaliy: D'acord, la següent pregunta és sobre els equips digitals. Vas ser investigador allà. Quina diferència hi ha entre treballar al departament d'R+D d'una gran empresa i treballar a una universitat? Quins són els avantatges i els inconvenients?
Maurice: Fa vint anys que estic a Microsoft, treballant estretament amb gent de Sun Microsystems, Oracle, Facebook i ara Algorand. A partir de tot això, vull dir que és possible fer recerca de primer nivell tant a les empreses com a la universitat. La diferència important és que en una empresa treballes amb els companys. Si de sobte tinc una idea per a un projecte que encara no existeix, he de convèncer els meus companys que aquesta és una bona idea. Si sóc a Brown, puc dir als meus alumnes: treballem l'antigravetat! O aniran a una altra persona o assumiran el projecte. Sí, hauré de trobar finançament, hauré d'escriure una sol·licitud de subvenció, etc. En tot cas, sempre hi haurà molts alumnes, i podreu prendre decisions de manera unilateral. Però a la universitat, probablement no treballaràs amb gent del teu nivell. En el món de la investigació industrial, primer has de convèncer tothom que val la pena assumir el teu projecte. No puc demanar res a ningú. I aquestes dues maneres de treballar són valuoses, perquè si estàs treballant en alguna cosa realment boja i els teus companys són difícils de convèncer, és més fàcil convèncer els estudiants de postgrau, sobretot si els pagues. Si estàs treballant en alguna cosa que requereix molta experiència i coneixements profunds, necessites companys que puguin dir "no, passa que entenc aquesta àrea i la teva idea és dolenta, no en sortirà res". Això és molt útil pel que fa a la pèrdua de temps. I a més, si als laboratoris industrials passes molt de temps escrivint informes, a la universitat dediques aquest temps a buscar diners. Si vull que els estudiants puguin viatjar a algun lloc, he de trobar els diners en un altre lloc. I com més important sigui la teva posició a la universitat, més temps hauràs de dedicar a recollir diners. Per tant, ara ja saps com treballo: un captaire professional! Com un d'aquells monjos que passegen amb un plat de donació. En general, aquestes dues activitats es complementen. Per això intento viure i mantenir-me ferm en tots dos mons.
Vitaliy: Sembla que convèncer una empresa és més difícil que convèncer altres científics.
Maurice: Més difícil, i molt més. A més, en diferents àrees és diferent: algú fa una investigació a gran escala i algú està centrat en el seu tema. Si anés a Microsoft o Facebook i digués, fem antigravetat, difícilment ho agrairien. Però si digués exactament el mateix als meus estudiants de postgrau, molt probablement es posarien a la feina a l'instant, tot i que ara ja tindria problemes, perquè cal trobar diners per a això. Però sempre que vulguis fer alguna cosa d'acord amb els objectius de l'empresa, aquesta empresa pot ser un molt bon lloc per investigar.
Hydra i SPTDC
Vitaliy: Les meves preguntes estan arribant a la seva fi, així que parlem una mica del proper viatge a Rússia.
Maurice: Sí, tinc moltes ganes de tornar a Petersburg.
Alexey: És un gran honor per a mi que estiguis amb nosaltres aquest any. Aquesta és la teva segona vegada a Sant Petersburg, oi?
Maurice: Ja és el tercer!
Alexei: Entenc, però - exactament el segon. L'última vegada que es va trucar a l'escola , ara hem canviat una lletra (C a D, Concurrent a Distribuïda) per destacar que aquest any hi ha més àrees relacionades amb la informàtica distribuïda. Pots dir unes paraules sobre les teves presentacions a l'Escola i ?
Maurice: A l'escola, vull parlar sobre els conceptes bàsics de la cadena de blocs i què pots fer-hi. M'agradaria demostrar que les cadenes de blocs són molt semblants a la programació multifil que coneixem, però amb els seus propis matisos, i és important entendre aquestes diferències. Si cometeu un error en una aplicació web normal, només és molest. Si escriviu un codi defectuós en una aplicació financera, algú us robarà definitivament tots els vostres diners. Aquest és un nivell de responsabilitat i conseqüències completament diferent. Parlaré una mica de prova de treball, contractes intel·ligents, transaccions entre diferents blockchains.
Al meu costat treballaran altres ponents, que també tenen alguna cosa a dir sobre la cadena de blocs, i vam acordar coordinar-nos entre nosaltres perquè les nostres històries encaixin bé. Però per a la xerrada d'enginyeria, vull donar una explicació clara a un públic ampli per què no us heu de creure tot el que escolteu sobre les cadenes de blocs, per què les cadenes de blocs són un gran camp, com encaixa amb altres idees conegudes i per què hauríem de fer-ho. mirar cap al futur amb valentia.
Alexey: A més, vull dir que això no es farà en format de trobada o grup d'usuaris, com va ser fa dos anys. Vam decidir fer una petita conferència prop de l'escola. El motiu és que després de parlar amb Peter Kuznetsov, ens vam adonar que l'escola està limitada a només un centenar, potser 120 persones. Al mateix temps, hi ha molts enginyers que volen parlar amb tu, assistir a informes i, en general, estan interessats en el tema. Per a això hem creat una nova conferència . Per cert, tens idea de per què Hydra?
Maurice: Perquè tindrà set altaveus? I se'ls pot tallar el cap i créixer nous altaveus al seu lloc?
Alexey: Gran idea per fer créixer nous altaveus. Però realment, aquí hi ha una història. Recordeu la llegenda d'Odisseu, on va haver de navegar entre ells ? Hydra és una cosa semblant a Caribdis. La història és que una vegada vaig parlar en una conferència i vaig parlar de multithreading. Només hi havia dues pistes en aquesta conferència. Al principi de l'informe, vaig dir a l'audiència a la sala que ara tenen la possibilitat de triar entre Escil·la i Caribdis. El meu esperit animal és Caribdis, perquè Caribdis té molts caps i el meu tema és multifilar. Així apareixen els noms de les conferències.
En qualsevol cas, ens hem quedat sense preguntes i sense temps. Així que gràcies amics per una gran entrevista i ens veiem a SPTDC i Hydra 2019!
Es podrà continuar la comunicació amb Maurice a la conferència Hydra 2019, que se celebrarà de l'11 al 12 de juliol de 2019 a Sant Petersburg. Vindrà amb un informe . Les entrades es poden comprar .
Font: www.habr.com