- il proprietario di due. Il primo è per lavoro (Brown University) e la seconda, più recente, - (Università Tecnologica della Virginia). Il Premio Dijkstra viene assegnato a opere il cui significato e influenza sono evidenti da almeno dieci anni e, ovviamente, Maurice è uno dei più famosi specialisti del settore. Attualmente è professore presso la Brown University e ha risultati lunghi un paragrafo. Ora è impegnato nella ricerca blockchain nel contesto del calcolo distribuito classico.
In precedenza, Maurice è già venuto in Russia per SPTCC () e ha fatto un eccellente incontro della comunità di sviluppatori JUG.ru Java a San Pietroburgo ().
Questo habrapost è un'ottima intervista con Maurice Herlihy. Tratta i seguenti argomenti:
- Interazione tra il mondo accademico e l'industria;
- Fondazione per la ricerca blockchain;
- Da dove vengono le idee rivoluzionarie? Influenza della popolarità;
- PhD sotto la guida di Barbara Liskov;
- Il mondo sta aspettando il multi-core;
- Nuovo mondo, nuovi problemi. NVM, NUMA e hacking dell'architettura;
- Compilatori vs CPU, RISC vs CISC, memoria condivisa vs scambio di messaggi;
- L'arte di scrivere fragile codice multi-thread;
- Come insegnare agli studenti come scrivere codice multi-thread complesso;
- Nuova edizione del libro "The Art of Multiprocessor Programming";
- Come è stata inventata la memoria transazionale?
- Perché vale la pena fare ricerca nel campo del calcolo distribuito;
- Lo sviluppo di algoritmi si è fermato e come continuare a vivere;
- Lavora alla Brown University;
- La differenza tra ricerca universitaria e aziendale;
- Idra e SPTDC.
Le interviste sono condotte da:
Vitaly Aksenov — attualmente post-dottorato presso IST Austria e dipendente del Dipartimento di tecnologie informatiche presso l'Università ITMO. È impegnato nella ricerca nel campo della teoria e della pratica delle strutture dati competitive. Prima di entrare a far parte dell'IST, ha conseguito il dottorato di ricerca presso l'Università Diderot di Parigi e l'Università ITMO sotto la guida del Prof. Petr Kuznetsov.
Alexey Fedorov è produttore presso JUG Ru Group, una società russa che organizza conferenze per sviluppatori. Alexey ha partecipato alla preparazione di oltre 50 conferenze e il suo curriculum contiene di tutto, dalla posizione di ingegnere di sviluppo presso Oracle (JCK, Java Platform Group) alla posizione di sviluppatore presso Odnoklassniki.
Vladimir Sitnikov è un ingegnere di Netcracker. Da dieci anni si occupa delle performance e della scalabilità di NetCracker OS, software utilizzato dagli operatori di telecomunicazioni per automatizzare i processi di gestione della rete e degli apparati di rete. Interessato ai problemi di prestazioni di Java e Oracle Database. Autore di oltre una dozzina di miglioramenti delle prestazioni nel driver JDBC PostgreSQL ufficiale.
Interazione tra mondo accademico e industria
Alexey: Maurice, lavori nel mondo accademico da molto tempo e la prima domanda riguarda l'interazione tra mondo accademico e industria. Potresti dirci come sono cambiate le interazioni tra loro ultimamente? Cosa era 20-30 anni fa e cosa sta succedendo adesso?
Maurice: Ho sempre cercato di lavorare a stretto contatto con aziende commerciali perché hanno sfide interessanti. Di norma, non sono molto interessati né alla pubblicazione dei loro risultati né a spiegazioni dettagliate dei loro problemi alla comunità mondiale. A loro interessa solo risolvere questi problemi. Ho lavorato per alcune di queste aziende per un po'. Ho trascorso cinque anni lavorando a tempo pieno in un laboratorio di ricerca presso la Digital Equipment Corporation, che era un'importante azienda di computer. Ho lavorato un giorno alla settimana alla Sun, alla Microsoft, alla Oracle, ho lavorato un po' a Facebook. Ora andrò in congedo sabbatico (un professore di un'università americana può prendersi una vacanza del genere per un anno circa una volta ogni sei anni) e lavorerò in , questa è una tale società di criptovaluta a Boston. Lavorare a stretto contatto con le aziende è sempre stato un piacere, perché è così che si imparano cose nuove e interessanti. In genere puoi essere la prima o la seconda persona a pubblicare un articolo su un argomento scelto, invece di migliorare gradualmente le soluzioni ai problemi su cui tutti gli altri stanno già lavorando.
Alexey: Puoi dirci di più su come questo accade?
Maurizio: Certo. Sai, quando ero alla Digital Equipment Corporation, io ed Elliot Moss, abbiamo inventato la memoria transazionale. È stato un periodo molto fruttuoso in cui tutti hanno iniziato a interessarsi alla tecnologia dell'informazione. Concorrenza inclusa, sebbene i sistemi multi-core non esistessero ancora. Ai tempi di Sun e Oracle, ho lavorato molto su strutture di dati parallele. Su Facebook, sono stato coinvolto nel loro progetto blockchain, di cui non posso parlare ma che spero diventi presto pubblico. L'anno prossimo, in Algorand, lavorerò in un gruppo di ricerca che studia i contratti intelligenti.
Alexey: Negli ultimi anni, la blockchain è diventata un argomento molto popolare. Aiuterà la tua ricerca? Forse renderà più facile ottenere sovvenzioni o dare accesso alle risorse delle aziende che operano nel settore?
Maurice: Ho già ricevuto una piccola sovvenzione dalla Ethereum Foundation. La popolarità della blockchain è molto utile per ispirare gli studenti a lavorare in questo campo. Sono molto interessati e felici di essere coinvolti, ma a volte non si rendono conto che la ricerca che sembra allettante all'esterno si rivela un lavoro davvero duro. Tuttavia, sono molto felice di usare tutta questa mistica intorno alla blockchain, aiuta ad attrarre studenti.
Ma non è tutto. Faccio parte del comitato consultivo di diverse startup blockchain. Alcuni di loro possono avere successo, altri no, ma è sempre molto interessante vedere le loro idee, studiarle e consigliare le persone. La cosa più eccitante è quando avverti le persone di non fare qualcosa. Molte cose all'inizio sembrano una buona idea, ma lo sono davvero?
Fondazione per la ricerca blockchain
Vitaly: Alcune persone pensano che la blockchain e i suoi algoritmi siano il futuro. E altre persone dicono che è solo un'altra bolla. Puoi condividere la tua opinione su questo argomento?
Maurice: Molto di ciò che sta accadendo nel mondo blockchain non funziona correttamente, alcuni sono solo truffe, molte cose sono sopravvalutate. Tuttavia, penso che ci sia una solida base scientifica per questi studi. Il fatto che il mondo blockchain sia pieno di divisioni ideologiche mostra il livello di eccitazione e dedizione. D'altra parte, non è particolarmente vantaggioso per la ricerca scientifica. Ora, se pubblichi un articolo che parla delle carenze di un particolare algoritmo, la reazione ricevuta non è sempre del tutto scientifica. Spesso le persone esprimono le loro emozioni. Penso che un tale clamore in quest'area possa sembrare attraente per alcuni, ma alla fine ci sono problemi scientifici e ingegneristici reali che devono ancora essere affrontati. C'è molta informatica qui.
Vitaliy: Quindi stai cercando di gettare le basi per la ricerca blockchain, giusto?
Maurice: Sto cercando di gettare le basi per una disciplina solida, scientificamente e matematicamente valida. E parte del problema è che a volte devi contraddire alcune delle posizioni eccessivamente dure di altre persone, per ignorarle. A volte le persone mi chiedono perché lavoro in un campo che interessa solo ai terroristi e agli spacciatori. Una tale reazione è priva di significato quanto il comportamento dei follower che ripetono ciecamente le tue parole. Penso che la verità stia da qualche parte nel mezzo. Blockchain deve ancora avere un profondo impatto sulla società e sull'economia globale. Ma, probabilmente, questo non accadrà grazie alla tecnologia moderna. Le moderne tecnologie si svilupperanno e quella che in futuro si chiamerà blockchain diventerà molto importante. Forse non assomiglierà nemmeno alle moderne blockchain, questa è una domanda aperta.
Se le persone inventeranno nuove tecnologie, continueranno a chiamarle blockchain. Voglio dire, proprio come il Fortran di oggi non ha niente a che fare con il linguaggio Fortran degli anni '1960, ma tutti continuano a chiamarlo Fortran. Lo stesso per UNIX. Quella che viene chiamata “blockchain” deve ancora fare la sua rivoluzione. Ma dubito che questa nuova blockchain sarà come quella che tutti amano usare oggi.
Da dove vengono le idee rivoluzionarie? Influenza della popolarità
Alexey: La popolarità della blockchain ha portato a nuovi risultati dal punto di vista scientifico? Più interazione, più studenti, più aziende sul territorio. Ci sono già risultati di questa crescita di popolarità?
Maurice: Mi sono interessato a questo quando qualcuno mi ha consegnato un volantino ufficiale per un'azienda che aveva appena raccolto un bel po' di soldi. Ha scritto di che conosco più che bene. Scritto nel volantino era chiaramente tecnicamente errato. Le persone che hanno scritto questo non capivano davvero il modello alla base del problema... eppure questa azienda ha raccolto molti soldi. Successivamente, l'azienda ha tranquillamente sostituito questo volantino con una versione molto più corretta - e non dirò quale fosse il nome di questa azienda. Esistono ancora e stanno andando molto bene. Questo caso mi ha convinto che, in primo luogo, la blockchain è solo una forma di calcolo distribuito. In secondo luogo, la soglia di ingresso (all'epoca, quattro anni fa) era piuttosto bassa. Le persone che lavoravano in quest'area erano molto energiche e intelligenti, ma non leggevano articoli scientifici. Hanno provato a reinventare cose conosciute e lo hanno fatto male. Oggi il dramma è stato ridotto.
Alexey: È molto interessante, perché alcuni anni fa abbiamo avuto una tendenza diversa. È un po' come lo sviluppo front-end, in cui gli sviluppatori dell'interfaccia del browser hanno reinventato intere tecnologie che erano già popolari nel back-end a quel tempo: costruire sistemi, integrazione continua e cose del genere.
Maurizio: sono d'accordo. Ma questo non è sorprendente, perché le idee veramente rivoluzionarie provengono sempre dall'esterno della comunità consolidata. È improbabile che i ricercatori affermati, in particolare le autorità nel mondo accademico, facciano qualcosa di veramente rivoluzionario. È facile scrivere un rapporto per la prossima conferenza su come hai leggermente migliorato i risultati del tuo lavoro passato. Vai a una conferenza, incontra gli amici, parla delle stesse cose. E le persone che irrompono con idee rivoluzionarie vengono quasi sempre dall'esterno. Non conoscono le regole, non conoscono la lingua, ma comunque... Se sei all'interno di una comunità consolidata, ti consiglio di prestare attenzione alle novità, a qualcosa che non rientra nel grande immagine. In un certo senso, si può tentare di combinare sviluppi esterni, più fluidi, con tecniche che già comprendiamo. Come primo passo, prova a creare una base scientifica, quindi modificala in modo che possa essere applicata a nuove idee rivoluzionarie. Penso che la blockchain sia ottima per il ruolo di una nuova idea rivoluzionaria.
Alexei: Perché pensi che stia accadendo? Perché le persone "fuori" non hanno barriere specifiche insite nella comunità?
Maurice: C'è uno schema qui. Se leggi la storia degli impressionisti nella pittura e nell'arte in generale, un tempo artisti famosi rifiutarono l'impressionismo. Dissero che era una specie di puerilità. Una generazione dopo, questa forma d'arte precedentemente rifiutata divenne lo standard. Quello che vedo nel mio campo: gli inventori della blockchain non erano interessati al potere, alla liquidazione delle pubblicazioni e all'indice delle citazioni, volevano solo fare qualcosa di buono. E così si sono seduti e hanno iniziato a farlo. Mancava una certa quantità di profondità tecnica, ma è risolvibile. È molto più difficile trovare nuove idee creative piuttosto che correggere e amplificare quelle non sufficientemente mature. Grazie a questi inventori, ora ho qualcosa da fare!
Alexey: Questo è simile alla differenza tra startup e progetti legacy. Ereditiamo molte limitazioni di pensiero, barriere, requisiti speciali e così via.
Maurice: Una buona analogia è il calcolo distribuito. Pensa alla blockchain come se fosse una startup e al calcolo distribuito come a una grande azienda consolidata. Il calcolo distribuito è in procinto di essere acquistato e unito alla blockchain.
Dottorato di ricerca con Barbara Liskov
Vitaliy: Abbiamo ancora molte domande! Abbiamo fatto ricerche sulla tua biografia e ci siamo imbattuti in un fatto interessante sul tuo dottorato di ricerca. Sì, è stato tanto tempo fa, ma l'argomento sembra essere importante. Hai conseguito il dottorato di ricerca sotto la supervisione di ! Barbara è molto conosciuta nella comunità di sviluppo del linguaggio di programmazione e una persona molto famosa in generale. È logico che la tua ricerca fosse nel campo dei linguaggi di programmazione. Come sei passato al calcolo parallelo? Perché hai deciso di cambiare argomento?
Maurice: A quel tempo, Barbara e il suo gruppo stavano solo guardando al calcolo distribuito, che era un'idea molto nuova. C'era anche chi diceva che il calcolo distribuito non ha senso, la comunicazione tra computer non ha senso. Uno dei problemi considerati nel calcolo distribuito, che li distingue dal calcolo centralizzato, è la tolleranza ai guasti. Dopo molte ricerche, abbiamo deciso che in un linguaggio di programmazione per il calcolo distribuito è necessario disporre di qualcosa come le transazioni atomiche, perché non si può mai essere sicuri che una chiamata remota avrà successo. Una volta che hai le transazioni, c'è un problema di controllo della concorrenza. Poi c'è stato molto lavoro per ottenere strutture di dati transazionali altamente parallele. Poi quando mi sono laureato sono andato a e iniziò a cercare un argomento per il lavoro. Mi è venuto in mente che l'informatica si era spostata dai singoli computer alle reti di computer. Una naturale continuazione del progresso sarebbero i multiprocessori: allora la parola "multi-core" non esisteva. Ho pensato: qual è l'equivalente delle transazioni atomiche per un sistema multi-core? Operazioni decisamente non ordinarie, perché troppo grandi e pesanti. Ed è così che mi è venuta l'idea ed è così che mi è venuta in mente l'intera sincronizzazione senza attesa. È stato un tentativo di rispondere alla domanda su quale sia l'analogo delle transazioni atomiche per un sistema multiprocessore con memoria condivisa. A prima vista, questo lavoro può sembrare molto diverso, ma in realtà è una continuazione dello stesso tema.
Il mondo in attesa di multi-core
Vitaly: Hai detto che all'epoca c'erano pochissimi computer multi-core, giusto?
Maurice: Semplicemente non esistevano. C'erano diversi cosiddetti multiprocessori simmetrici, che erano sostanzialmente collegati allo stesso bus. Non ha funzionato molto bene, perché ogni volta che una nuova azienda ha creato qualcosa di simile, Intel ha rilasciato un singolo processore che ha superato il multiprocessore.
Alexei: Questo non significa che in quei tempi antichi si trattava più di uno studio teorico?
Maurice: Non è stato uno studio teorico, ma piuttosto speculativo. Tutto questo non riguardava lavorare con molti teoremi, piuttosto, abbiamo avanzato ipotesi sull'architettura che a quel tempo non esisteva. Ecco a cosa serve la ricerca! Nessuna azienda l'avrebbe fatto, era tutto qualcosa che veniva da un lontano futuro. In effetti, questo è stato fino al 2004, quando sono comparsi veri e propri processori multi-core. A causa del surriscaldamento dei processori, puoi rendere il processore ancora più piccolo, ma non puoi renderlo più veloce. Per questo motivo, c'è stata una transizione verso architetture multi-core. E poi significava che all'improvviso c'era un uso per tutti i concetti che avevamo sviluppato in passato.
Alexey: Perché pensi che i processori multi-core siano apparsi solo negli anni XNUMX? Allora perché così tardi?
Maurice: È dovuto a limitazioni hardware. Intel, AMD e altre società sono molto brave nell'aumentare la velocità del processore. Quando a un certo punto i processori sono diventati abbastanza piccoli da non poter più aumentare la velocità di clock perché i processori inizierebbero a esaurirsi. Puoi renderli più piccoli, ma non più veloci. Cosa è in loro potere: invece di un processore molto piccolo, inserire otto, sedici o trentadue processori nello stesso volume del case, dove solo uno si adattava. Ora hai il multithreading e la comunicazione veloce tra di loro perché condividono le cache. Ma non puoi farli correre più veloci: c'è un limite di velocità molto specifico. Continuano a migliorare a poco a poco, ma non così tanto. Le leggi della fisica si sono messe in mezzo.
Nuovo mondo, nuovi problemi. NUMA, NVM e hacking dell'architettura
Alexei: Sembra molto ragionevole. Con i nuovi processori multi-core sono arrivati nuovi problemi. Tu e i tuoi colleghi vi aspettavate questi problemi? Forse li hai studiati in anticipo? Negli studi teorici spesso non è molto facile prevedere queste cose. Quando si sono verificati problemi, in che misura hanno soddisfatto le aspettative tue e dei tuoi colleghi? O erano nuovi di zecca e tu e i tuoi colleghi avete dovuto dedicare molto tempo a risolvere i problemi man mano che si presentavano?
Vitaliy: Aggiungo alla domanda di Alexey: hai previsto correttamente l'architettura dei processori mentre studiavi teoria?
Maurice: Non tutto al 100%. Ma penso che io e i miei colleghi abbiamo fatto un buon lavoro nel prevedere il multi-core a memoria condivisa. Penso che abbiamo previsto correttamente le difficoltà nella progettazione di strutture di dati parallele che funzionano senza blocchi. Tali strutture dati sono state importanti per molte applicazioni, anche se non per tutte, ma spesso è davvero necessaria una struttura dati priva di blocchi. Quando li abbiamo inventati, molti hanno sostenuto che questa non ha senso, che tutto funziona bene con le serrature. Avevamo previsto abbastanza bene che ci sarebbero state soluzioni già pronte a molti problemi di programmazione e problemi di struttura dei dati. C'erano anche problemi più complessi, come – Accesso irregolare alla memoria. In effetti, non sono stati nemmeno presi in considerazione fino all'invenzione dei processori multi-core perché erano troppo specifici. La comunità di ricerca ha lavorato su domande generalmente prevedibili. Alcuni problemi hardware associati ad architetture specifiche hanno dovuto attendere dietro le quinte, infatti, l'aspetto di queste architetture. Ad esempio, nessuno ha davvero lavorato su strutture dati specifiche della GPU perché allora la GPU non esisteva. Sebbene sia stato fatto molto lavoro , questi algoritmi erano pronti per l'uso non appena è apparso l'hardware giusto. Tuttavia, è impossibile prevedere tutto.
Alexey: Se ho capito bene, NUMA è una sorta di compromesso tra costo, prestazioni e altre cose. Hai idea del perché la NUMA sia arrivata così tardi?
Maurice: Penso che NUMA esista a causa di un problema con l'hardware utilizzato per creare la memoria: più i componenti sono lontani, più lentamente vi si accede. D'altra parte, il secondo valore di questa astrazione è l'uniformità della memoria. Pertanto, una delle caratteristiche del calcolo parallelo è che tutte le astrazioni sono leggermente interrotte. Se l'accesso fosse perfettamente uniforme, tutta la memoria sarebbe equidistante, ma questo è economicamente, e forse anche fisicamente impossibile. Quindi sorge questo conflitto. Se scrivi il tuo programma come se la memoria fosse uniforme, molto probabilmente sarà corretto. Nel senso che non darà risposte sbagliate. Ma la performance delle sue stelle dal cielo non afferrerà. Allo stesso modo, se scrivi senza comprendere la gerarchia delle cache, il blocco stesso sarà corretto, ma puoi dimenticare le prestazioni. In un certo senso, devi scrivere programmi che vivono sopra un'astrazione molto semplice, ma devi superare in astuzia le persone che ti hanno dato quell'astrazione: devi sapere che sotto l'astrazione c'è una qualche gerarchia di memoria, che c'è un autobus tra te e questo ricordo, e così via. Quindi, c'è qualche conflitto tra astrazioni che sono utili di per sé, il che ci porta a problemi molto specifici e pragmatici.
Vitaliy: E il futuro? Puoi prevedere come si svilupperanno ulteriormente i processori? C'è l'idea che una delle risposte sia la memoria transazionale. Probabilmente hai qualcos'altro in magazzino.
Maurice: Ci sono un paio di grandi sfide da affrontare. Uno è che la memoria coerente è un'astrazione meravigliosa, ma inizia a rompersi in casi speciali. Quindi, per esempio, NUMA è un esempio vivente di qualcosa in cui puoi continuare a fingere che esista una memoria uniforme. In realtà - no, la performance ti farà piangere. Ad un certo punto, gli architetti dovranno abbandonare l'idea di un'architettura di memoria unificata, non puoi fingere per sempre. Saranno necessari nuovi modelli di programmazione che siano abbastanza facili da usare e abbastanza potenti da rendere efficiente l'hardware sottostante. Questo è un compromesso molto difficile, perché se mostri ai programmatori l'architettura effettivamente utilizzata nell'hardware, impazziranno. È troppo complicato e non portatile. Se presenti un'interfaccia troppo semplice, le prestazioni saranno scarse. Pertanto, dovranno essere fatti molti compromessi molto difficili per fornire utili modelli di programmazione applicabili a processori multi-core veramente grandi. Non sono sicuro che chiunque non sia uno specialista ristretto sia in grado di programmare su un computer da 2000 core. E a meno che tu non stia facendo calcoli, crittografia o altro molto specializzati o scientifici, non è ancora del tutto chiaro come farlo nel modo giusto.
Un'altra direzione simile sono le architetture specializzate. Gli acceleratori grafici esistono da molto tempo, ma sono già diventati una specie di classico esempio di come si può prendere un tipo di calcolo specializzato ed eseguirlo su un chip dedicato. Ciò aggiunge le sue sfide: come si comunica con un dispositivo del genere, come lo si programma. Recentemente ho lavorato su compiti nella zona . Prendi un piccolo processore e lo incolli a un'enorme porzione di memoria in modo che la memoria funzioni alla velocità della cache L1, quindi comunichi con un dispositivo come - il processore è impegnato a caricare nuove attività nel core della memoria. Lo sviluppo di strutture dati e protocolli di comunicazione per questo genere di cose è un altro esempio interessante. Pertanto, processori e hardware specializzati saranno soggetti a miglioramenti per un bel po' di tempo.
Alexey: E la memoria non volatile ()?
Maurice: Oh, questo è un altro grande esempio! NVM cambierà notevolmente il modo in cui guardiamo cose come le strutture dati. La memoria non volatile, in un certo senso, promette di accelerare davvero le cose. Ma non semplificherà la vita, perché la maggior parte dei processori, delle cache e dei registri sono ancora volatili. Quando ti avvii dopo un crash, il tuo stato e lo stato della tua memoria non saranno esattamente gli stessi di prima del crash. Sono molto grato alle persone coinvolte in NVM: per molto tempo i ricercatori avranno qualcosa da fare, cercando di capire le condizioni di correttezza. I calcoli sono corretti se possono sopravvivere a un arresto anomalo in cui i contenuti delle cache e dei registri vengono persi, ma la memoria principale rimane intatta.
Compilatori vs CPU, RISC vs CISC, memoria condivisa vs scambio di messaggi
Vladimir: Cosa ne pensi del dilemma tra compilatori e processori in termini di set di istruzioni? Per spiegare per coloro che non sono in materia: se andiamo a memoria irregolare o qualcosa del genere, potremmo applicare un set di istruzioni molto semplice e chiedere al compilatore di generare codice complesso che può sfruttare i vantaggi scoperti. Oppure possiamo andare dall'altra parte: implementare istruzioni complesse e chiedere al processore di riordinare le istruzioni e fare altre manipolazioni con esse. Cosa ne pensi?
Maurice: Non ho davvero una risposta a questa domanda. Questo dibattito va avanti da quattro decenni. C'è stato un tempo in mezzo set di comandi e le guerre civili sono state condotte da una serie di squadre. Per un po ', le persone RISC hanno vinto, ma poi Intel ha ricostruito i loro motori in modo da utilizzare un set di istruzioni ridotto all'interno e quello completo è stato esportato all'esterno. Forse questo è un argomento in cui ogni nuova generazione deve trovare i propri compromessi e prendere le proprie decisioni. È molto difficile prevedere quale di queste cose andrà meglio. Quindi qualsiasi previsione che faccio sarà vera per un certo periodo di tempo, e poi diventerà di nuovo falsa per un po', e poi sarà di nuovo vera.
Alexey: Quanto è comune per l'industria in generale che alcune idee vincano per diversi decenni e perdano nel prossimo? Ci sono altri esempi di tali cambiamenti periodici?
Maurice: Nel campo del calcolo distribuito, ci sono persone che ci credono e persone che ci credono . Originariamente nel calcolo distribuito, il calcolo parallelo significa passaggio di messaggi. Poi qualcuno ha scoperto che la memoria condivisa rendeva la programmazione molto più semplice. L'altra parte ha affermato che la memoria condivisa è troppo complicata, perché hanno bisogno di blocchi e simili, quindi vale la pena passare a lingue in cui esiste solo il passaggio di messaggi. Qualcuno ha guardato cosa ne è venuto fuori e ha detto: "wow, questa implementazione di messaggistica sembra molto simile alla memoria condivisa, perché crei molti, molti di questi piccoli moduli, si scambiano messaggi e tutti , - rendiamo migliore un database di memoria condivisa!". Tutto questo si ripete più e più volte ed è impossibile affermare che una delle parti abbia ragione inequivocabilmente. Una parte dominerà sempre, perché non appena una di loro quasi vince, le persone ancora e ancora inventano modi per migliorare l'altra.
L'arte di scrivere codice multi-thread fragile
Alexei: Questo è molto interessante. Ad esempio, quando scriviamo codice, indipendentemente dal linguaggio di programmazione, di solito dobbiamo creare astrazioni come celle che possono essere lette e scritte. Ma in realtà, a un certo livello fisico, potrebbe sembrare come inviare un messaggio su un bus hardware tra diversi computer e altri dispositivi. Si scopre che c'è lavoro su entrambi i livelli di astrazione contemporaneamente.
Maurice: È assolutamente vero che la memoria condivisa è costruita sullo scambio di messaggi: bus, cache e così via. Ma è difficile scrivere programmi usando il passaggio di messaggi, quindi l'hardware mente deliberatamente, fingendo di avere una sorta di memoria uniforme. Questo ti renderà più facile scrivere programmi semplici e corretti prima che le prestazioni inizino a calare. Poi dici: sembra che sia ora di fare amicizia con la cache. Ed è allora che inizi a preoccuparti della posizione della cache, e poi si parte. In un certo senso, stai rompendo l'astrazione: sai che non è solo una memoria piatta e uniforme, e userai quella conoscenza per scrivere programmi compatibili con la cache. Questo è ciò che devi fare nei compiti reali. Questo conflitto tra la bella semplice bella astrazione che ti è stata data e l'implementazione terribilmente complessa dell'hardware sottostante è dove ognuno fa il proprio compromesso. Ho un libro sui multiprocessori e la sincronizzazione, e un giorno avrei scritto un capitolo sulle strutture dati java.util.concurrent. Se li guardi, cose come Queste sono incredibili opere d'arte. (Nota del redattore: coloro che hanno familiarità con il linguaggio Java dovrebbero almeno dare un'occhiata all'implementazione Mappa SkipList simultanea, Puoi guardare i link per и ). Ma dal mio punto di vista, sarebbe irresponsabile mostrarli agli studenti, perché una tale struttura di dati è una specie di ragazzo in un circo, che corre su una fune sopra una fossa di orsi. Se cambi anche un piccolo dettaglio, l'intera struttura crollerà. Questo codice è molto veloce ed elegante proprio perché è scritto perfettamente, ma il minimo cambiamento porterà al completo fallimento. Se do questo codice come esempio agli studenti, diranno subito: posso farlo anche io! E poi un aereo si schianterà o un reattore nucleare esploderà, e sarà colpa mia se non ho dato loro troppe informazioni al momento giusto.
Alexey: Quando ero un po' più giovane, molte volte ho provato a studiare il codice sorgente di Doug Lee, per esempio, java.util.concurrent, poiché è open source, è molto facile trovarlo e cercare di capire cosa sta succedendo lì. Non è andata molto bene: spesso non è del tutto chiaro perché Doug abbia deciso di fare qualcosa in questo modo, quando tutti gli altri lo fanno in modo diverso. Come spieghi queste cose ai tuoi studenti? Esiste un modo particolare e corretto per descrivere i dettagli specifici di un algoritmo hardcore, ad esempio? Come si fa?
Maurice: Gli insegnanti di disegno hanno un cliché che ricordano per primi: se vuoi disegnare come Picasso, devi prima imparare a disegnare immagini semplici e realistiche, e solo quando conosci le regole puoi iniziare a infrangerle. Se cominci subito infrangendo le regole, fai un pasticcio. Innanzitutto, insegno agli studenti come scrivere codice semplice e corretto senza preoccuparsi delle prestazioni. Sto dicendo che ci sono complessi problemi di temporizzazione in agguato qui, quindi non preoccuparti delle cache, non preoccuparti dei modelli di memoria, assicurati solo che tutto funzioni correttamente. È già abbastanza difficile: la programmazione moderna non è facile da sola, soprattutto per i nuovi studenti. E quando hanno un'intuizione su come scrivere programmi corretti, dico: guarda queste due implementazioni di spinlock: una è molto lenta, e anche la seconda non è molto buona, ma già migliore. Tuttavia, matematicamente questi due algoritmi sono gli stessi. In effetti, uno di loro utilizza la località della cache. Uno di loro gira su dati memorizzati nella cache locale e l'altro esegue ripetutamente operazioni che passano attraverso il bus. Non puoi scrivere codice efficiente se non lo capisci, se non sai come rompere l'astrazione e guardare la struttura sottostante. Ma non sarai in grado di iniziare a farlo subito. Ci sono persone che iniziano a farlo subito e credono nel proprio genio, di solito finisce male perché non ne capiscono i principi. Nessuno disegna come Picasso o scrive programmi come Doug Lee, appena uscito dall'università, nella sua prima settimana. Ci vogliono anni per raggiungere questo livello di conoscenza.
Alexey: Si scopre che dividi il problema in due parti: la prima è la correttezza, la seconda è la performance?
Maurizio: Esattamente. E, in quest'ordine. Parte del problema è che i nuovi studenti non si rendono conto che la correttezza è difficile da raggiungere. Dicono a prima vista: questo è ovviamente corretto, resta solo da accelerare. Quindi a volte parlo loro di un algoritmo intrinsecamente errato come se fosse corretto.
Come insegnare agli studenti come scrivere codice multi-thread complesso
Alexei: Solo per vedere se riescono a percepire il trucco?
Maurice: Ti avverto sempre in anticipo che a volte inventerò gli algoritmi sbagliati. Non dovresti ingannare le persone. Suggerisco loro di essere scettici riguardo alle informazioni. Se dico qualcosa e dico: "guarda, questo è ovviamente corretto", questo è un segnale che da qualche parte stanno cercando di ingannarti e dovresti iniziare a fare domande. Successivamente, cerco di incoraggiare gli studenti a continuare a fare domande, e poi chiedo: "cosa succede se lasciamo tutto così com'è?". E vedono immediatamente l'errore. Ma convincere gli studenti che devono preoccuparsi della correttezza è più difficile di quanto sembri a prima vista. Molti di questi studenti arrivano con esperienza di programmazione al liceo, alcuni hanno già ottenuto un lavoro e programmato lì, e sono tutti pieni di fiducia in se stessi. Questo è qualcosa di militare: devi prima cambiare la loro mentalità per convincerli ad avvicinarsi pazientemente alla soluzione dei problemi emergenti. O forse è come i monaci buddisti: prima imparano a ragionare sulla correttezza, e una volta compresi i modi di ragionare sulla correttezza, possono passare al livello successivo e iniziare a preoccuparsi delle prestazioni.
Alexey: Cioè, a volte mostri agli studenti esempi non funzionanti, grazie ai quali ricevi feedback che mostrano se comprendono l'essenza del problema, se riescono a trovare il codice sbagliato e il risultato sbagliato. Ebbene, in che modo gli studenti di solito si accontentano o si arrabbiano?
Maurice: Quasi sempre gli studenti alla fine scoprono l'errore. Se cercano troppo lentamente, pongo domande importanti, e qui è importante capire che se non vengono mai ingannati, inizieranno a percepire sconsideratamente le tue parole come la verità ultima. Poi si annoiano e si addormentano leggendo Facebook sul loro laptop durante le lezioni. Ma quando gli fai sapere in anticipo che saranno truffati e sembreranno stupidi se non percepiscono un trucco, diventano molto più vigili. Questo è buono in molti modi. Vorrei che gli studenti non solo mettessero in dubbio la loro comprensione del problema, ma mettessero anche in discussione l'autorità dell'insegnante. L'idea è che lo studente possa alzare la mano in qualsiasi momento e dire: Penso che quello che hai appena detto sia sbagliato. È un importante strumento di apprendimento. Non voglio che nessuno degli studenti si sieda e pensi in silenzio a se stesso: tutto questo sembra una totale assurdità, ma è troppo spaventoso per alzare la mano, e in effetti è un professore, quindi tutto ciò che dice è vero. Pertanto, se vengono avvertiti in anticipo che non tutto ciò che viene detto è necessariamente vero, hanno un incentivo a prestare maggiore attenzione al materiale. Dichiaro esplicitamente che alzare la mano e fare domande va bene. La tua domanda può sembrare sciocca o ingenua, ma spesso è così che nascono le domande migliori.
Alessio: Molto interessante. Di solito le persone hanno una sorta di barriera psicologica che impedisce loro di fare una domanda al professore. Soprattutto se ci sono molte persone nella stanza e tutti temono che discutere la tua stupida domanda richieda il tempo di tutte queste persone. Ci sono dei trucchi per affrontare questo?
Maurice: Spesso mi fermo e faccio le classiche domande. Qualsiasi affermazione sarà corretta o come risolverebbe il problema in discussione. Questo è un passaggio fondamentale, soprattutto all'inizio di una sessione, quando le persone sono imbarazzate a dire anche la più piccola cosa. Fai una domanda agli studenti e non dici altro. C'è silenzio, tutti si irrigidiscono un po', la tensione cresce, poi all'improvviso qualcuno crolla, crolla e dice la risposta. Quindi spieghi la situazione: diventa più difficile e scomodo tacere che rispondere! Questo è un trucco pedagogico standard. Ogni insegnante nel mondo dovrebbe sapere come farlo.
Alexey: Ora abbiamo un bel titolo per questa intervista: "è più facile rispondere che tacere".
Vitaly: Lascia che ti chieda un'altra cosa. Stai lavorando su dimostrazioni topologiche. Come sei stato coinvolto in questo, perché il calcolo distribuito e la topologia sono cose completamente diverse!
Maurice: C'è una relazione nascosta lì. Quando ero studente e studiavo matematica, studiavo matematica pura. Non ho avuto un vero interesse per i computer fino alla fine dei miei studi e mi sono trovato nell'urgente necessità di cercare un lavoro. Da studente, ho studiato topologia algebrica. Molti anni dopo, mentre lavoravo su un problema chiamato , ho usato i grafici per modellare il problema e, come sembrava allora, ho trovato una soluzione. Dovevi solo sederti e fare il giro del grafico. Prova a trovare una risposta adatta su questo grafico. Ma il mio algoritmo non ha funzionato: si è scoperto che correva sempre in tondo. Sfortunatamente, niente di tutto ciò potrebbe essere spiegato nel linguaggio formale della teoria dei grafi, il linguaggio che tutti gli informatici conoscono. E poi mi sono ricordato che molti anni fa, anche nelle lezioni di topologia, usavamo il concetto , che è una generalizzazione dei grafici a dimensioni superiori. Allora mi sono chiesto: cosa succede se riformuliamo il problema in termini di complessi simpliciali? Questa è diventata la chiave. Usando un formalismo più potente, il problema diventa improvvisamente molto più semplice. Le persone hanno lottato con esso per molto tempo, usando i grafici, ma non potevano fare nulla. E anche adesso non possono: la risposta corretta non era l'algoritmo, ma la prova dell'impossibilità di risolvere il problema. Cioè, un tale algoritmo semplicemente non esiste. Ma si basa o su complessi simpliciali o su cose che le persone fingono di non considerare complessi simpliciali. Dal fatto che hai chiamato qualcosa con un nuovo nome, non perde la sua essenza.
Vitaliy: Si scopre che sei stato solo fortunato?
Maurice: Oltre alla fortuna, lo è anche готовность. Significa che non dovresti dimenticare le cose "inutili" che hai imparato prima. Più cose inutili impari, più intuizioni sarai in grado di estrarre di fronte a un nuovo problema. Questo tipo di pattern matching intuitivo è importante perché... Diciamo solo che è una catena: all'inizio ho scoperto che i grafici non funzionavano del tutto o non funzionavano affatto, mi ha ricordato qualcosa di otto anni fa e anni da studente quando abbiamo studiato tutti questi complessi simpliciali. A sua volta, questo mi ha permesso di ritrovare il mio vecchio libro di testo di topologia e di ricaricarmelo in testa. Ma se non fosse stato per quella vecchia conoscenza, non avrei mai fatto progressi nella risoluzione del problema originale.
Nuova edizione di The Art of Multiprocessor Programming
Alexei: Hai detto alcune parole sul tuo libro. Probabilmente non è il più grande segreto che tu abbia scritto il libro più famoso al mondo sul multithreading, . Ha già circa 11 anni e da allora è uscita solo . Ci sarà una seconda edizione?
Maurice: È un bene che tu l'abbia chiesto! Sarà molto presto, tra tre mesi circa. Ci sono altri due autori, abbiamo aggiunto molto più materiale, migliorato la sezione sul parallelismo fork/join, scritto una sezione su MapReduce, aggiunto molte cose nuove e eliminato quelle non necessarie - qualcosa che era molto interessante al momento della scrittura la prima edizione, ma non è più oggi. Si è rivelato essere un libro molto seriamente rivisto.
Alexei: Tutto è già stato fatto, resta solo da rilasciare?
Maurice: Devono ancora lavorare su un paio di capitoli. Il nostro editore (penso che ci odi già) sta ancora cercando di comunicare che dovremmo lavorare più velocemente. Siamo molto in ritardo sul programma. Teoricamente, avremmo potuto fare questo libro un paio di anni prima.
Alexey: C'è qualche possibilità di ottenere una nuova versione del libro prima di Natale?
Maurice: Questo è il nostro obiettivo! Ma ho predetto la vittoria così tante volte che nessuno mi crede più. Probabilmente non dovresti fidarti troppo di me nemmeno in questa faccenda.
Alexei: In ogni caso, questa è una notizia fantastica. Mi è piaciuta molto la prima edizione del libro. Si potrebbe dire che sono un fan.
Maurice: Spero che la nuova edizione sia degna del vostro fervente entusiasmo, grazie!
Come è stata inventata la memoria transazionale
Vitaly: La prossima domanda riguarda la memoria transazionale. A quanto ho capito, sei un pioniere in questo campo, l'hai inventato in un momento in cui nessuno pensava a queste cose. Perché hai deciso di trasferirti in quest'area? Perché le transazioni erano importanti per te? Pensavi che un giorno sarebbero stati incarnati nel ferro?
Maurice: Conosco le transazioni dai tempi dei miei studi universitari.
Vitaliy: Sì, ma queste sono transazioni diverse!
Maurice: Ho lavorato con Elliott Moss sulla raccolta dei rifiuti non bloccanti. Il nostro problema era che volevamo modificare atomicamente alcune parole in memoria e quindi gli algoritmi sarebbero diventati molto semplici e almeno alcuni di essi sarebbero diventati più efficienti. Usando per fornito dall'architettura parallela, è possibile fare qualcosa, ma è molto inefficiente e brutto perché dovresti affrontare livelli di indiretto. Voglio cambiare le parole di memoria e devo cambiare perché posso cambiare solo un puntatore, quindi devono puntare a una sorta di struttura simile a una directory. Abbiamo parlato di quanto sarebbe fantastico se potessimo cambiare l'hardware in modo che possa registrare simultaneamente. Elliot sembra averlo notato: se guardi ai protocolli di coerenza della cache, forniscono già la maggior parte delle funzionalità richieste. In una transazione ottimistica, il protocollo di coerenza della cache noterà la presenza di un conflitto temporale e la cache diventerà . Cosa succede se avvii speculativamente una transazione sulla tua cache e utilizzi i meccanismi del protocollo di coerenza per rilevare i conflitti? L'architettura hardware speculativa era facile da progettare. Quindi l'abbiamo scritto sulla memoria transazionale. Allo stesso tempo, la società per cui lavoravo, la Digital Equipment Corporation, stava costruendo un nuovo processore a 64 bit chiamato Alpha. E così sono andato a fare una presentazione al team di sviluppo Alpha sulla nostra meravigliosa memoria transazionale, e loro hanno chiesto: quale reddito aggiuntivo otterrà la nostra azienda se mettiamo tutto questo direttamente nel processore? E non avevo assolutamente una risposta a questo, perché sono un tecnologo, non sono uno specialista di marketing. Non avevo davvero niente da dire. Non erano molto colpiti dal fatto che non sapessi nulla.
Vitaly: Miliardi! Basta dire "miliardi"!
Maurice: Sì, è quello che avrei dovuto dire. Ora, nell'era delle startup e tutto il resto, so come scrivere un business plan. Che puoi mentire un po 'sulla dimensione del potenziale profitto. Ma a quei tempi sembrava ingenuo, quindi ho detto solo: "Non lo so". Se guardi la storia della pubblicazione sulla memoria transazionale, noterai che dopo un anno c'erano diversi riferimenti ad essa, e poi per circa dieci anni nessuno ha citato questo articolo. Le citazioni sono apparse intorno al 2004, quando è nato il vero multi-core. Quando le persone hanno scoperto che scrivere codice parallelo poteva fare soldi, sono iniziate nuove ricerche. Ravi Rajwar , che in qualche modo ha introdotto il mainstream al concetto di memoria transazionale. (Nota del redattore: questo articolo ha una seconda versione rilasciata nel 2010 ed è disponibile gratuitamente ). All'improvviso, le persone hanno capito come utilizzare esattamente tutto questo, come possono velocizzare gli algoritmi tradizionali con i blocchi. Un buon esempio di qualcosa che in passato sembrava un interessante problema accademico. E sì, se mi avessi chiesto in quel momento se pensavo che tutto questo sarebbe stato importante in futuro, avrei detto: certo, ma quando esattamente non è chiaro. Forse tra 50 anni? In pratica, si è rivelato essere solo un decennio. È molto bello quando fai qualcosa, e in soli dieci anni la gente se ne accorge.
Perché vale la pena fare ricerca nel campo del calcolo distribuito
Vitaly: Se parliamo di nuove ricerche, cosa consiglieresti ai lettori: calcolo distribuito o multi-core e perché?
Maurice: Al giorno d'oggi è facile ottenere un processore multi-core, ma è più difficile configurare un vero sistema distribuito. Ho iniziato a lavorarci perché volevo fare qualcosa di diverso dal mio dottorato di ricerca. Questo è il consiglio che do sempre ai principianti: non scrivere una dissertazione di follow-up, prova ad andare in una nuova direzione. Inoltre, il multithreading è facile. Posso sperimentare sul mio fork in esecuzione su un laptop senza alzarmi dal letto. Ma se all'improvviso volessi creare un vero sistema distribuito, dovrei fare molto lavoro, attrarre studenti e così via. Sono una persona pigra e preferirei lavorare su multi-core. Sperimentare con sistemi multi-core è anche più facile che sperimentare sistemi distribuiti, perché anche in uno stupido sistema distribuito ci sono troppi fattori da controllare.
Vitaliy: Cosa stai facendo ora, ricercando blockchain? A quali articoli dovresti prestare attenzione per primi?
Maurice: Apparso di recente che ho scritto con il mio studente, Vikram Saraf, appositamente per il a Parigi tre settimane fa. Questo è un articolo sugli utili sistemi distribuiti in cui proponiamo di rendere Ethereum multi-thread. Ora i contratti intelligenti (codice che viene eseguito sulla blockchain) vengono eseguiti in sequenza. Abbiamo scritto un articolo in precedenza che parlava di un modo per utilizzare transazioni speculative per accelerare il processo. Abbiamo preso molte idee dalla memoria transazionale del software e abbiamo detto che se rendi queste idee parte della macchina virtuale Etherium, allora tutto funzionerà più velocemente. Ma per questo è necessario che non ci siano conflitti di dati nei contratti. E poi abbiamo ipotizzato che nella vita reale non ci siano davvero conflitti del genere. Ma non abbiamo avuto modo di scoprirlo. Poi ci è venuto in mente che avevamo tra le mani quasi dieci anni di storia contrattuale reale, quindi abbiamo scaricato la blockchain di Etherium e ci siamo chiesti: cosa succederebbe se questi record storici corressero in parallelo? Abbiamo riscontrato un aumento significativo della velocità. Nei primi giorni di Etherium, la velocità è aumentata molto, ma oggi tutto è un po' più complicato, perché ci sono meno contratti e la probabilità di conflitti sui dati che richiedono la serializzazione è aumentata. Ma tutto questo è un lavoro sperimentale con dati storici reali. La cosa bella della blockchain è che ricorda tutto per sempre, quindi puoi tornare indietro nel tempo e studiare cosa succederebbe se usassimo altri algoritmi per eseguire il codice. Come le persone in passato avrebbero apprezzato la nostra nuova idea. È molto più facile e piacevole fare tali ricerche, perché c'è una cosa che controlla tutto e registra tutto. Questo è già qualcosa di più simile alla sociologia che allo sviluppo di algoritmi.
Lo sviluppo di algoritmi si è fermato e come continuare a vivere
Vitaly: È ora dell'ultima domanda teorica! Ti sembra che i progressi nelle strutture dati competitive si stiano riducendo ogni anno? Pensi che abbiamo raggiunto un plateau nella nostra comprensione delle strutture dati o ci saranno dei miglioramenti importanti? Forse ci sono alcune idee intelligenti che possono cambiare completamente tutto?
Maurice: Potremmo aver raggiunto un plateau nelle strutture dati per le architetture tradizionali. Ma le strutture dati per le nuove architetture sono ancora un'area molto promettente. Se si desidera creare strutture dati per, ad esempio, acceleratori hardware, le strutture dati GPU sono molto diverse dalle strutture dati CPU. Quando progetti strutture di dati per blockchain, devi eseguire l'hashing di pezzi di dati e poi inserirli in qualcosa di simile , per prevenire la contraffazione. Ultimamente c'è stata un'ondata di attività in quest'area, molti stanno facendo un ottimo lavoro. Ma penso che ciò che accadrà è che nuove architetture e nuove applicazioni porteranno a nuove strutture di dati. Vecchie applicazioni e architettura tradizionale - forse non c'è più molto spazio per la ricerca. Ma se esci dai sentieri battuti e guardi oltre il limite, vedrai cose folli che il mainstream non prende sul serio - è lì che accadono tutte le cose eccitanti.
Vitaly: Pertanto, per essere un ricercatore molto famoso, ho dovuto inventare la mia architettura 🙂
Maurice: Puoi "rubare" la nuova architettura di qualcun altro - sembra molto più facile!
Lavora presso Brown University
Vitaliy: Potresti dirci di più in cui lavori? Non si sa molto di lui nel contesto della tecnologia dell'informazione. Meno del MIT, per esempio.
Maurice: La Brown University è una delle università più antiche degli Stati Uniti. Penso che solo Harvard sia un po' più grande. Brown fa parte del cosiddetto , che è una raccolta di otto università più antiche. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pennsylvania, Princeton. Questa è una specie di università vecchia, piccola e un po' aristocratica. L'attenzione si concentra sull'educazione alle arti liberali. Non sta cercando di essere come il MIT, il MIT è molto specializzato e tecnico. Brown è un ottimo posto per studiare letteratura russa o greco classico e, naturalmente, informatica. Si concentra sull'istruzione completa. La maggior parte dei nostri studenti va su Facebook, Apple, Google, quindi penso che i nostri studenti non abbiano problemi a trovare un lavoro nel settore. Sono andato a lavorare alla Brown perché prima lavoravo alla Digital Equipment Corporation di Boston. Era un'azienda che ha inventato molte cose interessanti, ma ha negato l'importanza dei personal computer. Un'azienda dal destino difficile, i cui fondatori un tempo erano giovani rivoluzionari, non hanno imparato nulla e non hanno dimenticato nulla, e quindi sono passati da rivoluzionari a reazionari in circa un decennio. A loro piaceva scherzare dicendo che i personal computer appartenevano a un garage, un garage abbandonato, ovviamente. È abbastanza ovvio che sono stati distrutti da aziende più flessibili. Quando è diventato chiaro che l'azienda era nei guai, ho chiamato il mio amico di Brown, che è a circa un'ora da Boston. Non volevo lasciare Boston in quel momento, perché le altre università non avevano molti posti vacanti. Era un periodo in cui non c'erano tanti posti vacanti nel campo dell'informatica come ce ne sono adesso. E Brown aveva un lavoro, non ho dovuto lasciare la mia casa, non ho dovuto spostare la mia famiglia, e mi piace molto vivere a Boston! Così ho preso la decisione di andare alla Brown. Mi piace. Gli studenti sono fantastici, quindi non ho mai nemmeno provato ad andare da qualche altra parte. In un anno sabbatico ho lavorato un anno in Microsoft, un anno al Technion di Haifa e ora sarò in Algorand. Ho molti colleghi ovunque e quindi l'ubicazione fisica delle nostre aule non è così importante. Ma la cosa più importante sono gli studenti, qui sono i migliori. Non ho mai provato ad andare da nessun'altra parte, perché sono abbastanza felice qui.
Eppure, nonostante la fama di Brown negli Stati Uniti, è sorprendentemente sconosciuto all'estero. Come puoi vedere, ora sto facendo del mio meglio per correggere questo stato di cose.
La differenza tra ricerca universitaria e aziendale
Vitaliy: Ok, la prossima domanda riguarda l'attrezzatura digitale. Eri un ricercatore lì. Qual è la differenza tra lavorare nel reparto R&S di una grande azienda e lavorare in un'università? quali sono i vantaggi e gli svantaggi?
Maurice: Lavoro in Microsoft da vent'anni, lavorando a stretto contatto con persone di Sun Microsystems, Oracle, Facebook e ora Algorand. Sulla base di tutto ciò, voglio dire che è possibile condurre ricerche di prim'ordine sia nelle aziende che all'università. La differenza importante è che in azienda si lavora con i colleghi. Se all'improvviso mi viene un'idea per un progetto che ancora non esiste, devo convincere i miei colleghi che questa è una buona idea. Se sono alla Brown, allora posso dire ai miei studenti: lavoriamo sull'antigravità! Andranno da qualcun altro o assumeranno il progetto. Sì, avrò bisogno di trovare finanziamenti, dovrò scrivere una domanda di sovvenzione e così via. In ogni caso, ci saranno sempre molti studenti e potrai prendere decisioni unilateralmente. Ma all'università molto probabilmente non lavorerai con persone del tuo livello. Nel mondo della ricerca industriale, devi prima convincere tutti che vale la pena intraprendere il tuo progetto. Non posso ordinare niente da nessuno. Ed entrambi questi modi di lavorare sono preziosi, perché se stai lavorando a qualcosa di veramente folle e i tuoi colleghi sono difficili da convincere, è più facile convincere gli studenti laureati, specialmente se li paghi. Se stai lavorando a qualcosa che richiede molta esperienza e profonda competenza, allora hai bisogno di colleghi che possano dire "no, capita che io capisca quest'area e la tua idea è cattiva, non ne verrà fuori nulla". Questo è molto utile in termini di perdita di tempo. Inoltre, se nei laboratori industriali passi molto tempo a scrivere rapporti, allora all'università passi questo tempo a trovare soldi. Se voglio che gli studenti possano viaggiare da qualche parte, devo trovare i soldi da qualche altra parte. E più importante è la tua posizione all'università, più tempo devi dedicare alla raccolta di denaro. Quindi, ora sai come lavoro: un mendicante professionista! Come uno di quei monaci che vanno in giro con un piatto per le donazioni. In generale, queste due attività si completano a vicenda. Ecco perché cerco di vivere e stare fermamente in entrambi i mondi.
Vitaliy: Sembra che convincere un'azienda sia più difficile che convincere altri scienziati.
Maurice: Più difficile, e molto di più. Inoltre, in diverse aree è diverso: qualcuno conduce ricerche su vasta scala e qualcuno si concentra sul proprio argomento. Se andassi su Microsoft o Facebook e dicessi, facciamo l'antigravità, difficilmente lo apprezzerebbero. Ma se dicessi esattamente la stessa cosa ai miei studenti laureati, molto probabilmente si metterebbero al lavoro all'istante, anche se ora avrei già dei problemi, perché devi trovare soldi per questo. Ma fintanto che vuoi fare qualcosa in linea con gli obiettivi dell'azienda, quell'azienda può essere un ottimo posto per fare ricerca.
Idra e SPTDC
Vitaliy: Le mie domande stanno per finire, quindi parliamo un po' del prossimo viaggio in Russia.
Maurice: Sì, non vedo l'ora di tornare a Pietroburgo.
Alexey: È un grande onore per me che tu sia con noi quest'anno. Questa è la tua seconda volta a San Pietroburgo, giusto?
Maurice: Già il terzo!
Alexei: Capito, ma - esattamente il secondo. L'ultima volta che la scuola è stata chiamata , ora abbiamo cambiato una lettera (da C a D, da Concurrent a Distributed) per sottolineare che quest'anno ci sono più aree relative al calcolo distribuito. Puoi dire qualche parola sulle tue presentazioni alla Scuola e ?
Maurice: A scuola, voglio parlare delle basi della blockchain e di cosa puoi farci. Vorrei mostrare che le blockchain sono molto simili alla programmazione multi-thread che conosciamo, ma con le loro sfumature, ed è importante comprendere queste differenze. Se commetti un errore in una normale applicazione web, è solo fastidioso. Se scrivi codice difettoso in un'app finanziaria, qualcuno ruberà sicuramente tutti i tuoi soldi. Questo è un livello di responsabilità e conseguenze completamente diverso. Parlerò un po' di proof-of-work, contratti intelligenti, transazioni tra diverse blockchain.
Altri relatori lavoreranno accanto a me, che hanno anche qualcosa da dire sulla blockchain, e abbiamo concordato di coordinarci tra di noi in modo che le nostre storie si adattino bene. Ma per il discorso di ingegneria, voglio dare una chiara spiegazione a un vasto pubblico perché non dovresti credere a tutto ciò che senti sulle blockchain, perché le blockchain sono un grande campo, come si adatta ad altre idee ben note e perché dovremmo guardare con coraggio al futuro.
Alexey: Inoltre, voglio dire che questo non avverrà nel formato di un meetup o di un gruppo di utenti, come due anni fa. Abbiamo deciso di fare una piccola conferenza vicino alla scuola. Il motivo è che dopo aver parlato con Peter Kuznetsov, ci siamo resi conto che la scuola è limitata a sole cento, forse 120 persone. Allo stesso tempo, ci sono molti ingegneri che vogliono parlare con te, partecipare a rapporti e sono generalmente interessati all'argomento. Per questo abbiamo creato una nuova conferenza . A proposito, hai idea del perché Hydra?
Maurice: Perché avrà sette altoparlanti? E possono essere tagliati loro la testa e al loro posto cresceranno nuovi oratori?
Alexey: Ottima idea per far crescere nuovi altoparlanti. Ma davvero, c'è una storia qui. Ricorda la leggenda di Ulisse, dove doveva navigare tra ? Hydra è qualcosa come Cariddi. La storia è che una volta ho parlato a una conferenza e ho parlato di multithreading. C'erano solo due tracce in questa conferenza. All'inizio della relazione, ho detto al pubblico in sala che ora possono scegliere tra Scilla e Cariddi. Il mio animale spirituale è Cariddi, perché Cariddi ha molte teste e il mio tema è il multithreading. Ecco come appaiono i nomi delle conferenze.
In ogni caso, abbiamo esaurito sia le domande che il tempo. Quindi grazie amici per l'ottima intervista e ci vediamo a SPTDC e Hydra 2019!
Sarà possibile continuare la comunicazione con Maurice alla conferenza Hydra 2019, che si terrà dall'11 al 12 luglio 2019 a San Pietroburgo. Verrà con un rapporto . I biglietti possono essere acquistati .
Fonte: habr.com