multicore - procesadores - ¿Te preocupa el multinúcleo?

procesadores de doble nucleo intel (20)

Creo que en general vale la pena interesarme, por decirlo suavemente.

No es necesario decir que el aumento masivo de la velocidad de las CPU en las últimas décadas ha sido extremadamente valioso, y que las ganancias adicionales serán igual de valiosas.

Pero esas ganancias a partir de ahora consistirán principalmente en una duplicación regular de la cantidad de núcleos. Entonces, para beneficiarse de estas ganancias, el software debe ser paralelizable.

Muchas de las partes de muchas aplicaciones que hacen un uso intensivo de los cálculos están en realidad escritas en SQL, por lo que ya son funcionales y pueden descomponerse en tareas paralelas mediante el RDBMS. Entonces esa gente puede relajarse.

Pero aquellos de nosotros que escribimos principalmente en C #, incluso si estamos escribiendo GUI, debemos prestar mucha atención a esto. Una GUI frecuentemente tiene que realizar alguna operación útil en cualquier modelo que presente al usuario, y el usuario se molesta cuando tiene que sentarse y esperar a que termine. Se molestarán aún más en unos pocos años, cuando miren al Administrador de tareas y vean que se está utilizando alrededor del 3% de su nueva y lujosa máquina de 32 núcleos.

Esto es innegable: las computadoras multinúcleo llegaron para quedarse.

Lo mismo ocurre con esto: una programación multinúcleo eficiente es bastante difícil. No es solo un caso de comprensión de pthreads.

Esto es discutible: el ''desarrollador en la calle'' necesita preocuparse por estos desarrollos.

¿Hasta qué punto te preocupa tener que expandir tu conjunto de habilidades para multinúcleo? ¿El software que está escribiendo es candidato para la paralelización y, de ser así, está haciendo algo para educarse a sí mismo (si aún no sabía las técnicas)? ¿O crees que el sistema operativo se encargará de la mayor parte, el tiempo de ejecución del idioma hará su trabajo y tu aplicación se sentará felizmente en un solo núcleo y dejará que los demás hagan lo suyo?

Es un buen argumento para comenzar a aprender idiomas funcionales, que son más fáciles de optimizar para la ejecución paralela.

He estado programando con hilos por más de 15 años. No estoy preocupado en lo más mínimo

No estoy preocupado. Los conceptos no son demasiado difíciles y más desarrolladores escriben aplicaciones multiproceso = más material sobre el tema = más fácil para descubrir lo que necesita.

Bueno, dado que hago desarrollo web en ASP.Net, hay algunas áreas en las que podría ver multinúcleo jugando un papel:

1) Del lado del cliente. ¿Cómo se puede optimizar algo como Javascript para el cliente que tiene una CPU de cuatro núcleos si eso es lo que alguien quiere aprovechar para ejecutar algo así como ordenar una larga lista de datos? ¿Los clientes gordos vuelven con las nuevas versiones de IE, Firefox, Safari y Chrome?

2) Servidor en un servidor web. Dentro de IIS y el framework .Net que utiliza, ¿cómo ayudan cosas como PLINQ a usar programación paralela o concurrente para ayudar a acelerar las solicitudes de manejo? ¿Qué tipos de configuraciones de IIS se pueden hacer para mejorar el rendimiento y sintonizarlo con el hardware?

3) Middleware / DB Back-end. ¿Cómo se maneja el último servidor MS-SQL u Oracle o MySQL utilizando los recursos adicionales de multi-core y multi-socket, por ejemplo, si una placa base quad-socket tiene CPU de cuatro núcleos en cada socket y algo así como Hyperthreading en la parte superior hay 32 hilos que podrían ejecutarse a la vez, que es realmente diferente a una CPU de un solo núcleo en los días.

Además, hay algo que decir sobre los aspectos multinúcleo de las GPU donde Crossfire y SLI fueron el comienzo, pero ahora hay más soluciones de gráficos híbridos que pueden preguntarse cómo se aprovecharán en el futuro, por ejemplo, AMD''s Fusion es una idea que No estoy seguro de lo bien que funcionará, pero está llegando lo último que escuché.

Sobre el tema de educarme, no estoy seguro de cuán difícil sería la optimización de mi código en algunos casos. Estoy más interesado en cómo IIS tratará de aprovechar el nuevo dominio informático antes, ya que podría limitar algunas cosas que se pueden hacer, incluso si aislo mi código para que se ejecute en su propio pequeño mundo.

Estos son solo mis pensamientos actuales y están sujetos a cambios en cualquier momento.

¡De ninguna manera! ¡Soy un programador de Clojure! :RE

¿ Sus programas suelen estar vinculados a la CPU?

Si no, olvídalo. No le concierne, y le brinda a sus usuarios una experiencia más fluida sin ninguna exigencia en absoluto.

Genial, ¿eh?

Si está vinculado a la CPU y su problema es paralelizable, es posible que pueda aprovechar los múltiples núcleos. Ese es el momento de comenzar a preocuparse por eso.

De los comentarios:

Sugerencia para mejorar la respuesta: da una explicación aproximada de cómo saber si tu programa está vinculado a la CPU. - Earwicker

Límite de CPU significa que lo que impide que el programa se ejecute más rápido es la falta de potencia de cálculo. Compare con IO obligado (o a veces vinculado a la red ). Una mala elección de la placa base y el procesador puede hacer que las máquinas también estén atadas a la memoria (sí, te estoy mirando, alfa).

Por lo tanto, necesitará saber qué está haciendo su programa de momento a momento (y cuán ocupada está la máquina ...) Para descubrir en un sistema unix, ejecute la top . En Windows usa el administrador de tareas (gracias Roboprog).

En una máquina con una carga inferior a 1 por núcleo (es decir, su máquina de escritorio cuando no está haciendo mucho), un proceso vinculado a la CPU siempre tendrá más del 50% de un procesador (a menudo más del 90%). Cuando el promedio de carga es mayor que eso (es decir, tiene tres compilaciones, SETI @ home y dos redes de igual a igual que se ejecutan en segundo plano), un proceso vinculado a la CPU tendrá una gran fracción de (# of cores)/(load average) .

Como desarrollador de juegos independientes, estoy muy entusiasmado con eso. Varios juegos se envían a la CPU durante los momentos activos. Y casi todos los juegos 3D modernos son muy exigentes con el hardware. Multicore ha sido la ley de la tierra para video durante los últimos años. Con algunas tarjetas nvidia hoy en día tienen más de 200 núcleos.

Escribir shaders para estas tarjetas es un placer, y no puedo esperar para ver qué sale de más y más máquinas que son multi-proc.

Creo que esta necesidad generará una mejor compatibilidad con el tiempo. Todavía tenemos planes locos como el modelo apaches MPM-Worker donde se obtiene una mezcla de varios procesos y subprocesos al mismo tiempo. Me gustaría ver una mejor adopción de cosas como los hilos verdes, donde todos parecen estar en el mismo proceso, pero en realidad están distribuidos sobre núcleos. Pero, por supuesto, alguien tendrá que tener alguna idea innovadora con memoria compartida para lograrlo.

A corto plazo: no es un gran problema a menos que estés aplastando tu procesador. Largo plazo: mejor ponte cómoda con los bloqueos :)

Día a día no pienso mucho en la programación multi-core, pero siempre está en mi radar.

El mayor problema que siempre he tenido con el procesamiento paralelo es determinar qué debería ser paralelizado. Es fácil derivar un hilo para procesar un archivo en segundo plano, pero ¿el proceso de archivo puede paralelizarse?

Creo que las preguntas sobre qué puede y debe ser paralelizado se responden con decisiones arquitectónicas complejas superpuestas a las ya complejas decisiones arquitectónicas de la aplicación en general. Mi creencia es que esta complejidad será resuelta por el sistema operativo o por el lenguaje de programación. El modelo de hilo tradicional de paralelización encontrado en C y sus descendientes no es la respuesta final.

En lo que he estado pensando, ¿no son la mayoría de los algoritmos de división y conquista masivamente paralelizables? Cada división debería poder ejecutarse en dos hilos separados ...

De todos modos, estoy preocupado cuando tengo que preocuparme. Cuando mi programa empiece a ser lento, entonces buscaré maneras de acelerarlo. Desafortunadamente, este es un problema en mi línea de trabajo.

No, no estoy preocupado.

Mi trabajo es un poco inusual y posiblemente se puede comparar más fácilmente que la media, pero a pesar de eso, lo veo como una oportunidad más que un problema.

En parte, estoy impaciente por que las cosas lleguen al punto en que realmente valga la pena optimizar para multinúcleo. No sé cuáles son los números exactos en este momento, pero parece que la mitad de nuestros clientes tiene una máquina de un solo núcleo, el 49% tiene doble núcleo y quizás el 1% tiene cuádruple. Eso significa que el multihilo no da realmente un gran aumento en el rendimiento en la mayoría de los casos y, por lo tanto, no merece la pena dedicarle mucho tiempo.

Dentro de unos años, cuando el promedio sea de cuatro núcleos, va a haber muchas más razones para gastar un poco de tiempo en el código inteligente de subprocesos múltiples, lo que creo que va a ser algo bueno para los desarrolladores. Todo lo que necesitamos es que Intel y AMD se apresuren y hagan más de ellos ... :-)

Uno de mis profesores orientados al hardware nos dice (bueno, predica) que se trata de un área de informática enormemente importante. Más aún, será tratado ya sea por el sistema operativo (noté que Apple está llegando a este punto fuerte, MS probablemente también), o el codificador mismo tendrá que pensar en la ejecución paralela (enhebrado, etc.).

Todo un área ordenada de CS. :)

Yo diría que para la mayoría de los programadores y las aplicaciones, significativo-multinúcleo no presenta una ventaja significativa o potencial sobre el desarrollo multiproceso estándar. La mayoría de las personas tiene hilos para realizar trabajos secuenciales, y no hay mucho potencial para dividir esos hilos en unidades mucho más pequeñas.

En mi humilde opinión, la mayoría de los beneficios de multicore significativo vendrían de las mejoras a los marcos subyacentes (por ejemplo, acceso a la base de datos, IO, GUI y juegos de herramientas 3D, etc.), y la gran mayoría de los desarrolladores se beneficiarían de forma transparente.

Además, las futuras herramientas de análisis estático pueden recomendar piezas que podrían dividirse más en hilos.

La programación de Dataflow muestra algunas promesas para una solución relativamente fácil al problema multinúcleo.

Sin embargo, como dice Wikipedia, requiere un cambio de paradigma bastante importante, lo que parece impedir su fácil adopción por parte de la comunidad de programación.

Creo que lo que es probable que suceda es que una vez que una gran cantidad de núcleos (digamos 8+) se vuelvan comunes, veremos el desarrollo de aplicaciones que aprovechan el paralelismo que no se consideraba viable en un mundo de subprocesos únicos.

No puedo pensar en ejemplos específicos, pero considere lo que sucedió cuando los aceleradores 3D se volvieron comunes. Los juegos en ese momento (creo que Doom) estaban limitados por la velocidad de su código de renderizado de software. No se consideraron siquiera tener modelos 3D altamente detallados que simularan la reflexión / refracción y la iluminación por píxel. Hoy en día todos lo hacen.

Entonces, a menos que sus aplicaciones actuales estén muy atadas a la CPU, no me preocuparía la posibilidad de hacerlas paralelas. Si encuentra que tiene un montón de potencia de CPU a través de múltiples núcleos, entonces busque maneras de explotarlo en nuevos proyectos.

