¿Cuánto esfuerzo debemos dedicar a la programación de múltiples núcleos?

12

Los procesadores están obteniendo más y más núcleos en estos días, lo que me deja pensando ...

¿Deberíamos nosotros, los programadores, adaptarnos a este comportamiento y dedicar más esfuerzo a la programación de múltiples núcleos?

¿Hasta qué punto debemos hacer y optimizar esto? ¿Hilo? ¿Afinidad? Optimizaciones de hardware? ¿Algo más?

    
pregunta Tom Wijsman 24.09.2010 - 13:30

8 respuestas

15

No importa lo bueno que seas, será poco probable que encuentres un mejor esquema de gestión de subprocesos, etc. que los equipos que desarrollan el lenguaje y el compilador en el que escribes tu código. .

Si necesita que su aplicación sea multiproceso, cree los subprocesos que necesita y deje que el compilador y el sistema operativo continúen con sus trabajos.

Debe ser consciente de cómo se administran esos subprocesos para poder hacer un mejor uso de los recursos. No crear demasiados hilos es una cosa que viene a la mente como ejemplo.

También debe ser consciente de lo que está sucediendo (ver el comentario de Lorenzo) para poder proporcionar sugerencias a la gestión de subprocesos (o anularlo en casos especiales), pero hubiera pensado que estos serían pocos y muy distintos. .

    
respondido por el ChrisF 24.09.2010 - 13:43
5

Soy un programador .NET, y sé que .NET tiene una abstracción de alto nivel para multiproceso llamada Tareas. Lo protege de tener que saber demasiado acerca de cómo hacer un multihilo adecuado contra el metal. Supongo que otras plataformas de desarrollo actuales tienen abstracciones similares. Entonces, si vas a hacer algo con subprocesos múltiples, trataría de trabajar a ese nivel si es posible.

Ahora, a la pregunta de debería incluso te interesa el multihilo en tu aplicación particular. La respuesta a esa pregunta depende mucho de la aplicación que está escribiendo. Si está escribiendo una aplicación que procesa en miles (o más) cosas independientes, y este procesamiento se puede hacer en paralelo, es casi seguro que obtendrá una ventaja del multihilo. Sin embargo, si está escribiendo una pantalla de entrada de datos simple, es posible que el multihilo no le compre mucho.

Como mínimo, debe preocuparse por los subprocesos múltiples cuando está trabajando en una interfaz de usuario. No quieres disparar una operación de larga duración desde la IU y hacer que no responda porque secuestraste el hilo de la IU para realizar esa operación. Dispare un hilo de fondo, y al menos dé al usuario el botón Cancelar para que no tengan que esperar a que se complete si cometieron un error.

    
respondido por el RationalGeek 24.09.2010 - 13:51
5

En la tierra de Objective-C y Mac OS X e iOS, los marcos (como muchos otros) están escritos para aprovechar estos aumentos en los núcleos de los procesadores y presentar al desarrollador una interfaz agradable para utilizarlos.

El ejemplo en Mac OS X y iOS es el despacho de Grand Central. Hay adiciones a libc (creo) para facilitar el multihilo basado en la cola. Luego, los marcos de Cocoa y Foundation (entre otros) se escriben en la parte superior de GCD, lo que permite al desarrollador acceder fácilmente a las colas de envío y los hilos con muy poco código de placa de caldera.

Muchos lenguajes y marcos tienen conceptos similares.

    
respondido por el Jasarien 24.09.2010 - 16:00
5

La parte más difícil es dividir el algoritmo de uso intensivo de la CPU en trozos de ejecución que podrían estar enlazados.

Luego, un subproceso que salta continuamente de un núcleo a otro tendrá penalizaciones de rendimiento (debido a la falta de caché de CPU de primer y segundo nivel), especialmente en arquitecturas donde se emplean dos matrices físicas distintas. En este caso, la afinidad del núcleo del hilo es algo bueno.

    
respondido por el Wizard79 24.09.2010 - 18:38
3

Estamos ahora (octubre de 2010) en un momento de inmensa transición.

Hoy podríamos comprar un escritorio de 12 núcleos.
Hoy podríamos comprar una tarjeta de procesamiento del núcleo 448 (buscar NVidia Tesla).

Hay límites en cuanto a cuánto podemos trabajar los desarrolladores, ignorando los entornos tremendamente paralelos en los que estarán trabajando nuestros programas en un futuro cercano.

Los sistemas operativos, los entornos de ejecución y las bibliotecas de programación solo pueden hacer mucho.

En el futuro, tendremos que dividir nuestro procesamiento en partes discretas para un procesamiento independiente, utilizando abstracciones como el nuevo "Framework de Tarea" .NET.

Los detalles, como la gestión de la memoria caché y la afinidad, seguirán estando presentes, pero solo serán el origen de la aplicación de alto rendimiento. Ningún mismo desarrollador querrá administrar estos detalles manualmente en una máquina central de 10k.

    
respondido por el Bevan 09.10.2010 - 22:02
3

bueno, realmente depende de lo que estés desarrollando. La respuesta, dependiendo de lo que está desarrollando, puede ir desde "es insignificante" hasta "es absolutamente crítica, y esperamos que todos en el equipo tengan un buen entendimiento y uso de implementaciones paralelas".

para la mayoría de los casos, una buena comprensión y uso de bloqueos, subprocesos y tareas y grupos de tareas será un buen comienzo cuando se requiera la necesidad de paralelismo. (varía por lang / lib)

