concurrency - programming - ¿Cómo estás aprovechando Multicore?

python es multihilo (22)

Como alguien en el mundo de HPC que proviene del mundo del desarrollo web empresarial, siempre siento curiosidad por ver cómo los desarrolladores que se encuentran en el "mundo real" aprovechan la computación paralela. Esto es mucho más relevante ahora que todos los chips se están procesando en varios núcleos, y será aún más relevante cuando hay miles de núcleos en un chip en lugar de solo unos pocos.

Mis preguntas son:

¿Cómo afecta esto a su hoja de ruta del software?
Estoy particularmente interesado en historias reales sobre cómo multicore está afectando diferentes dominios de software, así que especifique qué tipo de desarrollo hace en su respuesta ( por ejemplo , en el lado del servidor, aplicaciones del lado del cliente, informática científica, etc.).
¿Qué está haciendo con su código actual para aprovechar las máquinas multinúcleo y qué desafíos ha enfrentado? ¿Estás usando OpenMP , Erlang , Haskell , CUDA , TBB , UPC u otra cosa?
¿Qué planeas hacer a medida que los niveles de concurrencia continúan aumentando y cómo manejarás cientos o miles de núcleos?
Si su dominio no se beneficia fácilmente con el cálculo paralelo, entonces explicar por qué es interesante también.

Finalmente, he enmarcado esto como una pregunta multinúcleo, pero no dude en hablar sobre otros tipos de computación paralela. Si está portando parte de su aplicación para usar MapReduce , o si MPI en clústeres grandes es el paradigma para usted, entonces definitivamente mencione eso también.

Actualización: si responde # 5, mencione si cree que las cosas cambiarán si llegan a haber más núcleos (100, 1000, etc.) de los que puede alimentar con ancho de banda de memoria disponible (ya que el ancho de banda es cada vez más pequeño por núcleo ) ¿Todavía puede usar los núcleos restantes para su aplicación?

Por el momento, no lo afecta demasiado, para ser honesto. Estoy más en la ''etapa de preparación'', aprendiendo sobre las tecnologías y las características del lenguaje que hacen esto posible.
No tengo un dominio en particular, pero he encontrado dominios como matemática (donde multi-core es esencial), clasificación / búsqueda de datos (donde la división y conquista en multi-core es útil) y requisitos de múltiples computadoras (por ejemplo, un requisito de que la potencia de procesamiento de una estación de respaldo se utiliza para algo).
Esto depende del idioma en el que estoy trabajando. Obviamente en C #, tengo las manos atadas con una implementación aún no preparada de Parallel Extensions que parece aumentar el rendimiento, hasta que comiences a comparar los mismos algoritmos con OpenMP (quizás no sea una comparación justa). Así que en .NET va a ser un paseo fácil con algunos for → Parallel.For refactorizaciones y similares.
Donde las cosas se ponen realmente interesantes es con C ++, porque el rendimiento que puedes sacar de cosas como OpenMP es asombroso en comparación con .NET. De hecho, OpenMP me sorprendió mucho, porque no esperaba que funcionara tan eficientemente. Bueno, supongo que sus desarrolladores han tenido mucho tiempo para pulirlo. También me gusta que esté disponible en Visual Studio desde el primer momento, a diferencia de TBB por el que tiene que pagar.
En cuanto a MPI, utilizo PureMPI.net para pequeños proyectos hogareños (tengo una LAN) para tontear con cálculos que una máquina no puede realizar. Nunca utilicé MPI comercialmente, pero sí sé que MKL tiene algunas funciones MPI optimizadas, que pueden ser interesantes para cualquiera que las necesite.
Planeo hacer ''computación frívola'', es decir, usar núcleos adicionales para la precomputación de resultados que podrían o no ser necesarios, si RAM lo permite, por supuesto. También pretendo profundizar en algoritmos y enfoques costosos que la mayoría de las máquinas de los usuarios finales ahora no pueden manejar.
En cuanto a los dominios que no se benefician de la paralelización ... bueno, uno siempre puede encontrar algo. Una cosa que me preocupa es el soporte decente en .NET, aunque lamentablemente he perdido la esperanza de que se puedan alcanzar velocidades similares a C ++.

Ahora puedo separar mi sistema operativo principal de mi desarrollo / instalación, lo que me gusta, usando configuraciones de vitualización con Virtual PC o VMWare.

Dual core significa que una CPU ejecuta mi sistema operativo host, la otra ejecuta mi sistema operativo de desarrollo con un nivel de rendimiento decente.

Nuestra lógica de dominio se basa en gran medida en un motor de flujo de trabajo y cada instancia de flujo de trabajo se ejecuta en ThreadPool.

Eso es suficiente para nosotros.

Trabajo en imágenes médicas y procesamiento de imágenes.

Estamos manejando múltiples núcleos de la misma manera en que manejamos núcleos individuales: tenemos múltiples hilos ya en las aplicaciones que escribimos para tener una interfaz de usuario receptiva.

Sin embargo, debido a que ahora podemos, estamos evaluando la implementación de la mayoría de nuestras operaciones de procesamiento de imágenes en CUDA o OpenMP. El compilador Intel proporciona una gran cantidad de código de muestra bueno para OpenMP, y es solo un producto mucho más maduro que CUDA, y proporciona una base instalada mucho más grande, por lo que probablemente vayamos a seguir con eso.

Lo que tendemos a hacer por operaciones costosas (es decir, más de un segundo) es bifurcar esa operación en otro proceso, si es posible. De esa manera, la interfaz de usuario principal sigue siendo receptiva. Si no podemos, o es demasiado inconveniente o lento para mover esa cantidad de memoria, la operación todavía está en un hilo, y luego esa operación puede engendrar múltiples hilos.

La clave para nosotros es asegurarnos de no golpear los cuellos de botella de concurrencia. Desarrollamos en .NET, lo que significa que las actualizaciones de UI deben realizarse desde una llamada Invoke a la IU para que el hilo principal actualice la IU.

Tal vez soy flojo, pero en realidad, no quiero pasar demasiado tiempo pensando en muchas cosas cuando se trata de paralelizar cosas como inversiones de matrices y cosas por el estilo. Mucha gente realmente inteligente ha pasado mucho tiempo haciendo esas cosas rápido como nitroso, y solo quiero tomar lo que han hecho y llamarlo. Algo como CUDA tiene una interfaz interesante para el procesamiento de imágenes (por supuesto, para eso está definido), pero todavía es demasiado inmaduro para ese tipo de programación plug-and-play. Si yo u otro desarrollador recibimos mucho tiempo libre, podríamos intentarlo. Por lo tanto, en su lugar, vamos a ir con OpenMP para que nuestro procesamiento sea más rápido (y eso definitivamente está en la hoja de ruta de desarrollo para los próximos meses).

Estoy en el procesamiento de imágenes. Estamos aprovechando el multinúcleo siempre que sea posible procesando imágenes en sectores distribuidos a diferentes hilos.

Hasta ahora, nada más que una compilación más eficiente con make :

gmake -j

la opción -j permite que las tareas que no dependen unas de otras se ejecuten en paralelo.

Mi trabajo de posgrado consiste en desarrollar conceptos para realizar trabajos de núcleo desnudo y enseñar lo mismo en sistemas integrados.

También estoy trabajando un poco con F # para aumentar la velocidad de mis instalaciones de idiomas de alto nivel con capacidad de multiprocesamiento.

Para las aplicaciones web es muy, muy fácil: ignórelo. A menos que tengas un código que realmente se pida que se haga en paralelo, simplemente puedes escribir el código de un solo hilo antiguo y ser feliz.

Por lo general, tiene muchas más solicitudes que atender en cualquier momento que sus núcleos. Y dado que cada uno se maneja en su propio subproceso (o incluso proceso, dependiendo de su tecnología), esto ya está funcionando en paralelo.

El único lugar donde debe tener cuidado es cuando accede a algún tipo de estado global que requiere sincronización. Mantenga eso al mínimo para evitar la introducción de cuellos de botella artificiales a un mundo que de otro modo (casi) perfectamente escalable.

Entonces, para mí, multi-core básicamente se reduce a estos elementos:

Mis servidores tienen menos "CPU", mientras que cada uno tiene más núcleos (no mucha diferencia para mí)
La misma cantidad de CPU puede generar una mayor cantidad de usuarios concurrentes
Cuando parece que el cuello de botella de rendimiento no es el resultado de que la CPU esté cargada al 100%, eso indica que estoy realizando una mala sincronización en alguna parte.

Mi trabajo de investigación incluye el trabajo en compiladores y en el filtrado de spam. También hago muchas cosas de Unix de "productividad personal". Además, escribo y uso software para administrar las clases que enseño, lo que incluye calificación, prueba de código de estudiante, seguimiento de calificaciones y una infinidad de curiosidades.

