- o propietario de dous. O primeiro é para o traballo (Brown University) e a segunda, máis recente, - (Universidade Tecnolóxica de Virginia). O Premio Dijkstra concédese a obras cuxa significación e influencia se notan dende hai polo menos dez anos e, obviamente, Maurice é un dos máis famosos especialistas na materia. Actualmente é profesor na Universidade de Brown e ten logros de longo parágrafo. Agora dedícase á investigación de blockchain no contexto da computación distribuída clásica.
Anteriormente, Maurice xa veu a Rusia para SPTCC () e fixo unha excelente reunión da comunidade de desenvolvedores Java de JUG.ru en San Petersburgo ().
Este habrapost é unha gran entrevista con Maurice Herlihy. Nel trata os seguintes temas:
- Interacción entre a academia e a industria;
- Fundación para a investigación blockchain;
- De onde veñen as ideas innovadoras? Influencia da popularidade;
- doutoramento baixo a dirección de Barbara Liskov;
- O mundo está á espera de múltiples núcleos;
- Novo mundo, novos problemas. NVM, NUMA e piratería de arquitectura;
- Compiladores vs CPUs, RISC vs CISC, memoria compartida vs paso de mensaxes;
- A arte de escribir código fráxil multi-fíos;
- Como ensinar aos estudantes a escribir código complexo multiproceso;
- Nova edición do libro "The Art of Multiprocessor Programming";
- Como se inventou a memoria transaccional?
- Por que paga a pena investigar no campo da computación distribuída;
- Detívose o desenvolvemento de algoritmos e como vivir;
- Traballa na Universidade de Brown;
- A diferenza entre investigación universitaria e corporativa;
- Hidra e SPTDC.
As entrevistas son realizadas por:
Vitali Aksenov — actualmente posdoctoral en IST Austria e empregado do Departamento de Tecnoloxías Informáticas da ITMO University. Dedícase á investigación no campo da teoría e práctica das estruturas de datos competitivas. Antes de unirse a IST, recibiu o seu doutoramento na Universidade Diderot de París e na Universidade ITMO baixo a dirección do profesor Petr Kuznetsov.
Alexei Fedorov é produtor de JUG Ru Group, unha empresa rusa que organiza conferencias para desenvolvedores. Alexey participou na preparación de máis de 50 conferencias e o seu currículo contén desde o posto de enxeñeiro de desenvolvemento en Oracle (JCK, Java Platform Group) ata o posto de programador en Odnoklassniki.
Vladimir Sitnikov é enxeñeiro en Netcracker. Desde hai dez anos traballa no rendemento e escalabilidade do sistema operativo NetCracker, software que utilizan os operadores de telecomunicacións para automatizar os procesos de xestión de equipos de rede e redes. Interesado en problemas de rendemento de Java e Oracle Database. Autor de máis dunha ducia de melloras de rendemento no controlador JDBC oficial de PostgreSQL.
Interacción entre a academia e a industria
Alexey: Maurice, levas traballando no mundo académico durante moito tempo e a primeira pregunta é sobre a interacción entre a academia e a industria. Poderías contarnos como cambiaron as interaccións entre eles ultimamente? Que foi hai 20-30 anos e que está a pasar agora?
Maurice: Sempre tentei traballar en estreita colaboración con empresas comerciais porque teñen retos interesantes. Por regra xeral, non están moi interesados nin en publicar os seus resultados nin en explicacións detalladas dos seus problemas á comunidade mundial. Só lles interesa resolver estes problemas. Traballei para algunhas destas empresas durante un tempo. Estiven cinco anos traballando a tempo completo nun laboratorio de investigación da Digital Equipment Corporation, que adoitaba ser unha importante empresa informática. Traballei un día á semana en Sun, en Microsoft, en Oracle, traballei un pouco en Facebook. Agora voume ir de vacacións sabáticas (un profesor dunha universidade americana ten permiso para tomarse esas vacacións durante un ano aproximadamente unha vez cada seis anos) e traballar en , esta é unha empresa de criptomonedas en Boston. Traballar estreitamente coas empresas sempre foi un pracer, porque así aprendes cousas novas e interesantes. En xeral, pode ser a primeira ou a segunda persoa en publicar un artigo sobre un tema elixido, en lugar de mellorar aos poucos as solucións aos problemas nos que xa están traballando todos os demais.
Alexey: Podes contarnos máis sobre como ocorre isto?
Maurice: Por suposto. Xa sabes, cando estaba en Digital Equipment Corporation, eu e Elliot Moss, inventamos a memoria transaccional. Foi un período moi fructífero no que todo o mundo comezou a interesarse polas tecnoloxías da información. Concurrencia incluída, aínda que aínda non existían sistemas multinúcleo. Nos tempos de Sun e Oracle, traballei moito en estruturas de datos paralelas. En Facebook, estiven implicado no seu proxecto blockchain, do que non podo falar, pero espero que se faga público pronto. O ano que vén, en Algorand, traballarei nun equipo de investigación que estuda os contratos intelixentes.
Alexey: Nos últimos anos, a cadea de bloques converteuse nun tema moi popular. Axudará á túa investigación? Quizais facilitará a obtención de subvencións ou o acceso aos recursos das empresas que operan no sector?
Maurice: Xa recibín unha pequena subvención da Fundación Ethereum. A popularidade da cadea de bloques é moi útil para inspirar aos estudantes a traballar neste campo. Están moi interesados niso e contentos de participar, pero ás veces non se dan conta de que unha investigación que por fóra parece tentadora resulta ser un traballo moi duro. Non obstante, estou moi feliz de usar toda esta mística arredor da cadea de bloques, que axuda a atraer estudantes.
Pero iso non é todo. Estou no consello asesor de varias startups de blockchain. Algúns poden ter éxito, outros non, pero sempre é moi interesante ver as súas ideas, estudalas e aconsellar á xente. O máis emocionante é cando avisas á xente que non faga algo. Moitas cousas parecen unha boa idea ao principio, pero son realmente?
Fundación para a investigación blockchain
Vitaly: Algunhas persoas pensan que a cadea de bloques e os seus algoritmos son o futuro. E outras persoas din que só é outra burbulla. Podes compartir a túa opinión sobre este asunto?
Maurice: Moito do que está a suceder no mundo da cadea de bloques non funciona correctamente, algúns son só estafas, moitas cousas están sobrevaloradas. Non obstante, creo que hai unha base científica sólida para estes estudos. O feito de que o mundo da cadea de bloques estea cheo de divisións ideolóxicas mostra o nivel de entusiasmo e dedicación. Por outra banda, non é especialmente beneficioso para a investigación científica. Agora ben, se publicas un artigo que fala das deficiencias dun determinado algoritmo, a reacción recibida non sempre é totalmente científica. Moitas veces as persoas expresan as súas emocións. Creo que tal exageración nesta área pode parecer atractiva para algúns, pero ao final, hai verdadeiros problemas científicos e de enxeñería que aínda teñen que ser abordados. Aquí hai moita informática.
Vitaliy: Entón estás tentando sentar as bases para a investigación blockchain, non?
Maurice: Estou tentando sentar as bases dunha disciplina sólida, científica e matemáticamente sólida. E parte do problema é que ás veces hai que contradicir algunhas das posicións excesivamente duras doutras persoas, para ignoralas. Ás veces a xente pregunta por que traballo nun campo no que só lles interesa aos terroristas e narcotraficantes. Tal reacción é tan sen sentido como o comportamento dos seguidores que repiten a cega as túas palabras. Creo que a verdade está nalgún lugar no medio. Blockchain aínda non ten un impacto profundo na sociedade e na economía global. Pero, probablemente, isto non ocorrerá grazas á tecnoloxía moderna. As tecnoloxías modernas desenvolveranse e o que se chamará blockchain no futuro será moi importante. Quizais nin sequera pareza a blockchains modernas, esa é unha pregunta aberta.
Se a xente inventa novas tecnoloxías, seguirá chamándoo blockchain. Quero dicir, do mesmo xeito que o Fortran de hoxe non ten nada que ver coa lingua Fortran dos anos 1960, pero todo o mundo segue chamándolle Fortran. O mesmo para UNIX. O que se chama "blockchain" aínda está por facer a súa revolución. Pero dubido que esta nova cadea de bloques sexa como o que a todos lle gusta usar hoxe.
De onde veñen as ideas innovadoras? Influencia da popularidade
Alexey: A popularidade da cadea de bloques levou a novos resultados desde o punto de vista científico? Máis interacción, máis estudantes, máis empresas da zona. Hai xa algún resultado deste crecemento da popularidade?
Maurice: Intereseime por isto cando alguén me entregou un folleto oficial dunha empresa que acababa de recadar bastantes cartos. Ela escribiu sobre co que estou máis que familiarizado. O escrito no folleto era claramente tecnicamente incorrecto. A xente que escribiu isto non entendía moi ben o modelo detrás do problema... e aínda así esta empresa recadou moito diñeiro. Posteriormente, a empresa substituíu silenciosamente este folleto por unha versión moito máis correcta, e non vou dicir cal era o nome desta empresa. Aínda existen e están facendo moi ben. Este caso convenceume de que, en primeiro lugar, a cadea de bloques é só unha forma de computación distribuída. En segundo lugar, o limiar de entrada (naquel momento, hai catro anos) era bastante baixo. A xente que traballaba nesta área era moi enérxica e intelixente, pero non lía artigos científicos. Intentaron reinventar cousas coñecidas e fixérono mal. Hoxe o drama reduciuse.
Alexey: É moi interesante, porque hai uns anos tiñamos unha tendencia diferente. É un pouco como o desenvolvemento front-end, onde os desenvolvedores de interfaces de navegador reinventaron tecnoloxías enteiras que xa eran populares no back-end daquela: construír sistemas, integración continua e cousas así.
Maurice: Estou de acordo. Pero isto non é sorprendente, porque as ideas verdadeiramente innovadoras sempre veñen de fóra da comunidade establecida. É improbable que os investigadores establecidos, especialmente as autoridades académicas, fagan algo verdadeiramente innovador. É doado escribir un informe para a próxima conferencia sobre como melloraches lixeiramente os resultados do teu traballo pasado. Ir a unha conferencia, reunirse cos amigos, falar das mesmas cousas. E as persoas que irrompen con ideas innovadoras case sempre veñen de fóra. Non saben as regras, non saben o idioma, pero aínda así... Se estás dentro dunha comunidade consolidada, aconsello que prestes atención ás cousas novas, a algo que non encaixa no grande. imaxe. En certo sentido, pódese tentar combinar desenvolvementos externos máis fluídos con técnicas que xa entendemos. Como primeiro paso, tenta crear unha base científica, e despois modificala para que se poida aplicar a novas ideas innovadoras. Creo que a cadea de bloques é xenial para o papel dunha nova idea innovadora.
Alexei: Por que cres que está a pasar isto? Porque a xente "de fóra" non ten ningunha barreira específica inherente á comunidade?
Maurice: Hai un patrón aquí. Se le a historia dos impresionistas na pintura e na arte en xeral, nalgún momento os artistas famosos rexeitaron o impresionismo. Dixeron que era unha especie de puerilidade. Unha xeración máis tarde, esta forma de arte previamente rexeitada converteuse no estándar. O que vexo no meu campo: os inventores da cadea de bloques non estaban interesados no poder, en liquidar publicacións e índices de citas, só querían facer algo bo. E así sentáronse e comezaron a facelo. Carecían dunha certa profundidade técnica, pero iso é arranxable. É moito máis difícil dar con novas ideas creativas que corrixir e amplificar as que non son suficientemente maduras. Grazas a estes inventores, agora teño algo que facer!
Alexey: Isto é semellante á diferenza entre startups e proxectos legados. Herdamos moitas limitacións de pensamento, barreiras, requisitos especiais, etc.
Maurice: Unha boa analoxía é a computación distribuída. Pense na cadea de bloques como se fose unha startup e informática distribuída como unha gran empresa establecida. A informática distribuída está en proceso de compra e fusión coa cadea de bloques.
Doutoramento baixo Barbara Liskov
Vitaliy: Aínda temos moitas preguntas! Estivemos investigando a túa biografía e atopamos un dato interesante sobre o teu doutoramento. Si, foi hai moito tempo, pero o tema parece ser importante. Recibiches o teu doutoramento baixo a supervisión de ! Barbara é moi famosa na comunidade de desenvolvemento da linguaxe de programación, e unha persoa moi famosa en xeral. É lóxico que a túa investigación fose no campo das linguaxes de programación. Como cambiaches á computación paralela? Por que decidiches cambiar de tema?
Maurice: Nese momento, Barbara e o seu grupo estaban só mirando a computación distribuída, que era unha idea moi nova. Tamén houbo quen dixo que a computación distribuída é unha tontería, a comunicación entre ordenadores carece de sentido. Unha das cuestións consideradas na computación distribuída, que os distingue da computación centralizada, é a tolerancia a fallos. Despois de moitas investigacións, decidimos que nunha linguaxe de programación para computación distribuída, cómpre ter algo así como transaccións atómicas, porque nunca pode estar seguro de que unha chamada remota terá éxito. Unha vez que teñas transaccións, hai un problema de control de concorrencia. Despois traballouse moito na obtención de estruturas de datos transaccionais moi paralelas. Despois, cando me graduei, fun e comezou a buscar un tema para traballar. Ocorréuseme que a informática pasara de ordenadores individuais a redes de ordenadores. Unha continuación natural do progreso serían os multiprocesadores: a palabra "multi-core" non existía entón. Pensei: cal é o equivalente ás transaccións atómicas para un sistema multinúcleo? Definitivamente non transaccións comúns, porque son demasiado grandes e pesadas. E así foi como se me ocorreu a idea e así foi como se me ocorreu toda a sincronización sen esperas. Foi un intento de responder á pregunta de cal é o análogo das transaccións atómicas para un sistema multiprocesador con memoria compartida. A primeira vista, esta obra pode parecer ben diferente, pero en realidade é unha continuación do mesmo tema.
O mundo á espera de varios núcleos
Vitaly: Mencionaches que había moi poucos ordenadores multinúcleo nese momento, non?
Maurice: Simplemente non existían. Había varios multiprocesadores denominados simétricos, que basicamente estaban conectados ao mesmo bus. Non funcionou moi ben, porque cada vez que unha nova empresa creaba algo así, Intel lanzaba un único procesador que superaba ao multiprocesador.
Alexei: Non quere dicir isto que naqueles tempos antigos, era máis un estudo teórico?
Maurice: Non foi un estudo teórico, senón especulativo. Todo isto non se trataba de traballar con moitos teoremas, senón que formulamos hipóteses sobre a arquitectura que non existía nese momento. Para iso serve a investigación! Ningunha empresa tería feito isto, todo era algo dun futuro afastado. De feito, isto foi ata 2004, cando apareceron auténticos procesadores multinúcleo. Debido ao feito de que os procesadores se sobrequentan, pode facer que o procesador sexa aínda máis pequeno, pero non pode facelo máis rápido. Debido a isto, houbo unha transición a arquitecturas multinúcleo. E entón significou que de súpeto houbo un uso para todos os conceptos que tiñamos desenvolvido no pasado.
Alexey: Por que cres que os procesadores multinúcleo apareceron só na década de XNUMX? Entón, por que tan tarde?
Maurice: É debido a limitacións de hardware. Intel, AMD e outras compañías son moi boas para aumentar a velocidade do procesador. Cando nalgún momento os procesadores quedaron o suficientemente pequenos como para que xa non puidesen aumentar a velocidade do reloxo porque os procesadores comezarían a queimarse. Podes facelos máis pequenos, pero non máis rápidos. O que está no seu poder: en lugar dun procesador moi pequeno, cabe oito, dezaseis ou trinta e dous procesadores no mesmo volume da caixa, onde só cabía un. Agora tes multithreading e comunicación rápida entre eles porque comparten cachés. Pero non podes facelos correr máis rápido: hai un límite de velocidade moi específico. Seguen mellorando pouco a pouco, pero non tanto. As leis da física puxéronse no camiño.
Novo mundo, novos problemas. NUMA, NVM e piratería de arquitectura
Alexei: Parece moi razoable. Cos novos procesadores multinúcleo xurdiron novos problemas. Vostede e os seus compañeiros esperaban estes problemas? Quizais os estudaches con antelación? Nos estudos teóricos moitas veces non é moi doado predicir tales cousas. Cando se produciron problemas, ata que punto cumpriron coas túas expectativas e as dos teus compañeiros? Ou eran novos e ti e os teus compañeiros tiveches que dedicar moito tempo a resolver problemas a medida que ían xurdindo?
Vitaliy: Eu engadirei á pregunta de Alexey: prediches correctamente a arquitectura dos procesadores mentres estudabas teoría?
Maurice: Non todo o 100%. Pero creo que os meus colegas e eu fixemos un bo traballo ao predicir o multinúcleo de memoria compartida. Creo que predixemos correctamente as dificultades para deseñar estruturas de datos paralelas que funcionen sen bloqueos. Tales estruturas de datos foron importantes para moitas aplicacións, aínda que non para todas, pero moitas veces realmente necesitas unha estrutura de datos sen bloqueo. Cando os inventamos, moitos argumentaban que isto é unha tontería, que todo funciona ben con peches. Previmos bastante ben que habería solucións preparadas para moitos problemas de programación e problemas de estrutura de datos. Tamén houbo problemas máis complexos, como – Acceso desigual á memoria. De feito, nin sequera se consideraron ata a invención dos procesadores multinúcleo porque eran demasiado específicos. A comunidade investigadora traballou en cuestións que en xeral eran previsibles. Algúns problemas de hardware asociados a arquitecturas específicas tiveron que agardar nas ás - de feito, a aparición destas arquitecturas. Por exemplo, ninguén realmente traballou en estruturas de datos específicas da GPU porque a GPU non existía daquela. Aínda que se traballou moito , estes algoritmos estaban listos para o seu uso en canto apareceu o hardware correcto. Non obstante, é imposible prever todo.
Alexey: Se entendo ben, NUMA é unha especie de compromiso entre custo, rendemento e algunhas outras cousas. Algunha idea de por que NUMA chegou tan tarde?
Maurice: Creo que NUMA existe por un problema co hardware utilizado para facer memoria: canto máis afastados estean os compoñentes, máis lento se accede a eles. Por outra banda, o segundo valor desta abstracción é a uniformidade da memoria. Polo tanto, unha das características da computación paralela é que todas as abstraccións están lixeiramente rotas. Se o acceso fose perfectamente uniforme, toda a memoria sería equidistante, pero isto é económicamente imposible, e quizais ata fisicamente. Así xorde este conflito. Se escribes o teu programa coma se a memoria fose uniforme, o máis probable é que sexa correcto. No sentido de que non dará respostas erróneas. Pero a actuación das súas estrelas desde o ceo non vai coller. Do mesmo xeito, se escribes sen comprender a xerarquía dos cachés, o bloqueo en si será correcto, pero podes esquecer o rendemento. En certo sentido, tes que escribir programas que vivan encima dunha abstracción moi sinxela, pero tes que ser máis intelixente que a xente que che deu esa abstracción: tes que saber que baixo a abstracción hai certa xerarquía da memoria, que hai un autobús entre ti e esta memoria, etc. Así, existe certo conflito entre abstraccións que son útiles por si mesmas, o que nos leva a problemas moi concretos e pragmáticos.
Vitaliy: E o futuro? Podes predecir como se desenvolverán os procesadores? Hai unha idea de que unha das respostas é a memoria transaccional. Probablemente teñas algo máis en stock.
Maurice: Hai un par de grandes retos por diante. Unha delas é que a memoria coherente é unha abstracción marabillosa, pero comeza a romperse en casos especiais. Así, por exemplo, NUMA é un exemplo vivo de algo onde podes seguir finxindo que existe unha memoria uniforme. En realidade - non, a actuación fará chorar. Nalgún momento, os arquitectos terán que abandonar a idea dunha arquitectura de memoria unificada, non podes finxir para sempre. Necesitaranse novos modelos de programación que sexan o suficientemente fáciles de usar e o suficientemente potentes como para que o hardware subxacente sexa eficiente. Este é un compromiso moi difícil, porque se lles mostras aos programadores a arquitectura que realmente se usa no hardware, volverán tolos. É demasiado complicado e non portátil. Se presentas unha interface demasiado sinxela, o rendemento será deficiente. Así, haberá que facer moitos compromisos moi difíciles para proporcionar modelos de programación útiles aplicables a procesadores multinúcleos realmente grandes. Non estou seguro de que ninguén máis que un estreito especialista sexa capaz de programar nun ordenador de 2000 núcleos. E a non ser que esteas facendo informática moi especializada ou científica, criptografía ou o que sexa, aínda non está nada claro como facelo ben.
Outra dirección similar son as arquitecturas especializadas. Os aceleradores gráficos existen dende hai moito tempo, pero xa se converteron nun exemplo clásico de como se pode tomar un tipo de cálculo especializado e executalo nun chip dedicado. Isto engade os seus propios retos: como se comunica con tal dispositivo, como o programa. Hai pouco traballei en tarefas no campo . Colles un pequeno procesador e pégalo a un gran anaco de memoria para que a memoria funcione á velocidade da caché L1 e, a continuación, comunícase cun dispositivo como - o procesador está ocupado cargando novas tarefas no seu núcleo de memoria. O desenvolvemento de estruturas de datos e protocolos de comunicación para este tipo de cousas é outro exemplo interesante. Así, os procesadores e hardware especializados estarán suxeitos a melloras durante bastante tempo.
Alexey: Que pasa coa memoria non volátil ()?
Maurice: Ah, ese é outro gran exemplo! NVM cambiará moito a forma en que miramos cousas como as estruturas de datos. A memoria non volátil, en certo sentido, promete realmente acelerar as cousas. Pero non vai facer a vida máis fácil, porque a maioría dos procesadores, cachés e rexistros aínda son volátiles. Cando se inicia despois dun accidente, o seu estado e o estado da súa memoria non serán exactamente os mesmos que antes do accidente. Estou moi agradecido ás persoas implicadas en NVM: durante moito tempo, os investigadores terán algo que facer, tratando de descubrir as condicións correctas. Os cálculos son correctos se poden sobrevivir a un fallo no que se perden o contido das cachés e rexistros, pero a memoria principal permanece intacta.
Compiladores vs CPU, RISC vs CISC, memoria compartida vs paso de mensaxes
Vladimir: Que pensas sobre o dilema entre compiladores e procesadores en canto ao conxunto de instrucións? Para explicar para os que non estean na materia: se pasamos a memoria desigual ou algo así, poderiamos aplicar un conxunto de instrucións moi sinxelo e pedirlle ao compilador que xere código complexo que poida aproveitar as vantaxes. Ou podemos ir por outro lado: implementar instrucións complexas e pedirlle ao procesador que reordene as instrucións e faga outras manipulacións con elas. Que opinas diso?
Maurice: Realmente non teño unha resposta a esa pregunta. Este debate leva catro décadas. Houbo un tempo entre conxunto de comandos e as guerras civís foron libradas por un conxunto de equipos. Durante un tempo, a xente de RISC gañou, pero entón Intel reconstruíu os seus motores para que se utilizase un conxunto de instrucións reducido dentro e o completo exportouse fóra. Quizais este sexa un tema no que cada nova xeración debe atopar os seus propios compromisos e tomar as súas propias decisións. É moi difícil prever cal destas cousas sairá mellor. Entón, calquera predición que faga será verdadeira durante un certo período de tempo, e despois volverá ser falsa durante un tempo, e despois volverá ser verdadeira.
Alexey: ¿Que tan común é para a industria en xeral que algunhas ideas gañen durante varias décadas e perdan nas próximas? Hai outros exemplos de tales cambios periódicos?
Maurice: No campo da computación distribuída, hai xente que cre e persoas que cren . Orixinalmente na computación distribuída, a computación paralela significa o paso de mensaxes. Entón alguén descubriu que a memoria compartida facilitaba moito a programación. O outro lado dixo que a memoria compartida é demasiado complicada, porque necesitan bloqueos e similares, polo que paga a pena pasar a idiomas onde só existe o paso de mensaxes. Alguén mirou o que saíu e di: “Guau, esta implementación de mensaxería semella moito á memoria compartida, porque creas moitos, moitos destes pequenos módulos, envíanse mensaxes entre si e todos eles. , - imos mellorar unha base de datos de memoria compartida!". Todo isto repítese unha e outra vez, e é imposible dicir que unha das partes teña unha razón inequívoca. Un bando sempre dominará, porque en canto un case gaña, a xente inventa unha e outra vez formas de mellorar o outro.
A arte de escribir código fráxil multi-fíos
Alexei: Isto é moi interesante. Por exemplo, cando escribimos código, independentemente da linguaxe de programación, normalmente temos que crear abstraccións como celas que se poden ler e escribir. Pero de feito, nalgún nivel físico, pode parecer enviar unha mensaxe nun bus de hardware entre diferentes ordenadores e outros dispositivos. Resulta que hai traballo nos dous niveis de abstracción á vez.
Maurice: É absolutamente certo que a memoria compartida baséase no paso de mensaxes: buses, cachés, etc. Pero é difícil escribir programas usando o paso de mensaxes, polo que o hardware mente deliberadamente, finxindo que tes algún tipo de memoria uniforme. Isto facilitaralle a escritura de programas sinxelos e correctos antes de que o rendemento comece a baixar. Despois dirás: parece que é hora de facer amizade co caché. E é entón cando comezas a preocuparte pola localización da caché, e despois imos. En certo sentido, estás a romper a abstracción: sabes que non é só unha memoria plana e uniforme, e que vas usar ese coñecemento para escribir programas compatibles coa memoria caché. Isto é o que tes que facer nas tarefas reais. Este conflito entre a simple abstracción que se lle deu e a implementación terriblemente complexa do hardware subxacente é onde cada un fai o seu propio compromiso. Teño un libro sobre multiprocesamento e sincronización, e un día ía escribir un capítulo sobre estruturas de datos en java.util.concurrent. Se os miras, cousas como Estas son obras de arte sorprendentes. (Nota do editor: aqueles que estean familiarizados coa linguaxe Java deberían polo menos botar unha ollada á implementación ConcurrentSkipListMap, Podes consultar as ligazóns para и ). Pero dende o meu punto de vista, sería irresponsable ensinalos aos estudantes, porque unha estrutura de datos deste tipo é unha especie de tipo nun circo que corre sobre unha corda floja sobre un foso de osos. Se cambias nin sequera un pequeno detalle, toda a estrutura colapsarase. Este código é moi rápido e elegante só porque está perfectamente escrito, pero o máis mínimo cambio levará a un fracaso total. Se dou este código como exemplo aos estudantes, inmediatamente dirán: Eu tamén podo facelo! E entón algún avión caerá ou estoupará un reactor nuclear, e será culpa miña que non lles dei demasiada información no momento oportuno.
Alexey: Cando era un pouco máis novo, moitas veces intentei estudar o código fonte de Doug Lee, por exemplo, java.util.concurrent, porque é de código aberto, é moi doado atopalo e tentar comprender o que está a suceder alí. Non resultou moi ben: moitas veces, non está completamente claro por que Doug decidiu facer algo deste xeito, cando todos os demais o fan de forma diferente. Como explicas estas cousas aos teus alumnos? Existe unha forma correcta de describir os detalles específicos dun algoritmo hardcore, por exemplo? Como o fas?
Maurice: Os profesores de debuxo teñen un cliché que lembran primeiro: se queres debuxar como Picasso, primeiro debes aprender a debuxar debuxos sinxelos e realistas, e só cando coñeces as regras podes comezar a rompelas. Se comezas inmediatamente por romper as regras, tes un desastre. En primeiro lugar, ensino aos estudantes a escribir código sinxelo e correcto sen preocuparse polo rendemento. Estou dicindo que hai problemas de tempo complexos á espreita, así que non te preocupes polos cachés, non te preocupes polos modelos de memoria, só asegúrate de que todo funcione correctamente. Xa é bastante difícil: a programación moderna non é fácil por si só, especialmente para os novos estudantes. E cando teñen unha intuición sobre como escribir programas correctos, digo: mira estas dúas implementacións de spinlock: unha é moi lenta, e a segunda tampouco é moi boa, pero xa mellor. Porén, matematicamente estes dous algoritmos son iguais. De feito, un deles usa a localidade da caché. Un deles xira en datos almacenados na caché local e o outro realiza repetidamente operacións que pasan polo autobús. Non podes escribir código eficiente se non o entendes, se non sabes como romper a abstracción e mirar a estrutura subxacente. Pero non poderás comezar a facelo de inmediato. Hai xente que comeza a facelo de inmediato e cre no seu propio xenio, normalmente acaba mal porque non entende os principios. Ninguén debuxa como Picasso nin escribe programas como Doug Lee, recén saído da universidade, na súa primeira semana. Leva anos chegar a este nivel de coñecemento.
Alexey: Resulta que divides o problema en dúas partes: a primeira é a corrección, a segunda é o rendemento?
Maurice: Exactamente. E, por esa orde. Parte do problema é que os novos estudantes non se dan conta de que a corrección é difícil de conseguir. Din a primeira vista: isto é obviamente correcto, só queda aceleralo. Entón, ás veces falo sobre un algoritmo inherentemente incorrecto como se fose correcto.
Como ensinar aos estudantes a escribir código complexo multiproceso
Alexei: Só para ver se poden sentir o truco?
Maurice: Sempre che aviso de antemán de que ás veces se me ocorren os algoritmos equivocados. Non debes enganar á xente. Suxiro que sexan escépticos sobre a información. Se digo algo e digo: "mira, isto é obviamente correcto" - este é un sinal de que nalgún lugar están intentando enganarte e deberías comezar a facer preguntas. A continuación, intento animar aos alumnos a que sigan facendo preguntas e, a continuación, pregunto: "¿Que pasa se deixamos todo como está?". E inmediatamente ven o erro. Pero convencer aos estudantes de que deben preocuparse pola corrección é máis difícil do que parece a primeira vista. Moitos destes estudantes veñen con experiencia en programación no instituto, algúns xa conseguiron traballo e programaron alí, e todos están cheos de confianza en si mesmos. Isto é algo militar: primeiro hai que cambiar a súa mentalidade para convencelos de abordar pacientemente a solución dos problemas emerxentes. Ou quizais sexa como os monxes budistas: primeiro aprenden a razoar sobre a corrección e, unha vez que comprenden as formas de razoar sobre a corrección, permítelles pasar ao seguinte nivel e comezar a preocuparse polo rendemento.
Alexey: É dicir, ás veces mostras aos estudantes exemplos que non funcionan, grazas aos cales recibes comentarios que mostran se entenden a esencia do problema, se poden atopar o código incorrecto e o resultado incorrecto. Ben, como adoitan gustar ou molestar os estudantes?
Maurice: Case sempre os estudantes finalmente atopan o erro. Se buscan demasiado lentamente, fago preguntas principais, e aquí é importante entender que se nunca se enganan, comezarán a percibir sen pensar as túas palabras como a verdade definitiva. Despois abúrranse e dormen lendo Facebook no seu portátil durante a clase. Pero cando lles avisas de antemán que van ser estafados e que se verán estúpidos se non senten o truco, fanse moito máis vixiantes. Isto é bo en moitos sentidos. Gustaríame que os estudantes non só cuestionasen a súa comprensión do tema, senón tamén a autoridade do profesor. A idea é que o alumno poida levantar a man en calquera momento e dicir: Creo que o que acabas de dicir está mal. É unha importante ferramenta de aprendizaxe. Non quero que ningún dos estudantes se sente e pense en silencio para si mesmo: todo isto parece unha tontería total, pero dá moito medo levantar a man e, de feito, é un profesor, polo que todo o que di é certo. Polo tanto, se se lles avisa con antelación de que non todo o contado é necesariamente certo, teñen un aliciente para prestar máis atención ao material. Declaro explícitamente que levantar a man e facer preguntas está ben. A túa pregunta pode parecer parva ou inxenua, pero moitas veces é así como xorden as mellores preguntas.
Alexei: Moi interesante. Normalmente as persoas teñen algún tipo de barreira psicolóxica que lles impide facerlle unha pregunta ao profesor. Especialmente se hai moita xente na sala e todos teñen medo de que discutir a túa estúpida pregunta ocupe o tempo de todas estas persoas. Hai trucos para tratar con isto?
Maurice: Moitas veces paro e fago as preguntas clásicas. Será correcta algunha afirmación ou como resolverían o problema en discusión. Este é un paso clave, especialmente ao comezo dunha sesión, cando a xente se avergoña de dicir ata o máis pequeno. Fai unha pregunta aos estudantes e non di nada máis. Hai silencio, todo o mundo tensase un pouco, a tensión crece, logo de súpeto alguén rompe, rompe e di a resposta. Así que desenvolvas a situación: faise máis difícil e incómodo quedar calado que responder! Este é un truco pedagóxico estándar. Todo profesor do mundo debería saber como facelo.
Alexey: Agora temos un gran título para esta entrevista: "é máis fácil responder que calar".
Vitaly: Déixame preguntarche unha cousa máis. Estás a traballar en probas topolóxicas. Como te involucraches nisto, porque a computación distribuída e a topoloxía son cousas completamente diferentes!
Maurice: Hai unha relación oculta alí. Cando era estudante e estudaba matemáticas, estudaba matemáticas puras. Non tiña verdadeiro interese pola informática ata o final dos meus estudos e atopeime na urxente necesidade de buscar traballo. Como estudante, estudei topoloxía alxébrica. Moitos anos despois, mentres traballaba nun problema chamado , usei gráficos para modelar o problema e, como parecía entón, atopei unha solución. Só tiñas que sentarte e dar a volta á conta. Tenta atopar unha resposta adecuada neste gráfico. Pero o meu algoritmo non funcionou: resultou que sempre correría en círculos. Desafortunadamente, nada disto podería explicarse na linguaxe formal da teoría de grafos, a linguaxe que todos os informáticos coñecen. E entón lembreime de que hai moitos anos, incluso nas clases de topoloxía, usabamos o concepto , que é unha xeneralización de gráficos a dimensións superiores. Entón pregunteime: que pasa se reformulamos o problema en termos de complexos simpliciais? Isto converteuse na clave. Ao usar un formalismo máis poderoso, o problema faise de súpeto moito máis sinxelo. A xente loitou con el durante moito tempo, usando gráficos, pero non podían facer nada. E aínda agora non poden - a resposta correcta non era o algoritmo, senón a proba da imposibilidade de resolver o problema. É dicir, tal algoritmo simplemente non existe. Pero baséase ou ben en complexos simpliciais, ou en cousas que a xente pretende non considerar complexos simpliciais. Do feito de que chamou algo cun novo nome, non perde a súa esencia.
Vitaliy: Resulta que tiveches sorte?
Maurice: Ademais da sorte, tamén o é preparación. É dicir, non debes esquecer as cousas "inútiles" que aprendiches anteriormente. Cantas máis cousas inútiles aprendas, máis coñecementos poderás extraer cando te enfrontes a un novo problema. Este tipo de coincidencia intuitiva de patróns é importante porque... Digamos que é unha cadea: ao principio, descubrín que os gráficos non funcionaban ou non funcionaban nada, recordábame a algo de hai oito anos. e anos de estudante cando estudamos todos estes complexos simpliciais . Á súa vez, isto permitiume atopar o meu antigo libro de texto de topoloxía e cargalo de novo na miña cabeza. Pero se non fose por ese vello coñecemento, nunca tería avanzado na resolución do problema orixinal.
Nova edición de The Art of Multiprocessor Programming
Alexei: Dixeches unhas palabras sobre o teu libro. Probablemente non sexa o maior segredo que escribiches o libro máis famoso do mundo sobre multithreading, . Xa ten uns 11 anos e dende entón só saíu . Haberá unha segunda edición?
Maurice: É bo que o preguntases! Será moi pronto, dentro de tres meses máis ou menos. Hai dous autores máis, engadimos moito máis material, melloramos a sección sobre o paralelismo de bifurcación/unión, escribimos unha sección sobre MapReduce, engadimos moitas cousas novas e tiramos as innecesarias, algo que era moi interesante no momento de escribir. a primeira edición, pero xa non é hoxe. Resultou un libro moi seriamente revisado.
Alexei: Xa está todo feito, só queda por liberar?
Maurice: Aínda faltan traballar un par de capítulos. O noso editor (creo que xa nos odia) aínda está intentando transmitir que debemos traballar máis rápido. Estamos moi atrasados. Teoricamente, poderiamos ter feito este libro un par de anos antes.
Alexey: Hai algunha posibilidade de conseguir unha nova versión do libro antes do Nadal?
Maurice: Ese é o noso obxectivo! Pero tantas veces augurei a vitoria que xa ninguén me cre. Probablemente tampouco deberías confiar demasiado en min neste asunto.
Alexei: En calquera caso, esta é unha noticia fantástica. Gustoume moito a primeira edición do libro. Poderíase dicir que son fan.
Maurice: Espero que a nova edición sexa digna do teu fervoroso entusiasmo, grazas!
Como se inventou a memoria transaccional
Vitaly: A seguinte pregunta é sobre a memoria transaccional. Polo que teño entendido, vostede é un pioneiro neste campo, inventárono nun momento en que ninguén pensaba en tales cousas. Por que decidiches mudarte a esta zona? Por que foron importantes para ti as transaccións? Pensabas que algún día se plasmarán en ferro?
Maurice: Coñezo as transaccións desde os meus estudos de posgrao.
Vitaliy: Si, pero estas son transaccións diferentes!
Maurice: Traballei con Elliott Moss na recollida de lixo sen bloqueo. O noso problema era que queriamos cambiar atómicamente algunhas palabras na memoria e despois os algoritmos serían moi sinxelos, e polo menos algúns deles serían máis eficientes. Usando para proporcionada pola arquitectura paralela, é posible facer algo, pero é moi ineficiente e feo porque terías que lidiar con niveis de indirecto. Quero cambiar as palabras de memoria e teño que cambiar porque só podo cambiar un punteiro, polo que precisan apuntar a algún tipo de estrutura de directorio. Falamos do xenial que sería se puidésemos cambiar o hardware para poder gravar simultaneamente. Elliot parece notar isto: se observas os protocolos de coherencia da caché, xa proporcionan a maior parte da funcionalidade necesaria. Nunha transacción optimista, o protocolo de coherencia da caché notará a presenza dun conflito de tempo e a caché converterase . Que pasa se inicias de xeito especulativo unha transacción na túa caché e utilizas os mecanismos do protocolo de coherencia para detectar conflitos? A arquitectura de hardware especulativa era fácil de deseñar. Entón escribimos iso sobre a memoria transaccional. Ao mesmo tempo, a empresa para a que traballaba, Digital Equipment Corporation, estaba construíndo un novo procesador de 64 bits chamado Alpha. E entón fun e dei unha presentación ao equipo de desenvolvemento de Alpha sobre a nosa marabillosa memoria transaccional, e preguntáronme: que ingresos adicionais obterá a nosa empresa se poñemos todo isto directamente no procesador? E a iso non tiña absolutamente ningunha resposta, porque son tecnólogo, non son especialista en mercadotecnia. Realmente non tiña nada que dicir. Non lles impresionou moito que eu non soubese nada.
Vitaly: millóns! Só di "millóns"!
Maurice: Si, é o que debería ter dito. Agora, na era das startups e todo iso, sei como escribir un plan de negocios. Que pode mentir un pouco sobre o tamaño do beneficio potencial. Pero naqueles tempos parecía inxenuo, así que só dixen: "Non o sei". Se miras a historia da publicación sobre a memoria transaccional, notarás que despois dun ano houbo varias referencias a ela, e despois durante uns dez anos ninguén citou este artigo. As citas apareceron ao redor de 2004, cando xurdiu o verdadeiro multi-núcleo. Cando a xente descubriu que escribir código paralelo podía gañar cartos, comezaron novas investigacións. Ravi Rajwar , que dalgunha maneira introduciu o mainstream no concepto de memoria transaccional. (Nota do editor: este artigo ten unha segunda versión publicada en 2010 e está dispoñible gratuitamente ). De súpeto, a xente deuse conta de como se pode usar exactamente todo isto, como poden acelerar os algoritmos tradicionais con bloqueos. Un bo exemplo de algo que no pasado parecía un problema académico interesante. E si, se me preguntarades nese momento se pensaba que todo isto sería importante no futuro, diría: claro, pero cando exactamente non está claro. Quizais dentro de 50 anos? Na práctica, resultou ser só unha década. É moi agradable cando fas algo, e en só dez anos a xente nótase.
Por que paga a pena investigar no campo da computación distribuída
Vitaly: Se falamos de novas investigacións, que aconsellarías aos lectores: computación distribuída ou multinúcleo e por que?
Maurice: É doado conseguir un procesador multinúcleo hoxe en día, pero é máis difícil configurar un verdadeiro sistema distribuído. Comecei a traballar nelas porque quería facer algo diferente ao meu doutoramento. Este é o consello que sempre lles dou aos principiantes: non escriban unha disertación de seguimento, intente ir nunha nova dirección. Ademais, multithreading é doado. Podo experimentar co meu propio garfo funcionando nun portátil sen levantarme da cama. Pero se de súpeto quixese crear un verdadeiro sistema distribuído, tería que facer moito traballo, atraer estudantes, etc. Son unha persoa preguiceiro e prefiro traballar en multinúcleo. Experimentar con sistemas multinúcleo tamén é máis doado que experimentar con distribuídos, porque mesmo nun sistema distribuído estúpido hai demasiados factores para controlar.
Vitaliy: Que estás facendo agora, investigando blockchain? A que artigos debes prestar atención primeiro?
Maurice: Apareceu recentemente que escribín co meu alumno, Vikram Saraf, específicamente para o en París hai tres semanas. Este é un artigo sobre sistemas distribuídos útiles no que propoñemos facer que Ethereum sexa multiproceso. Agora os contratos intelixentes (código que se executa na cadea de bloques) execútanse secuencialmente. Escribimos un artigo anteriormente que falaba dunha forma de utilizar transaccións especulativas para acelerar o proceso. Tomamos moitas ideas da memoria transaccional do software e dixemos que se fai que estas ideas formen parte da máquina virtual Etherium, todo funcionará máis rápido. Pero para iso é necesario que non haxa conflitos de datos nos contratos. E entón supuxemos que na vida real realmente non hai tales conflitos. Pero non tivemos a oportunidade de descubrilo. Entón ocorréusenos que tiñamos case dez anos de historial de contrato real nas nosas mans, polo que descargamos a cadea de bloques de Etherium e preguntámonos: que pasaría se estes rexistros históricos se executasen en paralelo? Atopamos un aumento significativo da velocidade. Nos primeiros tempos de Etherium, a velocidade aumentou moito, pero hoxe todo é algo máis complicado, porque hai menos contratos e a probabilidade de conflitos por datos que requiren serialización foi maior. Pero todo isto é traballo experimental con datos históricos reais. O bo da cadea de bloques é que lembra todo para sempre, polo que podes volver atrás no tempo e estudar o que pasaría se utilizasemos outros algoritmos para executar o código. Como lle gustaría á xente do pasado a nosa nova idea. É moito máis doado e agradable facer esa investigación, porque hai algo que o controla todo e o rexistra todo. Isto xa é algo máis parecido á socioloxía que ao desenvolvemento de algoritmos.
Detívose o desenvolvemento de algoritmos e como vivir
Vitaly: É hora da última pregunta teórica! Parece que os avances nas estruturas de datos competitivas están a diminuír cada ano? Cres que chegamos a unha meseta na nosa comprensión das estruturas de datos, ou haberá algunhas melloras importantes? Quizais hai algunhas ideas intelixentes que poden cambialo todo?
Maurice: Podemos ter alcanzado unha meseta en estruturas de datos para arquitecturas tradicionais. Pero as estruturas de datos para novas arquitecturas seguen sendo unha área moi prometedora. Se queres crear estruturas de datos para, por exemplo, aceleradores de hardware, entón as estruturas de datos da GPU son moi diferentes das estruturas de datos da CPU. Cando deseña estruturas de datos para cadeas de bloques, cómpre agrupar as pezas de datos e, a continuación, poñelas en algo así , para evitar falsificación. Últimamente hai un aumento da actividade nesta zona, moitos están facendo un moi bo traballo. Pero creo que o que pasará é que novas arquitecturas e novas aplicacións levarán a novas estruturas de datos. Aplicacións máis antigas e arquitectura tradicional - quizais xa non haxa moito espazo para a investigación. Pero se saes dos camiños trillados e miras máis aló, verás cousas tolas que o mainstream non se toma en serio; aí é onde suceden realmente todas as cousas emocionantes.
Vitaly: Polo tanto, para ser un investigador moi famoso, tiven que inventar a miña propia arquitectura 🙂
Maurice: Podes "roubar" a nova arquitectura doutra persoa, ¡parece moito máis fácil!
Traballa en Brown University
Vitaliy: Poderías contarnos máis sobre en que traballas? Non se sabe moito sobre el no contexto da tecnoloxía da información. Menos que sobre o MIT, por exemplo.
Maurice: Brown University é unha das universidades máis antigas dos Estados Unidos. Creo que só Harvard é un pouco maior. Brown forma parte do chamado , que é unha colección de oito universidades máis antigas. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pensilvania, Princeton. Esta é unha especie de universidade antiga, pequena e un pouco aristocrática. O foco está na educación das artes liberais. Non se trata de ser como o MIT, o MIT é moi especializado e técnico. Brown é un lugar estupendo para estudar literatura rusa ou grego clásico e, por suposto, informática. Céntrase na educación integral. A maioría dos nosos estudantes van a Facebook, Apple, Google, polo que creo que os nosos estudantes non teñen ningún problema para conseguir un emprego no sector. Fun traballar a Brown porque antes traballaba en Digital Equipment Corporation en Boston. Foi unha empresa que inventou moitas cousas interesantes, pero que negou a importancia dos ordenadores persoais. Unha empresa cun destino difícil, cuxos fundadores antes foron mozos revolucionarios, non aprenderon nada e non esqueceron nada, polo que pasaron de revolucionarios a reaccionarios en aproximadamente unha década. Gústalles bromear dicindo que os ordenadores persoais pertencían a un garaxe, un garaxe abandonado, por suposto. É bastante obvio que foron destruídos por empresas máis flexibles. Cando quedou claro que a empresa estaba en problemas, chamei ao meu amigo de Brown, que está a unha hora de Boston. Non quería marchar de Boston nese momento, porque outras universidades non tiñan moitas prazas libres. Era unha época na que non había tantas prazas no ámbito da Informática como as que hai agora. E Brown tiña un traballo, eu non tiña que mudarme da miña casa, non tiña que mudar a miña familia e gústame moito vivir en Boston. Entón tomei a decisión de ir a Brown. Gústame. Os estudantes son xeniais, así que nunca intentei ir a outro sitio. Nun ano sabático, traballei en Microsoft durante un ano, fun a Technion en Haifa durante un ano e agora estarei en Algorand. Teño moitos compañeiros por todas partes e polo tanto a localización física das nosas aulas non é tan importante. Pero o máis importante son os estudantes, aquí son os mellores. Nunca tentei ir a ningún outro sitio, porque aquí estou moi feliz.
Con todo, a pesar da fama de Brown nos Estados Unidos, é sorprendentemente descoñecido no exterior. Como vedes, agora estou facendo todo o posible para corrixir este estado de cousas.
A diferenza entre investigación universitaria e corporativa
Vitaliy: Está ben, a seguinte pregunta é sobre equipos dixitais. Fuches investigador alí. Cal é a diferenza entre traballar no departamento de I+D dunha gran empresa e traballar nunha universidade? Cales son as vantaxes e os inconvenientes?
Maurice: Levo vinte anos en Microsoft, traballando en estreita colaboración con Sun Microsystems, Oracle, Facebook e agora Algorand. En base a todo isto, quero dicir que é posible realizar investigacións de primeiro nivel tanto nas empresas como na universidade. A diferenza importante é que nunha empresa traballas con compañeiros. Se de súpeto teño unha idea para un proxecto que aínda non existe, teño que convencer aos meus compañeiros de que esta é unha boa idea. Se estou en Brown, entón podo dicirlles aos meus alumnos: ¡traballemos a antigravedade! Irán a outra persoa ou asumirán o proxecto. Si, terei que buscar financiamento, terei que escribir unha solicitude de subvención, etc. En calquera caso, sempre haberá moitos alumnos, e poderás tomar decisións unilateralmente. Pero na universidade, probablemente non traballes con persoas do teu nivel. No mundo da investigación industrial, primeiro tes que convencer a todos de que paga a pena asumir o teu proxecto. Non podo pedir nada a ninguén. E estas dúas formas de traballar son valiosas, porque se estás traballando en algo realmente tolo e os teus compañeiros son difíciles de convencer, é máis fácil convencer aos estudantes de posgrao, especialmente se lles pagas. Se estás traballando en algo que require moita experiencia e coñecementos profundos, necesitas colegas que poidan dicir "non, da casualidade que entendo esta área e a túa idea é mala, non sairá nada". Isto é moi útil en termos de perder tempo. E ademais, se nos laboratorios industriais pasas moito tempo escribindo informes, entón na universidade pasas este tempo buscando cartos. Se quero que os estudantes poidan viaxar a algún lugar, teño que buscar o diñeiro para iso noutro lugar. E canto máis importante sexa a túa posición na universidade, máis tempo tes que dedicar a recoller cartos. Entón, agora xa sabes como traballo: un mendigo profesional! Como un deses monxes que andan cun prato de doazón. En xeral, estas dúas actividades compleméntanse. Por iso intento vivir e estar firme nos dous mundos.
Vitaliy: Parece que convencer a unha empresa é máis difícil que convencer a outros científicos.
Maurice: Máis difícil, e moito máis. Ademais, en diferentes áreas é diferente: alguén realiza investigacións a gran escala e alguén está centrado no seu tema. Se fose a Microsoft ou Facebook e dixese: fagamos antigravedade, case non o agradecerían. Pero se lle dixese exactamente o mesmo aos meus estudantes de posgrao, o máis probable é que se poñan a traballar ao instante, aínda que agora xa tería problemas, porque necesitas atopar diñeiro para iso. Pero sempre que queiras facer algo acorde cos obxectivos da empresa, esa empresa pode ser un moi bo lugar para investigar.
Hidra e SPTDC
Vitaliy: As miñas preguntas están chegando ao seu fin, así que imos falar un pouco sobre a próxima viaxe a Rusia.
Maurice: Si, estou desexando volver a Petersburgo.
Alexey: É unha gran honra para min que esteas connosco este ano. Esta é a túa segunda vez en San Petersburgo, non?
Maurice: Xa o terceiro!
Alexei: Entendido, pero - exactamente o segundo. A última vez que chamou a escola , agora cambiamos unha letra (C a D, Concurrente a Distribuida) para salientar que hai máis áreas relacionadas coa computación distribuída este ano. Podes dicir unhas palabras sobre as túas presentacións na Escola e ?
Maurice: Na Escola, quero falar dos conceptos básicos da cadea de bloques e do que podes facer con el. Gustaríame demostrar que as cadeas de bloques son moi similares á programación multi-fíos que coñecemos, pero cos seus propios matices, e é importante comprender estas diferenzas. Se cometes un erro nunha aplicación web normal, é molesto. Se escribes código defectuoso nunha aplicación financeira, alguén definitivamente roubará todo o teu diñeiro. Este é un nivel de responsabilidade e consecuencias completamente diferente. Falarei un pouco sobre a proba de traballo, os contratos intelixentes, as transaccións entre diferentes blockchains.
Xunto a min traballarán outros relatores, que tamén teñen algo que dicir sobre a cadea de bloques, e acordamos coordinarnos entre nós para que as nosas historias encaixan ben. Pero para a charla de enxeñería, quero dar unha explicación clara a un público amplo por que non debes crer todo o que escoitas sobre as cadeas de bloques, por que as cadeas de bloques son un gran campo, como encaixa con outras ideas coñecidas e por que debemos mirar ao futuro con audacia.
Alexey: Ademais, quero dicir que isto non terá lugar en formato de encontro ou grupo de usuarios, como ocorreu hai dous anos. Decidimos facer unha pequena conferencia preto do colexio. O motivo é que despois de falar con Peter Kuznetsov, decatámonos de que a escola está limitada a só cen, quizais 120 persoas. Ao mesmo tempo, hai moitos enxeñeiros que queren falar contigo, asistir a informes e en xeral están interesados no tema. Para iso creamos unha nova conferencia . Por certo, algunha idea de por que Hydra?
Maurice: Porque terá sete altofalantes? E poden cortarlles a cabeza e no seu lugar crecerán novos altofalantes?
Alexey: gran idea para facer crecer novos falantes. Pero realmente, hai unha historia aquí. Lembra a lenda de Odiseo, onde tivo que navegar entre eles ? Hydra é algo así como Caribdis. A historia é que unha vez falei nunha conferencia e falei de multithreading. Só había dous temas nesta conferencia. Ao comezo da reportaxe, díxenlle ao público no salón que agora podían escoller entre Escila e Caribdis. O meu espírito animal é Caribdis, porque Caribdis ten moitas cabezas e o meu tema é o multiproceso. Así aparecen os nomes das conferencias.
En calquera caso, esgotámonos tanto preguntas como tempo. Entón, grazas amigos por unha gran entrevista e vémonos en SPTDC e Hydra 2019!
Será posible continuar a comunicación con Maurice na conferencia Hydra 2019, que se celebrará do 11 ao 12 de xullo de 2019 en San Petersburgo. Virá cun informe . As entradas pódense mercar .
Fonte: www.habr.com