El 2009-03-23 a las 09:04 +0100, Rafa Grimán escribió:
El Monday 23 March 2009, Shinji Ikari escribió:
¿será correcto ese término?
<modo pedante on> Pues a mi no me termina de convencer. "Paralelización" tiene un deje matemático-geométrico que no le veo aquí... un proceso no se puede ejecutar "en paralelo", sino al tiempo, de forma concurrente, eso sí. Pero no hay espacio ni distancia entre ellos.
Nota en /. http://developers.slashdot.org/article.pl?sid=09/03/22/193205&from=rss
Sí y no. Vamos a ver, "escalabilidad" no es un término absoluto. Es decir, no basta con que tengas un hw con muchos procesadores. Para poder escalar en la informática, hacen falta al menos 3 cosas: - escalabilidad en hw: es decir, que el hw escale. No basta con poder poner muchos procesadores. Aquí hay que tener en cuenta buses (ancho de banda), latencias, RAM, I/O. Es decir, tiene que escalar tanto en CPU, como en I/O como en RAM. Si NO lo hace, tienes cuellos de botella y NO tienes escalabilidad
Yo creo que con los equipos actuales esto ya lo tenemos... o casi.
- escalabilidad del sistema operativo: el sistema operativo debe ser capaz de reconocer (ver) y trabajar con todos los recursos hardware que tiene la máquina. O, lo que es lo mismo, debe ser capaz de gestionar todos los recursos: CPU, RAM, I/O, ...
Y esto creo que también. Los sistemas están preparados.
- escalabilidad de la aplicación: la aplicación que estás ejecutando debe ser capaz de utilizar todos los recursos hw que el sistema operativo le presenta a la aplicación. Es decir, si el sistem aoperativo reconoce 80 procesadores, pero la aplicación ha sido diseñada para usar uno ... pues no hay escalabilidad
Esto no. Aquí falta mucho trabajo que hacer :-P (...)
Lo que ocurre hoy en día es que se ha invertido poco en la programación paralela, IMHO por dos razones:
- desconocimiento, flojera y miedo: no es fácil programar para sistemas SMP y depurar y hacer profiling ya es un infierno
- falta de inversión y previsión: hay que diseñar y reprogramar todo
El SMP lo incorporaron en el kernel desde hace unas cuantas versiones, creo recordar. Y dentro de poco casi seguro que los 64 bits nos vendrán de serie, también >:-) Quizá se esté notando más el interés en las aplicaciones audiovisuales, 3D o de CAD/CAM/CAE, parece que hay más movimiento en este tema.
Hay otras razones que también hay que tener en cuenta:
- algunas aplicaciones no se benefician tanto: navegadores web, procesadores de texto, ... Luego la mejora obtenida no justifica la inversión en tiempo y dinero
¿Ein? Al openofice le vendría de perlas y a firefox con lo que tira de cpu y ram... y al plugin de flash ni te digo OX-)
- el usuario arranca varias aplicaciones: correo, web, ofimática, ... por lo que si no se paraleliza la aplicación, el usuario no se dará cuenta y tampoco pasa nada porque tendrá cada aplicación ejecutándose en un core por lo que notará cierta mejora. En este caso, el usuario no notará que las aplicaciones se ejcutan más rápido sino que las aplicaciones responden mejor ya que no hay que sacar una aplicación del core para meter otra, cada una tendría el suyo
Resumiendo: Linux (el kernel) sí escala, pero las aplicaciones no.
Ese es el problema.
De todas formas, hay una cosa que dicen, qu eno estoy de acuerdo:
"But many of the tools available are still works in progress, participants at the Multicore Expo said. Software compilers need to be able to identify code that can be parallelized, and then do the job of parallelizing it without manual intervention from programmers, said Shay Gal-on, director of software engineering at EEMBC, a nonprofit organization that develops benchmarks for embedded chips."
El programador debería saber lo que está haciendo y no dejar todo en manos del compilador. Está bien que el compilador haga ciertas cosas para facilitarle la vida al programador, pero otras las debería hacer el programador.
No sé cómo irá hoy en día la programación con leguajes actuales de alto nivel, pero yo me fiaría más de las sugerencias del compilador que de las de un humanoide :-). El compilador puede tener en cuenta más variables ¿no?.
En cambio, estoy totalmente de acuerdo con lo que dicen luego:
"While the programming side may present the biggest challenge, there are also hardware changes that need to be made, to overcome issues such as memory latency and slow bus speeds. "As you add more and more CPUs on the chip, you need the memory bandwidth to back it up," Gwennap said. Sharing a single memory cache or data bus among multiple cores can create a bottleneck, meaning the extra cores will be largely wasted. "By the time you get to six or eight CPUs, they spend all their time talking to each other and not moving forward to getting any work done," he said. The onus may ultimately lie with developers to bridge the gap between hardware and software to write better parallel programs. Many coders are not up to speed on the latest developments in hardware design, Gal-on said. They should open up data sheets and study chip architectures to understand how their code can perform better, he said."
Sólo le falta añadir que los fabricantes de chips y herramientas de desarrollo (compiladores/depuradores/profilers/...) deberían ayudar a los desarrolladores dando más información de cómo optimizar y programar para SMP, NUMA y clusters.
Bueno, en la noticia dice que sólo entre Intel y MS iban a destinar $20 millones de dólares en programas de investigación universitarios, que no es poco. Pero es cierto, parece que hoy día sólo se preocupan de que todo (componentes y software) sea "verde", ecológico y económico y para de contar, como si la eficiencia se midiera sólo en vatios/hora >:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org