No estoy de acuerdo con la respuesta aceptada actual.

El aspecto más importante de las máquinas multinúcleo es que la CPU y la memoria principal están muy separadas . Esto significa que a menos que la aplicación sea "vergonzosamente paralela" o fácil de paralelizar, es muy probable que sea un límite de memoria, en lugar de un límite de CPU. Una multiplicación de punto flotante toma alrededor de 4 ciclos de reloj, mientras que una recuperación de memoria de la memoria principal toma cientos de ciclos de reloj . Por lo tanto, explotar la localidad de caché se vuelve importante.

Para aplicaciones difíciles de paralelizar, si el rendimiento logrado en un solo núcleo es suficiente (la mayoría de las aplicaciones pertenecen a esta clase), no hay necesidad de paralelizar. Pero si no lo es (o la aplicación de su competidor es mucho más receptiva porque se paralelizaron), entonces sería mejor refactorizar su aplicación para explotar mejor el paralelismo y la localidad de memoria caché. Vagamente, la aplicación refactorizada consistiría en submódulos relativamente independientes (o menos comunicativos), que se ejecutan en paralelo (vea este ejemplo , para uno).

Consulte http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-183.html para obtener una buena visión general de multinúcleo y la forma en que se están desarrollando las cosas. Los principales puntos que dicen son:

La velocidad del reloj ya no aumenta como antes. Es más rentable fabricar más número de núcleos más lentos y simples que una pequeña cantidad de procesadores rápidos.
La memoria está (cada vez más) lejos de la CPU
En unos pocos años, habrá miles de núcleos en servidores web, cientos de computadoras de escritorio. Así que planee escalar su aplicación (probablemente a escala automática) a 100 o 1000 de núcleos. Esto significa que debe crear varias tareas independientes.
Los subprocesos son difíciles de trabajar, por lo tanto, mejor trabajar con "tareas" .

Solo una nota al margen: si su aplicación tiene una GUI y realiza cómputos intensos, SIEMPRE realice su cálculo intenso en un hilo separado. Olvidar hacer esto es por qué las GUI se congelan.

Creo que esta es una gran pregunta. Entonces, comencé una serie de publicaciones en el blog aquí .

La respuesta de Dmckee es correcta en el sentido más estricto. Permítanme reformular con mis propias palabras aquí, incluyendo implícitamente algunos de los comentarios:

No hay ningún valor en las operaciones de paralelización que no están vinculadas a la CPU. Tiene poco valor para las operaciones de paralelización que solo están vinculadas a la CPU durante períodos de tiempo cortos, por ejemplo, menos de unos pocos cientos de milisegundos. De hecho, hacerlo probablemente hará que un programa sea más complejo y con errores. Aprender cómo implementar el paralelismo de grano fino es complicado y hacerlo bien es difícil.

Eso es cierto hasta donde llega, pero creo que la respuesta es más rica para un conjunto más amplio de programas. De hecho, hay muchas razones para utilizar técnicas de múltiples hilos, y luego implícitamente multi-núcleo en sus aplicaciones de producción. Por ejemplo, es un gran beneficio para sus usuarios mover las operaciones de E / S de red y de disco de su cadena de interfaz de usuario.

Esto no tiene nada que ver con aumentar el rendimiento de las operaciones de computación encuadernada, y todo lo relacionado con mantener la interfaz de usuario de un programa sensible. Tenga en cuenta que aquí no necesita una interfaz gráfica de usuario: los programas de línea de comandos, los servicios y las aplicaciones basadas en servidor también se pueden beneficiar de esto.

Estoy completamente de acuerdo en que tomar una operación vinculada a la CPU y paralizarla a menudo puede ser una tarea compleja, que requiere conocimiento de sincronización fina, caché de la CPU, tuberías de instrucciones de CPU, etc. De hecho, esto puede ser clásicamente "difícil".