Multicore no me afecta para nada excepto como un problema de investigación para que los compiladores soporten otras aplicaciones. Pero esos problemas se encuentran principalmente en el sistema de tiempo de ejecución, no en el compilador.
Con grandes problemas y gastos, Dave Wortman demostró alrededor de 1990 que podía paralelizar un compilador para mantener ocupados a cuatro procesadores . Nadie que yo conozca ha repetido el experimento. La mayoría de los compiladores son lo suficientemente rápidos como para ejecutar un único subproceso. Y es mucho más fácil ejecutar su compilador secuencial en varios archivos de origen diferentes en paralelo que hacer que el compilador sea paralelo. Para el filtrado de spam, el aprendizaje es un proceso intrínsecamente secuencial . E incluso una máquina más antigua puede aprender cientos de mensajes por segundo, por lo que incluso un gran corpus se puede aprender en menos de un minuto. De nuevo, el entrenamiento es lo suficientemente rápido .
La única forma significativa que tengo de explotar máquinas paralelas es usando la marca paralela . Es una gran bendición, y las grandes construcciones son fáciles de paralelizar . Make hace casi todo el trabajo de forma automática. La única otra cosa que puedo recordar es utilizar el paralelismo con el código de estudiante de larga ejecución al cultivarlo en un grupo de máquinas de laboratorio, lo cual podía hacer con buena conciencia porque solo estaba golpeando un solo núcleo por máquina, así que usar solo 1 / 4 de recursos de CPU. Ah, y escribí un guión Lua que usará los 4 núcleos al copiar archivos MP3 con cojera. Ese script fue mucho trabajo para hacer las cosas bien.
Ignoraré decenas, cientos y miles de núcleos . La primera vez que me dijeron "vienen máquinas paralelas, debes estar listo" fue en 1984. Era cierto entonces y hoy es cierto que la programación paralela es un dominio para especialistas altamente calificados . Lo único que ha cambiado es que hoy los fabricantes nos obligan a pagar por hardware paralelo, lo queramos o no. Pero el hecho de que se pague el hardware no significa que sea de uso gratuito. Los modelos de programación son terribles, y hacer que el modelo de subprocesos / mutex funcione , y mucho menos funcionar bien, es un trabajo costoso incluso si el hardware es gratuito. Espero que la mayoría de los programadores ignoren el paralelismo y sigan calladamente sobre sus negocios. Cuando un especialista capacitado viene con una marca paralela o un gran juego de computadora, aplaudo silenciosamente y hago uso de sus esfuerzos. Si quiero rendimiento para mis propias aplicaciones, me concentraré en reducir las asignaciones de memoria e ignorar el paralelismo.
El paralelismo es realmente difícil. La mayoría de los dominios son difíciles de paralelizar. Una excepción ampliamente reutilizable como la marca paralela es motivo de mucho regocijo.

Resumen (que escuché de un orador principal que trabaja para un fabricante líder de CPU): la industria respaldada en multinúcleo porque no podían seguir haciendo que las máquinas corrieran más rápido y más caliente y no sabían qué hacer con los transistores adicionales. Ahora están desesperados por encontrar una forma de rentabilizar multinúcleo porque si no tienen ganancias, no pueden construir la próxima generación de líneas fab. El tren de la salsa terminó, y podríamos tener que empezar a prestar atención a los costos del software.

Muchas personas que toman en serio el paralelismo están ignorando estas máquinas de juguete de 4 núcleos o incluso de 32 núcleos a favor de las GPU con 128 procesadores o más. Creo que la verdadera acción va a estar allí.

Aprender un lenguaje de programación funcional podría usar múltiples núcleos ... costosos.

Creo que no es realmente difícil usar núcleos extra. Hay algunas trivialidades como aplicaciones web que no necesitan tener ningún cuidado adicional ya que el servidor web hace su trabajo al ejecutar las consultas en paralelo. Las preguntas son para algorythms de larga ejecución (long es lo que se llama long). Estos deben dividirse en dominios más pequeños que no dependen entre sí, o sincronizar las dependencias. Muchos algs pueden hacer esto, pero a veces se necesitan implementaciones horriblemente diferentes (cuesta de nuevo).

Entonces, no hay solución mágica hasta que esté usando lenguajes de programación imperativos, lo siento. O necesita programadores expertos (costosos) o necesita recurrir a otro lenguaje de programación (costoso). O puede tener suerte simplemente (web).

Trabajo en C # con .Net Threads. Puede combinar la encapsulación orientada a objetos con la gestión de subprocesos.

Leí algunas publicaciones de Peter hablando sobre un nuevo libro de Packt Publishing y encontré el siguiente artículo en la página web de Packt Publishing:

http://www.packtpub.com/article/simplifying-parallelism-complexity-c-sharp

He leído la Programación concurrente con Windows, el libro de Joe Duffy. Ahora, estoy esperando "C # 2008 y 2005 Threaded Programming", el libro de Hillar - http://www.amazon.com/2008-2005-Threaded-Programming-Beginners/dp/1847197108/ref=pd_rhf_p_t_2

Estoy de acuerdo con Szundi "¡No hay bala de plata"!

Usted dice "Para las aplicaciones web es muy, muy fácil: ignórelo. A menos que tenga un código que realmente se pida que se haga en paralelo, simplemente puede escribir el código de un solo hilo antiguo y ser feliz".

Estoy trabajando con aplicaciones web y necesito aprovechar al máximo el paralelismo. Entiendo tu punto. Sin embargo, debemos prepararnos para la revolución multinúcleo. Ignorarlo es lo mismo que ignorar la revolución de la GUI en los años 90.

Todavía no estamos desarrollando para DOS? Debemos abordar multinúcleo o estaremos muertos en muchos años.

Creamos el analizador de código VivaMP para detección de errores en programas OpenMP paralelos.

VivaMP es un analizador de código C / C ++ estático parecido a una pelusa destinado a indicar errores en programas paralelos basados en la tecnología OpenMP. El analizador estático VivaMP agrega mucho a las capacidades de los compiladores existentes, diagnostica cualquier código paralelo que tenga algunos errores o sea una fuente eventual de tales errores. El analizador está integrado en el entorno de desarrollo VisualStudio2005 / 2008.

VivaMP - una herramienta para OpenMP

32 trampas de OpenMP para desarrolladores de C ++

Dije algo de esto en respuesta a una pregunta diferente (¡espero que esto esté bien!): Existe un concepto / metodología llamada Programación Basada en Flujo (FBP) que existe desde hace más de 30 años y que se utiliza para manejar la mayor parte de el procesamiento por lotes en un importante banco canadiense. Tiene implementaciones basadas en subprocesos en Java y C #, aunque las implementaciones anteriores estaban basadas en fibra (C ++ y ensamblador de mainframe). La mayoría de las aproximaciones al problema de aprovechar las multinúcleo implican intentar tomar un programa de subproceso convencional y averiguar qué partes se pueden ejecutar en paralelo. FBP tiene un enfoque diferente: la aplicación está diseñada desde el principio en términos de múltiples componentes de "caja negra" que se ejecutan de forma asíncrona (piense en una línea de ensamblaje de fabricación). Dado que la interfaz entre los componentes es flujos de datos, FBP es esencialmente independiente del lenguaje y, por lo tanto, es compatible con aplicaciones de lenguaje mixto y lenguajes específicos de dominio. Se ha encontrado que las aplicaciones escritas de esta manera son mucho más fáciles de mantener que las aplicaciones convencionales de un solo subproceso y, a menudo, requieren menos tiempo, incluso en máquinas de un solo núcleo.

Creo que esta tendencia primero convencerá a algunos desarrolladores, y la mayoría de ellos verá que la paralelización es una tarea realmente compleja. Espero que algún patrón de diseño cumpla esta complejidad. No de bajo nivel, sino con patrones arquitectónicos que dificultarán hacer algo mal.

Por ejemplo, espero que los patrones de mensajería ganen popularidad, porque es intrínsecamente asíncrono, pero no se piensa en un punto muerto o mutex o lo que sea.

Estoy desarrollando aplicaciones web ASP.NET. Hay pocas posibilidades de utilizar multinúcleo directamente en mi código, sin embargo, IIS ya se adapta bien a múltiples núcleos / CPU al generar múltiples subprocesos / procesos de trabajo cuando está bajo carga.

Estoy usando y programando en una Mac. Grand Central Dispatch para la victoria. La revisión de Ars Technica de Snow Leopard tiene muchas cosas interesantes que decir acerca de la programación multinúcleo y dónde las personas (o al menos Apple) van con esto.

¿Cómo afecta esto a su hoja de ruta del software?
No es así Nuestra (como casi todas las demás) aplicaciones relacionadas con el negocio funciona perfectamente bien en un solo núcleo. Siempre que agregar más núcleos no reduzca significativamente el rendimiento de las aplicaciones de subproceso único, estamos contentos
... historias reales ...
Como todos los demás, las construcciones paralelas son el principal beneficio que obtenemos. El compilador de Visual Studio 2008 C # parece que no usa más de un núcleo, lo que realmente apesta
¿Qué estás haciendo con tu código actual para aprovechar las máquinas multinúcleo?
Podemos considerar el uso de las extensiones paralelas de .NET si alguna vez tenemos un algoritmo de larga ejecución que se puede paralelizar, pero las probabilidades de que esto realmente ocurra son escasas. La respuesta más probable es que algunos de los desarrolladores jugarán con ella por el interés, pero no mucho más
¿Cómo lidiarás con cientos o miles de núcleos?
Cabeza -> Arena.
Si su dominio no se beneficia fácilmente con el cálculo paralelo, entonces explicar por qué es interesante también.
La aplicación cliente principalmente empuja los datos, la aplicación de servidor se basa principalmente en el servidor SQL para hacer el trabajo pesado

Decidí aprovechar varios núcleos en una implementación del algoritmo DEFLATE . MArc Adler hizo algo similar en el código C con PIGZ (gzip paralelo). He entregado el equivalente filosófico, pero en una biblioteca de código administrado, en DotNetZip v1.9 . Este no es un puerto de PIGZ, sino una idea similar, implementada de manera independiente.

La idea detrás de DEFLATE es escanear un bloque de datos, buscar secuencias repetidas, construir un "diccionario" que mapee un "código" corto para cada una de esas secuencias repetidas, luego emitir una secuencia de bytes donde cada instancia de una de las secuencias repetidas es reemplazado por un "código" del diccionario.

Debido a que la construcción del diccionario requiere una gran cantidad de CPU, DEFLATE es un candidato perfecto para la paralelización. He tomado un enfoque de tipo Mapa + Reducir, donde divido el archivo de entrada no comprimido entrante en un conjunto de bloques más pequeños (mapa), digamos 64k cada uno, y luego los compré de forma independiente. Luego concateno los bloques resultantes juntos (reducir). Cada bloque de 64k se comprime independientemente, en su propio hilo, sin tener en cuenta los otros bloques.

En una máquina de doble núcleo, este enfoque se comprime en aproximadamente el 54% del tiempo del enfoque en serie tradicional. En las máquinas de clase servidor, con más núcleos disponibles, puede ofrecer incluso mejores resultados; sin máquina servidor, no lo he probado personalmente, pero la gente me dice que es rápido.

Hay una sobrecarga de tiempo de ejecución (CPU) asociada a la gestión de varios subprocesos, la sobrecarga de memoria de tiempo de ejecución asociada a los almacenamientos intermedios para cada cargo y la sobrecarga de datos asociada a la concatenación de los bloques. Por lo tanto, este enfoque solo vale para las más grandes corrientes. En mis pruebas, por encima de 512k, puede pagar. Debajo de eso, es mejor usar un enfoque en serie.

DotNetZip se entrega como una biblioteca. Mi objetivo era hacer que todo esto sea transparente. Entonces, la biblioteca usa automáticamente los hilos adicionales cuando el buffer está por encima de 512kb. No hay nada que la aplicación tenga que hacer para usar los hilos. Simplemente funciona, y cuando se usan hilos, es mágicamente más rápido. Creo que este es un enfoque razonable para la mayoría de las bibliotecas que consumen las aplicaciones.

Sería bueno para la computadora ser inteligente sobre la explotación dinámica y automática de recursos en algoritmos parallizables, pero la realidad actual es que los diseñadores de aplicaciones deben codificar explícitamente la paralelización en.

Estamos teniendo mucho éxito con el paralelismo de tareas en .NET 4 usando F #. ¡Nuestros clientes están pidiendo a gritos soporte multinúcleo porque no quieren que sus núcleos n-1 estén inactivos!

Creo que " Cycles es el mejor amigo de un ingeniero ".

Mi empresa ofrece una herramienta comercial para analizar y transformar sistemas de software muy grandes en muchos lenguajes de programación. "Grande" significa 10-30 millones de líneas de código. La herramienta es el kit de herramientas de reingeniería de software DMS (DMS para abreviar).

Los análisis (e incluso las transformaciones) en sistemas tan grandes tardan mucho tiempo: nuestro analizador de puntos para el código C tarda 90 horas de CPU en un x86-64 con 16 Gb de RAM. Los ingenieros quieren respuestas más rápido que eso.

En consecuencia, implementamos DMS en PARLANSE , un lenguaje de programación paralelo de nuestro propio diseño, destinado a aprovechar los sistemas de memoria compartida multinúcleo a pequeña escala.

Las ideas clave detrás de parlanse son: a) dejar que el programador exponga el paralelismo, b) dejar que el compilador elija qué parte puede realizar, c) mantener el cambio de contexto a un mínimo absoluto. Los pedidos parciales estáticos sobre cómputos son fáciles de ayudar a lograr los 3; fácil de decir, relativamente fácil de medir los costos, fácil para el compilador programar cálculos. (Escribir un quicksort paralelo con esto es trivial).

Desafortunadamente, lo hicimos en 1996 :-( Los últimos años finalmente han sido una reivindicación; ahora puedo obtener 8 máquinas centrales en Fry''s por menos de $ 1K y 24 máquinas centrales por casi el mismo precio que un automóvil pequeño (y probablemente caer rápidamente).

La buena noticia es que DMS es ahora bastante maduro, y hay varios mecanismos internos clave en DMS que aprovechan esto, en particular una clase completa de analizadores llamada "gramáticas de atributos", que escribimos usando un lenguaje específico de dominio. que NO es parlanse DMS compila estas gramáticas atributivas en PARLANSE y luego se ejecutan en paralelo. Nuestra interfaz de C ++ usa gramáticas de atributos, y tiene aproximadamente 100K de sloc; está compilado en 800K SLOC de código parlanse paralelo que realmente funciona de manera confiable.

Ahora (junio de 2009), estamos muy ocupados haciendo DMS útil, y no siempre tenemos suficiente tiempo para aprovechar el paralelismo. Por lo tanto, el análisis de puntos de 90 horas. Estamos trabajando en paralelizar eso, y tenemos una esperanza razonable de 10-20x de aceleración.

Creemos que a largo plazo, el uso adecuado de SMP hará que las estaciones de trabajo sean mucho más amigables con los ingenieros que hacen preguntas difíciles. También deberían.

Estoy aprovechando el multinúcleo con C, PThreads y una implementación casera de la comunicación de procesos secuenciales en una plataforma OpenVPX con Linux utilizando el programador del conjunto de parches PREEMPT_RT. Todo suma casi el 100% de utilización de CPU en varias instancias de sistema operativo sin tiempo de CPU utilizado para el intercambio de datos entre tarjetas de procesador en el chasis OpenVPX, y muy baja latencia también. También usa sFPDP para unir múltiples chasis OpenVPX en una sola máquina. No estoy usando el DMA interno de Xeon para aliviar la presión de memoria dentro de las CPU (DMA todavía usa ancho de banda de memoria a expensas de los núcleos de la CPU). En cambio, estamos dejando los datos en su lugar y transmitiendo la propiedad de manera CSP (por lo que no difiere de la filosofía de la biblioteca de flujo de datos en paralelo de tareas de .NET).

1) Hoja de ruta del software: tenemos presión para maximizar el uso de bienes inmuebles y la potencia disponible. Aprovechar al máximo el último hardware es esencial

2) Dominio de software - efectivamente Scientific Computing

3) ¿Qué estamos haciendo con el código existente? Constantemente dividiéndolo y redistribuyendo partes de él a través de los hilos para que cada núcleo esté al máximo haciendo todo lo posible sin romper el requisito de tiempo real. El nuevo hardware significa repensar bastante (los núcleos más rápidos pueden hacer más en el tiempo dado, no quieren que se los infrautilice). No es tan malo como parece, las rutinas centrales son muy modulares y se ensamblan fácilmente en grumos del tamaño de un hilo. Aunque planeamos tomar el control de la afinidad de hilos lejos de Linux, aún no hemos logrado extraer un rendimiento adicional significativo al hacerlo. Linux es bastante bueno para obtener datos y códigos en más o menos el mismo lugar.

4) En efecto, ya está allí: la máquina total ya suma miles de núcleos

5) La informática paralela es esencial: es un sistema MISD.

Si eso parece mucho trabajo, lo es. algunos trabajos requieren ir por completo para aprovechar al máximo el hardware disponible y evitar casi todo lo que sea de alto nivel. Estamos descubriendo que el rendimiento total de la máquina es una función del ancho de banda de la memoria de la CPU, no de la velocidad del núcleo de la CPU, el tamaño de la caché L1 / L2 / L3.