Hola .) El Monday 23 March 2009, Shinji Ikari escribió:
¿será correcto ese término? Nota en /. http://developers.slashdot.org/article.pl?sid=09/03/22/193205&from=rss
Tanto Linux y Windows no trabajan bien con procesadores de varios núcleos, este tema se trato ligeramente cuando se discutió acerca de 64 bits hace unos meses atrás, Los comentarios están muy interesantes. Y me parecen acertados en que los fabricantes de chips han hecho nada o demasiado poco para que se aproveche esta tecnología. También se mencionan algunas soluciones en los comentarios.
/. ¿News for nerds? es verdad... =P
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 - 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, ... - 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 Te pongo un ejemplo. Hace unos cuantos años, construimos una máquina que es capaz de escalar en hardware hasta 2048 cores y 128 TB de RAM en imagen única (una máquina NUMA, no es un cluster). Esto es escalabilidad de hardware. Esta máquina es capaz de escalar desde 8 cores hasta 2048. Pues resulta que al arrancar Linux en esa máquina, la tabla de procesos no era lo suficientemente grande por lo que al reconocer todos los procesadores ... no podías ejecutar ni un "ls" así que parcheamos el kernel para que no ocurra esto. Linux ya es capaz de escalar hasta 2048 cores "out of the box". Un cliente compró 4 máquinas de estas e instaló sus aplicaciones. Resulta que las aplicaciones sólo podían esclar hasta 1024 cores :( Al final el cliente ha dividido la máquina en 2 de 1024 procesadores y las demás tienen 512 cores sólo. Aquí, lo que no escala es la aplicación. El hw y Linux sí escalan, pero la aplicación no. Lo mismo ocurre con las aplicaciones de uso "cotidiano": paquetes ofimáticos, navegadores web, multimedia, ... Si no se han diseñado para utilizar todos los recuros del sistema ... el Linux escalará, pero la aplicación no. 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 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 - 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. 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. 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. Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com -- 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