agregue a eso las diferencias en los diseños que debe hacer: para el multiprocesamiento no trivial, a menudo se deben aprender varios nuevos modelos de programación o estrategias de paralelización. en ese caso, el tiempo para aprender, para fallar los tiempos suficientes para tener una comprensión sólida y para actualizar los programas existentes puede llevar a un equipo al año (o más). Una vez que haya llegado a ese punto, (con suerte!) no percibirá ni abordará los problemas / implementaciones como lo hace hoy (siempre que aún no haya realizado esa transición).

otro obstáculo es que estás optimizando efectivamente un programa para una ejecución determinada. Si no se le da mucho tiempo para optimizar los programas, entonces realmente no se beneficiará tanto como debería. la paralelización de alto nivel (o obvia) puede mejorar la velocidad percibida de su programa con bastante poco esfuerzo, y eso es lo que muchos equipos harán hoy: "Hemos paralelizado las partes realmente obvias de la aplicación", eso está bien en algunos casos. ¿El beneficio de tomar la fruta de baja altura y el uso de la simple paralización será proporcional al número de corazones? muchas veces, cuando hay dos o cuatro núcleos lógicos pero no tan a menudo más allá de eso. en muchos casos, es un rendimiento aceptable, dada la inversión de tiempo. este modelo paralelo es la introducción de muchas personas para implementar buenos usos del paralelismo. se implementa comúnmente mediante iteración en paralelo, tareas explícitas, subprocesos simples o tareas múltiples.

lo que aprendas usando estos modelos paralelos triviales no será ideal en todos los escenarios paralelos complejos; La aplicación efectiva de diseños paralelos complejos requiere una comprensión y un enfoque muy diferentes. estos modelos simples a menudo están separados o tienen una interacción trivial con otros componentes del sistema. Además, muchas implementaciones de estos modelos triviales no se adaptan bien a sistemas paralelos efectivamente complejos: un mal diseño paralelo complejo puede tardar tanto en ejecutarse como el modelo simple. ill: se ejecuta dos veces más rápido que el modelo de un solo hilo, mientras que utiliza 8 núcleos lógicos durante la ejecución. los ejemplos más comunes utilizan / crean demasiados hilos y altos niveles de interferencia de sincronización. En general, esto se denomina desaceleración paralela. es bastante fácil de encontrar si aborda todos los problemas paralelos como problemas simples.

entonces, digamos que realmente debería utilizar el multihilo eficiente en sus programas (la minoría, en el clima actual): deberá emplear el modelo simple de manera efectiva para aprender el modelo complejo y luego volver a aprender. Cómo aborda el flujo y la interacción del programa. el modelo complejo es donde debe estar su programa en última instancia, ya que es donde está el hardware hoy, y donde se realizarán las mejoras más dominantes.

la ejecución de modelos simples se puede visualizar como una bifurcación, y los modelos complejos funcionan como un ecosistema complejo, uh. Creo que la comprensión de los modelos simples, incluidos el bloqueo general y los subprocesos, debería ser o se esperará pronto de los desarrolladores intermedios cuando el dominio (en el que se desarrolle) lo use. entender modelos complejos es todavía un poco inusual hoy (en la mayoría de los dominios), pero creo que la demanda aumentará con bastante rapidez. como desarrolladores, muchos más de nuestros programas deberían apoyar estos modelos, y la mayoría de los usos están muy lejos de comprender e implementar estos conceptos. Dado que los conteos de procesadores lógicos son una de las áreas más importantes de mejora de hardware, la demanda de personas que entienden y pueden implementar sistemas complejos seguramente aumentará.

finalmente, hay muchas personas que piensan que la solución es simplemente "agregar paralelización". muchas veces, es mejor acelerar la implementación existente. Es mucho más fácil y mucho más sencillo en muchos casos. muchos programas en la naturaleza nunca han sido optimizados; algunas personas simplemente tenían la impresión de que la versión no optimizada sería eclipsada por el hardware pronto. la mejora del diseño o los recursos de los programas existentes también es una habilidad importante si el rendimiento es importante: lanzar más núcleos a los problemas no es necesariamente la mejor solución o la más sencilla.

al apuntar a las PC modernas, la mayoría de nosotros que necesitamos implementar buenos sistemas paralelos no tendremos que ir más allá de los subprocesos múltiples, el bloqueo, las bibliotecas paralelas, la lectura de un libro, y una gran cantidad de experiencia en escritura y pruebas de programas (básicamente, significativamente reestructurando cómo te acercas a escribir programas).

    
respondido por el justin 27.09.2011 - 10:05
2

Lo hacemos, pero escribimos software de cálculo pesado, por lo que nos beneficiamos directamente de múltiples núcleos.

A veces, el programador mueve mucho los hilos entre los núcleos. Si eso no es aceptable, puedes jugar con la afinidad del núcleo.

    
respondido por el Toon Krijthe 24.09.2010 - 13:48
0

En su forma actual, la frecuencia del procesador no aumentará en el futuro cercano. Estamos atrapados alrededor de la marca de 3 GHz (sin overclocking). Ciertamente, para muchas aplicaciones puede que no sea necesario ir más allá de los subprocesos múltiples muy básicos. Obviamente, si está creando una aplicación de interfaz de usuario, cualquier procesamiento intensivo debe realizarse en un subproceso en segundo plano.

Si está creando una aplicación que está procesando grandes cantidades de datos que deben ser en tiempo real, entonces sí, probablemente debería considerar la programación de subprocesos múltiples.

Para la programación de subprocesos múltiples encontrará que obtendrá rendimientos decrecientes en su rendimiento; puede pasar horas y mejorar el programa en un 15%, y luego pasar otra semana y solo mejorarlo en un 5% adicional.

    
respondido por el Harry 24.09.2010 - 16:51

Lea otras preguntas en las etiquetas