Procesadores multicore: amenaza para la industria

La pregunta es: ¿se puede dar la paradoja de que con chips más potentes tengamos ordenadores más lentos?. La respuesta es que, no es que se pueda dar, es que se está dando ya.


Hace ya unas semanas que tenía ganas de escribir sobre este tema desde que lo leí en el Fortune del 8 de septiembre (lo sé, me suscribo a cosas “muy raras”), pero como podéis comprobar si véis las fechas de mis últimos post, cada vez me resulta más complicado escribir algo con todo lo que tengo encima.


En fin, volviendo al tema, el caso es que la dinámica del sector hasta hace unos pocos años fué siempre la misma: los fabricantes de hardware hacían CPUs más rápidas y los fabricantes de software (entiéndase, de sistemas operativos) hacían sistemas más potentes también (lo cual no siempre se traduce en mayor rapidez, no hay que confundir). Así se cumplía la ley de Moore y todos tan contentos.


El problema es que llega un punto en que exprimir los ciclos del procesador para darles más velocidad no es viable, bien económicamente, bien por eficiencia energética, por lo que las últimas generaciones de CPUs de hecho corren a frecuencias de reloj menores que las que había hace tres o cuatro años. Es por eso que lo habitual ahora es que ni siquiera te indiquen la velocidad de reloj de las CPUs. Lo que se ha hecho para poder seguir progresando en potencia es algo más “fácil” para los geniecillos del hardware (ojo con el entrecomillado, es para entendernos) que para los del software: los procesadores multicore. En lugar de poner más velocidad ponemos dos procesadores o más en uno sólo. Es parecido a tener sistemas multiprocesador pero en un sólo chip. Hoy en día es casi seguro que tu ordenador de sobremesa o portátil tiene un doble núcleo. En nuestra oficina en Krasis, por ejemplo, el nuevo servidor de dominio (bastante normalito) tiene dos procesadores de cuatro núcleos, es decir, como si fueran ocho procesadores.


Lo que ocurre es que esta tecnología es tan diferente de la anterior que los que trabajan en software a bajo nivel “rillan” (como se dice en mi tierra gallega, que no es “dar grima” como en Canarias, sino “desesperarse intentando resolver un problema” o “hacer algo que cuesta demasiado esfuerzo”, entre otras cosas). Según Craig Mundie, el jefe de estrategia e investigación de Microsoft, “es el cambio debido a “conceptos diferentes” más importante de la historia moderna de la computación”. ¿Exagerado?. Bueno, Sean Maloney de Intel reconoce que “se trata de un gran problema”, y otros van más allá y dicen que es una verdadera crisis.


La informática masivamente paralela lleva siendo una realidad desde hace muchos años en entornos científicos (para simulaciones que conllevan complejísimos cálculos), pero se trata normalmente de entornos muy cerrados y especializados, no de propósito general y con sistemas con lo mínimo para correr ese tipo de aplicaciones. Ahora la guerra es diferente pues estamos hablando de sistemas que deben funcionar con miles de propósitos diferentes y en entornos no controlados. Al parecer, desarrollar con eficiencia para esto es tan endemoniadamente complicado que hoy en día hay no personal cualificado suficiente para poder desarrollar una industria sobre estos chips. Los propios fabricantes de CPUs como Intel reconociendo el problema está contratando programadores en masa para intentar aportar soluciones desde su parte también.


La industria de los videojuegos ha vivido una crisis parecida hace unos años, a principios de la década, cuando Sony empezó a incorporar diferentes y múltiples chips a la Playstation 2. Los creadores de juegos “rillaron” intentando ponerse al día y lograr sacar juegos que al final llevaban enormes retrasos (y por lo tantos pérdidas millonarias). Incluso hubo empresas que directamente dejaron de producir juegos por no ser capaz de adaptarlos a la nueva realidad hardware.


Pues algo similar e incluso peor está pasando hoy en día en el mundo de los ordenadores. Se puede dar (y se da) la paradoja de que te compras un maravilloso PC con un quadcore y que algunas tareas tardan lo mismo o incluso tardan más que antes en hacerse. Si ya la programación multi-subproceso de alto nivel con lenguajes como C# o C++ es compleja, imagínate como será a esos niveles tan bajos. Por cierto, si te interesa el tema deberías echarle un vistazo al lenguaje experimental C Omega que extiende a C# para paralelismo.


