- dono de dois. A primeira é para trabalhar (Brown University) e a segunda, mais recente, - (Universidade Técnica da Virgínia). O Prémio Dijkstra é atribuído a trabalhos cujo significado e influência são visíveis há pelo menos dez anos e Maurice é obviamente um dos especialistas mais famosos na área. Atualmente, ele trabalha como professor na Brown University e possui inúmeras realizações que duram um parágrafo. Atualmente ele está pesquisando blockchain no contexto da computação distribuída clássica.
Anteriormente, Maurice já havia vindo à Rússia para o SPTCC () e fez uma excelente reunião da comunidade de desenvolvedores Java JUG.ru em São Petersburgo ().
Este habrapost é uma ótima entrevista com Maurice Herlihy. Discute os seguintes tópicos:
- Interação entre academia e indústria;
- Fundação para Pesquisa Blockchain;
- De onde vêm as ideias inovadoras? A influência da popularidade;
- Doutorado sob orientação de Barbara Liskov;
- O mundo está esperando pelo multi-core;
- Um novo mundo traz novos problemas. NVM, NUMA e hacking de arquitetura;
- Compiladores vs processadores, RISC vs CISC, memória compartilhada vs passagem de mensagens;
- A arte de escrever código multithread frágil;
- Como ensinar os alunos a escrever códigos multithread complexos;
- Nova edição do livro “The Art of Multiprocessor Programming”;
- Como a memória transacional foi inventada;
- Por que vale a pena realizar pesquisas na área de computação distribuída;
- O desenvolvimento de algoritmos parou e como seguir em frente;
- Trabalhar na Brown University;
- A diferença entre a pesquisa em uma universidade e dentro de uma empresa;
- Hidra e SPTDC.
A entrevista é conduzida por:
Vitaly Aksenov — atualmente, pós-doutorado no IST Áustria e funcionário do Departamento de Tecnologias de Computação da Universidade ITMO. Realiza pesquisas na área de teoria e prática de estruturas de dados competitivas. Antes de trabalhar no IST, obteve o seu doutoramento pela Universidade Paris Diderot e pela Universidade ITMO sob a orientação do Professor Peter Kuznetsov.
Alexey Fedorov - Produtor do JUG Ru Group, empresa russa que organiza conferências para desenvolvedores. Alexey participou da preparação de mais de 50 conferências e seu currículo inclui desde o cargo de engenheiro de desenvolvimento na Oracle (JCK, Java Platform Group) até o cargo de desenvolvedor na Odnoklassniki.
Vladimir Sitnikov - Engenheiro na Netcracker. Dez anos de trabalho no desempenho e escalabilidade do NetCracker OS, software utilizado pelas operadoras de telecomunicações para automatizar processos de gerenciamento de redes e equipamentos de rede. Interessado em problemas de desempenho de Java e Oracle Database. Autor de mais de uma dúzia de melhorias de desempenho no driver PostgreSQL JDBC oficial.
Interação entre academia e indústria
Alexey: Maurice, você trabalha no ambiente acadêmico há muito tempo e a primeira questão é a interação entre as esferas acadêmica e industrial. Você poderia falar sobre como as interações entre eles mudaram recentemente? O que aconteceu há 20-30 anos e o que está acontecendo agora?
Maurice: Sempre tentei trabalhar em estreita colaboração com empresas comerciais porque elas têm problemas interessantes. Eles, via de regra, não estão muito interessados nem em publicar seus resultados, nem em explicações detalhadas de seus problemas à comunidade mundial. Eles estão interessados apenas em resolver esses problemas. Trabalhei para essas empresas por algum tempo. Passei cinco anos trabalhando em tempo integral em um laboratório de pesquisa na Digital Equipment Corporation, que era uma grande empresa de informática. Trabalhei um dia por semana na Sun, na Microsoft, na Oracle e fiz alguns trabalhos no Facebook. Agora vou tirar uma licença sabática (um professor de uma universidade americana pode tirar essa licença por um ano, aproximadamente uma vez a cada seis anos) e trabalhar em , esta é uma empresa de criptomoeda em Boston. Trabalhar em estreita colaboração com empresas sempre foi um prazer porque é assim que se aprende coisas novas e interessantes. Você pode até ser a primeira ou segunda pessoa a publicar um artigo sobre um tópico escolhido, em vez de trabalhar na melhoria gradual de soluções para problemas nos quais todos já estão trabalhando.
Alexey: Você pode nos contar com mais detalhes como isso acontece?
Maurício: Claro. Você sabe, quando eu trabalhava na Digital Equipment Corporation, eu e Elliot Moss, inventamos a memória transacional. Foi um período muito frutífero em que todos começaram a se interessar pela tecnologia da informação. Paralelismo, inclusive, embora ainda não existissem sistemas multi-core. Durante a época da Sun e da Oracle, trabalhei muito em estruturas de dados paralelas. No Facebook trabalhei no projeto blockchain deles, do qual não posso falar, mas espero que se torne público em breve. No próximo ano, na Algorand, estarei trabalhando em um grupo de pesquisa que estuda contratos inteligentes.
Alexey: Blockchain se tornou um tema muito popular nos últimos anos. Isso ajudará sua pesquisa? Talvez isso facilite a obtenção de subsídios ou o acesso a recursos de empresas que operam no setor?
Maurice: Já recebi uma pequena bolsa da Fundação Ethereum. A popularidade do blockchain é muito útil para inspirar os alunos a trabalhar nesta área. Eles estão muito interessados nisso e entusiasmados em se envolver, mas às vezes não percebem que a pesquisa que parece excitante externamente acaba envolvendo um trabalho realmente árduo. No entanto, estou muito animado para usar toda essa mística em torno do blockchain para ajudar a atrair estudantes.
Mas isso não é tudo. Faço parte do conselho consultivo de várias startups de blockchain. Alguns deles podem ter sucesso, outros não, mas é sempre muito interessante ver as suas ideias, estudá-las e aconselhar as pessoas. O mais emocionante é quando você alerta as pessoas para não fazerem algo. Muitas coisas parecem uma boa ideia à primeira vista, mas serão mesmo?
Fundação para Pesquisa Blockchain
Vitaly: Algumas pessoas pensam que o futuro está no blockchain e em seus algoritmos. E outras pessoas dizem que é apenas mais uma bolha. Você pode compartilhar sua opinião sobre este assunto?
Maurice: Muito do que está acontecendo no mundo blockchain está errado, algumas são apenas uma farsa, muitas são superestimadas. No entanto, penso que existe uma base científica sólida para estes estudos. O fato de o mundo blockchain estar cheio de diferenças ideológicas mostra o nível de entusiasmo e dedicação. Por outro lado, isto não é particularmente benéfico para a investigação científica. Agora, se você publicar um artigo que fale sobre as deficiências de um algoritmo específico, a reação resultante nem sempre será totalmente científica. Muitas vezes as pessoas jogam fora suas emoções. Penso que este tipo de entusiasmo nesta área pode parecer atraente para alguns, mas no final das contas, existem questões científicas e de engenharia reais que precisam de ser abordadas. Há muita Ciência da Computação aqui.
Vitaly: Então você está tentando estabelecer as bases para a pesquisa de blockchain, certo?
Maurice: Estou tentando estabelecer as bases para uma disciplina sólida, científica e matematicamente sólida. E parte do problema é que às vezes você tem que contradizer algumas das posições excessivamente duras de outras pessoas e ignorá-las. Às vezes as pessoas perguntam por que trabalho numa área onde apenas terroristas e traficantes de drogas estão interessados. Tal reação é tão sem sentido quanto o comportamento dos seguidores que repetem cegamente suas palavras. Acho que a verdade está em algum lugar no meio. O Blockchain terá um impacto profundo na sociedade e na economia global. Mas isso provavelmente não acontecerá graças à tecnologia moderna. As tecnologias modernas irão se desenvolver e o que será chamado de blockchain no futuro se tornará muito importante. Pode nem parecer blockchains modernos, essa é uma questão em aberto.
Se as pessoas inventarem novas tecnologias, continuarão a chamá-las de blockchain. Quero dizer, assim como o Fortran de hoje não tem nada a ver com a linguagem Fortran da década de 1960, mas todo mundo continua chamando-o de Fortran. O mesmo para UNIX. O que é chamado de “blockchain” ainda fará a sua revolução. Mas duvido que esse novo blockchain seja parecido com o que todo mundo gosta de usar hoje.
De onde vêm as ideias inovadoras? Impacto da popularidade
Alexey: A popularidade do blockchain levou a novos resultados do ponto de vista científico? Mais interação, mais alunos, mais empresas da área. Já existem resultados deste aumento de popularidade?
Maurice: Fiquei interessado nisso quando alguém me entregou um folheto oficial de uma empresa que acabara de arrecadar muito dinheiro. Escreveu sobre , com o qual estou mais do que familiarizado. O que estava escrito no folheto era claramente tecnicamente incorreto. As pessoas que escreveram tudo isso não entenderam realmente o modelo por trás do problema... e ainda assim esta empresa levantou muito dinheiro. Posteriormente, a empresa substituiu discretamente este folheto por uma versão muito mais correta - e não direi qual era o nome desta empresa. Eles ainda estão por aí e indo muito bem. Este incidente convenceu-me de que, em primeiro lugar, a blockchain é simplesmente uma forma de computação distribuída. Em segundo lugar, o limiar de entrada (pelo menos naquela altura, há quatro anos) era bastante baixo. As pessoas que trabalhavam nesta área eram muito enérgicas e inteligentes, mas não liam artigos científicos. Eles tentaram reinventar coisas conhecidas e fizeram isso errado. Hoje o drama diminuiu.
Alexey: Isso é muito interessante porque há alguns anos tínhamos uma tendência diferente. É um pouco como o desenvolvimento front-end, quando os desenvolvedores front-end baseados em navegador reinventaram tecnologias inteiras que já eram populares no back-end: sistemas de construção, integração contínua, coisas assim.
Maurício: Concordo. Mas isto não é surpreendente, porque as ideias verdadeiramente inovadoras vêm sempre de fora da comunidade estabelecida. É pouco provável que investigadores estabelecidos, especialmente académicos estabelecidos, façam algo verdadeiramente inovador. É fácil escrever um artigo para a próxima conferência sobre como você melhorou ligeiramente os resultados de seu trabalho anterior. Vá a uma conferência, reúna-se com amigos, converse sobre as mesmas coisas. E as pessoas que surgem com ideias inovadoras quase sempre vêm de fora. Eles não conhecem as regras, não conhecem a língua, mas mesmo assim... Se você está dentro de uma comunidade estabelecida, aconselho que preste atenção às coisas novas, a algo que não se enquadra no quadro geral. Num certo sentido, pode ser feita uma tentativa de combinar desenvolvimentos externos, mais fluidos, com métodos que já compreendemos. Como primeiro passo, tente estabelecer uma base científica e depois alterá-la para que possa ser aplicada a novas ideias inovadoras. Acho que o blockchain é ótimo por ser uma ideia nova e disruptiva.
Alexey: Por que você acha que isso acontece? Porque as pessoas “de fora” não têm barreiras específicas inerentes à comunidade?
Maurice: Há um padrão acontecendo aqui. Se você ler a história dos impressionistas na pintura e na arte em geral, verá que em certa época artistas famosos rejeitaram o impressionismo. Disseram que era meio infantil. Uma geração mais tarde, esta forma de arte anteriormente rejeitada tornou-se o padrão. O que vejo na minha área: os inventores do blockchain não estavam interessados em poder, em aumentar publicações e índice de citações, eles só queriam fazer algo de bom. E então eles se sentaram e começaram a fazer isso. Faltava-lhes uma certa profundidade técnica, mas isso pode ser corrigido. É muito mais difícil apresentar novas ideias criativas do que corrigir e fortalecer ideias insuficientemente maduras. Graças a esses inventores, agora tenho algo para fazer!
Alexey: Isso é semelhante à diferença entre startups e projetos legados. Herdamos muitas limitações de pensamento, barreiras, requisitos especiais e assim por diante.
Maurice: Uma boa analogia é a computação distribuída. Pense no blockchain como se fosse uma startup e na computação distribuída como uma empresa grande e estabelecida. A computação distribuída está em processo de aquisição e fusão com o blockchain.
Doutorado sob supervisão de Barbara Liskov
Vitaly: Ainda temos muitas dúvidas! Estávamos investigando sua formação e nos deparamos com um fato interessante sobre seu doutorado. Sim, isso foi há muito tempo, mas parece ser um tema importante. Você recebeu seu doutorado sob sua orientação ! Barbara é muito conhecida na comunidade de linguagens de programação e uma pessoa muito conhecida em geral. É lógico que sua pesquisa tenha sido na área de linguagens de programação. Como você mudou para a computação paralela? Por que você decidiu mudar de assunto?
Maurice: Na época, Barbara e seu grupo estavam apenas olhando para a computação distribuída, o que era uma ideia muito nova. Houve também quem dissesse que a computação distribuída era um disparate e que a comunicação entre computadores era inútil. Uma das questões abordadas na computação distribuída que a distingue da computação centralizada é a tolerância a falhas. Depois de muita pesquisa, decidimos que uma linguagem de programação de computação distribuída precisava ter algo parecido com transações atômicas, porque você nunca pode ter certeza de que uma chamada remota terá sucesso. Depois de realizar as transações, surge o problema do gerenciamento de simultaneidade. Depois, houve muito trabalho na obtenção de estruturas de dados transacionais altamente paralelas. Aí, quando me formei, fui para e comecei a procurar um tema para trabalhar. Ocorreu-me que a computação passou de computadores individuais para redes de computadores. Os multiprocessadores seriam uma continuação natural do progresso - a palavra “multi-core” ainda não existia. Pensei: qual é o equivalente às transações atômicas para um sistema multi-core? Definitivamente, não são transações regulares porque são muito grandes e pesadas. E foi assim que tive a ideia e foi assim que criei toda a sincronização sem espera. Esta foi uma tentativa de responder à questão de qual é o análogo das transações atômicas para um sistema multiprocessador com memória compartilhada. À primeira vista, este trabalho pode parecer completamente diferente, mas na verdade é uma continuação do mesmo tema.
O mundo está esperando por multi-core
Vitaly: Você mencionou que naquela época havia poucos computadores multi-core, certo?
Maurice: Eles simplesmente não estavam lá. Existiam vários multiprocessadores ditos simétricos, que eram basicamente conectados ao mesmo barramento. Isso não funcionou muito bem porque toda vez que uma nova empresa criava algo semelhante, a Intel lançava um único processador superior ao multiprocessador.
Alexey: Isso não significa que naqueles tempos antigos era mais um estudo teórico?
Maurice: Não foi um estudo teórico, mas sim um estudo especulativo. Tudo isso não se tratava de trabalhar com muitos teoremas, mas sim de apresentar hipóteses sobre uma arquitetura que não existia naquela época. É para isso que serve a pesquisa! Nenhuma empresa teria feito algo assim; era tudo algo de um futuro distante. Na verdade, foi assim até 2004, quando surgiram verdadeiros processadores multi-core. Como os processadores superaquecem, você pode torná-los ainda menores, mas não pode torná-los mais rápidos. Por causa disso, houve uma transição para arquiteturas multi-core. E então isso significou que de repente havia uma utilidade para todos os conceitos que desenvolvemos no passado.
Alexey: Por que você acha que os processadores multi-core apareceram apenas na década de XNUMX? Então por que é tão tarde?
Maurice: Isso se deve a limitações de hardware. Intel, AMD e outras empresas são muito boas em aumentar a velocidade do processador. Quando em algum momento os processadores ficaram pequenos o suficiente para não conseguirem mais aumentar a velocidade do clock porque os processadores começariam a queimar. Você pode torná-los menores, mas não mais rápidos. O que está em seu poder - em vez de um processador muito pequeno, eles podem acomodar oito, dezesseis ou trinta e dois processadores no mesmo volume do gabinete, onde antes cabia apenas um. Agora você tem multithreading e comunicação rápida entre eles porque eles compartilham caches. Mas você não pode forçá-los a correr mais rápido – há um limite de velocidade muito específico. Eles continuam melhorando pouco a pouco, mas não tanto. As leis da física impediram melhorias.
Um novo mundo traz novos problemas. NUMA, NVM e hacking de arquitetura
Alexey: Parece muito razoável. Com os novos processadores multi-core surgiram novos problemas. Você e seus colegas esperavam esses problemas? Talvez você os tenha estudado com antecedência? Em estudos teóricos muitas vezes não é muito fácil prever tais coisas. Quando ocorreram problemas, como eles atenderam às suas expectativas e às de seus colegas? Ou eram completamente novos e você e seus colegas tiveram que gastar muito tempo resolvendo problemas à medida que surgiam?
Vitaly: Acrescentarei à pergunta de Alexey: você previu corretamente a arquitetura do processador enquanto estudava a teoria?
Maurício: Não 100%. Mas acho que meus colegas e eu fizemos um bom trabalho prevendo multinúcleos com memória compartilhada. Acho que previmos corretamente as dificuldades no desenvolvimento de estruturas de dados paralelas que operam sem bloqueios. Essas estruturas de dados têm sido importantes para muitas aplicações, embora não para todas, mas muitas vezes o que você realmente precisa é de uma estrutura de dados sem bloqueio. Quando os inventamos, muitos argumentaram que isso era um absurdo, que tudo funcionava bem com fechaduras. Previmos muito bem que haveria soluções prontas para muitos problemas de programação e problemas de estrutura de dados. Havia também problemas mais complexos, como – acesso desigual à memória. Na verdade, eles nem foram considerados até que os processadores multi-core foram inventados porque eram muito específicos. A comunidade de pesquisa estava trabalhando em questões geralmente previsíveis. Alguns problemas de hardware associados a arquiteturas específicas tiveram que esperar nos bastidores - na verdade, o aparecimento dessas arquiteturas. Por exemplo, ninguém realmente trabalhou em estruturas de dados específicas de GPU porque as GPUs não existiam naquela época. Embora muito trabalho tenha sido feito , esses algoritmos estavam prontos para uso assim que o hardware adequado estivesse disponível. Porém, é impossível prever tudo.
Alexey: Se bem entendi, NUMA é uma espécie de compromisso entre custo, desempenho e algumas outras coisas. Alguma idéia de por que NUMA foi lançado tão tarde?
Maurice: Acho que o NUMA existe por causa de problemas com o hardware usado para produzir memória: quanto mais distantes os componentes estão, mais lento é o acesso a eles. Por outro lado, o segundo valor desta abstração é a uniformidade da memória. Portanto, uma das características da computação paralela é que todas as abstrações são ligeiramente quebradas. Se o acesso fosse perfeitamente uniforme, toda a memória seria equidistante, mas isso é economicamente, e talvez até fisicamente, impossível. Portanto surge este conflito. Se você escrever seu programa como se a memória fosse uniforme, provavelmente ele estará correto. No sentido de que não dará respostas erradas. Mas sua performance também não vai pegar as estrelas do céu. Da mesma forma, se você escrever Sem entender a hierarquia do cache, o bloqueio em si estará correto, mas você pode esquecer o desempenho. De certa forma, você tem que escrever programas que vivam em cima de uma abstração muito simples, mas você tem que enganar as pessoas que lhe deram essa abstração: você tem que saber que por baixo da abstração existe alguma hierarquia de memória, que existe um ônibus entre você e essa memória, e assim por diante. Assim, existe algum conflito entre abstrações individualmente úteis, o que nos leva a problemas muito concretos e pragmáticos.
Vitaly: E quanto ao futuro? Você pode prever como os processadores se desenvolverão a seguir? Existe a ideia de que uma das respostas seja a memória transacional. Você provavelmente tem algo mais em estoque.
Maurice: Existem alguns desafios importantes pela frente. Uma delas é que a memória coerente é uma abstração maravilhosa, mas começa a falhar em casos especiais. Assim, por exemplo, NUMA é um exemplo vivo de algo em que você pode continuar a fingir que existe memória uniforme. Na verdade não, a produtividade vai fazer você chorar. Em algum momento, os arquitetos terão que abandonar a ideia de uma arquitetura de memória única; você não pode fingir para sempre. Serão necessários novos modelos de programação que sejam fáceis de usar e poderosos o suficiente para tornar o hardware subjacente eficiente. Este é um compromisso muito difícil, porque se você mostrar aos programadores a arquitetura que é realmente usada no hardware, eles enlouquecerão. É muito complicado e não portátil. Se você apresentar uma interface muito simples, o desempenho será ruim. Assim, muitas compensações muito difíceis precisarão ser feitas para fornecer modelos de programação úteis aplicáveis a processadores multi-core verdadeiramente grandes. Não tenho certeza se alguém que não seja um especialista seja capaz de programar em um computador com 2000 núcleos. E a menos que você esteja fazendo computação ou criptografia muito especializada ou científica ou algo parecido - ainda não está claro como fazê-lo corretamente.
Outra área semelhante são as arquiteturas especializadas. Os aceleradores gráficos já existem há muito tempo, mas se tornaram um exemplo clássico de como você pode pegar um tipo especializado de computação e executá-lo em um chip dedicado. Isto acrescenta seus próprios desafios: como você se comunica com tal dispositivo, como você o programa. Recentemente tenho trabalhado em problemas na área . Você pega um pequeno processador e cola-o em um grande pedaço de memória para que a memória funcione na velocidade do cache L1 e então se comunique com um dispositivo como – o processador está ocupado carregando novas tarefas em seu núcleo de memória. Projetar estruturas de dados e protocolos de comunicação para esse tipo de coisa é outro exemplo interessante. Portanto, processadores e hardware personalizados continuarão a receber melhorias por algum tempo.
Alexey: E quanto à memória não volátil ()?
Maurice: Ah, esse é outro ótimo exemplo! A NVM mudará muito a maneira como vemos coisas como estruturas de dados. A memória não volátil, de certa forma, promete realmente acelerar as coisas. Mas isso não facilitará a vida porque a maioria dos processadores, caches e registros ainda são voláteis. Quando você inicia após uma falha, seu estado e o estado de sua memória não serão exatamente os mesmos de antes da falha. Sou muito grato às pessoas que trabalham com NVM – haverá muito o que os pesquisadores farão por muito tempo tentando descobrir as condições de correção. Os cálculos estão corretos se puderem sobreviver a uma falha na qual o conteúdo dos caches e dos registradores é perdido, mas a memória principal permanece intacta.
Compiladores vs processadores, RISC vs CISC, memória compartilhada vs passagem de mensagens
Vladimir: O que você acha do dilema “compiladores versus processadores” do ponto de vista do conjunto de instruções? Deixe-me explicar para quem não sabe: se formos para memória distorcida ou algo semelhante, poderíamos usar um conjunto de comandos muito simples e pedir ao compilador para gerar um código complexo que possa aproveitar as novas vantagens. Ou podemos fazer o contrário: implementar instruções complexas e pedir ao processador para reordenar as instruções e fazer outras manipulações com elas. O que você acha disso?
Maurice: Eu realmente não tenho uma resposta para essa pergunta. Esse debate já dura quatro décadas. Houve um tempo em que entre um conjunto de comandos e as guerras civis foram travadas por um conjunto de comandos. Por um tempo, o pessoal da RISC venceu, mas depois a Intel reconstruiu seus motores para que um conjunto reduzido de instruções fosse usado internamente e o conjunto completo fosse exportado externamente. Este é provavelmente um tema em que cada nova geração deve encontrar os seus próprios compromissos e tomar as suas próprias decisões. É muito difícil prever qual destas coisas será melhor. Portanto, qualquer previsão que eu fizer será verdadeira por um certo tempo, e depois falsa novamente por um tempo, e então verdadeira novamente.
Alexey: Quão comum é para a indústria que algumas ideias ganhem durante várias décadas e percam nas próximas? Existem outros exemplos de tais mudanças periódicas?
Maurice: No tema computação distribuída, há pessoas que acreditam em e pessoas que acreditam . Inicialmente, na computação distribuída, computação paralela significa passagem de mensagens. Então alguém descobriu que era muito mais fácil programar com memória compartilhada. O lado oposto disse que a memória compartilhada é muito complicada porque requer bloqueios e coisas do gênero, então vale a pena mudar para linguagens onde simplesmente existe apenas a passagem de mensagens. Alguém olhou o que resultou disso e disse: “uau, essa implementação de mensagens se parece muito com memória compartilhada, porque você cria muitos e muitos desses pequenos módulos, eles enviam mensagens uns para os outros e todos eles “Vamos criar um banco de dados de memória compartilhada melhor!” Tudo isso se repete continuamente e é impossível dizer que uma das partes está definitivamente certa. Um dos lados sempre dominará porque assim que um deles quase vence, as pessoas inventam repetidamente maneiras de melhorar o outro.
A arte de escrever código multithread frágil
Alexei: Isso é muito interessante. Por exemplo, quando escrevemos código, não importa qual linguagem de programação, geralmente temos que criar abstrações como células que podem ser lidas e escritas. Mas, na verdade, em algum nível físico, isso pode parecer o envio de uma mensagem através de um barramento de hardware entre diferentes computadores e outros dispositivos. Acontece que o trabalho está acontecendo nos dois níveis de abstração ao mesmo tempo.
Maurice: É absolutamente verdade que a memória compartilhada é construída na passagem de mensagens – barramentos, caches e assim por diante. Mas é difícil escrever programas usando passagem de mensagens, então o hardware mente deliberadamente, fingindo que você tem algum tipo de memória uniforme. Isso tornará mais fácil escrever programas simples e corretos antes que o desempenho comece a piorar. Aí você dirá: parece que está na hora de fazer amizade com o cache. E aí você começa a se preocupar com a localização do cache, e daí vai. De certa forma, você está hackeando a abstração: você sabe que não se trata apenas de memória plana e uniforme e usará esse conhecimento para escrever programas compatíveis com cache. Isto é o que você terá que fazer em problemas reais. Este conflito entre a abstração doce, simples e agradável que você recebeu e a implementação terrivelmente complexa do hardware subjacente é onde todos farão seus próprios compromissos. Tenho um livro sobre multiprocessadores e sincronização e, a certa altura, ia escrever um capítulo sobre estruturas de dados em java.util.concurrent. Se você olhar para eles, coisas como São obras de arte incríveis. (Nota do editor: Aqueles familiarizados com a linguagem Java deveriam pelo menos dar uma olhada na implementação ConcurrentSkipListMap, você pode ver os links em и ). Mas, do meu ponto de vista, seria irresponsável mostrá-los aos alunos, porque uma estrutura de dados deste tipo é como um tipo num circo a correr numa corda bamba sobre uma cova de ursos. Se você alterar mesmo um pequeno detalhe, toda a estrutura entrará em colapso. Este código é muito rápido e elegante simplesmente porque foi escrito perfeitamente, mas a menor alteração levará ao fracasso total. Se eu der este código como exemplo aos alunos, eles dirão imediatamente: eu também posso fazer isso! E então algum avião cairá ou um reator nuclear explodirá, e eu serei culpado de lhes dar muita informação na hora errada.
Alexey: Quando eu era um pouco mais jovem, muitas vezes tentei estudar o código-fonte de Doug Lee, por exemplo, java.util.concurrent, por ser open source, é muito fácil de encontrar e tentar entender o que está acontecendo ali. Não deu muito certo: muitas vezes não fica claro por que Doug decidiu fazer algo dessa maneira, quando todo mundo está fazendo de maneira diferente. Como você explica essas coisas para seus alunos? Existe uma maneira correta de descrever detalhes específicos de um algoritmo hardcore, por exemplo? Como você faz isso?
Maurice: Os professores de desenho têm um clichê do qual se lembram primeiro: se você quiser desenhar como Picasso, primeiro você precisa aprender a desenhar imagens simples e realistas, e somente quando conhecer as regras poderá começar a quebrá-las. Se você começar quebrando as regras imediatamente, acabará em uma confusão. Primeiro, ensino aos alunos como escrever código simples e correto, sem se preocupar com o desempenho. O que estou dizendo é que existem problemas complexos de tempo à espreita aqui, então não se preocupe com caches, não se preocupe com modelos de memória, apenas certifique-se de que tudo funcione corretamente. Isto já é bastante difícil: a programação moderna não é fácil por si só, especialmente para novos alunos. E quando eles têm uma intuição sobre como escrever os programas certos, eu digo: olhem essas duas implementações de spinlock: uma é muito lenta e a segunda também não é muito, mas melhor. No entanto, matematicamente os dois algoritmos são iguais. Na verdade, um deles usa localidade de cache. Um deles é executado em dados armazenados em cache localmente e o outro executa operações repetidamente no barramento. Você não pode escrever código eficiente se não entender o que é e não souber como quebrar a abstração e observar a estrutura subjacente. Mas você não poderá começar a fazer isso imediatamente. Tem gente que começa a fazer isso logo e acredita na própria genialidade, geralmente acaba mal porque não entende os princípios. Ninguém desenha como Picasso ou escreve programas como Doug Lee, recém-saído da faculdade, na primeira semana. Leva anos para atingir esse nível de conhecimento.
Alexey: Acontece que você divide o problema em duas partes: a primeira é a correção, a segunda é o desempenho?
Maurício: Exatamente. E, exatamente nessa ordem. Parte do problema é que os novos alunos não entendem que é difícil conseguir a correção. À primeira vista dizem: isso está obviamente correto, só falta agilizar. Então, às vezes, conto a eles sobre um algoritmo inicialmente incorreto, como se estivesse correto.
Como ensinar os alunos a escrever código multithread complexo
Alexey: Só para ver se eles conseguem sentir o problema?
Maurice: Sempre aviso com antecedência que às vezes irei propor algoritmos incorretos. Você não deve enganar as pessoas. Eu sugiro que eles considerem as informações com cautela. Se eu contar algo e disser: “olha, isso está obviamente correto” - isso é um sinal de que em algum lugar eles estão tentando enganá-lo, e você deve começar a fazer perguntas. Em seguida, tento incentivar os alunos a continuarem a fazer perguntas e depois sugiro: “O que acontecerá se deixarmos as coisas como estão?” E eles imediatamente percebem o erro. Mas convencer os alunos de que eles precisam se preocupar com a correção é muito mais difícil do que parece à primeira vista. Muitos desses alunos têm experiência em programação no ensino médio, alguns conseguiram empregos e programaram lá, e todos estão cheios de confiança. Isso é algo como o exército: primeiro você precisa mudar o humor deles para convencê-los a abordar com paciência a solução dos problemas que surgirem. Ou talvez seja como os monges budistas: primeiro eles aprendem a raciocinar sobre a correção e, uma vez que entendem as formas de raciocinar sobre a correção, podem passar para o próximo nível e começar a se preocupar com o desempenho.
Alexey: Ou seja, às vezes você mostra aos alunos exemplos não funcionais, graças aos quais você obtém feedback mostrando se eles entendem a essência do problema, se conseguem encontrar o código errado e o resultado errado. Então, os alunos costumam te deixar feliz ou triste?
Maurice: Os alunos quase sempre acabam descobrindo o erro. Se eles pesquisarem muito lentamente, eu faço perguntas importantes, e aqui é importante entender que, se você nunca os enganar, eles começarão a perceber inconscientemente suas palavras como a verdade última. Então eles ficarão entediados e começarão a adormecer enquanto lêem o Facebook em seus laptops durante a aula. Mas quando você lhes diz com antecedência que serão enganados e que parecerão estúpidos se não perceberem o truque, eles se tornam muito mais vigilantes. Isso é bom de diferentes maneiras. Gostaria que os alunos não apenas questionassem sua compreensão do assunto, mas também questionassem a autoridade do professor. A ideia é que um aluno possa levantar a mão a qualquer momento e dizer: acho que o que você acabou de dizer está errado. É uma importante ferramenta de aprendizagem. Não quero que nenhum dos alunos se sente e pense silenciosamente: tudo isso parece um absurdo completo, mas levantar a mão é muito assustador e, de qualquer forma, ele é professor, então tudo o que ele diz é verdade. Portanto, se forem avisados com antecedência de que nem tudo o que é dito é necessariamente verdade, eles terão um incentivo para prestar mais atenção ao material. Deixo claro que não há problema em levantar a mão e fazer perguntas. Sua pergunta pode parecer estúpida ou ingênua, mas muitas vezes é assim que surgem as melhores perguntas.
Alexei: Muito interessante. Normalmente as pessoas têm algum tipo de barreira psicológica que não lhes permite fazer perguntas a um professor. Principalmente se houver muitas pessoas na sala e todos tiverem medo de que discutir sua pergunta estúpida ocupe todo o tempo dessas pessoas. Existem truques para lidar com isso?
Maurice: Costumo parar e fazer perguntas clássicas. Se uma afirmação seria correta ou como resolveriam o problema em discussão. Esta é uma ação fundamental, especialmente no início de uma aula, quando as pessoas ficam com vergonha de dizer até mesmo a menor coisa. Você faz uma pergunta aos alunos e não diz mais nada. Há um silêncio, todo mundo fica um pouco tenso, a tensão aumenta, aí de repente alguém não aguenta, desiste e diz a resposta. É assim que você inverte a situação: continuar calado torna-se mais difícil e inconveniente do que responder! Este é um truque pedagógico padrão. Todo professor no mundo deveria saber como fazer isso.
Alexey: Agora temos um excelente título para esta entrevista: “é mais fácil responder do que ficar calado”.
Vitaly: Deixe-me perguntar novamente. Você está trabalhando em provas topológicas. Como você se envolveu nisso, porque computação distribuída e topologia são coisas completamente diferentes!
Maurice: Há uma conexão oculta aí. Quando eu era estudante de matemática, estudei matemática pura. Não tive nenhum interesse real por computadores até que meus estudos terminaram e me vi diante da necessidade premente de procurar emprego. Quando estudante, estudei topologia algébrica. Muitos anos depois, enquanto trabalhava em um problema chamado , usei gráficos para modelar o problema e, como parecia na época, encontrei uma solução. Você apenas tinha que sentar e fazer a contagem. Tente encontrar uma resposta adequada neste gráfico. Mas meu algoritmo não funcionou: descobri que ele ficaria correndo em círculos para sempre. Infelizmente, tudo isso não poderia ser explicado na linguagem formal da teoria dos grafos – aquela que todos os cientistas da computação conhecem. E então me lembrei que há muitos anos, nas aulas de topologia, usávamos o conceito , que é uma generalização de gráficos para dimensões superiores. Então me perguntei: o que aconteceria se reformulássemos o problema em termos de complexos simpliciais? Este se tornou o momento chave. Ao usar um formalismo mais poderoso, o problema torna-se subitamente muito mais simples. As pessoas lutaram muito tempo contra isso, usando gráficos, mas não puderam fazer nada. E mesmo agora eles não conseguem - a resposta correta acabou não sendo um algoritmo, mas uma prova da impossibilidade de resolver o problema. Ou seja, tal algoritmo simplesmente não existe. Mas baseado em complexos simpliciais ou em coisas que as pessoas fingiam não considerar complexos simpliciais. Só porque você chama algo de um novo nome, isso não perde sua essência.
Vitaly: Acontece que você teve sorte?
Maurice: Além da sorte, também é prontidão. Isso significa que você não deve esquecer as coisas “inúteis” que aprendeu anteriormente. Quanto mais coisas inúteis você aprender, mais ideias poderá extrair ao se deparar com um novo problema. Esse tipo de correspondência intuitiva de padrões é importante porque... Vamos fazer isso, isso é uma cadeia: no começo descobri que os gráficos não funcionavam ou não funcionavam de jeito nenhum, me lembrou algo dos eventos de oito anos atrás e meus anos de estudante, quando estudamos todos esses complexos simpliciais. Isso, por sua vez, me permitiu encontrar meu antigo livro de topologia e carregá-lo de volta na minha cabeça. Mas se não fosse por esse conhecimento antigo, eu nunca teria feito qualquer progresso na resolução do problema original.
Nova edição do livro “A Arte da Programação Multiprocessador”
Alexey: Você disse algumas palavras sobre o seu livro. Provavelmente não é o pior segredo que você escreveu o livro mais famoso do mundo sobre multithreading, . Já tem cerca de 11 anos e desde então só foi lançado . Haverá uma segunda edição?
Maurice: Que bom que você perguntou! Será muito em breve, daqui a três meses ou mais. São mais dois autores, adicionamos muito mais material, melhoramos a seção sobre paralelismo fork/join, escrevemos uma seção sobre MapReduce, adicionamos muitas coisas novas e jogamos fora coisas desnecessárias - algo que foi muito interessante no momento da escrita a primeira edição, mas não existe mais hoje. O resultado foi um livro seriamente revisado.
Alexey: Já está tudo feito, só falta liberar?
Maurice: Alguns capítulos ainda precisam de trabalho. Nosso editor (que acho que já nos odeia) ainda está tentando transmitir a mensagem de que deveríamos trabalhar mais rápido. Estamos muito atrasados. Teoricamente, poderíamos ter feito este livro alguns anos antes.
Alexey: Alguma chance de conseguir uma nova versão do livro antes do Natal?
Maurício: Esse é o nosso objetivo! Mas já previ a vitória tantas vezes que ninguém mais acredita em mim. Você provavelmente também não deveria confiar muito em mim neste assunto.
Alexey: De qualquer forma, esta é uma notícia fantástica. Gostei muito da primeira edição do livro. Você poderia dizer que sou um fã.
Maurice: Espero que a nova edição seja digna do seu fervoroso entusiasmo, obrigado!
Como a memória transacional foi inventada
Vitaly: A próxima pergunta é sobre memória transacional. Pelo que entendi, você é um pioneiro nessa área, você inventou numa época em que ninguém pensava nessas coisas. Por que você decidiu entrar nesta área? Por que as transações pareciam importantes para você? Você achou que algum dia eles seriam implementados em hardware?
Maurice: Conheço transações desde meus tempos de pesquisa de pós-graduação.
Vitaly: Sim, mas são transações diferentes!
Maurice: Trabalhei com Elliott Moss na coleta de lixo sem bloqueios. Nosso problema era que queríamos alterar atomicamente algumas palavras na memória e então os algoritmos se tornariam muito simples, e pelo menos alguns deles se tornariam mais eficientes. Usando para fornecido pela arquitetura paralela, é possível fazer alguma coisa, mas é muito ineficiente e feio porque você teria que lidar com camadas de indireção. Quero alterar as palavras da memória e preciso mudar porque só posso alterar um ponteiro, então elas precisam apontar para algum tipo de estrutura semelhante a um diretório. Conversamos sobre como seria ótimo se pudéssemos mudar o hardware para que pudesse fazer gravações simultâneas. Elliott parece ter notado isso: se você observar os protocolos de coerência de cache, verá que eles já fornecem a maior parte da funcionalidade necessária. Em uma transação otimista, o protocolo de coerência de cache perceberá que há um conflito de temporização e o cache se tornará . O que acontece se você executar especulativamente uma transação em seu cache e usar os mecanismos do protocolo de coerência para detectar conflitos? A arquitetura especulativa de hardware foi fácil de projetar. Então nós escrevemos aquele sobre memória transacional. Ao mesmo tempo, a empresa para a qual eu trabalhava, a Digital Equipment Corporation, estava criando um novo processador de 64 bits chamado Alpha. Então fiz uma apresentação ao grupo de desenvolvimento Alpha sobre nossa incrível memória transacional e eles perguntaram: Quanta receita adicional nossa empresa obteria se adicionássemos tudo isso diretamente ao processador? E eu não tinha absolutamente nenhuma resposta para isso, porque sou tecnólogo, não sou especialista em marketing. Eu realmente não tinha nada para responder. Eles não ficaram muito impressionados por eu não saber de nada.
Vitaly: Bilhões! Basta dizer bilhões!
Maurice: Sim, era isso que eu deveria ter dito. Agora, na era das startups e tudo mais, sei escrever um plano de negócios. Que você pode mentir um pouco sobre o tamanho do seu lucro potencial. Mas naquela época parecia ingênuo, então eu apenas disse: “Não sei”. Se você observar a história da publicação sobre memória transacional, notará que depois de um ano houve várias referências a ela e, por cerca de dez anos, ninguém citou esse artigo. As cotações surgiram por volta de 2004, quando surgiram os verdadeiros multi-cores. Quando as pessoas descobriram que escrever código paralelo poderia gerar dinheiro, novas pesquisas começaram. Ravi Rajwar , que de alguma forma introduziu o conceito de memória transacional no mainstream. (Nota do editor: existe uma segunda versão deste artigo, lançada em 2010 e disponível gratuitamente ). De repente, as pessoas perceberam exatamente como tudo isso poderia ser usado, como os algoritmos tradicionais com bloqueios poderiam ser acelerados. Um bom exemplo de algo que no passado parecia apenas um problema acadêmico interessante. E sim, se naquela altura me tivessem perguntado se eu achava que tudo isto seria importante no futuro, eu teria dito: claro, mas quando exactamente não está claro. Talvez em 50 anos? Na prática, isso durou apenas uma década. É muito bom quando você faz alguma coisa e depois de apenas dez anos as pessoas percebem.
Por que vale a pena realizar pesquisas na área de computação distribuída
Vitaly: Se falarmos sobre novas pesquisas, o que você aconselharia aos leitores - computação distribuída ou multi-core e por quê?
Maurice: Hoje em dia é fácil conseguir um processador multi-core, mas é mais difícil configurar um verdadeiro sistema distribuído. Comecei a trabalhar neles porque queria fazer algo diferente da minha tese de doutorado. Este é o conselho que sempre dou aos novos alunos: não escreva uma continuação da sua dissertação – tente seguir uma nova direção. E também, multithreading é fácil. Posso experimentar meu próprio garfo rodando em meu laptop sem sair da cama. Mas se de repente eu quisesse criar um sistema distribuído real, teria que trabalhar muito, atrair estudantes e assim por diante. Sou uma pessoa preguiçosa e prefiro trabalhar com multi-core. Experimentar em sistemas multi-core também é mais fácil do que fazer experimentos em sistemas distribuídos, porque mesmo em um sistema distribuído estúpido há muitos fatores que precisam ser controlados.
Vitaly: O que você está fazendo agora, pesquisando blockchain? Em quais artigos você deve prestar atenção primeiro?
Maurício: Apareceu recentemente , que escrevi junto com meu aluno, Vikram Saraf, especialmente para uma palestra em em Paris há três semanas. Este é um artigo sobre sistemas distribuídos práticos, no qual propomos tornar o Ethereum multithread. Atualmente, os contratos inteligentes (código que roda no blockchain) são executados sequencialmente. Escrevemos um artigo anteriormente que falava sobre uma maneira de usar transações especulativas para acelerar o processo. Pegamos muitas ideias da memória transacional de software e dissemos que se você tornar essas ideias parte da máquina virtual Etherium, tudo funcionará mais rápido. Mas para isso é necessário que não haja conflitos de dados nos contratos. E então presumimos que na vida real realmente não existem tais conflitos. Mas não tínhamos como descobrir. Então nos ocorreu que tínhamos quase uma década de histórico de contratos reais em nossas mãos, então descartamos o blockchain Ethereum e nos perguntamos: o que aconteceria se esses registros históricos fossem executados em paralelo? Encontramos um aumento significativo na velocidade. Nos primeiros tempos do Ethereum, a velocidade aumentou muito, mas hoje tudo é um pouco mais complicado, porque há menos contratos e a probabilidade de conflitos sobre dados que requerem serialização tornou-se maior. Mas tudo isso é trabalho experimental com dados históricos reais. O bom do blockchain é que ele se lembra de tudo para sempre, então podemos voltar no tempo e estudar o que teria acontecido se tivéssemos usado algoritmos diferentes para executar o código. Como as pessoas no passado teriam gostado da nossa nova ideia? Essa pesquisa é muito mais fácil e gostosa de fazer, porque tem uma coisa que monitora tudo e registra tudo. Isso já é algo mais parecido com a sociologia do que com o desenvolvimento de algoritmos.
O desenvolvimento de algoritmos parou e como seguir em frente?
Vitaly: Hora da última questão teórica! Parece que o progresso nas estruturas de dados competitivas está diminuindo a cada ano? Você acha que atingimos um patamar em nossa compreensão das estruturas de dados ou haverá algumas melhorias importantes? Talvez existam algumas ideias inteligentes que podem mudar tudo completamente?
Maurice: Podemos ter alcançado um patamar nas estruturas de dados para arquiteturas tradicionais. Mas as estruturas de dados para novas arquiteturas ainda são uma área muito promissora. Se você deseja criar estruturas de dados para, digamos, aceleradores de hardware, então as estruturas de dados de uma GPU são muito diferentes das estruturas de dados de uma CPU. Ao desenvolver estruturas de dados para blockchains, você precisa fazer hash de pedaços de dados e depois colocá-los em algo como , para evitar a falsificação. Tem havido um aumento de atividade nesta área ultimamente, com muitos fazendo um trabalho muito bom. Mas penso que o que acontecerá é que novas arquiteturas e novas aplicações levarão a novas estruturas de dados. Aplicativos legados e arquitetura tradicional – talvez não haja mais muito espaço para exploração. Mas se você sair do caminho tradicional e olhar além dos limites, verá coisas malucas que o mainstream não leva a sério - é aí que todas as coisas interessantes realmente acontecem.
Vitaly: Portanto, para ser um pesquisador muito famoso, tive que inventar minha própria arquitetura :)
Maurice: Você pode “roubar” a nova arquitetura de outra pessoa – parece muito mais fácil!
Trabalhando na Universidade Brown
Vitaly: Você poderia nos contar mais sobre onde você trabalha? Não se sabe muito sobre ele no contexto da tecnologia da informação. Menos do que o MIT, por exemplo.
Maurice: A Brown University é uma das universidades mais antigas dos Estados Unidos. Acho que só Harvard é um pouco mais velha. Brown faz parte do chamado , que é um conjunto de oito universidades mais antigas. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pensilvânia, Princeton. É uma universidade antiga, pequena e um pouco aristocrática. O foco principal está na educação em artes liberais. Não é tentar ser como o MIT, o MIT é muito especializado e técnico. Brown é um ótimo lugar para estudar Literatura Russa ou Grego Clássico e, claro, Ciência da Computação. Tem como foco a educação integral. A maioria dos nossos alunos acessa o Facebook, Apple, Google - então acho que nossos alunos não têm problemas para encontrar um emprego na indústria. Fui trabalhar na Brown porque já havia trabalhado na Digital Equipment Corporation em Boston. Esta foi uma empresa que inventou muitas coisas interessantes, mas negou a importância dos computadores pessoais. Uma empresa com um destino difícil, cujos fundadores foram outrora jovens revolucionários, nada aprenderam e nada esqueceram, e assim passaram de revolucionários a reacionários em cerca de uma dúzia de anos. Eles gostavam de brincar que os computadores pessoais pertenciam à garagem – uma garagem abandonada, é claro. É bastante óbvio que foram destruídos por empresas mais flexíveis. Quando ficou claro que a empresa estava com problemas, liguei para um amigo meu em Brown, que fica a cerca de uma hora de Boston. Eu não queria sair de Boston naquela época porque não havia muitas vagas em outras universidades. Esta foi uma época em que não havia tantos empregos em Ciência da Computação como há agora. E Brown teve uma vaga, não precisei mudar de casa, não precisei mudar minha família e adoro morar em Boston! Foi assim que decidi ir para Brown. Eu gosto disso. Os alunos são maravilhosos, então nunca tentei ir para outro lugar. Durante meu período sabático, trabalhei na Microsoft por um ano, fui para o Technion em Haifa por um ano e agora estarei na Algorand. Tenho muitos colegas em todos os lugares e, portanto, a localização física das nossas salas de aula não é tão importante. Mas o mais importante são os alunos, eles são os melhores aqui. Nunca tentei ir para outro lugar porque estou muito feliz aqui.
No entanto, apesar da fama de Brown nos Estados Unidos, ele é surpreendentemente desconhecido no exterior. Como podem ver, estou agora a fazer todo o possível para corrigir esta situação.
Diferença entre pesquisa em uma universidade e dentro de uma empresa
Vitaly: Ok, a próxima pergunta é sobre Equipamentos Digitais. Você estava lá como pesquisador. Qual a diferença entre trabalhar no departamento de P&D de uma grande empresa e trabalhar em uma universidade? Quais são as vantagens e desvantagens?
Maurice: Durante vinte anos trabalhei na Microsoft, trabalhei em estreita colaboração com funcionários da Sun Microsystems, Oracle, Facebook e agora Algorand. Com base em tudo isso, quero dizer que é possível realizar pesquisas de primeira linha tanto nas empresas quanto nas universidades. A diferença importante é que numa empresa você trabalha com colegas. Se de repente eu tiver uma ideia para um projeto que ainda não existe, devo convencer meus colegas de que é uma boa ideia. Se estou na Brown, posso dizer aos meus alunos: vamos trabalhar na antigravidade! Eles partirão para outra pessoa ou assumirão um projeto. Sim, precisarei encontrar financiamento, redigir um pedido de subsídio e assim por diante. De qualquer forma, sempre haverá muitos alunos e você poderá tomar decisões unilateralmente. Mas na universidade você provavelmente não trabalhará com pessoas do seu nível. No mundo da pesquisa industrial, primeiro você precisa convencer a todos de que vale a pena realizar seu projeto. Não posso pedir nada a ninguém. E ambas as formas de trabalhar são valiosas, porque se você está trabalhando em algo realmente maluco e seus colegas são difíceis de convencer, é mais fácil convencer estudantes de pós-graduação - especialmente se você os pagar. Se você está trabalhando em algo que exige muita experiência e profundo conhecimento, então você precisa de colegas que possam dizer “não, acontece que eu entendo nessa área e sua ideia é ruim, não vai funcionar”. Isto é muito útil em termos de perda de tempo. Além disso, se nos laboratórios industriais você passa muito tempo escrevendo relatórios, na universidade você gasta esse tempo tentando encontrar dinheiro. Se eu quiser que os alunos possam ir a algum lugar, tenho que encontrar dinheiro para isso em outro lugar. E quanto mais importante for a sua posição na universidade, mais tempo você terá para gastar arrecadando dinheiro. Então agora você sabe para que trabalho - um mendigo profissional! Como um daqueles monges que anda por aí com um prato de oferendas. Em geral, estas duas atividades complementam-se. É por isso que tento viver e manter os pés no chão nos dois mundos.
Vitaly: Parece que convencer uma empresa é mais difícil do que convencer outros cientistas.
Maurice: Mais difícil e muito mais. Além disso, em diferentes áreas é diferente: alguns realizam pesquisas em grande escala, enquanto outros se concentram no seu tema. Se eu fosse à Microsoft ou ao Facebook e dissesse: vamos fazer antigravidade, dificilmente eles iriam gostar. Mas se eu dissesse exatamente a mesma coisa aos meus alunos de pós-graduação, eles provavelmente começariam a trabalhar instantaneamente, embora agora eu tivesse problemas - afinal, preciso encontrar dinheiro para isso. Mas desde que você queira fazer algo que se alinhe aos objetivos da empresa, essa empresa pode ser um ótimo lugar para fazer pesquisas.
Hidra e SPTDC
Vitaly: Minhas perguntas estão chegando ao fim, então vamos falar um pouco sobre a próxima viagem à Rússia.
Maurice: Sim, estou ansioso para voltar a São Petersburgo.
Alexey: Estou honrado em ter você conosco este ano. Esta é a sua segunda vez em São Petersburgo, certo?
Maurice: Já é o terceiro!
Alexei: Eu entendo, mas – definitivamente o segundo. A última vez que a escola foi chamada , agora alteramos uma letra (C para D, Simultâneo para Distribuído) para enfatizar que há mais áreas relacionadas especificamente à computação distribuída este ano. Você pode dizer algumas palavras sobre seus relatórios na Escola e ?
Maurice: Na Escola quero falar sobre o básico do blockchain e o que você pode fazer com ele. Gostaria de mostrar que blockchains são muito semelhantes à programação multithread com a qual estamos familiarizados, mas com nuances próprias, e é importante entender essas diferenças. Se você cometer um erro em um aplicativo da web normal, será simplesmente irritante. Se você escrever um código com erros em um aplicativo financeiro, alguém certamente roubará todo o seu dinheiro. Estes são níveis completamente diferentes de responsabilidade e consequências. Falarei um pouco sobre prova de trabalho, sobre contratos inteligentes, sobre transações entre diferentes blockchains.
Haverá outros palestrantes trabalhando ao meu lado que também terão algo a dizer sobre blockchain, e concordamos em nos coordenar para que nossas histórias se encaixem bem. Mas para o relatório de engenharia, quero dar a um público amplo uma explicação compreensível de por que você não deve acreditar em tudo que ouve sobre blockchains, por que blockchains são um grande campo, como ele se encaixa com outras ideias conhecidas e por que devemos olhar com ousadia para o futuro.
Alexey: Além disso, quero dizer que isso não acontecerá no formato de encontro ou grupo de usuários, como acontecia há dois anos. Decidimos realizar uma pequena conferência perto da escola. A razão é que depois de nos comunicarmos com Peter Kuznetsov, percebemos que a escola está limitada a apenas cem, talvez 120 pessoas. Ao mesmo tempo, há muitos engenheiros que desejam se comunicar com você, assistir a apresentações e geralmente estão interessados no assunto. Por esta razão criamos uma nova conferência . A propósito, alguma ideia do porquê Hydra?
Maurice: Porque serão sete palestrantes? E suas cabeças podem ser cortadas e novos oradores crescerão em seu lugar?
Alexey: Ótima ideia para desenvolver novos palestrantes. Mas, na verdade, há uma história aqui. Lembre-se da lenda de Odisseu, onde ele teve que navegar entre ? Hydra é algo como Caríbdis. A história é que uma vez falei em uma conferência e falei sobre multithreading. Havia apenas duas faixas nesta conferência. No início da reportagem, eu disse ao público presente que agora eles podiam escolher entre Cila e Caríbdis. Meu espírito animal é Charybdis porque Charybdis tem muitas cabeças e meu tema é multi-threading. É assim que aparecem os nomes das conferências.
De qualquer forma, ficamos sem perguntas e sem tempo. Então, obrigado, amigos, pela ótima entrevista, e nos vemos na SPTDC School e na Hydra 2019!
Você pode continuar sua conversa com Maurice na conferência Hydra 2019, que será realizada de 11 a 12 de julho de 2019 em São Petersburgo. Ele virá com um relatório . Os ingressos podem ser adquiridos .
Fonte: habr.com