- come professore di informatica presso l'Università di Rochester e nella sua casa, l'Università del Wisconsin-Madison, è stato preside per cinque anni. Ricerca e insegna agli studenti la programmazione parallela e distribuita e la progettazione del linguaggio.
Il mondo conosce Michael dai libri di testo , che dire del lavoro ha ricevuto il Premio Dijkstra come uno dei più famosi nel campo del calcolo distribuito. Potresti anche conoscerlo come l'autore di quello stesso algoritmo .
Insieme a Doug Lee, ha sviluppato gli algoritmi non bloccanti e le code sincrone che alimentano le librerie Java. Implementazione in JavaSE 6 le prestazioni sono migliorate di 10 volte ThreadPoolExecutor.
Contenuto:
- Inizio carriera, Università di Rochester. Progetto Charlotte, linguaggio Lynx;
- Interfaccia coerente scalabile IEEE, blocco MCS;
- Sopravvivenza in un mondo in continua evoluzione;
- Gli studenti stanno diventando più stupidi? Tendenze globali, internazionalizzazione;
- Lavoro efficace con gli studenti;
- Come tenere il passo con la preparazione di nuovi corsi e libri;
- Collegamenti tra imprese e mondo accademico;
- Implementazione pratica delle idee. MCS, MS, CLH, JSR 166, lavorando con Doug Lee e altri;
- Memoria transazionale;
- Nuove architetture. La vittoria della memoria transazionale è vicina;
- Memoria non volatile, Optane DIMM, dispositivi ultraveloci;
- La prossima grande tendenza. Doppie strutture dati. Idra.
Le interviste sono condotte da:
Vitaly Aksenov - attualmente postdoc presso IST Austria e membro del Dipartimento di tecnologie informatiche presso l'Università ITMO. Conduce ricerche nel campo della teoria e della pratica delle strutture dati competitive. Prima di lavorare all'IST, ha conseguito il dottorato di ricerca presso l'Università Diderot di Parigi e l'Università ITMO sotto la supervisione del professor Peter 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.
Inizio carriera, Università di Rochester. Progetto Charlotte, linguaggio Lynx.
Alexey: Per cominciare volevo dirti che in Russia amiamo tutti davvero l'informatica, la scienza dei dati e gli algoritmi. E' decisamente osceno. Abbiamo letto tutto . Pertanto, la prossima conferenza, la scuola e questa stessa intervista dovrebbero essere molto popolari. Abbiamo ricevuto molte domande per questa intervista da studenti, programmatori e membri della comunità, quindi siamo molto grati per questa opportunità. L’informatica gode dello stesso amore negli Stati Uniti?
Michael: Il nostro campo è così vario, ha così tante direzioni e influenza la società in così tanti modi diversi che è difficile per me darti una risposta definitiva. Ma il fatto è che negli ultimi 30 anni ha portato enormi cambiamenti nel mondo degli affari, dell’industria, dell’arte e della società in generale.
Vitali: Cominciamo con qualcosa di lontano. In molte università esiste qualcosa come la specializzazione in un settore particolare. Per la Carnegie Mellon University si tratta di calcolo parallelo, per il MIT è crittografia, robot e multithreading. Esiste una specializzazione del genere all'Università di Rochester?
Michael: Ad essere onesti, direi che CMU e MIT sono specializzati in tutti i settori. Il nostro dipartimento ha sempre prestato la massima attenzione all’intelligenza artificiale. La metà delle persone che lavorano per noi sono impegnate nell'intelligenza artificiale o nell'interazione uomo-computer: questa percentuale è più alta che in altri dipartimenti ed è sempre stata così. Ma quando ero all'università non avevo corsi di intelligenza artificiale e non ho mai lavorato in questo campo. Quindi il mio dipartimento è specializzato in un problema con cui non ho nulla a che fare. La consolazione è che il secondo problema più importante per il nostro dipartimento è la programmazione parallela e multi-thread, cioè la mia specializzazione.
Vitali: Hai iniziato a lavorare nel campo dell'informatica quando il campo della programmazione multi-thread stava appena emergendo. Dall'elenco delle tue pubblicazioni emerge che i tuoi primi lavori trattavano uno spettro abbastanza ampio di tematiche: gestione della memoria in sistemi multi-thread, file system distribuiti, sistemi operativi. Perché tanta versatilità? Hai cercato di trovare il tuo posto nella comunità di ricerca?
Michael: Da studente ho partecipato presso l'Università del Wisconsin, dove è stato sviluppato uno dei primi sistemi operativi distribuiti. Lì ho lavorato insieme a Rafael Finkel () e Marvin Solomon (). La mia tesi era dedicata allo sviluppo di un linguaggio per software di sistema per sistemi distribuiti - ora tutti se ne sono dimenticati e grazie a Dio. Ho creato il linguaggio di programmazione Lynx, che aveva lo scopo di rendere più semplice la creazione di server per un sistema operativo distribuito liberamente accoppiato. Dato che a quel tempo mi occupavo principalmente di sistemi operativi, pensavo che la mia carriera sarebbe stata principalmente collegata ad essi. Ma Rochester era un'università molto piccola e per questo motivo i diversi gruppi interagivano molto strettamente tra loro. Non c'erano una dozzina di altri esperti di sistemi operativi con cui parlare, quindi tutti i miei contatti erano con persone che lavoravano in aree completamente diverse. Mi sono divertito molto, essere un tuttofare per me è un grande vantaggio. Se parliamo specificamente di strutture dati multi-thread e algoritmi di sincronizzazione, ho iniziato a lavorarci completamente per caso.
Interfaccia coerente scalabile IEEE, blocco MCS.
Vitali: Puoi dirmi qualcosa in più a riguardo?
Michael: Questa è una storia divertente che non mi stanco mai di raccontare a tutti. È successo durante una conferenza a Boston: era la fine degli anni '80 o l'inizio degli anni '90. John Mellor-Crummey (), laureato della nostra facoltà. Lo conoscevo, ma non avevamo mai condotto una ricerca congiunta prima. Mary Vernon () del Wisconsin ha parlato di un sistema multiprocessore che stavano sviluppando in Wisconsin: . Questo Multicube aveva un meccanismo di sincronizzazione a livello hardware chiamato Q on Sync Bit, e in seguito fu ribattezzato Q on Lock Bit perché suonava come Colby Cheese, che era un gioco di parole. Se sei interessato ai meccanismi di multithreading, probabilmente saprai che Colby alla fine divenne il motore di sincronizzazione per lo standard IEEE Scalable Coherent Interface. Si trattava di un meccanismo di blocco che creava puntatori da una cache all'altra a livello hardware in modo che ciascun detentore del blocco sapesse di chi era il turno. Quando John e io ne abbiamo sentito parlare, ci siamo guardati e abbiamo detto: perché farlo a livello hardware? Non è possibile ottenere la stessa cosa utilizzando il confronto e lo scambio? Abbiamo preso uno dei quaderni che giacevano in classe e ci abbiamo scarabocchiato sopra , mentre Mary continuava il suo resoconto. Successivamente l'abbiamo implementata, sperimentata, l'idea si è rivelata vincente e abbiamo pubblicato l'articolo. A quel tempo, per me questo argomento sembrava solo una divertente distrazione, dopodiché avevo intenzione di tornare ai sistemi operativi. Ma poi è sorto un altro problema sulla stessa linea e alla fine la sincronizzazione, il multithreading e le strutture dati sono diventate la mia specialità. Come puoi vedere, tutto questo è successo per caso.
Vitali: Conosco il blocco MCS da molto tempo, ma fino ad ora non sapevo che fosse opera tua e non avevo capito che fosse l'acronimo dei tuoi cognomi.
Come sopravvivere in un mondo in continua evoluzione?
Alexey: Ho una domanda su un argomento correlato. 30 o 40 anni fa c'era più libertà nelle diverse specialità. Se vuoi iniziare una carriera nel multithreading o nei sistemi distribuiti, sei il benvenuto, se vuoi entrare nei sistemi operativi, nessun problema. In ogni ambito c'erano molte domande aperte e pochi esperti. Ora sono emerse specializzazioni ristrette: non ci sono solo esperti di sistemi operativi in generale, ci sono specialisti di singoli sistemi. È lo stesso con il multithreading e i sistemi distribuiti. Ma il problema è che le nostre vite non sono infinite; ognuno può dedicare alla ricerca solo pochi decenni. Come sopravvivere in questo nuovo mondo?
Michael: Noi non siamo speciali in questo senso, la stessa cosa è successa una volta anche in altri ambiti. Ho avuto la fortuna di aver iniziato a lavorare nel campo dell’informatica quando il settore era nei suoi anni “adolescenti”. Alcune basi erano già state gettate, ma tutto era ancora molto acerbo. Questa opportunità non si presenta spesso. L'ingegneria elettrica esiste da moltissimo tempo, la fisica ancora più a lungo, la matematica quasi dall'inizio dei tempi. Ma questo non significa che nessuno faccia più scoperte interessanti in matematica. I problemi aperti sono ancora molti, ma allo stesso tempo c’è ancora molto da imparare. Hai ragione nel notare che ora ci sono molte più specializzazioni rispetto a prima, ma questo significa solo che ci troviamo nella stessa situazione della maggior parte degli altri settori dell'attività umana.
Alexey: Qui mi interessa l'aspetto più pratico della questione. Ho una formazione matematica e durante i miei studi ho spesso partecipato a conferenze e lavorato su vari argomenti scientifici. Ho scoperto che nessuno del pubblico capiva i miei resoconti, e allo stesso modo, i resoconti degli altri erano comprensibili solo a loro stessi. Questo non è il caso degli argomenti di alto livello, ma non appena inizi ad approfondire qualcosa, il pubblico non riesce più a starti dietro. come lo gestisci?
Michael: Non sempre ha successo. Recentemente ho preparato un rapporto in cui sono andato troppo in profondità nei dettagli tecnici. Man mano che il discorso andava avanti, è diventato chiaro che la maggior parte del pubblico non mi capiva, quindi ho dovuto adattarmi al volo alla situazione. Le diapositive non potevano essere modificate, quindi non è venuta molto bene, quindi, in generale, cerco di non usare le diapositive. Nel complesso, il mio consiglio è di considerare il tuo pubblico. Devi sapere con chi stai parlando, qual è il loro livello di conoscenza e cosa hanno bisogno di sentire per apprezzare il tuo lavoro.
Vitali: Potresti darci un suggerimento sull'argomento di questa conferenza?
Michael: Sinceramente preferirei non approfondire questo argomento per lasciare anonime le persone in questione. Il punto è che spesso entriamo troppo in profondità nella complessità del problema su cui stiamo lavorando, quindi diventa difficile per noi spiegare all'inizio del discorso perché il problema è interessante e importante e come si collega alle questioni che il problema sta affrontando. il pubblico lo sa già. Secondo le mie osservazioni, gli studenti hanno maggiori difficoltà ad apprendere questa abilità. E questo è stato anche il punto debole del mio recente rapporto. Un rapporto adeguatamente strutturato dovrebbe, fin dall'inizio, trovare un contatto con il pubblico, spiegare loro qual è esattamente il problema e come si collega ad argomenti a lui già noti. Quanto sia tecnica questa introduzione dipende dal pubblico. Se è completamente eterogeneo, il rapporto può essere in più fasi. L'introduzione dovrebbe essere accessibile a tutti e alla fine il pezzo potrebbe non essere in grado di tenere il passo con te, ma le persone che hanno una certa familiarità con il tuo campo saranno in grado di capirlo.
Gli studenti stanno diventando più stupidi? Tendenze globali, internazionalizzazione.
Alexey: Osserva gli studenti da diversi decenni. Gli studenti stanno diventando più stupidi o più intelligenti di decennio in decennio o di anno in anno? In Russia, i professori si lamentano costantemente del fatto che gli studenti diventano ogni anno più stupidi e non è davvero chiaro cosa fare al riguardo.
Michael: Da noi anziani si sente davvero molta negatività. Inconsciamente, abbiamo la tendenza ad aspettarci che gli studenti assorbano tutti i 30 anni di esperienza che già abbiamo. Se ho una comprensione più profonda di quella che avevo nel 1985, perché non ce l’hanno gli studenti? Probabilmente perché hanno 20 anni, cosa ne pensi? Penso che i cambiamenti più significativi negli ultimi decenni siano stati nella composizione demografica: ora abbiamo un numero significativamente maggiore di studenti internazionali, ad eccezione dei canadesi. C'erano molti canadesi perché siamo molto vicini al confine canadese e gli studenti da lì possono tornare a casa nei fine settimana. Ma ora ci sono molte buone università in Canada e i canadesi preferiscono studiare qui; molti meno di loro vengono negli Stati Uniti.
Alexey: Pensi che questa sia una tendenza locale o globale?
Michael: Non ricordo esattamente chi, ma qualcuno ha detto che il mondo è piatto. Il nostro campo è diventato molto più internazionale. In precedenza, si tenevano esclusivamente negli Stati Uniti, poi si decideva di tenerli una volta ogni 4 anni in altri paesi e ora si tengono in tutto il mondo. Questi cambiamenti hanno influenzato ancora di più , poiché è sempre stata un'organizzazione più internazionale dell'ACM. E ci sono presidenti di programma provenienti da Cina, India, Russia, Germania e molti altri paesi, perché ormai c’è molto da fare ovunque.
Alexey: Ma ci sono probabilmente degli aspetti negativi di tale internazionalizzazione?
Michael: Direi che tutti gli aspetti negativi non riguardano la tecnologia, ma la politica. Un tempo, il problema principale era il fatto che gli Stati Uniti rubavano le persone più intelligenti e talentuose dai paesi di tutto il mondo. E ora il problema principale sono i giochi politici tra i diversi paesi riguardo ai visti e all’immigrazione.
Alexey: Cioè, barriere e cose del genere. È chiaro.
Vladimir: Personalmente, mi interessa quale approccio adotti quando insegni una nuova materia agli studenti. Ci sono diverse opzioni: puoi provare innanzitutto a ispirarli a provare qualcosa di nuovo, oppure puoi prestare maggiore attenzione ai dettagli di come funziona una determinata tecnologia. Cosa preferisci?
Lavoro efficace con gli studenti
Alexey: E come trovare il dannato equilibrio tra il primo e il secondo?
Michael: Il problema è che le lezioni non sempre vanno come vorrei. Di solito do agli studenti materiale da leggere in anticipo in modo che lo approfondiscano, lo comprendano al meglio delle loro capacità e formino domande su quelle parti che non riescono a capire. Poi in classe potrete concentrarvi sui momenti più difficili ed esplorarli insieme. Questo è il modo in cui mi piace di più insegnare in classe. Ma dato il carico che ora grava sugli studenti, non sono sempre in grado di assicurarmi che si preparino in anticipo. Di conseguenza, devi dedicare molto più tempo alla rivisitazione generale del materiale di quanto vorresti. Nonostante ciò, cerco di mantenere le nostre lezioni interattive. Altrimenti, è più semplice registrare un video che gli studenti possano poi guardare a casa. Lo scopo delle lezioni dal vivo è l’interazione umana. In classe preferisco usare il gesso e la lavagna piuttosto che le diapositive, tranne in alcuni casi in cui un diagramma è troppo complesso per essere rappresentato alla lavagna. Grazie a questo, non devo attenermi a un rigido programma di lezioni. Poiché non esiste un ordine rigido in cui fornisco il materiale, mi permette di adattarlo al pubblico a seconda delle domande che ricevo. In generale, cerco di rendere le lezioni quanto più interattive possibile, in modo che il materiale che presento dipenda dalle domande che mi vengono poste.
Vladimir: È ottimo. Nella mia esperienza, è abbastanza difficile convincere gli ascoltatori a fare domande. Anche se chiedi in anticipo di fare qualsiasi domanda, non importa quanto stupida o intelligente, rimangono comunque in silenzio. come lo gestisci?
Michael: Riderai, ma se rimani in silenzio abbastanza a lungo, prima o poi tutti si sentiranno a disagio e qualcuno farà una domanda. Oppure puoi porre una semplice domanda tecnica con una risposta sì o no per determinare se le persone capiscono ciò che è stato appena detto. Ad esempio, nell'esempio sopra c'è una corsa ai dati? Chi la pensa così? Chi pensa di no? Chi non capisce proprio niente, perché in totale si è alzata solo la metà delle mani?
Vitali: E se rispondi in modo errato, vieni espulso dalla classe :)
Michael: Se non hai risposto a nulla, dovresti fare una domanda. Devo capire cosa esattamente lo studente deve sapere per rispondere alla domanda che ho appena posto. Ho bisogno che mi aiutino ad aiutarli. Sono pronto ad adattarmi a loro in modo che capiscano il problema. Ma se non so cosa sta succedendo nella loro testa, non posso farlo. E se non dai pace agli studenti per un tempo sufficientemente lungo, a volte alla fine fanno le domande giuste, cioè quelle che mi permettono di vedere cosa sta succedendo esattamente nella testa degli studenti.
Alexey: Queste domande a volte portano a idee a cui tu stesso non avevi pensato prima? Sono inaspettati? Ti permettono di guardare un problema sotto una nuova luce?
Michael: Ci sono domande che aprono un nuovo modo di presentare il materiale. Spesso ci sono domande che portano a problemi interessanti di cui non avevo intenzione di parlare. Gli studenti spesso mi dicono che ho la tendenza ad andare fuori tema quando ciò accade. E, secondo loro, molto spesso questa è la parte più interessante della lezione. Molto raramente, solo poche volte, gli studenti hanno posto domande che hanno suggerito una nuova direzione nella ricerca e sono sfociate in un articolo. Ciò accade molto più spesso nelle conversazioni con gli studenti piuttosto che durante le lezioni, ma occasionalmente accadeva durante le lezioni.
Alexey: Quindi gli studenti ti hanno fatto delle domande sulla base delle quali è stato poi possibile pubblicare un articolo?
MichaelSì
Vitali: Quanto spesso hai queste conversazioni con gli studenti? Quando vogliono imparare di più rispetto a quanto trattato durante la lezione?
Michael: Con i miei studenti laureati, sempre. Ne ho circa 5 o 6 e discutiamo continuamente di qualcosa con loro. E conversazioni di questo tipo con studenti che semplicemente frequentano le mie lezioni non sono molto comuni. Anche se vorrei che ciò accadesse più spesso. Ho il sospetto che abbiano semplicemente paura di venire in facoltà durante l'orario di ufficio. Ogni semestre alcuni studenti riescono a superare questa barriera psicologica ed è sempre molto interessante parlare con loro dopo le lezioni. È vero, se tutti gli studenti fossero altrettanto coraggiosi, semplicemente non avrei abbastanza tempo. Quindi forse tutto funziona come dovrebbe.
Vitali: Come riesci a trovare il tempo per comunicare con gli studenti? Per quanto ne so, negli Stati Uniti gli insegnanti hanno molto lavoro, come richiedere borse di studio e cose simili.
Michael: Sinceramente lavorare con gli studenti è l'aspetto del mio lavoro che mi piace di più. Quindi ho abbastanza motivazione per questo. La maggior parte del tempo che trascorro nel mio ufficio lo dedico a riunioni di ogni tipo. Adesso è estate, quindi i miei impegni sono meno impegnativi, ma durante l'anno scolastico, tutti i giorni dalle 9 alle 17 ho tutto pronto. Lavoro di ricerca, revisioni, borse di studio: per tutto questo ci sono solo serate e fine settimana.
Come tenere il passo con la preparazione di nuovi corsi e libri.
Alexey: Attualmente stai continuando a insegnare qualche corso che insegni da molto tempo? Qualcosa come un'introduzione all'informatica.
Michael: La prima cosa che mi viene in mente qui è un corso di linguaggi di programmazione.
Alexey: Quanto è diversa la versione odierna di questo corso da quella di 10, 20, 30 anni fa? Forse ciò che è più interessante qui non sono i dettagli di un corso particolare, ma le tendenze generali.
Michael: Il mio corso sui linguaggi di programmazione era alquanto insolito al momento in cui l'ho creato. Ho iniziato a leggerlo alla fine degli anni '1980, in sostituzione del mio collega Doug Baldwin (). L'argomento del corso era legato solo indirettamente alla mia specialità, ma quando se ne andò ero il miglior candidato per insegnare il corso. Non mi piaceva nessuno dei libri di testo esistenti all'epoca, quindi ho finito per scrivere io stesso il libro di testo per questo corso. (Ndr: stiamo parlando del libro) Ora è utilizzato in più di 200 università in tutto il mondo. Il mio approccio è insolito in quanto mescola deliberatamente i problemi di progettazione e implementazione del linguaggio e presta grande attenzione all'interazione tra questi aspetti in tutte le aree possibili. L'approccio di base è rimasto invariato, così come molti concetti di base: astrazioni, spazi dei nomi, modularità, tipi. Ma l’insieme dei linguaggi con cui questi concetti vengono dimostrati è completamente cambiato. Quando il corso è stato creato per la prima volta c'erano molti esempi in Pascal, ma oggi molti dei miei studenti non hanno nemmeno sentito parlare di questa lingua. Ma conoscono Swift, Go, Rust, quindi devo parlare dei linguaggi in uso oggi. Inoltre, gli studenti ora sono esperti nei linguaggi di scripting, ma quando ho iniziato a insegnare questo corso, era tutto sui linguaggi compilati. Ora abbiamo bisogno di molto materiale su Python, Ruby e persino Perl, perché questo è il codice che viene scritto al giorno d'oggi, e stanno accadendo molte cose interessanti in questi linguaggi, anche nel campo della progettazione del linguaggio.
Vitali: Allora la mia prossima domanda sarà collegata alla precedente. Come tenere il passo in questo settore? Ho il sospetto che aggiornare un corso come questo richieda molto lavoro: devi comprendere nuove lingue, comprendere le idee principali. Come fai a fare questo?
Michael: Non posso vantarmi di riuscirci sempre al 100%. Ma la maggior parte delle volte faccio quello che fanno tutti gli altri: leggo Internet. Se voglio capire Rust, lo cerco su Google, vado alla pagina di Mozilla e leggo il manuale pubblicato lì. Questo fa parte delle cose che accadono nello sviluppo commerciale. Se parliamo di scienza, allora dobbiamo seguire le relazioni delle principali conferenze.
Collegamento tra impresa e mondo accademico
Vitali: Parliamo del legame tra impresa e ricerca scientifica. Nel tuo elenco di lavori ho trovato diversi articoli sulla coerenza della cache. Capisco che gli algoritmi di coerenza della cache erano instabili al momento della pubblicazione? O non abbastanza diffuso. Quanto erano comuni le tue idee nella pratica?
Michael: Non sono esattamente sicuro di quali pubblicazioni stai parlando. Ho lavorato parecchio con i miei studenti Bill Bolosky () e Leonidas Kontotanassis () all'inizio degli anni '1990 sulla gestione della memoria delle macchine Neumann. A quel tempo, le aziende non avevano ancora capito come realizzare correttamente un sistema multiprocessore: vale la pena creare un supporto per l'accesso alla memoria remota a livello hardware, vale la pena distribuire la memoria, è possibile caricare la cache da memoria remota oppure è necessario spostare le pagine nel sistema della sala operatoria? Bill e Leonidas hanno lavorato entrambi in quest'area e hanno esplorato approcci senza caricamento della cache remota. Ciò non era direttamente correlato alla coerenza della cache, ma si trattava ancora di un lavoro sulla gestione della memoria NUMA e successivamente da questo sono nati gli approcci moderni al posizionamento delle pagine nei moderni sistemi operativi. Nel complesso, Bill e Leonidas hanno svolto un lavoro importante, anche se non i più influenti in quest'area: c'erano molte altre persone che lavoravano sulla stessa cosa in quel momento. Successivamente, ho lavorato su un argomento relativo alla coerenza della cache nel contesto della memoria transazionale hardware. Il gruppo con cui ho lavorato su questo problema ha finito per ricevere diversi brevetti. Dietro ci sono alcune idee piuttosto interessanti, ma non credo che verranno implementate nella pratica. In un modo o nell'altro, è difficile per me giudicare la loro redditività.
Alexey: A questo proposito, una domanda più personale: quanto è importante per te che le tue idee vengano messe in pratica? Oppure non ci pensi?
Michael: Adoro porre questa domanda nelle interviste con altre persone, candidati o candidati che vogliono entrare a far parte della facoltà. Non penso che ci sia una risposta corretta a questa domanda. Le persone che fanno cose interessanti possono avere motivazioni molto diverse. Sono attratto dai problemi perché personalmente li trovo interessanti, non per i loro vantaggi pratici. Ma d'altra parte, quando qualcosa di interessante trova ancora applicazione, mi piace davvero. Quindi non è facile qui. Ma all’inizio del mio lavoro, non sono ancora spinto dall’idea di un uso finale del mondo, ma dall’armonia dell’idea e dal desiderio di esplorarla e vedere cosa ne deriva. Se alla fine dà risultati pratici, bene.
Alexey: Grazie alla tua istruzione ed esperienza, sei maggiormente in grado di giudicare il valore delle idee degli altri. Puoi confrontarli e determinare quale funziona meglio con quale. Sono sicuro che hai un'opinione su cose che vengono attualmente utilizzate nella pratica da grandi produttori come Intel. Dal suo punto di vista, quanto è corretto il percorso che stanno seguendo queste aziende?
Michael: La pratica ruota sempre attorno a ciò che può avere successo commerciale, cioè creare profitto, ed è meglio chiederlo a qualcun altro. Il mio lavoro si traduce principalmente in pubblicazioni e nel campo dei sistemi operativi vengono valutate in base a indicatori di prestazione: velocità, consumo energetico, dimensione del codice. Ma mi è sempre sembrato che questi risultati empirici vengano aggiunti agli articoli solo per poterli pubblicare, e le vere motivazioni per cui le persone lavorano sono estetiche. I ricercatori valutano le soluzioni da una prospettiva artistica, si preoccupano di quanto siano eleganti le idee e cercano di creare qualcosa di migliore rispetto agli approcci esistenti. I ricercatori sono guidati da motivazioni personali, soggettive ed estetiche. Ma non si può scrivere di questo nell’articolo stesso; queste cose non sono argomenti per il comitato di programma. Fortunatamente, le soluzioni eleganti sono spesso anche veloci ed economiche. Una dozzina di miei colleghi e io abbiamo discusso di questo argomento circa 15 anni fa e abbiamo finito per scrivere un articolo al riguardo. Penso che tu possa trovarlo ancora adesso, si chiama o qualcosa del genere, ha più di una dozzina di autori. Questo è l'unico articolo di cui sono autore insieme , quindi se fai una ricerca con il suo nome nella mia lista delle pubblicazioni, troverai quello che ti serve. Parla della valutazione della ricerca sui sistemi e di quanto sia importante l'eleganza.
Alexey: Quindi c'è una differenza tra lo standard di ciò che è considerato buono nella scienza e negli affari. La scienza valuta prestazioni, consumo energetico, TDP, facilità di implementazione e molto altro. Hai l'opportunità di condurre questo tipo di ricerca all'università? Hai un laboratorio con diverse macchine e diverse architetture in cui potresti condurre esperimenti?
Michael: Sì, il nostro reparto ha molte macchine diverse e interessanti. Molto spesso sono piccoli, abbiamo un piccolo cluster e molti sistemi multiprocessore con acceleratori diversi. Inoltre, il campus dispone di un enorme centro informatico che serve scienziati di diverse decine di discipline diverse. Ha circa mille nodi e ventimila core, tutti su Linux. In caso di necessità, puoi sempre acquistare alcuni AWS. Quindi non abbiamo restrizioni significative con l'hardware.
Alexey: Com'era trent'anni fa? Ci sono stati problemi allora?
Michael: Allora era un po' diverso. Tra la metà e la fine degli anni ’1980, la scienza era considerata a corto di risorse informatiche. Per porre rimedio a questa situazione, la National Science Foundation ) ha creato un programma di ricerca sperimentale coordinata (Ricerca Sperimentale Coordinata, CER). La missione del programma era fornire un'infrastruttura informatica per i dipartimenti di informatica e ha ottenuto cambiamenti significativi. Con i soldi da lei forniti, noi dell'Università di Rochester acquistammo una BBN Butterfly da 1984 nodi nel 128, un anno prima del mio arrivo lì. A quel tempo era il più grande sistema multiprocessore al mondo con memoria condivisa. Aveva 128 processori, ciascuno su una scheda madre separata, e occupava quattro rack. Ogni processore aveva un megabyte di memoria, 128 megabyte di RAM erano una quantità inimmaginabile a quel tempo. Su questa macchina abbiamo implementato per la prima volta il blocco MCS.
Alexey: Quindi, se ho capito bene, al momento il problema con l'hardware è stato risolto?
Michael: In generale sì. Ci sono alcuni avvertimenti: in primo luogo, se stai realizzando un'architettura informatica a livello di chip, è difficile farlo in un ambiente accademico perché ci sono strumenti molto migliori per farlo nel mondo degli affari. Se hai bisogno di qualcosa di più piccolo di 10 nanometri, dovrai ordinarlo da qualcun altro. In questo ambito è molto più semplice essere un ricercatore presso Intel. Se lavori sulle comunicazioni ottiche su chip o sulle memorie a stato solido, nel mondo degli affari troverai tecnologie che non sono ancora nella scienza, quindi devi creare alleanze. Ad esempio, Stephen Swanson () creato per le nuove tecnologie di memoria. Questo modulo non sempre funziona, ma in alcuni casi può avere abbastanza successo. Inoltre, nella scienza lo sviluppo dei sistemi informatici più potenti è più difficile. I più grandi progetti di supercomputer attualmente negli Stati Uniti, in Giappone e in Cina sono tutti focalizzati sul business.
Implementazione pratica delle idee. MCS, MS, CLH, JSR 166, collaborazione con Doug Lee e altro ancora.
Vitali: Hai già parlato di come hai iniziato a lavorare sugli algoritmi di sincronizzazione. Hai due articoli molto famosi su и , che in un certo senso sono stati implementati in Java. (Nota del redattore: tutte le pubblicazioni sono visionabili ). Lì questo blocco è stato implementato con alcune modifiche e si è scoperto e la coda è stata implementata come previsto. Ma sono passati molti anni tra la pubblicazione dei suoi articoli e la loro applicazione pratica.
Alexey: Nel caso della coda sembrano circa 10 anni.
Michael: Prima che queste funzionalità apparissero nella libreria standard Java?
Vitali: SÌ. Cosa hai fatto perché ciò accadesse? Oppure non hanno fatto nulla?
Michael: Posso dirti come MS Queue è entrato in Java 5. Alcuni anni prima che uscisse, ho lavorato con il gruppo di Mark Moyers presso Sun Microsystems nel loro laboratorio vicino a Boston. Ha organizzato un workshop per persone che conosceva che stavano lavorando su problemi interessanti nel multithreading perché voleva trovare argomenti da vendere alla loro azienda. È lì che ho incontrato per la prima volta Doug Lea. Doug, io e circa altre 25 persone della Sun stavamo discutendo insieme della presentazione di Doug , che in seguito divenne java.util.concurrent. Lungo la strada, Doug ha detto che gli sarebbe piaciuto utilizzare la coda MS, ma per questo aveva bisogno di un contatore del numero di elementi nella coda per l'interfaccia. Cioè, questo avrebbe dovuto essere fatto con un metodo separato, atomico, preciso e veloce. Ho suggerito semplicemente di aggiungere numeri seriali ai nodi, prendendo il numero del primo nodo e dell'ultimo e sottraendo l'uno dall'altro. Doug si grattò la testa, disse "perché no" e alla fine fece proprio questo. Abbiamo discusso dell'implementazione di questo approccio nella biblioteca, ma Doug ha svolto la maggior parte del lavoro da solo. Di conseguenza, è riuscito a stabilire un eccellente supporto multithreading in Java.
Alexey: Quindi, se ho capito bene, il metodo .size() avrebbe dovuto far parte dell'interfaccia della coda standard e avrebbe dovuto avere una complessità algoritmica di O(1)?
Michael: Sì, e oltre a questo è necessario un contatore separato.
Alexey: Perché se chiami il metodo .size() in Java, il risultato dovrebbe essere disponibile immediatamente e non in base alla dimensione effettiva della raccolta. Capisco, grazie.
Michael: Qualche anno dopo stavo lavorando su strutture dati duali con il mio studente Bill Scherer - infatti, è di questo che parlerò . Doug è venuto da noi e ha detto che avrebbe potuto usarli nel Java Executor Framework. Insieme a Bill, hanno creato due implementazioni, le cosiddette code giuste e ingiuste. Li ho consigliati su questo progetto, anche se non ho partecipato alla stesura del codice vero e proprio. Di conseguenza, la velocità degli esecutori è aumentata in modo significativo.
Vladimir: Hai riscontrato implementazioni errate dei tuoi algoritmi o richieste di aggiunta di nuove funzionalità? In generale, la pratica dovrebbe coincidere con la teoria, ma molto spesso differiscono. Supponiamo che tu abbia scritto un algoritmo e che sulla carta funzioni, ma le persone coinvolte nell'implementazione iniziano a chiederti più funzionalità o qualche tipo di modifica dell'algoritmo. Ti è mai capitato di avere situazioni del genere?
Michael: L’unico esempio in cui qualcuno è venuto da me e mi ha chiesto “come implementarlo” è stata la domanda di Doug, di cui ho già parlato. Ma ci sono stati alcuni casi in cui sono state apportate modifiche interessanti per soddisfare le esigenze pratiche. Ad esempio, il team K42 di IBM ha convertito il blocco MCS e lo ha reso un'interfaccia standard, quindi non è stato necessario passare avanti e indietro il nodo della coda alle routine di acquisizione e rilascio. Grazie a questa interfaccia standard, un'idea bella in teoria ha iniziato a funzionare nella pratica. È sorprendente che non abbiano mai pubblicato un articolo a riguardo e, sebbene abbiano ricevuto un brevetto, in seguito lo abbiano abbandonato. L’idea era meravigliosa e cerco di parlarne ogni volta che è possibile.
Ci sono stati altri casi in cui le persone hanno apportato miglioramenti agli algoritmi che ho pubblicato. Ad esempio, la coda MS ha un meccanismo di installazione in due passaggi, il che significa che erano presenti due CAS sul percorso critico della coda. Sulle auto più vecchie i CAS erano piuttosto costosi. Intel e altri produttori le hanno ottimizzate abbastanza bene di recente, ma una volta queste erano istruzioni da 30 cicli, quindi averne più di una sul percorso critico non era desiderabile. Di conseguenza, è stata sviluppata una coda diversa, simile alla coda MS, ma che aveva una sola operazione atomica sul percorso critico. Ciò è stato ottenuto perché durante un certo periodo di tempo l'operazione potrebbe richiedere un tempo O(n) anziché O(1). Era improbabile, ma possibile. Ciò è dovuto al fatto che in determinati momenti l'algoritmo ha attraversato la coda dall'inizio fino alla posizione attuale in questa coda. In generale, l'algoritmo si è rivelato molto efficace. Per quanto ne so, non è molto utilizzato, in parte perché le operazioni atomiche richiedono molte meno risorse rispetto a prima. Ma l'idea era fantastica. Mi piace molto anche il lavoro di Dave Dice di Oracle. Tutto quello che fa è molto pratico e usa il ferro in modo molto intelligente. Ha contribuito a gran parte degli algoritmi di sincronizzazione compatibili con NUMA e delle strutture dati multi-thread.
Vladimir: Quando scrivi algoritmi o insegni agli studenti, il risultato del tuo lavoro non è immediatamente visibile. La comunità ha bisogno di un po' di tempo per acquisire familiarità, ad esempio, con un nuovo articolo. Il nuovo algoritmo non trova immediatamente applicazione.
Michael: Non è affatto chiaro se l'articolo sarà significativo o meno. Penso che sarebbe interessante fare uno studio sugli articoli che hanno vinto premi alle conferenze. Cioè, guarda gli articoli che un tempo i membri dei comitati di programma consideravano i migliori. Devi provare a calcolare in base al numero di collegamenti e all'impatto sul business quanto siano diventati realmente influenti questi articoli in 10, 20, 25 anni. Dubito che ci sarebbe una forte correlazione tra i due. Non sarà pari a zero, ma molto probabilmente sarà molto più debole di quanto vorremmo. Molte idee rimangono non rivendicate per molto tempo prima di diventare diffuse. Prendiamo ad esempio la memoria transazionale. Sono passati più di 10 anni dal momento in cui è stato pubblicato l'articolo originale al momento in cui le persone hanno effettivamente iniziato a costruire macchine con esso. E prima della comparsa di questo ricordo nei prodotti commerciali - e in tutti e 20. Per molto tempo nessuno ha prestato attenzione all'articolo, e quindi il numero di collegamenti ad esso è aumentato notevolmente. Sarebbe difficile prevederlo in anticipo. D'altra parte, a volte le idee trovano subito realizzazione. Qualche anno fa, ho scritto un articolo con Joe Izraelevitz per DISC che proponeva una nuova definizione formale di validità per strutture di dati persistenti che potrebbero essere utilizzate dopo che il computer che le esegue si blocca. L'articolo mi è piaciuto fin dall'inizio, ma si è rivelato molto più popolare di quanto mi aspettassi. È stato utilizzato da diversi gruppi e alla fine è diventato la definizione standard di strutture di persistenza. Il che, ovviamente, è carino.
Vladimir: Ci sono delle tecniche che usi per la valutazione? Provi anche a valutare i tuoi articoli e i tuoi studenti? In termini di se la persona a cui hai insegnato sta andando nella giusta direzione.
Michael: Come tutti gli altri, presto più attenzione a quello che sto facendo in questo momento. Ancora una volta, come tutti gli altri, ogni tanto controllo Google Scholar per vedere se i miei articoli passati vengono citati, ma è più per curiosità. Per lo più sono assorbito da ciò che stanno facendo i miei studenti adesso. Quando si tratta di valutare il lavoro attuale, in parte si tratta di considerazioni estetiche, cosa è elegante e cosa non lo è. E a livello quotidiano, le domande aperte giocano un ruolo importante. Ad esempio, uno studente viene da me con un grafico di alcuni risultati e stiamo cercando di capire da dove provenga uno strano comportamento del grafico. In generale, nel nostro lavoro cerchiamo costantemente di capire cose che ancora non comprendiamo.
Memoria transazionale
Vitali: Forse possiamo parlare un po' della memoria transazionale?
Michael: Penso che valga la pena dirlo almeno un po' perché ci metto molto impegno. Questo è un argomento sul quale ho più pubblicazioni di qualunque altro. Ma allo stesso tempo, stranamente, sono sempre stato molto scettico riguardo alla memoria transazionale. Secondo me, (M. Herlihy, J. E. B. Moss) è stato pubblicato in anticipo sui tempi. All'inizio degli anni '1990, suggerirono che la memoria transazionale potesse aiutare i programmatori di talento a lavorare su strutture di dati multi-thread, in modo che queste strutture potessero poi essere utilizzate come librerie da programmatori ordinari. Cioè, sarebbe di aiuto per Doug Lee che realizzasse il suo JSR 166. Ma la memoria transazionale non era destinata a rendere facile la programmazione multi-thread. Ma è proprio così che ha cominciato ad essere percepito all’inizio degli anni 2000, quando si è diffuso. È stato pubblicizzato come un modo per risolvere il problema della programmazione parallela. Questo approccio mi è sempre sembrato senza speranza. La memoria transazionale potrebbe solo rendere più semplice la scrittura di strutture dati parallele. Questo, mi sembra, è ciò che ha ottenuto.
Informazioni sulla difficoltà di scrivere codice multi-thread
Alexey: Molto interessante. Sembra esserci una certa barriera tra i programmatori regolari e coloro che possono scrivere codice multi-thread. L'anno scorso ho parlato più volte con persone che stavano implementando alcuni framework algoritmici. Ad esempio, con Martin Thomson, così come con i programmatori che lavorano su librerie multi-thread. (Nota del redattore: Martin Thompson è uno sviluppatore molto famoso, ha scritto и . E lo ha anche fatto alla nostra conferenza Joker 2015, registrazione video . Lui è lo stesso questa conferenza anche disponibile). La sfida principale, dicono, è rendere gli algoritmi veloci e facili da usare. Cioè, stanno cercando di superare questa barriera e di attirare quante più persone possibile in quest'area. Che ne pensate?
Michael: Questo è il problema principale del multithreading: come ottenere prestazioni elevate senza aumentare la complessità del sistema.
Alexey: Perché quando si cerca di evitare la complessità, l’algoritmo diventa meno universale.
Michael: La chiave qui sono le astrazioni progettate correttamente. Mi sembra che questa sia generalmente la cosa principale per i sistemi informatici come campo. Butler Lampson ama usare questo termine e ci chiama “mercanti di astrazioni”. Oggi non esistono tecnologie semplici. I processori che utilizziamo hanno 10 miliardi di transistor: la semplicità è fuori discussione. Allo stesso tempo, l'ISA è molto più semplice del processore, poiché abbiamo lavorato a lungo per fornirgli prestazioni elevate e un'interfaccia relativamente semplice. Ma non tutto va bene neanche con lei. Lo stesso problema riguarda gli acceleratori che stanno apparendo ora sul mercato. Sorgono domande: come realizzare l'interfaccia giusta per la GPU, un meccanismo di crittografia, compressione, un meccanismo di transcodifica, un meccanismo di algebra lineare o anche un FPGA più flessibile. Come creare un'interfaccia che renda lo strumento facile da usare e nasconda la complessità? Non lo eliminerà, ma piuttosto lo nasconderà a un semplice programmatore.
Alexey: A quanto ho capito, abbiamo ancora una barriera nella comprensione delle astrazioni. Prendiamo il modello della memoria: nella nostra fase di sviluppo della scienza e della tecnologia, questa è una delle principali astrazioni. Grazie ad esso, tutti i programmatori sono divisi in due gruppi: la maggior parte sono quelli che non lo capiscono, e la parte più piccola sono quelli che capiscono, o pensano di capire.
Michael: Questa è una buona domanda: qualcuno di noi capisce veramente il modello di memoria?
Vitali: Soprattutto in C++.
Michael: Parla con Hans Boehm qualche volta. È una delle persone più intelligenti che conosco, uno dei massimi esperti di modelli di memoria. Ti dirà subito che ci sono molte cose che non capisce. Ma se torniamo alla questione delle astrazioni, allora, a mio avviso, è stata espressa l'idea più importante nel campo dei modelli di memoria negli ultimi 30 anni . (Nota del redattore: è disponibile l'elenco completo delle pubblicazioni ).
Alexey: La mia domanda è: questa barriera deriva dalla natura stessa del concetto?
Michael: NO. Sarita è giunto alla conclusione che con l'approccio giusto è possibile nascondere con successo tutta la complessità, ottenere prestazioni elevate e fornire al programmatore un'API semplice. E se segui questa API, puoi ottenere una coerenza coerente. Penso che questo sia il modello giusto. Scrivi codice senza conflitti di dati e ottieni coerenza sequenziale. Naturalmente, per ridurre la probabilità di gareggiare, sono necessari strumenti speciali, ma questa è un'altra questione.
Vladimir: Ci sono stati momenti nella tua carriera in cui un problema che sembrava risolto si è improvvisamente trasformato in una catastrofe, o si è scoperto che questo problema era irrisolvibile? Ad esempio, in teoria puoi fattorizzare qualsiasi numero o determinare se un numero è primo. Ma in pratica questo può essere difficile da fare; con l’hardware attuale è difficile fattorizzare i numeri. Ti è successo qualcosa di simile?
Michael: Non ricordo subito nulla del genere. Ci sono stati momenti in cui mi sembrava che non ci fosse più niente da fare in una certa zona, ma poi lì è successo qualcosa di nuovo e interessante. Ad esempio, pensavo che l’area delle code illimitate fosse già giunta a maturazione. Dopo diversi miglioramenti alla coda MNS, non è successo più nulla. E poi Morrison (Adam Morrison) e Afek (Yehuda Afek) hanno inventato . È diventato chiaro che era possibile una coda multi-thread illimitata, dove la maggior parte delle volte c'era solo un'istruzione di recupero e incremento sul percorso critico. E questo ha permesso di ottenere prestazioni migliori di un ordine di grandezza. Non è che non sappiamo che fetch-and-increment è una cosa molto utile. Eric Freudenthal ne scrisse nel suo lavoro sull'Ultracomputer con Allan Gottlieb alla fine degli anni '1980, ma si trattava di code limitate. Morrison e Afek sono stati in grado di utilizzare fetch-and-increment su una coda illimitata.
Nuove architetture. La vittoria della memoria transazionale è vicina?
Vladimir: Stai cercando nuove soluzioni architetturali che potrebbero essere utili per gli algoritmi?
Michael: Naturalmente ci sono molte cose che mi piacerebbe vedere implementate.
Vladimir: Di che tipo, per esempio?
Michael: Prima di tutto, alcune semplici estensioni alla nostra memoria transazionale a livello hardware nei processori Intel e IBM. In particolare, vorrei che il carico e l'archivio non transazionali appena verificatisi fossero immediatamente disponibili all'interno delle transazioni. Portano immediatamente a loop nella sequenza succede-prima, quindi possono essere difficili. Ma se mantieni livelli di astrazione, ci sono molte cose molto interessanti che puoi fare al di fuori della transazione mentre sta accadendo. Non so quanto sarebbe difficile da implementare, ma sarebbe molto utile.
Un'altra cosa utile è caricare la cache dalla memoria remota. Penso che prima o poi questo verrà fatto. Questa tecnologia consentirà la realizzazione di sistemi con memoria disaggregata. Sarebbe possibile mantenere, diciamo, 100 terabyte di memoria non volatile in un rack, e il sistema operativo stesso deciderebbe dinamicamente quali sezioni di quella memoria dovrebbero corrispondere allo spazio degli indirizzi fisici dei processori. Ciò sarebbe estremamente utile per il cloud computing, poiché consentirebbe di fornire grandi quantità di memoria alle attività che ne hanno bisogno. Penso che qualcuno lo farà.
Vitali: Per finire parlando della memoria transazionale, ho un'altra domanda su questo argomento. La memoria transazionale finirà per sostituire le strutture dati multi-thread standard?
Michael: NO. Le transazioni sono un meccanismo speculativo. A livello di programmazione si tratta di blocchi atomici, ma all’interno sono speculazioni. Tale previsione funziona se la maggior parte delle ipotesi sono corrette. Pertanto, la memoria transazionale funziona bene quando i thread difficilmente interagiscono tra loro e devi solo assicurarti che non ci siano interazioni. Ma se un messaggio inizia tra thread, le transazioni sono di scarsa utilità. Lasciatemi spiegare, stiamo parlando del caso in cui le transazioni riguardano l'intera operazione atomica. Possono ancora essere utilizzati con successo come componenti per strutture dati multi-thread. Ad esempio, se hai bisogno di un CAS di tre parole e devi eseguire il multithread di tre piccole cose nel mezzo di un algoritmo veramente multithread che funziona con venti thread contemporaneamente. In generale, le transazioni possono essere utili, ma non eliminano la necessità di progettare adeguatamente strutture dati multi-thread.
Memoria non volatile, Optane DIMM, dispositivi ultraveloci.
Vitali: L'ultima cosa di cui vorrei parlare è l'argomento della tua ricerca attuale: la memoria non volatile. Cosa possiamo aspettarci in questo ambito nel prossimo futuro? Forse conosci qualche implementazione efficace già esistente?
Michael: Non sono un esperto di hardware, so solo quello che leggo nelle notizie e quello che mi dicono i miei colleghi. Tutti hanno già sentito dire che Intel vende , che hanno circa 3 volte la latenza di lettura e 10 volte la latenza di scrittura rispetto alla RAM dinamica. Saranno presto disponibili in versioni a volume molto grande. È divertente pensare che potresti avere un laptop con diversi terabyte di RAM indirizzabile per byte. È probabile che tra 10 anni decideremo di utilizzare questa nuova tecnologia, poiché utilizziamo la DRAM, basta aumentare il volume. Ma grazie all’indipendenza energetica si aprono per noi opportunità completamente nuove. Possiamo modificare radicalmente lo stack di archiviazione in modo che non vi sia separazione tra memoria di lavoro indirizzabile a byte e memoria persistente strutturata a blocchi. Pertanto, non avremo bisogno di serializzare tutto ciò che deve essere trasferito da un programma all'altro in file strutturati a blocchi. Da ciò possiamo derivare molti principi importanti che influenzano i sistemi operativi, gli ambienti runtime e gli archivi dati distribuiti. È molto interessante lavorare in questo settore. Personalmente, è difficile per me prevedere a cosa porterà tutto questo, ma i problemi qui sono estremamente divertenti. Potrebbero esserci cambiamenti rivoluzionari qui, e derivano in modo molto naturale dal lavoro sul multithreading, poiché il ripristino dopo un errore è un processo di "multithreading" accanto al normale funzionamento del sistema.
Il secondo argomento principale su cui sto attualmente lavorando è la gestione dei dispositivi ultraveloci e l'accesso sicuro ai dispositivi dallo spazio utente con controllo delle policy sistemiche. Negli ultimi anni si è osservata la tendenza a spostare l’accesso al dispositivo nello spazio utente. Ciò avviene perché lo stack del kernel TCP-IP non può funzionare su un'interfaccia di rete che necessita di un nuovo pacchetto ogni 5 microsecondi; semplicemente non terrà il passo. Pertanto, i produttori forniscono accesso diretto ai dispositivi. Ciò significa però che il sistema operativo perde il controllo del processo e non è in grado di fornire un accesso adeguato al dispositivo per le applicazioni concorrenti. Il nostro gruppo di ricerca ritiene che questa carenza possa essere evitata. Questo mese pubblicheremo un articolo su questo argomento all'ATC USENIX. È legato al lavoro sulla persistenza, poiché la memoria persistente indirizzabile a byte di lunga durata è, in sostanza, un dispositivo con I/O ultraveloce a cui è necessario accedere nello spazio utente. Questa ricerca rende possibili nuovi approcci ai microkernel, agli exokernel e ad altri tentativi tradizionali di spostare in modo sicuro le funzionalità dal kernel del sistema operativo allo spazio utente.
Vladimir: La memoria indirizzabile in byte è eccezionale, ma esiste una limitazione fisica: la velocità della luce. Ciò significa che ci sarà inevitabilmente un ritardo nell'interazione con il dispositivo.
Michael: Assolutamente giusto.
Vladimir: La capacità sarà sufficiente per far fronte ai nuovi carichi?
Michael: Questa è un'ottima domanda, ma mi sarà difficile rispondere. L'idea dell'elaborazione in memoria esiste da parecchio tempo, è molto interessante, ma anche molto complessa. Non ho lavorato in quest'area, ma sarebbe fantastico se si facessero delle scoperte lì. Temo di non avere altro da aggiungere.
Vladimir: C'è un altro problema. Sarà impossibile inserire nella CPU nuove quantità di RAM significativamente più grandi. Pertanto, a causa di limitazioni fisiche, questa RAM deve essere isolata.
Michael: Tutto dipende dal numero di difetti nella produzione dei circuiti integrati. Se fosse possibile creare wafer semiconduttori interamente privi di difetti, sarebbe possibile ricavarne un intero microcircuito. Ma ora non sappiamo come realizzare microcircuiti più grandi di un francobollo.
Vladimir: Ma parliamo pur sempre di taglie enormi, di centimetri. Ciò ha inevitabilmente un impatto sulla latenza.
Michael: SÌ. Non c'è niente che puoi fare riguardo alla velocità della luce.
Vladimir: Purtroppo.
La prossima grande tendenza. Doppie strutture dati. Idra.
Vitali: Da quanto ho capito, cogli le nuove tendenze molto rapidamente. Sei stato uno dei primi a lavorare con la memoria transazionale e uno dei primi a lavorare con la memoria non volatile. Quale pensi sarà il prossimo grande trend? O forse è un segreto?
Michael: A dire il vero, non lo so. Spero di riuscire a notare quando succede qualcosa di nuovo. Non ho avuto la fortuna di inventare un nuovo campo da solo, ma ho avuto un po' di fortuna e ho potuto iniziare a lavorare abbastanza presto in nuovi campi creati da altri. Spero di poterlo fare in futuro.
Alexey: L'ultima domanda in questa intervista riguarderà il tuo rendimento all'Hydra e le tue attività a scuola. Se ho capito bene, la relazione a scuola riguarderà gli algoritmi senza blocchi e alla conferenza le doppie strutture di dati. Potresti dire qualche parola su questi rapporti?
Michael: In parte abbiamo già toccato con voi questi argomenti in questa intervista. Riguarda il lavoro che ho fatto con il mio studente Bill Scherer. Ha scritto una tesi su di esso, e anche Doug Lee ha contribuito ad esso, e alla fine è diventato parte delle code sincrone multi-thread nella libreria Java. Supponiamo che la struttura dati venga letta e scritta senza blocchi, ovvero che ogni operazione abbia un numero limitato di istruzioni sul percorso critico. Se provi a rimuovere dati da un contenitore vuoto o provi a rimuovere determinati dati che non si trovano in questo contenitore, verrai immediatamente informato che ciò non può essere fatto. Ma questo comportamento potrebbe non essere accettabile se il thread ha davvero bisogno di questi dati. Quindi la prima cosa che mi viene in mente è creare un ciclo che chiederà costantemente se sono comparsi i dati necessari. Ma poi ci sono interferenze per tutti gli altri. Inoltre, con questo approccio, puoi attendere 10 minuti, quindi arriverà qualche altro thread e riceverà prima accidentalmente i dati necessari. Le strutture dati doppie non hanno ancora blocchi, ma consentono ai thread di attendere correttamente. Il termine "doppio" significa che la struttura contiene dati o richieste di dati, chiamiamoli anti-dati. Pertanto, se provi a recuperare qualcosa da un contenitore vuoto, verrà invece inserita una richiesta nel contenitore. Ora il thread può attendere una richiesta senza disturbare nessun altro. Inoltre, la struttura dei dati assegna priorità alle richieste in modo che, una volta ricevute, le passino alla persona giusta. Il risultato è un meccanismo non bloccabile che ha ancora una specifica formale e buone prestazioni nella pratica.
Alexey: Quali sono le tue aspettative da questa struttura dati? Migliorerà le prestazioni in tutti i casi comuni o è più adatto a determinate situazioni?
Michael: È utile se, in primo luogo, hai bisogno di un contenitore senza blocco e, in secondo luogo, devi attendere in una situazione in cui devi recuperare dati dal contenitore che non si trova al suo interno. Per quanto ne so, il nostro framework fornisce un comportamento ottimale quando queste due condizioni sono soddisfatte. Pertanto in questi casi ne consiglio l'utilizzo. Il vantaggio principale delle strutture dati senza blocco è che evitano problemi di prestazioni. E l'attesa è molto importante in molti algoritmi se i dati vengono trasferiti da un thread all'altro.
Vitali: Faccio chiarezza: parlerete della stessa cosa sia a scuola che al convegno?
Michael: A scuola in generale sulle strutture dati multi-thread, con i principi base delineati all'inizio della lezione. Presumo che il pubblico sappia cosa sono i thread e abbia familiarità con i lucchetti. Sulla base di queste conoscenze di base, parlerò di strutture dati prive di blocchi. Darò una panoramica dei problemi più importanti in quest'area, toccando argomenti come la gestione della memoria. Non penso che ci sarà qualcosa di più complicato della coda della SM.
Alexey: Hai intenzione di insegnare le strutture duali dei dati alla fine della tua lezione a scuola?
Michael: Li citerò, ma non mi soffermerò molto su di essi. A loro sarà dedicato il rapporto dell'Hydra. Riguarderà il progetto che alla fine è arrivato in Java, oltre alla collaborazione con Joe Israelevich per creare una doppia variante della coda LCRQ e alla creazione di un progetto quasi universale per strutture di dati doppie.
Alexey: Quindi la lezione a scuola può essere consigliata ai principianti, e la lezione sulle strutture dati doppie su Hydra - per chi ha già un po' di esperienza?
Michael: Correggimi se sbaglio, ma il pubblico di Hydra sarà piuttosto diversificato, inclusi molti esperti Java e in generale persone che non sono specificatamente coinvolte nella programmazione multi-thread.
Vitali: Si è vero.
Alexey: Almeno lo speriamo.
Michael: In questo caso mi troverò di fronte allo stesso problema con cui abbiamo iniziato questa intervista: come realizzare un resoconto sufficientemente ricco di dettagli tecnici e accessibile a tutti gli ascoltatori.
Vitali: Farai una relazione nello stesso modo in cui tieni le lezioni? Cioè parlare con il pubblico e adattarsi alla situazione?
Michael: Temo che non funzionerà così, perché il rapporto avrà delle diapositive. Le diapositive sono importanti quando gli ascoltatori parlano inizialmente lingue diverse. Molte persone avranno difficoltà a capirmi in inglese, soprattutto se parlo troppo velocemente. Ho scelto questi argomenti perché mi ha chiesto di parlare di strutture dati senza blocchi alla SPTDC School; e poi avevo bisogno di un rapporto per una conferenza di un gruppo di utenti Java e volevo scegliere qualcosa che potesse interessare specificamente ai programmatori Java. Il modo più semplice era parlare di quelle cose della libreria Java a cui avevo contribuito in un modo o nell'altro.
Alexey: Partiamo dal presupposto che il pubblico di Hydra sappia già qualcosa sulla programmazione senza blocchi e forse abbia qualche esperienza in questo settore. Ma questa è solo un'ipotesi; la situazione sarà più chiara nel corso della conferenza stessa. Comunque, grazie per il tuo tempo. Sono sicuro che l’intervista sarà molto interessante per i nostri lettori. Molte grazie!
Vitali: Grazie.
Michael: Sarò felice di incontrarti a San Pietroburgo.
Alexey: Anche noi, abbiamo una bella città. Sei mai stato qui?
Michael: No, non sono mai stato in Russia. Ma San Pietroburgo è sempre stata nella lista dei posti dove non sono ancora stata, ma dove voglio davvero andare, quindi sono stata molto contenta dell'invito.
Alexey: A proposito, avremo un programma di escursioni per i relatori. Grazie mille per l'intervista e buona giornata!
Puoi continuare la tua conversazione con Michael alla conferenza Hydra 2019, che si terrà l'11 e il 12 luglio 2019 a San Pietroburgo. Verrà con un rapporto . I biglietti possono essere acquistati .
Fonte: habr.com