Pero, yo diría que la necesidad de hacer la suya es rara; simplemente no hay tantos problemas que necesiten este tipo de paralelismo de grano fino. ¡Sí! existen y puede tratar esto todos los días, pero yo diría que en la vida cotidiana de la mayoría de los desarrolladores, esto es bastante raro.

Aun así, existen buenas razones para aprender los fundamentos del desarrollo de múltiples subprocesos y, por lo tanto, multinúcleo.

Puede hacer que su programa sea más receptivo desde la perspectiva del usuario al mover las operaciones más largas fuera de la cadena del bucle del mensaje.
Incluso para cosas que no están vinculadas a la CPU, a menudo puede tener sentido hacerlas en paralelo.
Puede dividir máquinas complejas de un solo enrutador en un código más simple y de mayor procedimiento.

De hecho, el sistema operativo ya hace mucho por ti aquí, y puedes usar bibliotecas que están habilitadas para varios núcleos (como las cosas de Intel ). Sin embargo, los sistemas operativos y las bibliotecas no son mágicos: yo sostengo que es valioso para la mayoría de los desarrolladores aprender los conceptos básicos de la programación de subprocesos múltiples. Esto te permitirá escribir un mejor software con el que tus usuarios estén más felices.

Por supuesto, no todos los programas deben ser multiproceso o multi-núcleo habilitado. Está bien que algunas cosas se implementen de una manera sencilla y única. Por lo tanto, no tome esto como un consejo de que cada programa debe ser de subprocesos múltiples: use su propio buen juicio aquí. Sin embargo, a menudo puede ser una técnica valiosa y muy beneficiosa en muchos aspectos. Como mencioné anteriormente, planeo escribir un blog sobre esto comenzando aquí . Siéntase libre de seguir y publicar comentarios allí como se sienta inclinado

Sí, he estado programando con hilos, también. Pero no soy lo suficientemente masoquista como para amarlos. Todavía es demasiado fácil tener conversaciones cruzadas entre hilos, no importa cuán superhombre eres, más cualquier ayuda que recibas de tus compañeros de trabajo. Los hilos son fáciles de hacer, pero muy difíciles de hacer correctamente, así que, por supuesto, Joe-Schmoe gravita sobre eso, ¡además, son rápidos! (que es todo lo que importa, por supuesto)

En * nix, el buen tenedor viejo () sigue siendo una buena forma de ir por muchas cosas. La sobrecarga no es tan mala (sí, tendré que medir eso para hacer una copia de seguridad de mi BS algún día), particularmente si está bifurcando a un intérprete y luego generando una gran cantidad de datos específicos de la tarea en el proceso secundario.

Dicho esto, los procesos secundarios son tremendamente caros en Windoze, según me cuentan. Así que el enfoque de Erlang se ve bastante bien: obligue a Joe Schmoe a escribir funciones puras y usar el paso de mensajes en lugar de su autómata de estado aparentemente infinito (instancia) variable whack-fest con extravagancia cross-talk de hilo extra.

Pero no estoy amargado :-)

Revisión / comentario:

Excelente comentario en otro lugar sobre la distancia a la memoria. Había estado pensando en esto bastante recientemente también. La recolección de basura con marcas y barridos realmente daña el aspecto de "localidad" de los procesos en ejecución. M / S GC en 0 estado de espera RAM en un 80286 antiguo puede parecer inofensivo, pero realmente duele en las arquitecturas de almacenamiento en caché de varios niveles. ¿Tal vez hacer referencia al conteo + fork / exit no es tan mala idea como la implementación de GC en algunos casos?

editar: hago un esfuerzo para hacer una copia de seguridad de mi charla aquí (los resultados varían): http://roboprogs.com/devel/2009.04.html

No. Siento que el multinúcleo marcará una diferencia significativa en ciertas áreas de programación, pero apenas afectará otras áreas. Después de un tiempo, las áreas que lo hacen lo absorberán y encapsularán y la publicidad apenas tocará las otras áreas.