- como profesor de Ciencias de la Computación en la Universidad de Rochester, y en su casa, la Universidad de Wisconsin-Madison, fue decano durante cinco años. Investiga y enseña a los estudiantes sobre programación paralela y distribuida y diseño de lenguajes.
El mundo conoce a Michael por el libro de texto. , qué del trabajo Recibió el Premio Dijkstra como uno de los más famosos en el campo de la informática distribuida. Quizás también lo conozcas como el autor de ese mismo algoritmo. .
Junto con Doug Lee, desarrolló los algoritmos sin bloqueo y las colas síncronas que impulsan las bibliotecas de Java. Implementación en JavaSE 6 mejoró el rendimiento 10 veces ThreadPoolExecutor.
Contenido:
- Carrera temprana, Universidad de Rochester. Proyecto Charlotte, lenguaje Lynx;
- Interfaz coherente escalable IEEE, bloqueo MCS;
- Supervivencia en un mundo en constante cambio;
- ¿Se están volviendo más tontos los estudiantes? Tendencias globales, internacionalización;
- Trabajo eficaz con los estudiantes;
- Cómo mantenerse al día con la preparación de nuevos cursos y libros;
- Vínculos entre empresas y academia;
- Implementación práctica de ideas. MCS, MS, CLH, JSR 166, trabajando con Doug Lee y más;
- Memoria transaccional;
- Nuevas arquitecturas. La victoria de la memoria transaccional está cerca;
- Memoria no volátil, Optane DIMM, dispositivos ultrarrápidos;
- La próxima gran tendencia. Estructuras de datos duales. Hidra.
Las entrevistas son realizadas por:
Vitali Aksenov — actualmente postdoctorado en IST Austria y miembro del Departamento de Tecnologías Informáticas de la Universidad ITMO. Realiza investigaciones en el campo de la teoría y la práctica de las estructuras de datos competitivas. Antes de trabajar en IST, recibió su doctorado en la Universidad Paris Diderot y en la Universidad ITMO bajo la supervisión del profesor Peter 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.
Carrera temprana, Universidad de Rochester. Proyecto Charlotte, lenguaje Lynx.
Alexey: Para empezar, quería decirles que en Rusia a todos nos encanta la informática, la ciencia de datos y los algoritmos. Es francamente obsceno. Hemos leído todo . Por lo tanto, la próxima conferencia, la escuela y esta entrevista en sí deberían ser muy populares. Recibimos muchas preguntas para esta entrevista de estudiantes, programadores y miembros de la comunidad, por lo que estamos muy agradecidos por esta oportunidad. ¿La informática recibe el mismo amor en Estados Unidos?
Michael: Nuestro campo es tan diverso, tiene tantas direcciones y afecta a la sociedad de tantas maneras diferentes que me resulta difícil darle una respuesta definitiva. Pero el hecho es que ha provocado enormes cambios en los negocios, la industria, el arte y la sociedad en general durante los últimos 30 años.
Vitali: Empecemos con algo lejano. En muchas universidades existe algo así como una especialización en un área en particular. Para la Universidad Carnegie Mellon esto es computación paralela, para el MIT es criptografía, robots y subprocesos múltiples. ¿Existe tal especialización en la Universidad de Rochester?
Michael: Para ser honesto, diría que CMU y MIT se especializan en todas las áreas. Nuestro departamento siempre ha prestado la mayor atención a la inteligencia artificial. La mitad de las personas que trabajan para nosotros se dedican a la IA o a la interacción persona-computadora; esta proporción es mayor que en otros departamentos, y siempre lo ha sido. Pero cuando estaba en la universidad, no tenía ningún curso sobre IA y nunca trabajé en este campo. Entonces mi departamento se especializa en un problema con el que yo no tengo nada que ver. El consuelo es que el segundo problema más importante para nuestro departamento es la programación paralela y multiproceso, es decir, mi especialización.
Vitali: Empezaste a trabajar en Ciencias de la Computación cuando recién estaba surgiendo el campo de la programación multiproceso. La lista de sus publicaciones muestra que sus primeros trabajos abordaron una gama bastante amplia de temas: gestión de memoria en sistemas multiproceso, sistemas de archivos distribuidos, sistemas operativos. ¿A qué se debe tanta versatilidad? ¿Ha estado tratando de encontrar su lugar en la comunidad de investigación?
Michael: Como estudiante, participé en en la Universidad de Wisconsin, donde se desarrolló uno de los primeros sistemas operativos distribuidos. Allí trabajé junto a Rafael Finkel () y Marvin Salomón (). Mi tesis estuvo dedicada al desarrollo de un lenguaje para software de sistema para sistemas distribuidos; ahora todo el mundo lo ha olvidado, y gracias a Dios. Creé el lenguaje de programación Lynx, cuyo objetivo era facilitar la creación de servidores para un sistema operativo distribuido débilmente acoplado. Como en aquel momento me dedicaba principalmente a los sistemas operativos, supuse que mi carrera estaría principalmente relacionada con ellos. Pero Rochester era una universidad muy pequeña y, debido a esto, los diferentes grupos interactuaban muy estrechamente entre sí. No había allí una docena de personas más sobre sistemas operativos con quienes pudiera hablar, por lo que todos mis contactos eran con personas que trabajaban en áreas completamente diferentes. Realmente lo disfruté, ser un todoterreno es una gran ventaja para mí. Si hablamos específicamente de estructuras de datos multiproceso y algoritmos de sincronización, entonces comencé a trabajar en ellos por pura casualidad.
Interfaz coherente escalable IEEE, bloqueo MCS.
Vitali: ¿Puedes contarme un poco más sobre esto?
Michael: Esta es una historia divertida que nunca me canso de contarles a todos. Sucedió en una conferencia en Boston, esto fue a finales de los 80 o principios de los 90. John Mellor-Crummey (), egresado de nuestra facultad. Lo conocía, pero nunca antes habíamos realizado una investigación conjunta. María Vernon () de Wisconsin dio una charla sobre un sistema multiprocesador que estaban desarrollando en Wisconsin: . Este Multicube tenía un mecanismo de sincronización a nivel de hardware llamado Q on Sync Bit, y luego pasó a llamarse Q on Lock Bit porque sonaba a queso Colby, lo cual era un juego de palabras. Si está interesado en los mecanismos de subprocesos múltiples, probablemente sepa que Colby eventualmente se convirtió en el motor de sincronización para el estándar IEEE Scalable Coherent Interface. Este era un mecanismo de bloqueo que creaba punteros de un caché a otro a nivel de hardware para que cada titular de la cerradura supiera de quién era el turno. Cuando John y yo nos enteramos de esto, nos miramos y dijimos: ¿por qué hacer esto a nivel de hardware? ¿No se puede lograr lo mismo usando comparar e intercambiar? Tomamos uno de los cuadernos que había en el salón de clases y escribimos en él. , mientras Mary continuaba con su informe. Posteriormente lo implementamos, experimentamos, la idea resultó exitosa y publicamos el artículo. En ese momento, este tema me parecía solo una distracción divertida, después de lo cual planeaba volver a los sistemas operativos. Pero luego surgió otro problema en el mismo sentido y, finalmente, la sincronización, los subprocesos múltiples y las estructuras de datos se convirtieron en mi especialidad. Como puedes ver, todo esto sucedió por accidente.
Vitali: Conozco el bloqueo MCS desde hace mucho tiempo, pero hasta ahora no sabía que era trabajo tuyo y no entendía que era un acrónimo de tus apellidos.
¿Cómo sobrevivir en un mundo en constante cambio?
Alexey: Tengo una pregunta sobre un tema relacionado. Hace 30 o 40 años había más libertad en las distintas especialidades. Si quieres iniciar una carrera en sistemas multihilo o distribuidos, de nada, si quieres iniciarte en sistemas operativos, no hay problema. En cada área había muchas preguntas abiertas y pocos expertos. Ahora han surgido especializaciones estrechas: no sólo hay expertos en sistemas operativos en general, sino que también hay especialistas en sistemas individuales. Lo mismo ocurre con los sistemas distribuidos y de subprocesos múltiples. Pero el problema es que nuestras vidas no son infinitas; todo el mundo puede dedicar sólo unas pocas décadas a la investigación. ¿Cómo sobrevivir en este nuevo mundo?
Michael: No somos especiales en este sentido, lo mismo sucedió una vez en otras áreas. Tuve la suerte de empezar a trabajar en Ciencias de la Computación cuando el campo estaba en su “adolescencia”. Ya se habían puesto algunas bases, pero todo estaba todavía muy inmaduro. Esta oportunidad no se presenta a menudo. La ingeniería eléctrica existe desde hace mucho tiempo, la física aún más y las matemáticas casi desde el principio de los tiempos. Pero esto no significa que ya nadie esté haciendo descubrimientos interesantes en matemáticas. Todavía quedan muchos problemas abiertos, pero al mismo tiempo es necesario aprender más. Tiene razón al señalar que ahora hay muchas más especializaciones que antes, pero esto sólo significa que nos encontramos en la misma situación que la mayoría de las demás áreas de la actividad humana.
Alexey: Estoy interesado en el aspecto más práctico del tema aquí. Tengo experiencia en matemáticas y durante mis estudios asistí a menudo a conferencias y trabajé en diversos temas científicos. Descubrí que nadie en la audiencia entendía mis informes y, de la misma manera, los informes de otras personas sólo eran comprensibles para ellos mismos. Este no es el caso en temas de alto nivel, pero en cuanto empiezas a profundizar en algo, la audiencia ya no puede seguirte. Como tratas con esto?
Michael: No siempre tiene éxito. Recientemente preparé un informe en el que profundicé demasiado en detalles técnicos. A medida que avanzaba la charla, quedó claro que la mayoría de los asistentes no me entendían, por lo que tuve que adaptarme a la situación sobre la marcha. Las diapositivas no se pudieron cambiar, por lo que no quedó muy bien; así que, en términos generales, trato de no usar diapositivas. En general, mi consejo es considerar a su audiencia. Necesita saber con quién está hablando, cuál es su nivel de conocimiento y qué necesitan escuchar para apreciar su trabajo.
Vitali: ¿Podría darnos una pista de qué se trató esta conferencia?
Michael: Para ser honesto, preferiría no extenderme sobre este tema para dejar a las personas en cuestión en el anonimato. El punto es que a menudo profundizamos demasiado en las complejidades del problema en el que estamos trabajando, por lo que nos resulta difícil explicar al comienzo de la charla por qué el problema es interesante e importante y cómo se relaciona con cuestiones que el El público ya lo sabe. Según mis observaciones, los estudiantes tienen más dificultades para aprender esta habilidad. Y éste fue también el punto débil de mi reciente informe. Un informe correctamente estructurado debe, desde el principio, encontrar contacto con el público, explicarle cuál es exactamente el problema y cómo se relaciona con temas que ya conoce. El grado de técnica de esta introducción depende de la audiencia. Si es completamente heterogéneo, entonces el informe puede tener varias etapas. La introducción debe ser accesible para todos y, al final, es posible que el artículo no pueda seguirle el ritmo, pero las personas relativamente familiarizadas con su campo podrán resolverlo.
¿Se están volviendo más tontos los estudiantes? Tendencias globales, internacionalización.
Alexey: Usted ha estado observando a los estudiantes durante varias décadas. ¿Los estudiantes se están volviendo más tontos o más inteligentes de década en década o de año en año? En Rusia, los profesores se quejan constantemente de que los estudiantes son cada año más tontos y realmente no está claro qué hacer al respecto.
Michael: Realmente se puede escuchar mucha negatividad por parte de nosotros, los ancianos. Inconscientemente, tenemos una tendencia a esperar que los estudiantes absorban los 30 años de experiencia que ya tenemos. Si tengo una comprensión más profunda que la que tenía en 1985, ¿por qué los estudiantes no la tienen? Probablemente porque tienen 20 años, ¿qué opinas? Creo que los cambios más significativos en las últimas décadas se han producido en la composición demográfica: ahora tenemos significativamente más estudiantes internacionales, con la excepción de los canadienses. Solía haber muchos canadienses porque estamos muy cerca de la frontera canadiense y los estudiantes de allí pueden viajar a casa los fines de semana. Pero ahora hay muchas buenas universidades en Canadá y los canadienses prefieren estudiar aquí; muchos menos vienen a los Estados Unidos.
Alexey: ¿Crees que se trata de una tendencia local o global?
Michael: No recuerdo exactamente quién, pero alguien dijo que el mundo es plano. Nuestro campo se ha vuelto mucho más internacional. Anteriormente se realizaban exclusivamente dentro de Estados Unidos, luego decidieron realizarlos una vez cada 4 años en otros países y ahora se realizan en todo el mundo. Estos cambios afectaron aún más , ya que siempre ha sido una organización más internacional que ACM. Y hay presidentes de programas de China, India, Rusia, Alemania y muchos otros países, porque ahora están sucediendo muchas cosas en todas partes.
Alexey: Pero, ¿probablemente hay algunos aspectos negativos de tal internacionalización?
Michael: Yo diría que todos los aspectos negativos no tienen que ver con la tecnología, sino con la política. Érase una vez, el principal problema era el hecho de que Estados Unidos estaba robando a las personas más inteligentes y talentosas de países de todo el mundo. Y ahora el principal problema son los juegos políticos entre diferentes países en torno a visas e inmigración.
Alexey: Es decir, barreras y cosas así. Está vacío.
Vladimir: Personalmente, me interesa saber qué enfoque adopta al enseñar una nueva materia a los estudiantes. Hay diferentes opciones: puedes intentar primero inspirarlos a probar algo nuevo, o puedes prestar más atención a los detalles de cómo funciona una determinada tecnología. ¿Qué prefieres?
Trabajo efectivo con los estudiantes.
Alexey: ¿Y cómo encontrar el maldito equilibrio entre el primero y el segundo?
Michael: El problema es que las clases no siempre salen como me gustaría. Normalmente doy a los estudiantes material de lectura con antelación para que profundicen en él, lo entiendan lo mejor que puedan y formulen preguntas sobre aquellas partes que no pudieron entender. Luego, en clase podréis centraros en los momentos más difíciles y explorarlos juntos. Así es como más me gusta dar clases. Pero dada la carga que ahora recae sobre los estudiantes, no siempre puedo asegurarme de que se preparen con antelación. Como resultado, tendrá que dedicar mucho más tiempo del que le gustaría al recuento general del material. A pesar de esto, trato de mantener nuestras clases interactivas. De lo contrario, es más fácil grabar un vídeo una vez que los estudiantes puedan verlo en casa. El objetivo de las clases en vivo es la interacción humana. En clase, prefiero usar tiza y una pizarra en lugar de diapositivas, excepto en ciertos casos cuando un diagrama es demasiado complejo para representarlo en la pizarra. Gracias a esto, no tengo que ceñirme a un plan de lecciones rígido. Como no hay un orden estricto en el que entrego el material, esto me permite adaptarlo a la audiencia dependiendo de las preguntas que recibo. En general trato de que las clases sean lo más interactivas posible, de manera que el material que presento dependa de las preguntas que me hagan.
Vladimir: Es genial. En mi experiencia, es bastante difícil lograr que los oyentes hagan preguntas. Incluso si pides con anticipación que hagas alguna pregunta, no importa cuán estúpida o inteligente sea, todavía guardan silencio. Como tratas con esto?
Michael: Te reirás, pero si te quedas en silencio el tiempo suficiente, tarde o temprano todos se sentirán incómodos y alguien hará una pregunta. O puede hacer una pregunta técnica simple con una respuesta de sí o no para determinar si las personas entienden lo que se acaba de decir. Por ejemplo, ¿hay una carrera de datos en el ejemplo anterior? ¿Quién piensa eso? ¿Quién piensa que no? ¿Quién no entiende nada de nada, porque en total sólo se levantaron la mitad de las manos?
Vitali: Y si respondiste incorrectamente, te echarán de la clase :)
Michael: Si no has respondido nada, entonces deberías hacer una pregunta. Necesito entender qué necesita saber exactamente el estudiante para responder la pregunta que acabo de hacer. Necesito que me ayuden a ayudarlos. Estoy dispuesto a adaptarme a ellos para que comprendan el problema. Pero si no sé lo que pasa por su cabeza, no puedo hacerlo. Y si no se les da tranquilidad a los estudiantes durante un tiempo suficiente, a veces al final hacen las preguntas correctas, es decir, preguntas que me permiten ver qué está pasando exactamente por las cabezas de los estudiantes.
Alexey: ¿Estas preguntas a veces te llevan a ideas en las que no habías pensado antes? ¿Son inesperados? ¿Le permiten ver un problema desde una nueva perspectiva?
Michael: Hay preguntas que abren una nueva forma de presentar el material. A menudo surgen preguntas que conducen a problemas interesantes de los que no pensaba hablar. Los estudiantes a menudo me dicen que tengo tendencia a salirme del tema cuando esto sucede. Y, según ellos, muy a menudo esta es la parte más interesante de la lección. Muy raramente, sólo unas pocas veces, los estudiantes hicieron preguntas que impulsaron una nueva dirección en la investigación y se convirtieron en un artículo. Esto sucede mucho más a menudo en las conversaciones con los estudiantes que durante las clases, pero ocasionalmente sucedió durante las clases.
Alexey: ¿Entonces los estudiantes le hicieron preguntas a partir de las cuales fue posible publicar un artículo?
Michael: Si
Vitali: ¿Con qué frecuencia tienes estas conversaciones con los estudiantes? ¿Cuándo quieren aprender más de lo que se cubrió durante la lección?
Michael: Con mis estudiantes de posgrado, todo el tiempo. Tengo unos 5 o 6 y discutimos algo con ellos todo el tiempo. Y conversaciones de este tipo con alumnos que simplemente asisten a mis clases no son muy habituales. Aunque desearía que esto sucediera más a menudo. Sospecho que simplemente tienen miedo de venir a la facultad durante el horario de oficina. Cada semestre, algunos alumnos logran superar esta barrera psicológica y siempre es muy interesante hablar con ellos después de clase. Es cierto que si todos los estudiantes fueran igual de valientes, simplemente no tendría suficiente tiempo. Entonces tal vez todo esté funcionando como debería.
Vitali: ¿Cómo logra encontrar tiempo para comunicarse con los estudiantes? Hasta donde yo sé, en Estados Unidos los profesores tienen mucho trabajo: solicitar becas y cosas por el estilo.
Michael: Sinceramente, trabajar con estudiantes es el aspecto de mi trabajo que más disfruto. Entonces tengo suficiente motivación para esto. La mayor parte del tiempo que paso en mi oficina lo dedico a reuniones de todo tipo. Ahora es verano, así que mi agenda está menos ocupada, pero durante el año escolar, todos los días de 9 a 17 tengo todo empacado. Trabajos de investigación, reseñas, becas: para todo esto solo hay tardes y fines de semana.
Cómo mantenerse al día con la preparación de nuevos cursos y libros.
Alexey: ¿Actualmente continúas impartiendo algún curso que ya vienes impartiendo desde hace mucho tiempo? Algo así como una introducción a la Informática.
Michael: Lo primero que me viene a la mente aquí es un curso de lenguajes de programación.
Alexey: ¿Qué tan diferente es la versión actual de este curso de la que era hace 10, 20 o 30 años? Quizás lo más interesante aquí no sean los detalles de un curso en particular, sino las tendencias generales.
Michael: Mi curso sobre lenguajes de programación era algo inusual en el momento en que lo creé. Comencé a leerlo a finales de los años 1980, reemplazando a mi colega Doug Baldwin (). El tema del curso solo estaba tangencialmente relacionado con mi especialidad, pero cuando él se fue, yo era el mejor candidato para impartir el curso. No me gustaba ninguno de los libros de texto que existían en ese momento, así que terminé escribiendo yo mismo el libro de texto de este curso. (Nota del editor: estamos hablando del libro) Actualmente se utiliza en más de 200 universidades de todo el mundo. Mi enfoque es inusual porque mezcla deliberadamente los problemas de diseño e implementación del lenguaje y presta gran atención a la interacción entre estos aspectos en todas las áreas posibles. El enfoque básico se ha mantenido sin cambios, al igual que muchos conceptos básicos: abstracciones, espacios de nombres, modularidad, tipos. Pero el conjunto de lenguajes con los que se demuestran estos conceptos ha cambiado por completo. Cuando se creó el curso por primera vez, había muchos ejemplos en Pascal, pero hoy muchos de mis alumnos ni siquiera han oído hablar de este idioma. Pero conocen Swift, Go, Rust, así que tengo que hablar sobre los lenguajes que se utilizan hoy en día. Además, los estudiantes ahora conocen bien los lenguajes de programación, pero cuando comencé a impartir este curso, todo se trataba de lenguajes compilados. Ahora necesitamos mucho material sobre Python, Ruby e incluso Perl, porque así es como se escribe el código hoy en día, y están sucediendo muchas cosas interesantes en estos lenguajes, incluso en el campo del diseño de lenguajes.
Vitali: Entonces mi próxima pregunta estará relacionada con la anterior. ¿Cómo mantenerse al día en esta área? Sospecho que actualizar un curso como este requiere mucho trabajo: es necesario comprender nuevos idiomas y comprender las ideas principales. ¿Cómo haces esto?
Michael: No puedo presumir de tener siempre éxito al 100%. Pero la mayor parte del tiempo hago lo que hacen todos los demás: leer Internet. Si quiero entender Rust, lo busco en Google, voy a la página de Mozilla y leo el manual publicado allí. Esto es parte de las cosas que suceden en el desarrollo comercial. Si hablamos de ciencia, entonces hay que seguir los informes de las principales conferencias.
Vínculo entre empresa y academia
Vitali: Hablemos de la conexión entre los negocios y la investigación científica. En su lista de trabajos, encontré varios artículos sobre coherencia de caché. ¿Entiendo que los algoritmos de coherencia de la caché eran inestables en el momento de su publicación? O no lo suficientemente extendido. ¿Qué tan comunes fueron sus ideas en la práctica?
Michael: No estoy exactamente seguro de qué publicaciones estás hablando. He trabajado bastante con mis alumnos Bill Bolosky () y Leonidas Kontotanassis () a principios de la década de 1990 sobre la gestión de la memoria de las máquinas Neumann. En ese momento, las empresas aún no entendían cómo hacer correctamente un sistema multiprocesador: ¿vale la pena crear soporte para acceder a la memoria remota a nivel de hardware? ¿Vale la pena distribuir la memoria? ¿Es posible cargar el caché desde memoria remota, o es necesario mover páginas en el sistema operativo? Bill y Leonidas trabajaron en esta área y exploraron enfoques sin carga remota de caché. Esto no estaba directamente relacionado con la coherencia de la caché, pero todavía era un trabajo en la administración de la memoria NUMA y, posteriormente, a partir de esto surgieron enfoques modernos para la ubicación de páginas en los sistemas operativos modernos. En general, Bill y Leonidas hicieron un trabajo importante, aunque no el más influyente en esta área: había muchas otras personas trabajando en lo mismo en ese momento. Posteriormente trabajé en un tema relacionado con la coherencia del caché en el contexto de la memoria transaccional de hardware. El grupo con el que trabajé en este problema acabó recibiendo varias patentes. Hay algunas ideas bastante interesantes detrás de ellas, pero no creo que terminen implementándose en la práctica. De una forma u otra, me resulta difícil juzgar su rentabilidad.
Alexey: En este sentido, una pregunta más personal: ¿qué importancia tiene para usted que sus ideas se pongan en práctica? ¿O no lo piensas?
Michael: Me encanta hacer esta pregunta en entrevistas con otras personas, aspirantes o candidatos que quieran incorporarse a la facultad. No creo que haya una respuesta correcta a esta pregunta. Las personas que hacen cosas interesantes pueden tener motivaciones muy diferentes. Me atraen los problemas porque personalmente los encuentro interesantes, no por sus beneficios prácticos. Pero, por otro lado, cuando algo interesante todavía encuentra aplicación, me gusta mucho. Entonces aquí no es fácil. Pero al comienzo de mi trabajo, todavía no me impulsa la idea de un uso final en el mundo, sino la armonía de la idea y el deseo de explorarla y ver qué resulta de ella. Si al final da resultados prácticos, genial.
Alexey: Debido a su educación y experiencia, usted es más capaz que la mayoría de juzgar el valor de las ideas de otras personas. Puede compararlos y determinar cuál funciona mejor con cuál. Estoy seguro de que tiene una opinión sobre las cosas que actualmente utilizan en la práctica grandes fabricantes como Intel. Desde su punto de vista, ¿qué tan correcto es el rumbo que están tomando estas empresas?
Michael: La práctica siempre gira en torno a lo que puede tener éxito comercial, es decir, generar ganancias, y será mejor que le preguntes a alguien más sobre eso. Mi trabajo se traduce principalmente en publicaciones, y en el campo de los sistemas operativos se evalúan en función de indicadores de rendimiento: velocidad, consumo de energía, tamaño del código. Pero siempre me pareció que estos resultados empíricos se añaden a los artículos sólo para que puedan ser publicados, y los verdaderos motivos de trabajo de la gente son estéticos. Los investigadores evalúan las soluciones desde una perspectiva artística, se preocupan por la elegancia de las ideas y tratan de crear algo mejor que los enfoques existentes. Los investigadores están impulsados por motivos personales, subjetivos y estéticos. Pero no se puede escribir sobre esto en el artículo mismo; estas cosas no son argumentos para el comité del programa. Afortunadamente, las soluciones elegantes suelen ser también rápidas y económicas. Una docena de mis colegas y yo discutimos este tema hace unos 15 años y terminamos escribiendo un artículo al respecto. Creo que todavía puedes encontrarlo ahora, se llama o algo así, tiene más de una docena de autores. Este es el único artículo del que soy autor junto con , así que si buscas su nombre en mi lista de publicaciones, encontrarás lo que necesitas. Habla sobre la evaluación de la investigación de sistemas y lo importante que es la elegancia.
Alexey: Entonces hay una diferencia entre el estándar de lo que se considera bueno en la ciencia y en los negocios. La ciencia evalúa el rendimiento, el consumo de energía, el TDP, la facilidad de implementación y mucho más. ¿Tienes la oportunidad de realizar este tipo de investigación en la universidad? ¿Tiene un laboratorio con diferentes máquinas y diferentes arquitecturas en el que podría realizar experimentos?
Michael: Sí, nuestro departamento tiene muchas máquinas diferentes e interesantes. La mayoría de las veces son pequeños, tenemos un clúster pequeño y muchos sistemas multiprocesador con diferentes aceleradores. Además, el campus cuenta con un enorme centro de computación que atiende a científicos de varias docenas de disciplinas diferentes. Tiene alrededor de mil nodos y veinte mil núcleos, todos en Linux. Si surge la necesidad, siempre puedes comprar algo de AWS. Por lo tanto, no tenemos restricciones importantes con el hardware.
Alexey: ¿Cómo era hace treinta años? ¿Hubo problemas entonces?
Michael: Era un poco diferente entonces. A mediados y finales de la década de 1980, se consideraba que la ciencia carecía de recursos informáticos. Para remediar esta situación, la Fundación Nacional de Ciencias ) creó un programa de investigación experimental coordinada (Investigación Experimental Coordinada, CER). La misión del programa era proporcionar infraestructura informática para los departamentos de Ciencias de la Computación y ha logrado cambios significativos. Con el dinero que ella nos proporcionó, en la Universidad de Rochester compramos un BBN Butterfly de 1984 nudos en 128, esto fue un año antes de que yo llegara allí. En aquel momento era el sistema multiprocesador con memoria compartida más grande del mundo. Tenía 128 procesadores, cada uno en una placa base independiente, y ocupaba cuatro bastidores. Cada procesador tenía un megabyte de memoria, 128 megabytes de RAM era una cantidad inimaginable en aquella época. En esta máquina implementamos el bloqueo MCS por primera vez.
Alexey: Entonces, si le entendí correctamente, ¿por el momento se ha resuelto el problema con el hardware?
Michael: En general, sí. Hay algunas advertencias: primero, si estás haciendo arquitectura de computadora a nivel de chip, es difícil hacerlo en un entorno académico porque existen herramientas mucho mejores para hacerlo en los negocios. Si necesita algo de menos de 10 nanómetros, tendrá que pedírselo a otra persona. En este ámbito es mucho más fácil ser investigador en Intel. Si estás trabajando en comunicaciones ópticas en chips o en memorias de estado sólido, encontrarás tecnologías en los negocios que aún no están en la ciencia, por lo que tendrás que crear alianzas. Por ejemplo, Stephen Swanson () creado para nuevas tecnologías de memoria. Esta forma no siempre funciona, pero en algunos casos puede resultar bastante eficaz. Además, en ciencia el desarrollo de los sistemas informáticos más potentes es más difícil. Los mayores proyectos de supercomputadoras actualmente en Estados Unidos, Japón y China se centran en los negocios.
Implementación práctica de ideas. MCS, MS, CLH, JSR 166, trabajando con Doug Lee y más.
Vitali: Ya has hablado de cómo empezaste a trabajar en algoritmos de sincronización. Tienes dos artículos muy famosos sobre и , que en cierto sentido se implementaron en Java. (Nota del editor: todas las publicaciones se pueden ver ). Allí se implementó este bloqueo con algunos cambios y resultó y la cola se implementó según lo previsto. Pero pasaron muchos años entre la publicación de sus artículos y su aplicación práctica.
Alexey: Parecen unos 10 años en el caso de la cola.
Michael: ¿Antes de que aparecieran estas funciones en la biblioteca estándar de Java?
Vitali: Sí. ¿Qué hiciste para que esto sucediera? ¿O no hicieron nada?
Michael: Puedo contarles cómo MS Queue llegó a Java 5. Unos años antes de que saliera, trabajé con el grupo de Mark Moyers en Sun Microsystems en su laboratorio cerca de Boston. Organizó un taller para personas que conocía que estaban trabajando en problemas interesantes en subprocesos múltiples porque quería encontrar temas que pudiera vender a su empresa. Allí conocí a Doug Lea por primera vez. Doug, yo y unas 25 personas más de Sun estábamos juntos discutiendo la presentación de Doug sobre , que luego se convirtió en java.util.concurrent. En el camino, Doug dijo que le gustaría usar la cola de MS, pero para ello necesitaba un contador para la cantidad de elementos en la cola de la interfaz. Es decir, esto debería haberse hecho mediante un método independiente, atómico, preciso y rápido. Sugerí simplemente agregar números de serie a los nodos, tomando el número del primer nodo y del último y restando uno del otro. Doug se rascó la cabeza, dijo "¿por qué no?" y terminó haciendo precisamente eso. Discutimos la implementación de este enfoque en la biblioteca, pero Doug hizo la mayor parte del trabajo él mismo. Como resultado, logró establecer un excelente soporte para subprocesos múltiples en Java.
Alexey: Entonces, si entendí correctamente, ¿el método .size() debería haber sido parte de la interfaz de cola estándar y debería haber tenido una complejidad algorítmica de O(1)?
Michael: Sí, y además se requiere un contador aparte.
Alexey: Porque si llama al método .size() en Java, se espera que el resultado esté disponible inmediatamente y no según el tamaño real de la colección. Ya entiendo, gracias.
Michael: Unos años más tarde estaba trabajando en estructuras de datos duales con mi alumno Bill Scherer; de hecho, de esto es de lo que hablaré . Doug vino a nosotros y nos dijo que podía usarlos en Java Executor Framework. Junto con Bill, crearon dos implementaciones, las llamadas colas justas e injustas. Les asesoré en este proyecto, aunque no participé en la redacción del código real. Como resultado, la velocidad de los ejecutores ha aumentado significativamente.
Vladimir: ¿Ha encontrado implementaciones incorrectas de sus algoritmos o solicitudes para agregar nuevas funciones? En general, la práctica debería coincidir con la teoría, pero muy a menudo difieren. Supongamos que escribe un algoritmo y, en papel, funciona, pero las personas involucradas en la implementación comenzaron a pedirle más funciones o algún tipo de ajuste del algoritmo. ¿Alguna vez has tenido situaciones así?
Michael: El único ejemplo en el que alguien se me acercó y me preguntó “cómo implementarlo” fue la pregunta de Doug, de la que ya hablé. Pero ha habido algunos casos en los que se han realizado cambios interesantes para satisfacer necesidades prácticas. Por ejemplo, el equipo K42 de IBM convirtió el bloqueo MCS y lo convirtió en una interfaz estándar para que no fuera necesario pasar el nodo de cola de un lado a otro entre las rutinas de adquisición y liberación. Gracias a esta interfaz estándar, una idea que en teoría era hermosa comenzó a funcionar en la práctica. Es sorprendente que nunca publicaran un artículo al respecto y, aunque obtuvieron una patente, luego la abandonaron. La idea fue maravillosa y trato de hablar de ello siempre que sea posible.
Ha habido otros casos en los que las personas han realizado mejoras en los algoritmos que he publicado. Por ejemplo, la cola de MS tiene un mecanismo de instalación de dos pasos, lo que significa que había dos CAS en la ruta crítica de la cola. En los coches más antiguos, los CAS eran bastante caros. Intel y otros fabricantes las han optimizado bastante bien recientemente, pero alguna vez fueron instrucciones de 30 ciclos, por lo que no era deseable tener más de una en la ruta crítica. Como resultado, se desarrolló una cola diferente que era similar a la cola MS, pero que tenía solo una operación atómica en la ruta crítica. Esto se logró debido al hecho de que durante un cierto período de tiempo la operación podría tomar O(n) tiempo, en lugar de O(1). Era poco probable, pero posible. Esto sucedió debido al hecho de que en ciertos momentos el algoritmo atravesó la cola desde el principio hasta la posición actual en esta cola. En general, el algoritmo resultó ser muy exitoso. Hasta donde yo sé, no se usa mucho, en parte porque las operaciones atómicas requieren muchos menos recursos que antes. Pero la idea era genial. También me gusta mucho el trabajo de Dave Dice de Oracle. Todo lo que hace es muy práctico y utiliza el hierro de forma muy inteligente. Participó en gran parte de los algoritmos de sincronización compatibles con NUMA y las estructuras de datos multiproceso.
Vladimir: Cuando escribe algoritmos o enseña a sus estudiantes, el resultado de su trabajo no es visible de inmediato. La comunidad necesita algo de tiempo para familiarizarse con, digamos, un artículo nuevo. El nuevo algoritmo no encuentra aplicación de inmediato.
Michael: No está nada claro de inmediato si el artículo será significativo o no. Creo que sería interesante hacer un estudio de artículos que hayan ganado premios en congresos. Es decir, mire los artículos que las personas de los comités del programa alguna vez consideraron los mejores. Debe intentar calcular, por la cantidad de enlaces y el impacto en los negocios, qué tan influyentes fueron realmente estos artículos en 10, 20 o 25 años. Dudo que haya una fuerte correlación entre los dos. No será cero, pero lo más probable es que sea mucho más débil de lo que nos gustaría. Muchas ideas permanecen sin ser reclamadas durante mucho tiempo antes de que se generalicen. Por ejemplo, tomemos la memoria transaccional. Pasaron más de 10 años desde que se publicó el artículo original hasta que la gente empezó a construir máquinas con él. Y antes de la aparición de esta memoria en productos comerciales, y los 20. Durante mucho tiempo nadie prestó atención al artículo, y luego el número de enlaces a él aumentó considerablemente. Sería difícil predecir esto de antemano. Por otro lado, a veces las ideas se implementan inmediatamente. Hace unos años, escribí un artículo con Joe Izraelevitz para DISC que proponía una nueva definición formal de validez para estructuras de datos persistentes que podrían usarse después de que falla la computadora que las ejecuta. Me gustó el artículo desde el principio, pero resultó ser mucho más popular de lo que esperaba. Fue utilizado por varios grupos diferentes y finalmente se convirtió en la definición estándar de estructuras de persistencia. Lo cual, por supuesto, es agradable.
Vladimir: ¿Existe alguna técnica que utilice para la evaluación? ¿Intentas siquiera evaluar tus artículos y a tus alumnos? En términos de si la persona a la que enseñaste va en la dirección correcta.
Michael: Como todos, presto más atención a lo que estoy haciendo en este momento. Nuevamente, como todos los demás, de vez en cuando reviso Google Scholar para ver si se citan mis artículos anteriores, pero eso es más por curiosidad. Principalmente estoy absorto en lo que mis alumnos están haciendo ahora. Cuando se trata de evaluar el trabajo actual, parte de ello son consideraciones estéticas, qué es elegante y qué no. Y a nivel cotidiano, las preguntas abiertas juegan un papel importante. Por ejemplo, un estudiante viene a mí con un gráfico de algunos resultados y estamos tratando de entender de dónde vino algún comportamiento extraño del gráfico. En general, en nuestro trabajo intentamos constantemente comprender cosas que aún no entendemos.
memoria transaccional
Vitali: ¿Quizás podamos hablar un poco sobre la memoria transaccional?
Michael: Creo que vale la pena decir al menos un poco porque le puse mucho esfuerzo. Este es un tema sobre el que tengo más publicaciones que cualquier otro. Pero al mismo tiempo, curiosamente, siempre fui muy escéptico acerca de la memoria transaccional. En mi opinión, (M. Herlihy, J. E. B. Moss) se publicó antes de su tiempo. A principios de la década de 1990, sugirieron que la memoria transaccional podría ayudar a los programadores talentosos a trabajar en estructuras de datos de subprocesos múltiples, de modo que los programadores comunes pudieran utilizar estas estructuras como bibliotecas. Es decir, sería de ayuda para Doug Lee haciendo su JSR 166. Pero la memoria transaccional no estaba destinada a facilitar la programación multiproceso. Pero así es exactamente como empezó a percibirse a principios de la década de 2000, cuando se generalizó. Se anunció como una forma de resolver el problema de la programación paralela. Este enfoque siempre me ha parecido inútil. La memoria transaccional sólo podría facilitar la escritura de estructuras de datos paralelas. Esto, me parece, es lo que logró.
Sobre la dificultad de escribir código multiproceso
Alexey: Muy interesante. Parece haber una cierta barrera entre los programadores habituales y aquellos que pueden escribir código multiproceso. El año pasado, hablé varias veces con personas que estaban implementando algún marco algorítmico. Por ejemplo, con Martin Thomson, así como con programadores que trabajan en bibliotecas multiproceso. (Nota del editor: Martin Thompson es un desarrollador muy famoso, escribió и . Y el tambien tiene en nuestra conferencia Joker 2015, grabación de vídeo . el es el mismo esta conferencia también disponible). El principal desafío, dicen, es hacer que los algoritmos sean rápidos y fáciles de usar. Es decir, están intentando superar esta barrera y atraer a la mayor cantidad de gente posible a esta zona. ¿Que piensas de eso?
Michael: Este es el principal problema del subproceso múltiple: cómo lograr un alto rendimiento sin aumentar la complejidad del sistema.
Alexey: Porque cuando intentan evitar la complejidad, el algoritmo se vuelve menos universal.
Michael: La clave aquí son las abstracciones correctamente diseñadas. Me parece que esto es generalmente lo principal para los sistemas informáticos como campo. A Butler Lampson le gusta usar este término y nos llama “comerciantes de abstracciones”. Hoy en día no existen tecnologías simples. Los procesadores que utilizamos tienen 10 mil millones de transistores; la simplicidad está fuera de discusión. Al mismo tiempo, ISA es mucho más simple que el procesador, ya que trabajamos durante mucho tiempo para brindarle un alto rendimiento y una interfaz relativamente simple. Pero tampoco todo va bien con ella. El mismo problema ocurre con los aceleradores que están apareciendo ahora en el mercado. Surgen preguntas: cómo crear la interfaz adecuada para la GPU, un mecanismo de cifrado, compresión, un mecanismo de transcodificación, un mecanismo de álgebra lineal o incluso una FPGA más flexible. ¿Cómo crear una interfaz que haga que la herramienta sea fácil de usar y oculte la complejidad? No lo eliminará, sino que lo ocultará a un simple programador.
Alexey: Según tengo entendido, todavía tenemos una barrera para comprender las abstracciones. Tomemos el modelo de la memoria; en nuestra etapa de desarrollo de la ciencia y la tecnología, esta es una de las principales abstracciones. Gracias a ello, todos los programadores se dividen en dos grupos: la mayor parte son los que no lo entienden, y la menor parte son los que entienden, o creen que entienden.
Michael: Esa es una buena pregunta: ¿alguno de nosotros entiende realmente el modelo de memoria?
Vitali: Especialmente en C++.
Michael: Habla con Hans Boehm alguna vez. Es una de las personas más inteligentes que conozco, un destacado experto en modelos de memoria. Él le dirá de inmediato que hay muchas cosas que no comprende. Pero si volvemos a la cuestión de las abstracciones, entonces, en mi opinión, la idea más importante en el campo de los modelos de memoria durante los últimos 30 años se expresó. . (Nota del editor: una lista completa de publicaciones está disponible ).
Alexey: Mi pregunta es: ¿esta barrera proviene de la naturaleza misma del concepto?
Michael: No. Sarita llegó a la conclusión de que con el enfoque correcto se puede ocultar con éxito toda la complejidad, obtener un alto rendimiento y darle al programador una API simple. Y si sigue esta API, puede lograr una coherencia constante. Creo que este es el modelo correcto. Escriba código sin carreras de datos y obtenga coherencia secuencial. Por supuesto, para reducir la probabilidad de carreras, se necesitan herramientas especiales, pero eso es otra cuestión.
Vladimir: ¿Ha habido momentos en su carrera en los que un problema que parecía resuelto de repente se convirtió en una catástrofe, o resultó que ese problema no tenía solución? Por ejemplo, en teoría puedes factorizar cualquier número o determinar si algún número es primo. Pero en la práctica esto puede ser difícil de hacer; con el hardware actual es difícil factorizar números. ¿Te ha pasado algo parecido?
Michael: No recuerdo inmediatamente nada de eso. Ha habido momentos en los que me parecía que ya no quedaba nada por hacer en un área determinada, pero luego sucedió algo nuevo e interesante allí. Por ejemplo, pensé que el área de colas ilimitadas ya había llegado a su madurez. Después de varias mejoras en la cola MNS, ya no pasó gran cosa. Y luego Morrison (Adam Morrison) y Afek (Yehuda Afek) inventaron . Quedó claro que era posible una cola ilimitada de subprocesos múltiples, donde la mayoría de las veces solo había una instrucción de búsqueda e incremento en la ruta crítica. Y esto hizo posible lograr un rendimiento mucho mejor. No es que no sepamos que buscar e incrementar es algo muy útil. Eric Freudenthal escribió sobre esto en su trabajo sobre la ultracomputadora con Allan Gottlieb a fines de la década de 1980, pero se trataba de colas limitadas. Morrison y Afek pudieron utilizar la función de búsqueda e incremento en una cola ilimitada.
Nuevas arquitecturas. ¿Está cerca la victoria de la memoria transaccional?
Vladimir: ¿Está buscando nuevas soluciones arquitectónicas que puedan resultar útiles para los algoritmos?
Michael: Por supuesto, hay muchas cosas que me gustaría que se implementaran.
Vladimir: ¿Qué tipo, por ejemplo?
Michael: En primer lugar, algunas extensiones simples de nuestra memoria transaccional a nivel de hardware en los procesadores Intel e IBM. En particular, me gustaría que la carga y el almacén no transaccionales que acaban de ocurrir estén disponibles de inmediato dentro de las transacciones. Inmediatamente conducen a bucles en la secuencia de lo que sucede antes, por lo que pueden resultar difíciles. Pero si mantiene capas de abstracción, hay muchas cosas muy interesantes que puede hacer fuera de la transacción mientras ésta ocurre. No sé qué tan difícil sería implementar esto, pero sería muy útil.
Otra cosa útil es cargar el caché desde la memoria remota. Creo que tarde o temprano esto se hará. Esta tecnología permitirá la creación de sistemas con memoria desagregada. Sería posible mantener, digamos, 100 terabytes de memoria no volátil en un rack, y el propio sistema operativo decidiría dinámicamente qué secciones de esa memoria deberían corresponder al espacio de direcciones físicas de los procesadores. Esto sería de gran utilidad para la computación en la nube, ya que permitiría dotar de grandes cantidades de memoria a las tareas que la necesiten. Creo que alguien lo hará.
Vitali: Para terminar de hablar de la memoria transaccional, tengo una pregunta más sobre este tema. ¿La memoria transaccional eventualmente reemplazará las estructuras de datos estándar de subprocesos múltiples?
Michael: No. Las transacciones son un mecanismo especulativo. A nivel de programación se trata de cerraduras atómicas, pero por dentro son especulaciones. Este tipo de pronóstico funciona si la mayoría de las conjeturas son correctas. Por lo tanto, la memoria transaccional funciona bien cuando los subprocesos apenas interactúan entre sí y solo hay que asegurarse de que no haya interacciones. Pero si un mensaje comienza entre hilos, las transacciones son de poca utilidad. Permítanme explicarles, estamos hablando del caso en el que las transacciones abarcan toda la operación atómica. Todavía se pueden utilizar con éxito como componentes para estructuras de datos multiproceso. Por ejemplo, si necesita un CAS de tres palabras y necesita subprocesos múltiples de tres cosas pequeñas en medio de un algoritmo verdaderamente multiproceso que funciona con veinte subprocesos al mismo tiempo. En general, las transacciones pueden ser útiles, pero no eliminarán la necesidad de diseñar adecuadamente estructuras de datos multiproceso.
Memoria no volátil, Optane DIMM, dispositivos ultrarrápidos.
Vitali: Lo último de lo que me gustaría hablar es del tema de su investigación actual: la memoria no volátil. ¿Qué podemos esperar en este ámbito en el futuro próximo? ¿Quizás conozca alguna implementación efectiva que ya exista?
Michael: No soy un experto en hardware, sólo sé lo que leo en las noticias y lo que me dicen mis compañeros. Todo el mundo ya ha oído que Intel vende , que tienen aproximadamente 3 veces la latencia de lectura y 10 veces la latencia de escritura que la RAM dinámica. Pronto estarán disponibles en versiones de gran volumen. Es curioso pensar que se puede tener una computadora portátil con varios terabytes de RAM direccionable por bytes. Es probable que dentro de 10 años decidamos utilizar esta nueva tecnología, ya que usamos DRAM, simplemente aumente el volumen. Pero gracias a la independencia energética se nos abren oportunidades completamente nuevas. Podemos cambiar fundamentalmente la pila de almacenamiento para que no haya separación entre la memoria de trabajo direccionable por bytes y la memoria persistente estructurada en bloques. Por lo tanto, no necesitaremos serializar todo lo que deba transferirse de un programa ejecutado a otro en archivos estructurados en bloques. De esto podemos derivar muchos principios importantes que afectan a los sistemas operativos, los entornos de ejecución y los almacenes de datos distribuidos. Esta área es muy interesante para trabajar. Personalmente, es difícil para mí predecir a qué conducirá todo esto, pero los problemas aquí son extremadamente entretenidos. Puede haber cambios revolucionarios aquí, y se derivan de forma muy natural del trabajo sobre subprocesos múltiples, ya que la recuperación de fallas es un proceso de "subprocesos múltiples" además del funcionamiento normal del sistema.
El segundo tema principal en el que estoy trabajando actualmente es la gestión de dispositivos ultrarrápidos y el acceso seguro a dispositivos desde el espacio de usuario con control de políticas sistémicas. En los últimos años, ha habido una tendencia a trasladar el acceso al dispositivo al espacio del usuario. Esto se hace porque la pila del kernel TCP-IP no puede funcionar sobre una interfaz de red que necesita un nuevo paquete cada 5 microsegundos; simplemente no mantiene el ritmo. Por tanto, los fabricantes proporcionan acceso directo a los dispositivos. Pero esto significa que el sistema operativo pierde el control del proceso y no puede proporcionar un acceso adecuado al dispositivo para las aplicaciones de la competencia. Nuestro equipo de investigación cree que esta deficiencia se puede evitar. Tendremos un artículo sobre esto en USENIX ATC este mes. Está relacionado con el trabajo en persistencia, ya que la memoria persistente direccionable por bytes de larga duración es, en esencia, un dispositivo con E/S ultrarrápidas al que se debe acceder en el espacio de usuario. Esta investigación hace posibles nuevos enfoques para microkernels, exokernels y otros intentos tradicionales de trasladar de forma segura la funcionalidad del kernel del sistema operativo al espacio de usuario.
Vladimir: La memoria direccionable por bytes es excelente, pero existe una limitación física: la velocidad de la luz. Esto significa que inevitablemente habrá un retraso al interactuar con el dispositivo.
Michael: Absolutamente correcto.
Vladimir: ¿Habrá suficiente capacidad para hacer frente a las nuevas cargas?
Michael: Esta es una pregunta excelente, pero me resultará difícil responderla. La idea de procesar en memoria existe desde hace bastante tiempo, es muy interesante, pero también muy compleja. No he trabajado en esta área, pero sería fantástico si se hicieran algunos descubrimientos allí. Me temo que no tengo nada más que añadir.
Vladimir: Hay un problema más. Será imposible introducir nuevas cantidades de RAM significativamente mayores en la CPU. Por lo tanto, debido a limitaciones físicas, esta RAM debe estar aislada.
Michael: Todo depende del número de defectos en la producción de circuitos integrados. Si fuera posible crear obleas semiconductoras sin defectos, entonces sería posible fabricar un microcircuito completo a partir de ellas. Pero ahora no sabemos cómo hacer microcircuitos más grandes que los sellos postales.
Vladimir: Pero seguimos hablando de tamaños enormes, de centímetros. Esto inevitablemente tiene un impacto en la latencia.
Michael: Sí. No hay nada que puedas hacer con la velocidad de la luz.
Vladimir: Desafortunadamente.
La próxima gran tendencia. Estructuras de datos duales. Hidra.
Vitali: Según tengo entendido, las nuevas tendencias se detectan muy rápidamente. Fuiste uno de los primeros en trabajar con memoria transaccional y uno de los primeros en trabajar con memoria no volátil. ¿Cuál crees que será la próxima gran tendencia? ¿O tal vez es un secreto?
Michael: Para ser honesto, no lo sé. Con suerte podré darme cuenta cuando surja algo nuevo. No he tenido la suerte de inventar ningún campo nuevo por mi cuenta, pero sí he tenido algo de suerte y he podido empezar a trabajar bastante pronto en nuevos campos creados por otros. Espero poder hacer esto en el futuro.
Alexey: La última pregunta de esta entrevista será sobre tu desempeño en Hydra y tus actividades en la escuela. Si entendí correctamente, el informe en la escuela será sobre algoritmos sin bloqueo, y en la conferencia sobre estructuras de datos dobles. ¿Podría decir algunas palabras sobre estos informes?
Michael: En parte, ya hemos tocado estos temas con usted en esta entrevista. Se trata del trabajo que hice con mi alumno Bill Scherer. Escribió una tesis al respecto y Doug Lee también contribuyó a ella, y finalmente se convirtió en parte de las colas síncronas de subprocesos múltiples en la biblioteca Java. Supongamos que la estructura de datos se lee y escribe sin bloqueo, es decir, cada operación tiene un número limitado de instrucciones en la ruta crítica. Si intenta eliminar datos de un contenedor vacío, o intenta eliminar ciertos datos que no están en este contenedor, se le informará inmediatamente que no se puede hacer. Pero este comportamiento puede no ser aceptable si el hilo realmente necesita estos datos. Entonces lo primero que se nos viene a la cabeza es crear un bucle que preguntará constantemente si han aparecido los datos necesarios. Pero luego hay interferencia para todos los demás. Además, con este enfoque, puede esperar 10 minutos y luego aparecerá otro hilo y accidentalmente recibirá primero los datos necesarios. Las estructuras de datos duales todavía no tienen bloqueos, pero permiten que los subprocesos esperen correctamente. El término "doble" significa que la estructura contiene datos o solicitudes de datos, llamémoslos antidatos. Entonces, si intenta recuperar algo de un contenedor vacío, se colocará una solicitud en el contenedor. Ahora el hilo puede esperar una solicitud sin molestar a nadie más. Además, la estructura de datos asigna prioridades a las solicitudes para que, cuando las reciba, las pase a la persona adecuada. El resultado es un mecanismo sin bloqueo que todavía tiene una especificación formal y un buen rendimiento en la práctica.
Alexey: ¿Cuáles son sus expectativas de esta estructura de datos? ¿Mejorará el rendimiento en todos los casos comunes o es más adecuado para determinadas situaciones?
Michael: Es útil si, en primer lugar, necesita un contenedor sin bloqueo y, en segundo lugar, necesita esperar en una situación en la que necesita recuperar datos del contenedor que no está en él. Hasta donde yo sé, nuestro marco proporciona un comportamiento óptimo cuando se cumplen estas dos condiciones. Por eso, en estos casos recomiendo usarlo. La principal ventaja de las estructuras de datos sin bloqueo es que evitan problemas de rendimiento. Y la espera es muy importante en muchos algoritmos si los datos se transfieren de un hilo a otro.
Vitali: Déjame aclarar: ¿hablarás de lo mismo tanto en la escuela como en la conferencia?
Michael: En la escuela en general sobre estructuras de datos multiproceso, con los principios básicos descritos al comienzo de la lección. Supongo que el público sabe qué son los hilos y está familiarizado con las cerraduras. Con base en este conocimiento básico, hablaré sobre estructuras de datos sin bloqueo. Daré una descripción general de los problemas más importantes en esta área, tocando temas como la gestión de la memoria. No creo que haya nada más complicado que la cola de MS.
Alexey: ¿Planea enseñar sobre estructuras de datos duales al final de su clase en la escuela?
Michael: Los mencionaré, pero no les dedicaré mucho tiempo. El informe Hydra estará dedicado a ellos. Cubrirá el proyecto que finalmente llegó a Java, además de trabajar con Joe Israelevich para crear una variante dual de la cola LCRQ y crear un diseño casi universal para estructuras de datos duales.
Alexey: Entonces, ¿la conferencia en la escuela puede recomendarse para principiantes y la conferencia sobre estructuras de datos dobles en Hydra, para personas que ya tienen algo de experiencia?
Michael: Corríjame si me equivoco, pero la audiencia en Hydra será bastante diversa, incluidos muchos expertos en Java y, en general, personas que no están específicamente involucradas en la programación multiproceso.
Vitali: Si es cierto.
Alexey: Por lo menos así lo espero.
Michael: En este caso, me enfrentaré al mismo problema con el que comenzamos esta entrevista: cómo hacer un informe suficientemente rico en detalles técnicos y accesible a todos los oyentes.
Vitali: ¿Darás un informe de la misma manera que das conferencias? Es decir, ¿hablar con el público y adaptarse a la situación?
Michael: Me temo que no funcionará así, porque el informe tendrá diapositivas. Las diapositivas son importantes cuando los oyentes hablan inicialmente idiomas diferentes. A muchas personas les resultará difícil entenderme en inglés, especialmente si hablo demasiado rápido. Elegí estos temas porque me pidió que hablara sobre estructuras de datos sin bloqueo en la escuela SPTDC; y luego necesitaba un informe para una conferencia de un grupo de usuarios de Java y quería elegir algo que fuera de interés específico para los programadores de Java. La forma más sencilla era hablar de aquellas cosas de la biblioteca de Java en las que participé de una forma u otra.
Alexey: Suponemos que la audiencia de Hydra ya sabe algo sobre programación sin bloqueos y quizás tenga algo de experiencia en esta área. Pero esto es sólo una suposición; la situación quedará más clara en la propia conferencia. De todos modos, gracias por su tiempo. Estoy seguro de que la entrevista será muy interesante para nuestros lectores. ¡Muchas gracias!
Vitali: Gracias
Michael: Estaré encantado de conocerte en San Petersburgo.
Alexey: Nosotros también tenemos una ciudad hermosa. ¿Alguna vez has estado aquí?
Michael: No, nunca he estado en Rusia. Pero San Petersburgo siempre ha estado en la lista de lugares donde aún no he estado, pero a los que realmente quiero ir, así que me alegré mucho de la invitación.
Alexey: Por cierto, tendremos un programa de excursiones para ponentes. ¡Muchas gracias por la entrevista y que tengas un buen día!
Puede continuar su conversación con Michael en la conferencia Hydra 2019, que se llevará a cabo del 11 al 12 de julio de 2019 en San Petersburgo. Él vendrá con un informe. . Los boletos se pueden comprar .
Fuente: habr.com