- el dueño de dos. La primera es para el trabajo. (Universidad de Brown) y el segundo, más reciente, - (Universidad Tecnológica de Virginia). El Premio Dijkstra se otorga a obras cuya importancia e influencia han sido notorias durante al menos diez años y, obviamente, Maurice es uno de los especialistas más famosos en el campo. Actualmente es profesor en la Universidad de Brown y tiene logros de un párrafo. Ahora se dedica a la investigación de blockchain en el contexto de la computación distribuida clásica.
Anteriormente, Maurice ya ha venido a Rusia para SPTCC () e hizo una excelente reunión de la comunidad de desarrolladores de Java JUG.ru en San Petersburgo ().
Este habrapost es una gran entrevista con Maurice Herlihy. Trata los siguientes temas:
- Interacción entre la academia y la industria;
- Fundación para la investigación de blockchain;
- ¿De dónde vienen las ideas innovadoras? Influencia de la popularidad;
- PhD bajo la dirección de Barbara Liskov;
- El mundo está esperando multinúcleo;
- Nuevo mundo, nuevos problemas. NVM, NUMA y piratería de arquitectura;
- Compiladores frente a CPU, RISC frente a CISC, memoria compartida frente a paso de mensajes;
- El arte de escribir código frágil de múltiples subprocesos;
- Cómo enseñar a los estudiantes cómo escribir código complejo de subprocesos múltiples;
- Nueva edición del libro "El Arte de la Programación Multiprocesador";
- ¿Cómo se inventó la memoria transaccional?
- Por qué vale la pena investigar en el campo de la computación distribuida;
- ¿Se ha detenido el desarrollo de algoritmos y cómo seguir viviendo?
- Trabajo en la Universidad de Brown;
- La diferencia entre investigación universitaria y corporativa;
- Hydra y SPTDC.
Las entrevistas son realizadas por:
Vitali Aksenov — actualmente un postdoctorado en IST Austria y un empleado del Departamento de Tecnologías Informáticas de la Universidad ITMO. Se dedica a la investigación en el campo de la teoría y la práctica de estructuras de datos competitivas. Antes de unirse a IST, recibió su doctorado de la Universidad Paris Diderot y la Universidad ITMO con el Prof. Petr Kuznetsov.
Alexey Fedorov es productor en JUG Ru Group, una empresa rusa que organiza conferencias para desarrolladores. Alexey participó en la preparación de más de 50 conferencias, y su currículum contiene desde el puesto de ingeniero de desarrollo en Oracle (JCK, Java Platform Group) hasta el puesto de desarrollador en Odnoklassniki.
Vladímir Sitnikov es ingeniero en Netcracker. Durante diez años ha estado trabajando en el rendimiento y la escalabilidad de NetCracker OS, un software utilizado por los operadores de telecomunicaciones para automatizar los procesos de gestión de redes y equipos de red. Interesado en problemas de rendimiento de Java y Oracle Database. Autor de más de una docena de mejoras de rendimiento en el controlador JDBC oficial de PostgreSQL.
Interacción entre la academia y la industria
Alexey: Maurice, has estado trabajando en el mundo académico durante mucho tiempo y la primera pregunta es sobre la interacción entre el mundo académico y la industria. ¿Podría decirnos cómo han cambiado las interacciones entre ellos últimamente? ¿Qué fue hace 20-30 años y qué está pasando ahora?
Maurice: Siempre he tratado de trabajar de cerca con empresas comerciales porque tienen desafíos interesantes. Por regla general, no están muy interesados en publicar sus resultados o en explicaciones detalladas de sus problemas a la comunidad mundial. Sólo les interesa resolver estos problemas. Trabajé para algunas de estas empresas durante un tiempo. Pasé cinco años trabajando a tiempo completo en un laboratorio de investigación en Digital Equipment Corporation, que solía ser una importante empresa informática. Trabajé un día a la semana en Sun, en Microsoft, en Oracle, trabajé un poco en Facebook. Ahora voy a tomarme una licencia sabática (a un profesor de una universidad estadounidense se le permite tomar esas vacaciones durante un año aproximadamente una vez cada seis años) y trabajaré en , esta es una empresa de criptomonedas en Boston. Trabajar en estrecha colaboración con las empresas siempre ha sido un placer, porque así es como aprendes cosas nuevas e interesantes. Por lo general, puede ser la primera o la segunda persona en publicar un artículo sobre un tema elegido, en lugar de mejorar gradualmente las soluciones a los problemas en los que todos los demás ya están trabajando.
Alexey: ¿Puedes contarnos más sobre cómo sucede esto?
mauricio: por supuesto. Sabes, cuando estaba en Digital Equipment Corporation, Elliot Moss y yo inventamos la memoria transaccional. Fue un período muy fructífero en el que todo el mundo empezó a interesarse por las tecnologías de la información. Concurrencia incluida, aunque aún no existían sistemas multinúcleo. En los días de Sun y Oracle, trabajé mucho en estructuras de datos paralelas. En Facebook, participé en su proyecto de cadena de bloques, del que no puedo hablar, pero espero que se haga público pronto. El próximo año, en Algorand, estaré trabajando en un equipo de investigación que estudiará contratos inteligentes.
Alexey: En los últimos años, blockchain se ha convertido en un tema muy popular. ¿Ayudará a su investigación? ¿Quizás facilitará la obtención de subvenciones o dará acceso a los recursos de las empresas que operan en la industria?
Maurice: Ya he recibido una pequeña subvención de la Fundación Ethereum. La popularidad de blockchain es muy útil para inspirar a los estudiantes a trabajar en este campo. Están muy interesados en él y felices de participar, pero a veces no se dan cuenta de que la investigación que suena tentadora en el exterior resulta ser un trabajo muy duro. Sin embargo, estoy muy feliz de usar toda esta mística en torno a la cadena de bloques, ayuda a atraer estudiantes.
Pero eso no es todo. Estoy en el consejo asesor de varias nuevas empresas de blockchain. Algunos de ellos pueden tener éxito, algunos de ellos no, pero siempre es muy interesante ver sus ideas, estudiarlas y asesorar a la gente. Lo más emocionante es cuando le adviertes a la gente que no haga algo. Muchas cosas parecen una buena idea al principio, pero ¿lo son realmente?
Fundación para la investigación de blockchain
Vitaly: Algunas personas piensan que blockchain y sus algoritmos son el futuro. Y otras personas dicen que es solo otra burbuja. ¿Puedes compartir tu opinión sobre este asunto?
Maurice: Mucho de lo que sucede en el mundo de la cadena de bloques no funciona correctamente, algunos son solo estafas, muchas cosas están sobrevaloradas. Sin embargo, creo que hay una base científica sólida para estos estudios. El hecho de que el mundo blockchain esté lleno de divisiones ideológicas muestra el nivel de entusiasmo y dedicación. Por otro lado, no es particularmente beneficioso para la investigación científica. Ahora bien, si publicas un artículo que habla sobre las deficiencias de un algoritmo en particular, la reacción recibida no siempre es del todo científica. A menudo, las personas expresan sus emociones. Creo que tal exageración en esta área puede parecer atractiva para algunos, pero al final, hay cuestiones científicas y de ingeniería reales que aún no se han abordado. Aquí hay mucha informática.
Vitaliy: Entonces, estás tratando de sentar las bases para la investigación de blockchain, ¿verdad?
Maurice: Estoy tratando de sentar las bases para una disciplina sólida, científica y matemáticamente sólida. Y parte del problema es que a veces tienes que contradecir algunas de las posiciones demasiado duras de otras personas para ignorarlas. A veces la gente me pregunta por qué trabajo en un campo que solo interesa a los terroristas y narcotraficantes. Tal reacción es tan insignificante como el comportamiento de los seguidores que repiten ciegamente tus palabras. Creo que la verdad está en algún lugar en el medio. Blockchain aún no ha tenido un impacto profundo en la sociedad y la economía global. Pero, probablemente, esto no sucederá gracias a la tecnología moderna. Se desarrollarán tecnologías modernas y lo que se llamará blockchain en el futuro será muy importante. Tal vez ni siquiera se parezca a las cadenas de bloques modernas, esa es una pregunta abierta.
Si las personas inventan nuevas tecnologías, seguirán llamándolo blockchain. Quiero decir, al igual que el Fortran actual no tiene nada que ver con el lenguaje Fortran de la década de 1960, pero todo el mundo sigue llamándolo Fortran. Lo mismo para UNIX. Lo que se llama "blockchain" aún está por hacer su revolución. Pero dudo que esta nueva cadena de bloques sea como lo que a todos les encanta usar hoy.
¿De dónde vienen las ideas innovadoras? Influencia de la popularidad
Alexey: ¿La popularidad de la cadena de bloques ha dado lugar a nuevos resultados desde un punto de vista científico? Más interacción, más estudiantes, más empresas de la zona. ¿Ya hay algún resultado de este crecimiento en popularidad?
Maurice: Me interesé en esto cuando alguien me entregó un folleto oficial de una empresa que acababa de recaudar bastante dinero. ella escribió sobre con el que estoy más que familiarizado. Lo escrito en el folleto era claramente técnicamente incorrecto. Las personas que escribieron esto no entendieron realmente el modelo detrás del problema... y sin embargo, esta empresa recaudó mucho dinero. Posteriormente, la compañía reemplazó silenciosamente este folleto con una versión mucho más correcta, y no diré cuál era el nombre de esta compañía. Todavía existen y lo están haciendo muy bien. Este caso me convenció de que, en primer lugar, blockchain es solo una forma de computación distribuida. En segundo lugar, el umbral de entrada (en ese momento, hace cuatro años) era bastante bajo. Las personas que trabajaban en esta área eran muy enérgicas e inteligentes, pero no leían artículos científicos. Intentaron reinventar cosas conocidas y lo hicieron mal. Hoy el drama se ha reducido.
Alexey: Es muy interesante, porque hace unos años teníamos una tendencia diferente. Es un poco como el desarrollo front-end, donde los desarrolladores de la interfaz del navegador reinventaron tecnologías completas que ya eran populares en el back-end en ese momento: construir sistemas, integración continua y cosas por el estilo.
mauricio: estoy de acuerdo. Pero esto no es sorprendente, porque las ideas verdaderamente innovadoras siempre provienen de fuera de la comunidad establecida. Es poco probable que los investigadores establecidos, especialmente las autoridades académicas, hagan algo realmente innovador. Es fácil escribir un informe para la próxima conferencia sobre cómo mejoró ligeramente los resultados de su trabajo anterior. Ir a una conferencia, juntarse con amigos, hablar de las mismas cosas. Y la gente que irrumpe con ideas innovadoras casi siempre viene de afuera. No conocen las reglas, no conocen el idioma, pero aún así... Si estás dentro de una comunidad establecida, te aconsejo que prestes atención a las cosas nuevas, a algo que no encaja en la gran imagen. En cierto sentido, se puede intentar combinar desarrollos externos más fluidos con técnicas que ya comprendemos. Como primer paso, intente crear una base científica y luego modifíquela para que pueda aplicarse a nuevas ideas innovadoras. Creo que la cadena de bloques es excelente para el papel de una nueva idea innovadora.
Alexei: ¿Por qué crees que está pasando esto? ¿Porque la gente de "afuera" no tiene barreras específicas inherentes a la comunidad?
Maurice: Hay un patrón aquí. Si lees la historia de los impresionistas en la pintura y el arte en general, en un momento los artistas famosos rechazaron el impresionismo. Dijeron que era una especie de infantilismo. Una generación más tarde, esta forma de arte previamente rechazada se convirtió en el estándar. Lo que veo en mi campo: los inventores de la cadena de bloques no estaban interesados en el poder, en liquidar publicaciones e índice de citas, solo querían hacer algo bueno. Así que se sentaron y empezaron a hacerlo. Carecían de cierta profundidad técnica, pero eso se puede arreglar. Es mucho más difícil generar nuevas ideas creativas que corregir y ampliar las que no están lo suficientemente maduras. ¡Gracias a estos inventores, ahora tengo algo que hacer!
Alexey: Esto es similar a la diferencia entre nuevas empresas y proyectos heredados. Heredamos muchas limitaciones de pensamiento, barreras, requisitos especiales, etc.
Maurice: Una buena analogía es la computación distribuida. Piense en blockchain como si fuera una startup y la computación distribuida como una gran empresa establecida. La computación distribuida está en proceso de compra y fusión con blockchain.
Doctorado con Barbara Liskov
Vitaliy: ¡Todavía tenemos muchas preguntas! Hemos estado investigando su biografía y encontramos un dato interesante sobre su doctorado. Sí, fue hace mucho tiempo, pero el tema parece ser importante. Recibió su doctorado bajo la supervisión de ! Barbara es muy famosa en la comunidad de desarrollo de lenguajes de programación y una persona muy famosa en general. Es lógico que su investigación fuera en el campo de los lenguajes de programación. ¿Cómo cambiaste a la computación paralela? ¿Por qué decidiste cambiar de tema?
Maurice: En ese momento, Barbara y su grupo solo analizaban la computación distribuida, que era una idea muy nueva. También hubo quienes dijeron que la computación distribuida es una tontería, la comunicación entre computadoras no tiene sentido. Uno de los temas considerados en la computación distribuida, que los distingue de la computación centralizada, es la tolerancia a fallas. Después de mucha investigación, decidimos que en un lenguaje de programación para computación distribuida, debe tener algo como transacciones atómicas, porque nunca puede estar seguro de que una llamada remota tendrá éxito. Una vez que tiene transacciones, hay un problema de control de concurrencia. Luego hubo mucho trabajo para obtener estructuras de datos transaccionales altamente paralelas. Luego, cuando me gradué fui a y comencé a buscar un tema de trabajo. Se me ocurrió que la computación había pasado de las computadoras individuales a las redes de computadoras. Una continuación natural del progreso serían los multiprocesadores: la palabra "multinúcleo" no existía entonces. Pensé: ¿cuál es el equivalente de transacciones atómicas para un sistema multinúcleo? Definitivamente no son transacciones ordinarias, porque son demasiado grandes y pesadas. Y así fue como se me ocurrió la idea. y así es como se me ocurrió toda la sincronización sin esperas. Fue un intento de responder a la pregunta de cuál es el análogo de las transacciones atómicas para un sistema multiprocesador con memoria compartida. A primera vista, este trabajo puede parecer bastante diferente, pero de hecho es una continuación del mismo tema.
El mundo que espera multinúcleo
Vitaly: Mencionaste que había muy pocas computadoras multinúcleo en ese momento, ¿verdad?
Maurice: Simplemente no existían. Existían varios de los llamados multiprocesadores simétricos, que básicamente estaban conectados al mismo bus. No funcionó muy bien, porque cada vez que una nueva empresa creaba algo como esto, Intel lanzaba un solo procesador que superaba al multiprocesador.
Alexei: ¿No significa esto que en aquellos tiempos antiguos, era más un estudio teórico?
Maurice: No fue un estudio teórico, sino especulativo. Todo esto no se trataba de trabajar con un montón de teoremas, sino que planteábamos hipótesis sobre la arquitectura que no existían en ese momento. ¡Para eso está la investigación! Ninguna empresa hubiera hecho esto, todo era algo del futuro lejano. De hecho, esto fue hasta 2004, cuando aparecieron los verdaderos procesadores multinúcleo. Debido al hecho de que los procesadores se sobrecalientan, puede hacer que el procesador sea aún más pequeño, pero no puede hacerlo más rápido. Debido a esto, hubo una transición a arquitecturas multinúcleo. Y luego significó que, de repente, había un uso para todos los conceptos que habíamos desarrollado en el pasado.
Alexey: ¿Por qué crees que los procesadores multinúcleo aparecieron solo en la década de XNUMX? Entonces, ¿por qué tan tarde?
Maurice: Es debido a limitaciones de hardware. Intel, AMD y otras empresas son muy buenas para aumentar la velocidad de los procesadores. Cuando en algún momento los procesadores se volvieron lo suficientemente pequeños como para no poder aumentar más la velocidad del reloj porque los procesadores comenzarían a agotarse. Puedes hacerlos más pequeños, pero no más rápidos. Lo que está en su poder: en lugar de un procesador muy pequeño, coloque ocho, dieciséis o treinta y dos procesadores en el mismo volumen de la carcasa, donde solo cabía uno. Ahora tiene subprocesos múltiples y una comunicación rápida entre ellos porque comparten cachés. Pero no puedes hacer que corran más rápido, hay un límite de velocidad muy específico. Siguen mejorando poco a poco, pero no tanto. Las leyes de la física se interpusieron en el camino.
Nuevo mundo, nuevos problemas. NUMA, NVM y piratería de arquitectura
Alexei: Suena muy razonable. Con los nuevos procesadores multinúcleo surgieron nuevos problemas. ¿Usted y sus colegas esperaban estos problemas? ¿Quizás los has estudiado de antemano? En estudios teóricos, a menudo no es muy fácil predecir tales cosas. Cuando surgieron problemas, ¿en qué medida cumplieron con sus expectativas y las de sus colegas? ¿O eran nuevos y usted y sus colegas tuvieron que pasar mucho tiempo resolviendo problemas a medida que surgían?
Vitaliy: Agregaré a la pregunta de Alexey: ¿predijiste correctamente la arquitectura de los procesadores mientras estudiabas teoría?
Maurice: No todo al 100%. Pero creo que mis colegas y yo hicimos un buen trabajo al predecir el multinúcleo de memoria compartida. Creo que predijimos correctamente las dificultades para diseñar estructuras de datos paralelas que funcionen sin bloqueos. Tales estructuras de datos han sido importantes para muchas aplicaciones, aunque no para todas, pero a menudo realmente necesita una estructura de datos sin bloqueo. Cuando los inventamos, muchos argumentaron que esto es una tontería, que todo funciona bien con cerraduras. Previmos bastante bien que habría soluciones listas para usar para muchos problemas de programación y problemas de estructura de datos. También había problemas más complejos, como – Acceso desigual a la memoria. De hecho, ni siquiera se consideraron hasta la invención de los procesadores multinúcleo porque eran demasiado específicos. La comunidad de investigación trabajó en preguntas que generalmente eran predecibles. Algunos problemas de hardware asociados con arquitecturas específicas tuvieron que esperar entre bastidores; de hecho, la aparición de estas arquitecturas. Por ejemplo, nadie trabajó realmente en estructuras de datos específicas de GPU porque la GPU no existía en ese entonces. Aunque se ha trabajado mucho en , estos algoritmos estaban listos para usar tan pronto como apareció el hardware adecuado. Sin embargo, es imposible predecirlo todo.
Alexey: Si entiendo correctamente, NUMA es una especie de compromiso entre costo, rendimiento y algunas otras cosas. ¿Alguna idea de por qué la NUMA llegó tan tarde?
Maurice: Creo que NUMA existe debido a un problema con el hardware utilizado para crear memoria: cuanto más lejos están los componentes, más lento es el acceso a ellos. Por otro lado, el segundo valor de esta abstracción es la uniformidad de la memoria. Por lo tanto, una de las características de la computación paralela es que todas las abstracciones se rompen ligeramente. Si el acceso fuera perfectamente uniforme, toda la memoria sería equidistante, pero esto es económicamente y tal vez incluso físicamente imposible. Entonces surge este conflicto. Si escribe su programa como si la memoria fuera uniforme, lo más probable es que sea correcto. En el sentido de que no dará respuestas incorrectas. Pero el rendimiento de sus estrellas desde el cielo no agarrará. Del mismo modo, si escribes sin comprender la jerarquía de los cachés, el bloqueo en sí será correcto, pero puede olvidarse del rendimiento. En cierto sentido, tienes que escribir programas que vivan sobre una abstracción muy simple, pero tienes que burlar a las personas que te dieron esa abstracción: tienes que saber que bajo la abstracción hay una jerarquía de memoria, que hay un autobús entre tú y este recuerdo, y así sucesivamente. Por lo tanto, existe cierto conflicto entre abstracciones que son útiles por sí mismas, lo que nos lleva a problemas muy específicos y pragmáticos.
Vitaliy: ¿Qué pasa con el futuro? ¿Puede predecir cómo se desarrollarán más los procesadores? Existe la idea de que una de las respuestas es la memoria transaccional. Probablemente tengas algo más en stock.
Maurice: Hay un par de desafíos importantes por delante. Una es que la memoria coherente es una abstracción maravillosa, pero comienza a fallar en casos especiales. Entonces, por ejemplo, NUMA es un ejemplo vivo de algo en lo que puedes seguir fingiendo que existe una memoria uniforme. En realidad, no, la actuación te hará llorar. En algún momento, los arquitectos tendrán que abandonar la idea de una arquitectura de memoria unificada, no se puede pretender para siempre. Se necesitarán nuevos modelos de programación que sean lo suficientemente fáciles de usar y lo suficientemente potentes para hacer que el hardware subyacente sea eficiente. Este es un compromiso muy difícil, porque si les muestra a los programadores la arquitectura que realmente se usa en el hardware, se volverán locos. Es demasiado complicado y no portátil. Si presenta una interfaz demasiado simple, el rendimiento será deficiente. Por lo tanto, será necesario realizar muchos compromisos muy difíciles para proporcionar modelos de programación útiles aplicables a procesadores multinúcleo realmente grandes. No estoy seguro de que alguien que no sea un especialista limitado sea capaz de programar en una computadora de 2000 núcleos. Y a menos que esté haciendo computación muy especializada o científica, criptografía o lo que sea, todavía no está del todo claro cómo hacerlo bien.
Otra dirección similar son las arquitecturas especializadas. Los aceleradores de gráficos existen desde hace mucho tiempo, pero ya se han convertido en una especie de ejemplo clásico de cómo puede tomar un tipo especializado de computación y ejecutarlo en un chip dedicado. Esto agrega sus propios desafíos: cómo se comunica con un dispositivo de este tipo, cómo lo programa. Recientemente trabajé en tareas en el campo. . Toma un pequeño procesador y lo pega a una gran cantidad de memoria para que la memoria se ejecute a la velocidad de caché L1, y luego se comunica con un dispositivo como - el procesador está ocupado cargando nuevas tareas en su núcleo de memoria. El desarrollo de estructuras de datos y protocolos de comunicación para este tipo de cosas es otro ejemplo interesante. Por lo tanto, los procesadores y el hardware especializados estarán sujetos a mejoras durante bastante tiempo.
Alexey: ¿Qué pasa con la memoria no volátil ()?
Maurice: ¡Oh, ese es otro gran ejemplo! NVM cambiará en gran medida la forma en que vemos cosas como las estructuras de datos. La memoria no volátil, en cierto sentido, promete realmente acelerar las cosas. Pero no hará la vida más fácil, porque la mayoría de los procesadores, cachés y registros siguen siendo volátiles. Cuando inicie después de un bloqueo, su estado y el estado de su memoria no serán exactamente los mismos que antes del bloqueo. Estoy muy agradecido con las personas involucradas en NVM: durante mucho tiempo, los investigadores tendrán algo que hacer, tratando de descubrir las condiciones correctas. Los cálculos son correctos si pueden sobrevivir a un bloqueo en el que se pierden los contenidos de las cachés y los registros, pero la memoria principal permanece intacta.
Compiladores frente a CPU, RISC frente a CISC, memoria compartida frente a paso de mensajes
Vladimir: ¿Qué piensa sobre el dilema de compiladores versus procesadores en términos del conjunto de instrucciones? Para explicar a los que no están en el tema: si vamos a memoria desigual o algo así, podríamos aplicar un conjunto muy simple de instrucciones y pedirle al compilador que genere un código complejo que pueda aprovechar los beneficios descubiertos. O podemos ir por el otro lado: implementar instrucciones complejas y pedirle al procesador que reordene las instrucciones y haga otras manipulaciones con ellas. ¿Qué piensa usted al respecto?
Maurice: Realmente no tengo una respuesta a esa pregunta. Este debate ha durado cuatro décadas. Hubo un tiempo entre conjunto de comandos y las guerras civiles eran libradas por un conjunto de equipos. Durante un tiempo, la gente de RISC ganó, pero luego Intel reconstruyó sus motores para que se usara un conjunto de instrucciones reducido en el interior y el conjunto completo se exportara al exterior. Quizás este sea un tema en el que cada nueva generación deba encontrar sus propios compromisos y tomar sus propias decisiones. Es muy difícil predecir cuál de estas cosas resultará mejor. Entonces, cualquier predicción que haga será cierta durante un cierto período de tiempo, y luego se volverá falsa nuevamente por un tiempo, y luego volverá a ser cierta.
Alexey: ¿Qué tan común es para la industria en general que algunas ideas ganen durante varias décadas y pierdan en la siguiente? ¿Hay otros ejemplos de tales cambios periódicos?
Maurice: En el campo de la computación distribuida, hay gente que cree en y la gente que cree en . Originalmente en computación distribuida, computación paralela significa paso de mensajes. Entonces alguien descubrió que la memoria compartida facilitaba mucho la programación. El otro lado dijo que la memoria compartida es demasiado complicada, porque necesitan bloqueos y cosas por el estilo, por lo que vale la pena pasar a idiomas donde solo existe el paso de mensajes. Alguien miró lo que salió y dijo: “vaya, esta implementación de mensajería se parece mucho a la memoria compartida, porque creas muchos, muchos de estos pequeños módulos, se envían mensajes entre sí y todos , - ¡mejoremos una base de datos de memoria compartida!". Todo esto se repite una y otra vez, y es imposible decir que una de las partes tiene razón sin ambigüedades. Un lado siempre dominará, porque tan pronto como uno de ellos casi gana, la gente una y otra vez inventa formas de mejorar al otro.
El arte de escribir código frágil de múltiples subprocesos
Alexei: Esto es muy interesante. Por ejemplo, cuando escribimos código, sin importar el lenguaje de programación, generalmente tenemos que crear abstracciones como celdas que se pueden leer y escribir. Pero, de hecho, en algún nivel físico, puede parecer como enviar un mensaje en un bus de hardware entre diferentes computadoras y otros dispositivos. Resulta que hay trabajo en ambos niveles de abstracción a la vez.
Maurice: Es absolutamente cierto que la memoria compartida se basa en el paso de mensajes: buses, cachés, etc. Pero es difícil escribir programas utilizando el paso de mensajes, por lo que el hardware miente deliberadamente, fingiendo que tiene algún tipo de memoria uniforme. Esto le facilitará la escritura de programas simples y correctos antes de que el rendimiento comience a disminuir. Entonces dices: parece que es hora de hacerse amigo del caché. Y ahí es cuando empiezas a preocuparte por la ubicación del caché, y luego nos vamos. En cierto sentido, está rompiendo la abstracción: sabe que no se trata solo de una memoria plana y uniforme, y utilizará ese conocimiento para escribir programas compatibles con la memoria caché. Esto es lo que tienes que hacer en tareas reales. Este conflicto entre la agradable, simple, agradable abstracción que le dieron y la implementación terriblemente compleja del hardware subyacente es donde cada uno hace su propio compromiso. Tengo un libro sobre multiprocesadores y sincronización, y un día iba a escribir un capítulo sobre estructuras de datos en java.util.concurrente. Si los miras, cosas como Estas son increíbles obras de arte. (Nota del editor: aquellos que están familiarizados con el lenguaje Java deberían al menos echar un vistazo a la implementación Mapa de lista de saltos simultáneos, Puedes mirar los enlaces de и ). Pero desde mi punto de vista, sería irresponsable mostrárselos a los estudiantes, porque esa estructura de datos es una especie de tipo en un circo, corriendo en la cuerda floja sobre un foso de osos. Si cambia incluso un pequeño detalle, toda la estructura se derrumbará. Este código es muy rápido y elegante simplemente porque está perfectamente escrito, pero el más mínimo cambio conducirá al fracaso total. Si doy este código como ejemplo a los estudiantes, inmediatamente dirán: ¡Yo también puedo hacer esto! Y luego algún avión se estrellará o explotará un reactor nuclear, y será mi culpa que no les di demasiada información en el momento adecuado.
Alexey: Cuando era un poco más joven, muchas veces traté de estudiar el código fuente de Doug Lee, por ejemplo, java.util.concurrente, debido a que es de código abierto, es muy fácil encontrarlo y tratar de entender qué está pasando allí. No resultó muy bien: a menudo, no está del todo claro por qué Doug decidió hacer algo de esta manera, cuando todos los demás lo hacen de manera diferente. ¿Cómo explicas estas cosas a tus alumnos? ¿Hay alguna forma correcta en particular de describir los detalles específicos de un algoritmo extremo, por ejemplo? ¿Cómo lo haces?
Maurice: Los profesores de dibujo tienen un cliché que recuerdan primero: si quieres dibujar como Picasso, primero debes aprender a dibujar imágenes simples y realistas, y solo cuando conoces las reglas puedes comenzar a romperlas. Si inmediatamente empiezas por romper las reglas, te metes en un lío. Primero, les enseño a los estudiantes cómo escribir código simple y correcto sin preocuparse por el rendimiento. Estoy diciendo que hay problemas de tiempo complejos al acecho aquí, así que no te preocupes por los cachés, no te preocupes por los modelos de memoria, solo asegúrate de que todo funcione correctamente. Esto ya es bastante difícil: la programación moderna no es fácil en sí misma, especialmente para los nuevos estudiantes. Y cuando tienen una intuición sobre cómo escribir programas correctos, digo: mira estas dos implementaciones de spinlock: una es muy lenta y la segunda tampoco es muy buena, pero ya es mejor. Sin embargo, matemáticamente estos dos algoritmos son iguales. De hecho, uno de ellos usa la localidad de caché. Uno de ellos gira en torno a los datos almacenados en caché localmente y el otro realiza repetidamente operaciones a través del bus. No puedes escribir código eficiente si no lo entiendes, si no sabes cómo romper la abstracción y observar la estructura subyacente. Pero no podrá comenzar a hacerlo de inmediato. Hay personas que empiezan a hacer esto de inmediato y creen en su propio genio, por lo general termina mal porque no entienden los principios. Nadie dibuja como Picasso ni escribe programas como Doug Lee, recién salido de la universidad, en su primera semana. Lleva años alcanzar este nivel de conocimiento.
Alexey: Resulta que divides el problema en dos partes: la primera es la corrección, la segunda es el rendimiento.
mauricio: exacto. Y, en ese orden. Parte del problema es que los nuevos estudiantes no se dan cuenta de que es difícil lograr la corrección. Dicen a primera vista: esto es obviamente correcto, solo queda acelerarlo. Así que a veces les hablo de un algoritmo inherentemente incorrecto como si fuera correcto.
Cómo enseñar a los estudiantes cómo escribir código complejo de subprocesos múltiples
Alexei: ¿Solo para ver si pueden sentir el truco?
Maurice: Siempre te advierto de antemano que a veces se me ocurrirán algoritmos incorrectos. No debes engañar a la gente. Sugiero que sean escépticos acerca de la información. Si digo algo y digo: "mira, esto es obviamente correcto", esta es una señal de que en algún lugar están tratando de engañarte y debes comenzar a hacer preguntas. A continuación, trato de alentar a los estudiantes a que sigan haciendo preguntas y luego les pregunto: "¿qué pasa si dejamos todo como está?". E inmediatamente ven el error. Pero convencer a los estudiantes de que deben preocuparse por la corrección es más difícil de lo que parece a primera vista. Muchos de estos estudiantes tienen experiencia en programación en la escuela secundaria, algunos han conseguido trabajos y han programado allí, y todos están llenos de confianza en sí mismos. Esto es algo militar: primero hay que cambiar su estado de ánimo para convencerlos de que se acerquen con paciencia a la solución de los problemas emergentes. O tal vez sea como los monjes budistas: primero aprenden a razonar sobre la corrección, y una vez que entienden las formas de razonar sobre la corrección, pueden pasar al siguiente nivel y empezar a preocuparse por el desempeño.
Alexey: Es decir, a veces les muestras a los estudiantes ejemplos que no funcionan, gracias a los cuales obtienes comentarios que muestran si entienden la esencia del problema, si pueden encontrar el código incorrecto y el resultado incorrecto. Bueno, ¿cómo suelen complacer o molestar a los estudiantes?
Maurice: Casi siempre los estudiantes finalmente encuentran el error. Si buscan con demasiada lentitud, hago preguntas tendenciosas, y aquí es importante comprender que si nunca se dejan engañar, comenzarán a percibir sin pensar sus palabras como la verdad última. Luego se aburren y se quedan dormidos leyendo Facebook en su laptop durante la clase. Pero cuando les haces saber de antemano que serán estafados y parecerán estúpidos si no detectan un truco, se vuelven mucho más atentos. Esto es bueno de muchas maneras. Me gustaría que los estudiantes no solo cuestionaran su comprensión del tema, sino que también cuestionaran la autoridad del maestro. La idea es que el alumno pueda levantar la mano en cualquier momento y decir: Creo que lo que acabas de decir está mal. Es una importante herramienta de aprendizaje. No quiero que ninguno de los estudiantes se siente y piense en silencio: todo esto parece una completa tontería, pero da demasiado miedo levantar la mano y, de hecho, es profesor, por lo que todo lo que dice es verdad. Por lo tanto, si se les advierte de antemano que no todo lo que se cuenta es necesariamente cierto, tienen un incentivo para prestar más atención al material. Declaro explícitamente que levantar la mano y hacer preguntas está bien. Su pregunta puede sonar tonta o ingenua, pero a menudo es así como surgen las mejores preguntas.
Alexei: Muy interesante. Por lo general, las personas tienen algún tipo de barrera psicológica que les impide hacer una pregunta al profesor. Especialmente si hay muchas personas en la sala y todos tienen miedo de que discutir tu estúpida pregunta les quite el tiempo a todas estas personas. ¿Hay algún truco para lidiar con esto?
Maurice: A menudo me detengo y hago las preguntas clásicas. ¿Será alguna afirmación correcta, o cómo resolverían el problema en discusión? Este es un paso clave, especialmente al comienzo de una sesión, cuando las personas se avergüenzan de decir incluso las cosas más pequeñas. Haces una pregunta a los estudiantes y no dices nada más. Hay un silencio, todos se tensan un poco, la tensión crece, entonces de repente alguien se derrumba, se derrumba y dice la respuesta. Entonces despliegas la situación: ¡se vuelve más difícil e incómodo permanecer en silencio que responder! Este es un truco pedagógico estándar. Todos los maestros del mundo deberían saber cómo hacer esto.
Alexey: Ahora tenemos un gran título para esta entrevista: "Es más fácil responder que permanecer en silencio".
Vitaly: Déjame preguntarte una cosa más. Estás trabajando en pruebas topológicas. ¿Cómo te involucraste en esto, porque la computación distribuida y la topología son cosas completamente diferentes?
Maurice: Hay una relación oculta ahí. Cuando era estudiante y estudiaba matemáticas, estudiaba matemáticas puras. No tuve ningún interés real en las computadoras hasta el final de mis estudios y me encontré en la necesidad urgente de buscar un trabajo. Como estudiante, estudié topología algebraica. Muchos años después, mientras trabajaba en un problema llamado , usé gráficos para modelar el problema y, como parecía entonces, encontré una solución. Solo tenías que sentarte y recorrer el gráfico. Trate de encontrar una respuesta adecuada en este gráfico. Pero mi algoritmo no funcionó: resultó que siempre corría en círculos. Desafortunadamente, nada de esto podría explicarse en el lenguaje formal de la teoría de grafos, el lenguaje que conocen todos los informáticos. Y luego recordé que hace muchos años, incluso en las clases de topología, usábamos el concepto , que es una generalización de grafos a dimensiones superiores. Entonces me pregunté: ¿qué pasa si reformulamos el problema en términos de complejos simpliciales? Esto se convirtió en la clave. Al usar un formalismo más poderoso, el problema de repente se vuelve mucho más simple. La gente luchó con eso durante mucho tiempo, usando gráficos, pero no pudieron hacer nada. E incluso ahora no pueden: la respuesta correcta no era el algoritmo, sino la prueba de la imposibilidad de resolver el problema. Es decir, tal algoritmo simplemente no existe. Pero se basa en complejos simpliciales o en cosas que la gente pretende no considerar complejos simpliciales. Por el hecho de que llamaste a algo con un nuevo nombre, no pierde su esencia.
Vitaliy: ¿Resulta que solo tuviste suerte?
Maurice: Además de la suerte, también es готовность. Es decir, no debes olvidar las cosas "inútiles" que has aprendido antes. Cuantas más cosas inútiles aprenda, más ideas podrá extraer cuando se enfrente a un nuevo problema. Este tipo de coincidencia de patrones intuitiva es importante porque... Digamos que es una cadena: al principio, descubrí que los gráficos no funcionaban del todo o no funcionaban en absoluto, me recordó a algo de hace ocho años. y años de estudiante cuando estudiamos todos estos complejos simpliciales. A su vez, esto me permitió encontrar mi antiguo libro de texto de topología y volver a cargarlo en mi cabeza. Pero si no fuera por ese viejo conocimiento, nunca hubiera avanzado en la solución del problema original.
Nueva edición de El arte de la programación multiprocesador
Alexei: Dijiste algunas palabras sobre tu libro. Probablemente no sea el mayor secreto que escribiste el libro más famoso del mundo sobre subprocesos múltiples, . Ya tiene unos 11 años y desde entonces solo salio . ¿Habrá una segunda edición?
Maurice: ¡Qué bueno que preguntaste! Será muy pronto, dentro de tres meses más o menos. Hay dos autores más, agregamos mucho más material, mejoramos la sección sobre el paralelismo de bifurcación/unión, escribimos una sección sobre MapReduce, agregamos muchas cosas nuevas y eliminamos las innecesarias, algo que era muy interesante en el momento de escribir este artículo. la primera edición, pero ya no es hoy. Resultó ser un libro revisado muy seriamente.
Alexei: Ya se ha hecho todo, ¿solo queda liberar?
Maurice: Todavía hay que trabajar en un par de capítulos. Nuestro editor (creo que ya nos odia) sigue intentando transmitir que deberíamos trabajar más rápido. Estamos muy atrasados. En teoría, podríamos haber hecho este libro un par de años antes.
Alexey: ¿Hay alguna posibilidad de obtener una nueva versión del libro antes de Navidad?
Maurice: ¡Ese es nuestro objetivo! Pero he pronosticado la victoria tantas veces que ya nadie me cree. Probablemente tampoco deberías confiar demasiado en mí en este asunto.
Alexei: En cualquier caso, esta es una noticia fantástica. Me gustó mucho la primera edición del libro. Se podría decir que soy un fan.
Maurice: Espero que la nueva edición sea digna de su ferviente entusiasmo, ¡gracias!
Cómo se inventó la memoria transaccional
Vitaly: La siguiente pregunta es sobre la memoria transaccional. Según tengo entendido, eres un pionero en este campo, lo inventaste en un momento en que nadie pensaba en esas cosas. ¿Por qué decidiste mudarte a esta zona? ¿Por qué las transacciones eran importantes para usted? ¿Pensaste que algún día se plasmarán en hierro?
Maurice: Conozco las transacciones desde mis estudios de posgrado.
Vitaliy: ¡Sí, pero estas son transacciones diferentes!
Maurice: Trabajé con Elliott Moss en la recolección de basura sin bloqueo. Nuestro problema era que queríamos cambiar atómicamente algunas palabras en la memoria y luego los algoritmos se volverían muy simples, y al menos algunos de ellos se volverían más eficientes. Usando para proporcionado por la arquitectura paralela, es posible hacer algo, pero es muy ineficiente y feo porque tendrías que lidiar con niveles de direccionamiento indirecto. Quiero cambiar las palabras de memoria y necesito cambiar porque solo puedo cambiar un puntero, por lo que deben apuntar a algún tipo de estructura similar a un directorio. Hablamos de lo genial que sería si pudiéramos cambiar el hardware para que pudiera grabar simultáneamente. Elliot parece haber notado esto: si observa los protocolos de coherencia de caché, ya brindan la mayor parte de la funcionalidad requerida. En una transacción optimista, el protocolo de coherencia de caché notará la presencia de un conflicto de tiempo y la caché se volverá . ¿Qué sucede si especulativamente inicia una transacción en su caché y utiliza los mecanismos del protocolo de coherencia para detectar conflictos? La arquitectura de hardware especulativa fue fácil de diseñar. Así que escribimos eso sobre la memoria transaccional. Al mismo tiempo, la empresa para la que trabajaba, Digital Equipment Corporation, estaba construyendo un nuevo procesador de 64 bits llamado Alpha. Así que fui y di una presentación al equipo de desarrollo de Alpha sobre nuestra maravillosa memoria transaccional, y me preguntaron: ¿qué ingresos adicionales obtendrá nuestra empresa si ponemos todo esto directamente en el procesador? Y no tenía absolutamente ninguna respuesta a eso, porque soy tecnólogo, no soy una persona de marketing. Realmente no tenía nada que decir. No estaban muy impresionados de que yo no supiera nada.
Vitaly: ¡Miles de millones! ¡Solo di "miles de millones"!
Maurice: Sí, eso es lo que debería haber dicho. Ahora, en la era de las startups y todo eso, sé cómo escribir un plan de negocios. Que puedes mentir un poco sobre el tamaño de la ganancia potencial. Pero en esos días parecía ingenuo, así que simplemente dije: "No sé". Si observa la historia de la publicación sobre la memoria transaccional, notará que después de un año hubo varias referencias y luego, durante unos diez años, nadie citó este artículo en absoluto. Las citas aparecieron alrededor de 2004, cuando surgió el verdadero multinúcleo. Cuando la gente descubrió que escribir código paralelo podía generar dinero, comenzó una nueva investigación. Ravi Rajwar , que de alguna manera introdujo la corriente principal en el concepto de memoria transaccional. (Nota del editor: este artículo tiene una segunda versión publicada en 2010 y está disponible gratuitamente ). De repente, la gente se dio cuenta de cómo se puede usar exactamente todo esto, cómo pueden acelerar los algoritmos tradicionales con bloqueos. Un buen ejemplo de algo que en el pasado parecía ser solo un interesante problema académico. Y sí, si me hubieras preguntado en ese momento si pensaba que todo esto sería importante en el futuro, te habría dicho: por supuesto, pero cuándo exactamente no está claro. ¿Quizás en 50 años? En la práctica, resultó ser solo una década. Es muy bonito cuando haces algo, y en solo diez años la gente lo nota.
Por qué vale la pena investigar en el campo de la computación distribuida
Vitaly: Si hablamos de nuevas investigaciones, ¿qué aconsejaría a los lectores: computación distribuida o multinúcleo y por qué?
Maurice: Actualmente es fácil obtener un procesador multinúcleo, pero es más difícil configurar un verdadero sistema distribuido. Empecé a trabajar en ellos porque quería hacer algo diferente a mi doctorado. Este es el consejo que siempre doy a los principiantes: no escriban una disertación de seguimiento, traten de ir en una nueva dirección. Además, multiproceso es fácil. Puedo experimentar con mi propio tenedor funcionando en una computadora portátil sin levantarme de la cama. Pero si de repente quisiera crear un sistema distribuido real, tendría que trabajar mucho, atraer estudiantes, etc. Soy una persona perezosa y preferiría trabajar en varios núcleos. Experimentar con sistemas multinúcleo también es más fácil que experimentar con sistemas distribuidos, porque incluso en un sistema distribuido estúpido hay demasiados factores que controlar.
Vitaliy: ¿Qué estás haciendo ahora, investigando blockchain? ¿A qué artículos debes prestar atención primero?
Maurice: Recientemente aparecido que escribí con mi estudiante, Vikram Saraf, específicamente para el en París hace tres semanas. Este es un artículo sobre sistemas distribuidos útiles en el que proponemos hacer que Ethereum sea multihilo. Ahora los contratos inteligentes (código que se ejecuta en la cadena de bloques) se ejecutan secuencialmente. Anteriormente escribimos un artículo que hablaba sobre una forma de utilizar transacciones especulativas para acelerar el proceso. Tomamos muchas ideas de la memoria transaccional del software y dijimos que si estas ideas forman parte de la máquina virtual Etherium, entonces todo funcionará más rápido. Pero para ello es necesario que no existan conflictos de datos en los contratos. Y luego asumimos que en la vida real realmente no existen tales conflictos. Pero no hemos tenido la oportunidad de averiguarlo. Entonces se nos ocurrió que teníamos casi diez años de historial de contratos reales en nuestras manos, así que descargamos la cadena de bloques de Etherium y nos preguntamos: ¿qué pasaría si estos registros históricos se ejecutaran en paralelo? Encontramos un aumento significativo en la velocidad. En los primeros días de Etherium, la velocidad aumentaba mucho, pero hoy todo es algo más complicado, porque hay menos contratos y la probabilidad de conflictos por los datos que requieren serialización se ha vuelto mayor. Pero todo esto es un trabajo experimental con datos históricos reales. Lo bueno de blockchain es que recuerda todo para siempre, por lo que puedes retroceder en el tiempo y estudiar qué sucedería si usáramos otros algoritmos para ejecutar el código. Cómo le hubiera gustado a la gente en el pasado nuestra nueva idea. Es mucho más fácil y más agradable hacer esa investigación, porque hay algo que monitorea todo y registra todo. Esto ya es algo más parecido a la sociología que al desarrollo de algoritmos.
¿Se ha detenido el desarrollo de algoritmos y cómo seguir viviendo?
Vitaly: ¡Es hora de la última pregunta teórica! ¿Siente que los avances en las estructuras de datos competitivas se reducen cada año? ¿Cree que hemos llegado a una meseta en nuestra comprensión de las estructuras de datos, o habrá algunas mejoras importantes? ¿Quizás hay algunas ideas inteligentes que pueden cambiar todo por completo?
Maurice: Es posible que hayamos llegado a una meseta en las estructuras de datos para las arquitecturas tradicionales. Pero las estructuras de datos para nuevas arquitecturas siguen siendo un área muy prometedora. Si desea crear estructuras de datos para, por ejemplo, aceleradores de hardware, las estructuras de datos de GPU son muy diferentes de las estructuras de datos de CPU. Cuando diseña estructuras de datos para cadenas de bloques, necesita codificar piezas de datos y luego ponerlas en algo como , para evitar la falsificación. Ha habido una oleada de actividad en esta área últimamente, muchos están haciendo un muy buen trabajo. Pero creo que lo que sucederá es que las nuevas arquitecturas y las nuevas aplicaciones conducirán a nuevas estructuras de datos. Aplicaciones antiguas y arquitectura tradicional: quizás ya no haya mucho espacio para la investigación. Pero si te sales de los caminos trillados y miras por el borde, verás cosas locas que la corriente principal no se toma en serio; ahí es donde realmente suceden todas las cosas emocionantes.
Vitaly: Por lo tanto, para ser un investigador muy famoso, tuve que inventar mi propia arquitectura 🙂
Maurice: Puedes "robar" la nueva arquitectura de otra persona. ¡Parece mucho más fácil!
Trabaja en la Universidad de Brown
Vitaliy: ¿Podría contarnos más sobre ¿en que trabajas? No se sabe mucho sobre él en el contexto de la tecnología de la información. Menos que sobre el MIT, por ejemplo.
Maurice: Brown University es una de las universidades más antiguas de los Estados Unidos. Creo que solo Harvard es un poco mayor. Brown es parte de los llamados , que es una colección de las ocho universidades más antiguas. Harvard, Brown, Cornell, Yale, Columbia, Dartmouth, Pensilvania, Princeton. Esta es una especie de universidad antigua, pequeña y un poco aristocrática. La atención se centra en la educación en artes liberales. No se trata de ser como el MIT, el MIT es muy especializado y técnico. Brown es un gran lugar para estudiar literatura rusa o griego clásico y, por supuesto, informática. Se enfoca en la educación integral. La mayoría de nuestros estudiantes van a Facebook, Apple, Google, así que creo que nuestros estudiantes no tienen problemas para conseguir un trabajo en la industria. Fui a trabajar a Brown porque antes de eso trabajé en Digital Equipment Corporation en Boston. Era una empresa que inventó muchas cosas interesantes, pero negó la importancia de las computadoras personales. Una empresa con un destino difícil, cuyos fundadores alguna vez fueron jóvenes revolucionarios, no aprendieron nada ni olvidaron nada, y por lo tanto pasaron de revolucionarios a reaccionarios en aproximadamente una década. Les gustaba bromear diciendo que las computadoras personales debían estar en el garaje, en un garaje abandonado, por supuesto. Es bastante obvio que fueron destruidos por empresas más flexibles. Cuando quedó claro que la empresa estaba en problemas, llamé a mi amigo de Brown, que está a una hora de Boston. No quería irme de Boston en ese momento, porque otras universidades no tenían muchas vacantes. Era una época en la que no había tantas vacantes en el campo de la Informática como ahora. Y Brown tenía un trabajo, no tuve que mudarme de mi casa, no tuve que mudarme con mi familia, ¡y realmente disfruto vivir en Boston! Así que tomé la decisión de ir a Brown. Me gusta. Los estudiantes son geniales, así que ni siquiera intenté ir a otro lugar. En un año sabático, trabajé en Microsoft durante un año, fui a Technion en Haifa durante un año y ahora estaré en Algorand. Tengo muchos colegas en todas partes y por lo tanto la ubicación física de nuestras aulas no es tan importante. Pero lo más importante son los estudiantes, son los mejores aquí. Nunca he tratado de ir a ningún otro lado, porque estoy bastante feliz aquí.
Sin embargo, a pesar de la fama de Brown en los Estados Unidos, es sorprendentemente desconocido en el extranjero. Como puede ver, ahora estoy haciendo todo lo posible para corregir este estado de cosas.
La diferencia entre investigación universitaria y corporativa
Vitaliy: Bien, la siguiente pregunta es sobre equipos digitales. Usted era investigador allí. ¿Cuál es la diferencia entre trabajar en el departamento de I+D de una gran empresa y trabajar en una universidad? ¿Cuáles son las ventajas y desventajas?
Maurice: Llevo veinte años en Microsoft, trabajando en estrecha colaboración con personas de Sun Microsystems, Oracle, Facebook y ahora Algorand. En base a todo esto, quiero decir que es posible realizar investigaciones de primer nivel tanto en las empresas como en la universidad. La diferencia importante es que en una empresa se trabaja con compañeros. Si de repente tengo una idea para un proyecto que aún no existe, tengo que convencer a mis compañeros de que es una buena idea. Si estoy en Brown, entonces puedo decirles a mis alumnos: ¡trabajemos en antigravedad! O irán a otra persona o asumirán el proyecto. Sí, tendré que encontrar financiación, tendré que redactar una solicitud de subvención, etc. En cualquier caso, siempre habrá muchos alumnos y podrás tomar decisiones de forma unilateral. Pero en la universidad, lo más probable es que no trabajes con gente de tu nivel. En el mundo de la investigación industrial, primero tienes que convencer a todo el mundo de que merece la pena emprender tu proyecto. No puedo pedir nada a nadie. Y ambas formas de trabajar son valiosas, porque si estás trabajando en algo realmente loco y tus colegas son difíciles de convencer, es más fácil convencer a los estudiantes de posgrado, especialmente si les pagas. Si está trabajando en algo que requiere mucha experiencia y conocimientos profundos, entonces necesita colegas que puedan decir "no, da la casualidad de que entiendo esta área y su idea es mala, no saldrá nada". Esto es muy útil en términos de perder el tiempo. Y también, si en los laboratorios industriales pasas mucho tiempo escribiendo informes, entonces en la universidad pasas ese tiempo buscando dinero. Si quiero que los estudiantes puedan viajar a alguna parte, tengo que encontrar el dinero en otra parte. Y cuanto más importante sea tu posición en la universidad, más tiempo tendrás para recolectar dinero. Entonces, ahora sabes en qué trabajo: ¡un mendigo profesional! Como uno de esos monjes que andan con un plato de donación. En general, estas dos actividades se complementan. Por eso trato de vivir y permanecer firme en ambos mundos.
Vitaliy: Parece que convencer a una empresa es más difícil que convencer a otros científicos.
Maurice: Más difícil, y mucho más. Además, en diferentes áreas es diferente: alguien realiza una investigación a gran escala y alguien se enfoca en su tema. Si fuera a Microsoft o Facebook y dijera, hagamos antigravedad, difícilmente lo apreciarían. Pero si les dijera exactamente lo mismo a mis estudiantes de posgrado, lo más probable es que se pusieran a trabajar de inmediato, aunque ahora ya tendría problemas, porque necesita encontrar dinero para esto. Pero siempre que desee hacer algo en línea con los objetivos de la empresa, esa empresa puede ser un muy buen lugar para investigar.
Hydra y SPTDC
Vitaliy: Mis preguntas están llegando a su fin, así que hablemos un poco sobre el próximo viaje a Rusia.
Maurice: Sí, tengo muchas ganas de volver a Petersburgo.
Alexey: Es un gran honor para mí que estés con nosotros este año. Esta es tu segunda vez en San Petersburgo, ¿verdad?
Maurice: Ya el tercero!
Alexei: Lo tengo, pero - exactamente el segundo. La última vez que llamaron a la escuela. , ahora hemos cambiado una letra (C a D, Concurrente a Distribuido) para enfatizar que hay más áreas relacionadas con la computación distribuida este año. ¿Puedes decir algunas palabras sobre tus presentaciones en la Escuela y ?
Maurice: En la Escuela, quiero hablar sobre los conceptos básicos de la cadena de bloques y lo que puedes hacer con ella. Me gustaría mostrar que las cadenas de bloques son muy similares a la programación de subprocesos múltiples con la que estamos familiarizados, pero con sus propios matices, y es importante comprender estas diferencias. Si comete un error en una aplicación web normal, es simplemente molesto. Si escribe un código con errores en una aplicación financiera, definitivamente alguien robará todo su dinero. Este es un nivel completamente diferente de responsabilidad y consecuencias. Hablaré un poco sobre prueba de trabajo, contratos inteligentes, transacciones entre diferentes cadenas de bloques.
Junto a mí trabajarán otros ponentes, que también tienen algo que decir sobre la cadena de bloques, y acordamos coordinarnos entre nosotros para que nuestras historias encajen bien. Pero para la charla de ingeniería, quiero dar una explicación clara a una amplia audiencia por qué no debe creer todo lo que escucha sobre las cadenas de bloques, por qué las cadenas de bloques son un gran campo, cómo encaja con otras ideas bien conocidas y por qué deberíamos mirar audazmente hacia el futuro.
Alexey: Además, quiero decir que esto no tendrá el formato de una reunión o un grupo de usuarios, como fue hace dos años. Decidimos hacer una pequeña conferencia cerca de la escuela. La razón es que después de hablar con Peter Kuznetsov, nos dimos cuenta de que la escuela está limitada a solo cien, tal vez 120 personas. Al mismo tiempo, hay muchos ingenieros que quieren hablar con usted, atender informes y, en general, están interesados en el tema. Para ello hemos creado una nueva conferencia. . Por cierto, ¿alguna idea de por qué Hydra?
Maurice: ¿Porque tendrá siete altavoces? ¿Y se les puede cortar la cabeza y crecerán nuevos oradores en su lugar?
Alexey: Gran idea para desarrollar nuevos oradores. Pero realmente, hay una historia aquí. Recuerde la leyenda de Odiseo, donde tuvo que navegar entre ? Hydra es algo así como Caribdis. La historia es que una vez hablé en una conferencia y hablé sobre multithreading. Solo hubo dos pistas en esta conferencia. Al comienzo del informe, le dije a la audiencia en la sala que ahora pueden elegir entre Scylla y Charybdis. Mi espíritu animal es Charybdis, porque Charybdis tiene muchas cabezas, y mi tema es multihilo. Así aparecen los nombres de las conferencias.
En cualquier caso, nos hemos quedado sin preguntas y sin tiempo. ¡Así que gracias amigos por una gran entrevista y nos vemos en SPTDC e Hydra 2019!
Será posible continuar la comunicación con Maurice en la conferencia Hydra 2019, que se llevará a cabo el 11 y 12 de julio de 2019 en San Petersburgo. vendrá con un informe . Los boletos se pueden comprar .
Fuente: habr.com