¿Y tú qué opinas de esto? ¿Comentarios? ¿Ideas?


Recursos de interés que te sugiero:


· Artículo original completo en Fortune
· Parallel Computing en Microsoft
· Blog del equipo de Parallel Computing de Microsoft
· LINQ Paralelo: Running Queries On Multi-Core Processors
· Optimize Managed Code For Multi-Core Machines
· Curso de programación multihilo con .NET de campusMVP


 

Sin categoría

24 thoughts on “Procesadores multicore: amenaza para la industria

  1. Excelente artículo, Jose!

    Otra referencia imprescindible que deberías agregar a la lista es el blog de Herb Sutter, http://herbsutter.wordpress.com/, arquitecto principal de Mcrosoft para el tema de la concurrencia, y una de las leyendas mundiales de C++. Particularmente importante fue su artículo “The free lunch is over”, publicado en Dr. Dobbs hace ya algunos años, donde llamó la atención sobre el fenómeno que tú describes aquí y sobre la importancia que tendía en el futuro inmediato la programación concurrente.

    Abrazo – Octavio

  2. Creo que efectivamente, debemos ir acostumbrándonos cada vez más a la programación concurrente.

    En mi caso llevo mirándola desde hace tiempo porque creo que es el siguiente paso natural que debemos dominar, y creo que es lo más sensato porque las tendencias van por ahí.

    Hay un estudio que indica que para el 2010 aproximadamente, tendremos procesadores de 16 cores, es decir, la duplicidad de transistores argumentada por Moore cambiaría radicalmente hacia la duplicidad de procesadores… paradojas de la vida, aunque quien sabe si es la tendencia o no. Lo cierto es que de los Dual Core hemos pasado a los Quad, y se escuchan rumores de que Intel ya tiene el procesador de 8 cores listo para distribuir (supuestamente) y aún no lo habría hecho esperando a que el mercado madurase. También esas mismas malas lenguas, comentarían que el procesador de 16 cores está ya en el horno de desarrollo… ver para creer si es cierto.

    El caso es que lo sensato es irse mirando con más rigor y seriedad, todo lo que tiene que ver con procesos concurrentes.

    Todo esto me recuerda a cosas como las hebras (sí sí, todos sabemos lo que es) olvidadas por muchos desarrolladores, o los pipes que muy bien comentaba el mismo Octavio en este artículo de MSDN (http://msdn.microsoft.com/en-us/vcsharp/cc178927.aspx) .

  3. Yo creo que lo que hay que hacer es incidir en la formación de los desarrolladores, las herramientas existen para atacar este problema: OPM en C++, Parallel Extensions en .Net, soporte para hilos en todos los lenguajes,…

    A lo mejor deberíamos empezar por desempolvar el curso de programación multihilo de Campus MVP… 🙂 y completarle con algo de Paralell Extensions ¿Te animas Octavin? 😉

  4. Más que una amenaza, creo que esto es una nueva oportunidad para nosotros los desarrolladores; como dice Sutter, una nueva oportunidad para ganarnos “el almuerzo gratis”.

  5. Me van a matar … pero creo que la programación concurrente si bien es algo que todos deberíamos conocer, la tecnología debería evolucionar de manera tal que estos conceptos sean abstractos para los desarrolladores, hoy todavía son bastante complejos (y peligrosos en malas manos !!!)

    No me malinterpreten, yo me he peleado bastante con la programación concurrente gracias a Robotics Studio, internamente posee un motor concurrente (muy pero muy currado) llamado CCR. Pensad que en el mundillo de la robótica las instrucciones tienen que fluir en varias direcciones y simultáneamente, hay que comprender como crear procedimientos “aislados”, … etc.

    Creo en lo que dice Octavio, que hoy es más una oportunidad que una amenaza … pero los invito a recordar las malas prácticas con programación multihilo los problemas que han traído, espero que no nos pase lo mismo …

    Saludos

  6. Aunque la velocidad de los procesadores Intel Core 2 es menor que los últimos Pentium 4, su rendimiento es superior, ya que la velocidad hace años que no es igual al rendimiento del procesador, con un solo núcleo por supuesto. La diferencia es la arquitectura interna del procesador. Y la del Pentium 4 ha demostrado ser ineficiente desde el principo hasta el final. Los PIII eran superiores a los primeros P4 aunque funcionaban a mayor velocidad y los últimos P4 no podían alcanzar la velocidad prevista para esa arquitectura( 5GHz) pPor lo que Intel la ha abandonado
    Los procesadores de AMD han seguido una progresión ascendente en la velocidad en todo momento.
    Hoy en día todavía hay muchos programas que no utilizan efecientemente varios núcleos y por ello es mejor un procesador dual rápido que un cuadruple más lento para esos programas. Un ejemplo son los juegos.

  7. Hola, Bruno!

    Yo creo que estamos 100% de acuerdo: en la medida en que esas posibilidades se usen de forma transparente, se ganará en productividad (y los principiantes podrán usar esas facilidades “sin peligro”). Esa es la línea, por ejemplo, de TPL y PLINQ.

    Pero todo programador que se precie debería conocer las facilidades que hay por debajo, como tú también dices.

    Abrazo – Octavio

  8. Hola a todos:

    Sólo quiero enfocar un poco la conversación: mi post original (y el artículo de Fortune) se refiere a la programación multinúcleo de bajísimo nivel, propia de sistemas operativos, y no a la de alto nivel con lenguajes como C++ o C#.

    El asunto es que sí que es mucho más fácil conseguir código bueno y eficiente para programas de propósito particular propio usando hilos, multisubproceso, etc… si bien estoy de acuerdo con vosotros en que la mayor parte de los programadores no los dominan como es debido.

    Tened en cuenta que puedes hacer una aplicación multihilo y multisubproceso (asíncrona comop sería propio llamarlas) en equipos con un solo procesador, lógicamente. El sistema operativo es el que decide de qué manera se reparten los tiempos en caso de haber un sólo procesador o cómo se reparten los procesos (y se MANTIENEN SINCRONIZADOS) en sistemas con más de un procesador o núcleo. Aquí está elquid de la cuestión.

    De lo que se trata aquí es de programación a bajo nivel de PROPÓSITO GENERAL, es decir, que sea eficiente y sepa sacarle partido a los núcleos para cualquier tipo de operación que se ejecute por encima de los sistemas operativos, lo cual es ya más complicado porque no se sabe qué será necesario ejecutar. Por eso hacía mención a los sistemas masivamente paralelos, que lo consiguen pero para cosas muy concretas como cálculos matemáticos.

    En un SO como Windows, Mac o Linux se ejecutan desde aplicaciones con una componente de cálculo alta como las de retoque gráfico hasta compiladores pasando por procesadores de texto o reproductores multimedia. Éstos deben funcionar en hardware de todo tipo (multinúcleo o no) y debe ser el SO el que se encargue de aislarlo de esa complejidad siendo transparente para ellos, pero al mismo tiempo debe conseguir que se ejecuten de la forma más eficiente. algunos programas realmente le podrán sacar partido a los varios procesadores y núcleos, otros no, y otros según las circunstancias deberían usar esos núcleos de una forma u otra. El poder distinguir eso para cada situación y sólo en función de las instrucciones que le lleguen al núcleo del SO pienso que es el verdadero reto al que se enfrentan los fabricantes y es de lo que va todo este asunto.

    Por supuesto, si encima de que ya es complicado los programadores de aplicaciones convencionales no saben gestionar los hilos y subprocesos (que no dejan de ser abstracciones de lo que hay por debajo) pues apaga y vámonos.

    Saludos 🙂

    JM

  9. programación a bajo nivel de PROPÓSITO GENERAL
    ¿Existe esto?

    ¿Por qué alguien querría hacer programación de bajo nivel y de uso general?

    Habiendo lenguajes de alto nivel que se enfocan el los usos generales y hacen muy bien su trabajo en aquello, uno cree que se deja la programación de bajo nivel para situaciones específicas (los propios SO incluso).

    En alto nivel, el paralelismo (en general) no se usa para mejorar el rendimiento de la aplicación, sino para entregar respuestas más fluidas al usuario, y solo cuando es necesario.
    Incluso un usuario ocupando una aplicación no programada de manera paralela, puede beneficiarse del poder de un multinucleo al poder utilizar otro programa de manera concurrente mientras el primero termina su tarea.
    (además, no es que los computadores los usemos con una sola aplicación a la vez)

    Recordemos que estamos hablando de aplicaciones de uso general y no de uso específico ni de alto poder de cálculo.

    Creo que me estoy perdiendo algo aquí, no entiendo el sentido del post.

  10. Hola Delm:

    El sentido del post es precisamente que la programación de bajo nivel, sistemas operativos vamos. Leyendo el artículo original de Fortune creo que se entiende mejor.

    No obstante desde mi punto de vista (y creo que el de la mayoría) un sistema operativo es un sistema de bajo nivel y además genérico, por lo que en ese ámbito el post es pertinente. ¿Qué hay más complicado a bajo nivel que un ejecutor de programas de alto nivel que decida cómo reparte los tiempos de CPU y/o las CPUs entre todos los procesos que se ejecutan sobre él? Eso es un problema grave de progamación.

    Por otro lado y yéndonos a programas de “modo usuario” que no era tanto la intención del post original, el hecho de tener varios núcleos o procesadores no sirve de nada si no se hace código multisubproceso y éste no es para nada trivial ya que el hecho de ejecutar tareas en paralelo y tener que coordinarlas, etc… no es precisamente algo sencillo tampoco, si bien no tanto como el problema original que describe el post.

    Espero que esto lo centre algo más.

    Saludos

    JM

  11. Estimado amigos:
    Sinceramente agradecerles por compartir sus ideas y puntos de vista, yo soy programador; de .NEt para ser exacto y no muy experimentado segun me veo a mi mismo al leer estas notas, LES AGRADECERIA si pudiera instruirme con alguna direccion en la web a fin de documentarme en el temas de los hilos y multisubprocesos para .NET.
    Por lo demas debo mencionar que la arquitectura de hoy en dia parece no soportar las aplicaciones a fin de hacerlas mucho mas rapido, porque veo que en la oficina muchas maquinas PIII hacen las tareas mucho mas rapido que los core 2 duo.

    Un saludo fraterno, y por favor no olviden mi pedido se los agracere sinceramente

  12. A nuestra industria le encanta inventarse crisis, algo que aburre, pero que entiendo porque las crisis sirven para hacer negocios. Acá va un consejo: cuando lean un artículo, que parte con una afirmación alarmista, piensen que hay alguien detrás que.

  13. Joer y yo terminando la carrera de Ing.Informática que no doy echo con todo lo que rodea a C#,LinQ,Ent.Library,… y en nada me decis que C-omega será el futuro, me cago en…. con lo mal que se me dio la asignatura de Sistemas de Tiempo Real donde nos machacarón con programación concurrente, paralela,…

    Me compro unas cabras!!!!!!!!!!!!

  14. Interesante el artículo.
    Creo que es la mayor oportunidad de los desarrolladores de tener mayores rentabilidades.
    Es más, ya están apareciendo libros específicos sobre el tema. He visto anunciado por la editorial Packt Publishing, un nuevo libro sobre programación paralela con C#: “C# 2008 and 2005 Threaded Programming”, del autor hispanoparlante Gastón C. Hillar (uno de los nuestros), http://www.packtpub.com/beginners-guide-for-C-sharp-2008-and-2005-threaded-programming/book. Imaginemos que tendremos la oportunidad de desarrollar nuevas aplicaciones con mayor rendimiento y tener ¡¡¡¡MÁS TRABAJO!!!!

  15. He llegado un poco tarde al post, pero son muy interesantes los puntos de vista expuestos. Hace poco entable un debate al respecto y me centre precisamente en el dilema del crecimiento multicore, pienso que esa es una de las soluciones para alcanzar aun mayores rendimientos y el software nunca va desligado a ello, son nuevos paradigmas de desarrollo y la base que es el Sistema Operativo es primordial, muchos de los conceptos de Inteligencia Artitifical encontrarian ahora un nicho de desarrollo, creo que la estrategia apuntaria a estos principios.

  16. Estimado JM,

    He leído tu artículo completo en Fortune (muy bueno y recomendable). Me ha dado una visión muy clara de qué es lo que está sucediendo y, a partir de él, empecé a analizar todo lo relacionado con los procesadores multicore. Y también leí los comentarios en este blog.
    Luego, empecé a buscar bibliografía especializada y seguí la recomendación de Daniel Craig (compré el e-Book y luego también el libro en español del mismo autor “Estructura Interna de la PC”, 5ta Edición), que habla de hardware.
    Al fin empecé a entener mejor las cosas. El libro “C# 2008 and 2005 Threaded Programming” viene con la opción para descargar los fuentes. Son todos ejercicios muy bien explicados (mi inglés es regular, así que si yo lo entendí…). Al fin pude ver mi Core 2 Quad Q6600 con los cuatro núcleos al 100% con código C#.
    Recién voy por el capítulo 4 de 12 (el libro e-book lo compré hace 3 días) y lo complemento con el libro Estructura Interna, que explica bien el hardware (y está en español).

  17. Muy buen artículo.
    Tal vez estamos ante una oportunidad histórica de posicionamiento.
    Mi interés en los procesadores multicore comenzó con un artículo que leí en la revistas española “Solo Programadores”, la Nº 161: “Programación con Múltiples Hilos (Threads) en Visual Basic; C# Y Java (I)”.
    Resulta que el autor de ese artículo es Argentino (escribió decenas de libros). Y, ahora, es nada menos que el autor que mencionan en los comentarios de este blog: “C# 2008 and 2005 Threaded Programming”, pero en idioma inglés.
    Hay cada vez más información e interés en los hispanoparlantes en este tema. Tenemos al Sr. Gastón Hillar, haciendo punta en el tema (lástima que el libro no está también en español).
    No será hora de tomar el toro por las astas y dar el gran salto y demostrar que los hispanoparlantes podemos resolver la revolución que nos plantea la tecnología hacia fines de la primera década del 2000.
    No soy bueno con el inglés, pero, encargué un libro del Sr. Hillar en Amazon, simplemente porque estoy seguro que el esfuerzo que está realizando vale la pena (cuando salga en español, lo leeré completo y lo entenderé).

  18. Estimados, el solo hecho de encontrar este blog en la segunda página de búsqueda de multicore con C# es un logro (sin filtrar por idioma). Coincido con Daniel Craig, es una oportunidad para tener más trabajo o bien, para RETENERLO!!
    Al fin el idioma español está demostrando que también podemos ser héroes en la tecnología. Qué buena noticia la del libro de Gaston Hillar, pensar que yo usé el libro Estructura Interna de la PC en la segunda materia de mi Licenciatura en Informática. Ojalá tenga suerte y que luego pueda publicarlo también en español.

  19. Para mi el gran problema de los sistemas multiprocesador son precisamente los procesos que no se pueden descomponer en hilos para utilizar toda la potencia del sistema. A parte de lo complicado que pueda ser programar de forma concurrente, hay procesos que por su naturaleza no se pueden descomponer y en un sistema de digamo 256 “cores” sólo podría utilizar 1. El ejemplo más típico es el de un algorítmo que opere con el resultado de la operación anterior.

    while (true) { a=sqrt (a); }

    si quisiera saber cuanto valdría a después de 10000000 de iteraciones del bucle?….
    Es un ejemplo muy burdo pero es para que se entienda.

  20. Hola,

    La verdad me gustaría mucho tener procesadores múltiples, pero si son muy frágiles, ya no me conviene.
    No se, veremos como van las cosas, la industria avanza lento pero seguro.
    Saludos,
    Ariana.

  21. Igual que Paloma, soy nueva en todo ésto pero me interesa mucho. Si alguien pudiera facilitarme más información acerca del tema lo agradecería mucho.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *