Lista Artículos Lista Editoriales Enlaces Juegos en Línea Noticias Tienda J por Amazon(com)
J de Juegos.com
PC
AYUDA   |   BUSCAR x CLAVE   |   
Buscar con GOOGLE >>>
 
Escríbenos! Galardones. Juegos Recientes.
Preguntas Frecuentes - Galerías - Códigos - Descargas - Enlaces - TOP 10
| ACCIÓN | | AVENTURA | | CARRERAS | | DEPORTES | | ESTRATEGIA | | JUEGOS DE ROL | | SIMULADORES |
Industria: El Dilema de Intel y AMD
x Webmaster

Lo dije ya antes en varios artículos del sitio Web, y lo digo otra vez y seguro lo andare repitiendo en muchos otros artículos más, el instante en que los fabricantes de procesadores, Intel y AMD (los más conocidos en todo caso), sacan al mercado sus primera generación de CPU multi-core (cualquiera el nombre privado que les dan) toda la industria del software, casi sin excepción, lanza un silencioso suspiro de preocupación y se dan cuenta que nunca, pero nunca más podrán estar por delante del hardware y jactarse de que sus productos consumen más cíclos de procesador de los que hay disponible o habrá en un futuro inmediato. Esto ya es, ya fue, historia.

Han pasado apenas un par de años desde aquellos ponposos y bien intencionados anuncios de la llegada de la era de los procesadores multi-core. Todos sin excepción han hablado de sus ventajas, todos sabemos su cara positiva. Desde entonces el porcentaje de la población mundial todavía trabajando con CPU de un sólo núcleo ha ido decreciendo. Actualmente están en boga los procesadores de dos núcleos, o cores, y a lo mucho se tiene en miras pasar a los de cuatro casi con seguridad para videojuegos porque no tiene mucho sentido para cualquier otra cosa. Con su modelo Tick-Tock de mejora-evolución Intel parece haber alcanzando un ritmo excelente para el incremento progresivo del número de núcleos; por su parte AMD tiene algo similar.

En lo que queda del 2008 Intel alcanza el punto Tock y si todo va bien presentarán a fin de año a nivel comercial la nueva arquitectura Nehalem que por las revisiones parciales ya salidas a la luz está muy bien realizada y mejora eficiencia y rendimiento según lo prometido y esperado. El 2009 se viene el Tick. Y si en un futuro inmediato Intel no quiere encontrarse con un Pum, deberá, creo que por primera vez en décadas, darle una larga mano y mucho soporte a la comunidad y a la industria desarrolladora de software en general.

El 2 de Julio bajo el título Intel cracks a whip at software developers, Fudzilla(com) ofrece una nota mínima sobre un tema que, prácticamente invisible a los usuarios, muy bien podría estar marcando el futuro de la industria en general. La nota destaca como Intel está pidiendo a los desarrolladores de programas, aplicaciones, videojuegos, y entre líneas a los de sistemas operativos, que diseñen e implementen no sólo con miras a dos cores, o cuatro, u ocho, sino a un número cualquiera. Con miras a futuro si se quiere. El detalle es que pedirlo, decirlo y hacerlo son cosas muy diferentes, y la tarea impuesta a quienes lidian con la parte intangible de la industria es una a escala monumental.

¿Por qué el requerimiento? Esto es fácil de responder. Actualmente, y perdonen la redundancia quienes leyeron los otros artículos afines, el software con que trabajamos tiene una capacidad entre mínima y ninguna para aprovechar al máximo entornos de más de un núcleo de procesamiento. Los paradigmas de desarrollo y programación en que están basados pueden usar sin gran problema más cíclos de procesador por segundo, pero no más procesadores, no ejecución real en paralelo, no concurrencia a nivel hardware.

La conclusión de lo anterior es preocupante para quienes tienen la intención de ofrecer más y más y más núcleos a rítmos acelerados. Y no sólo más núcleos físicos sino, además, mecanismos por los cuales un mismo core es capaz de trabajar hasta dos, o más, hilos-de-ejecución de manera simultánea (en el caso de Intel). Como usuario y consumidor cualquiera se ve ante la inevitable necesidad de preguntar, ¿para qué compro una de cuatro núcleos, u ocho o más, si el software que tengo, que uso, que requiero ni sabe aprovechar bien una de dos? Sin la necesidad, o siquiera un beneficio, el negocio se les podría acabar tanto a Intel como a AMD, al menos a nivel consumo masivo que es lo que les ha permitido crecer como setas.

A lo anterior hay que agregar que los procesadores de ahora, a nivel un núcleo, se han vuelto más eficientes y capaces que antes, por lo que aún software diseñado para aprovechar de mayor velocidad y cíclos de ejecución se encuentran con que el hardware ya rebasa sus necesidades, lo que no es malo per se.

Por otro lado, también hay que considerar la inevitable entrada en el juego de la ejecución general de aplicaciones de los GPU, ATI y Nvidia (y muy pronto quizá Larrabee de Intel). Si éste su papel secundario se torna relevante a corto plazo o es sólo un intento para mantenerse útiles para el usuario general, lo dira el futuro. Lo que no se puede negar es que para muchas tareas, por ejemplo al procesar imágenes, o codificar/decodificar audio o vídeo sus particulares características los hacen muy prometedores, no por nada la siguiente versión de Adobe Photoshop considera más y mejor integración con el potencial de procesamiento de un GPU.

Todo apunta a que el ya oficial DirectX 11, que por ahora se dice saldría el 2009 y es compatible tanto con Vista como Windows 7 (ahora Windows Vienna), incluye funciones de computo --general-- denominadas compute Shaders que de seguro tendrían aplicación fuera del dominio de los videojuegos. Al menos así se entiende el asunto con la información disponible en estos momentos. Lo que beneficiaría a los desarrolladores por tratarse de una plataforma muy conocida y estándar.

De todas maneras se trate de un CPU multi-core (de ahora en más CPUmc para abreviar) o un GPU, a la hora de la verdad ambos se enfrentan con el mismo problema desde el punto de vista del software, para aprovecharlos hay que prácticamente empezar de nuevo y casi desde cero. No es sólo que el código ejecutable --existente-- no tiene la capacidad de sacarle el jugo al paralelismo ofrecido, sino que la forma en que fueron concebidos y diseñados obedece a una lógica lineal o casi lineal. El concepto de hilo-de-ejecución trabaja sobre un razonamiento secuencial que permite no perder cíclos de procesador cuando un otro hilo está ocioso por alguna razón, esto no puede verse, al menos no siempre, como que ambos pueden ser asignados a un core y se acabo el problema. Si fuera así de simple no habría dilema.

Quizá al respecto el mayor inconveniente sean los propios hábitos de uso que tienen los usuarios para con el software. Podrán estarse ejecutando cinco, diez, mil programas a la vez pero desde el punto de vista del que los usa esto no quiere decir que los está viendo, o interactúando con todos a la vez. El ser humano no tiene ninguna capacidad innata, dígase lo que se diga, para hacer más de una cosa de forma simultánea sin que pase algo y no siempre bueno (de ahí todas esas campañas de que es malo hablar por celular y conducir, aún si se habla por micrófono o parlantes con las manos bien puestas en el volante, cuando el grado de atención sube para uno, siempre baja para el otro, no hay 50-50 ni 90-10 que valga, como bien dicen: basta un instante de distracción).

Para una PC moderna, escuchar música, tener descargando archivos, al navegador mostrando decenas de páginas Web, al programa X codificando vídeo, al antivirus activo, etcétera ya no le cuesta nada, y a lo mucho el sistema operativo asigna las diferentes tareas de manera que ningún core disponible esté del todo ocioso. Pero esto no quiere decir que se los esté empleando bien a todos, ni que por ello se puede aprovechar un número creciente de los mismos. ¿Qué pasa cuando tengo un CPUmc de cuatro u ocho núcleos y sólo quiero usar un procesador de texto, tampoco voy a tener dos o seis de ellos sin hacer nada, al fin de cuentas pague por todos, cierto? (asumiendo uno para el SO, otro para el procesador de texto). La solución tampoco es que todos empecemos a ayudar a iniciativas como SETI@Home o Folding@Home, o similares, para que nuestra inversión en cíclos de procesador sirva de algo (claro que si se desea hacerlo tampoco es malo o negativo).

No hay que olvidar que el dilema aquí es cómo obtener un mayor beneficio real de un número de cores que de ahora en más sólo irán en aumento. Esto desde el punto de vista del usuario común y las aplicaciones de software estándar. Considerando, además, que los videojuegos caen dentro lo estándar a pesar de su naturaleza compleja y lógica de software sumamente sofisticada. Al fin de cuentas estos son para entretenimiento, no para trabajo y más allá de relajar o distraer no ofrecen verdadero beneficio, a menos que se trabaje con, y/o viva de ellos (valga la excepción).

Y, ¿cuáles son/serían las soluciones? Responder a esta pregunta ya es algo más complicado y lamentablemente no depende tanto de nosotros como usuarios, aunque dependiendo como resuelva el dilema la industria puede que debamos adaptarnos y cambiar nuestras rutinas de uso para con la PC, al fin de cuentas puede que aparezcan nuevas idiosincracias un tanto bizarras pero podemos estar seguros, o al menos esperar, que son para mejor y no sólo para vendernos más, o vendernos algo que en realidad no necesitamos (podemos suponer que para evitar --en potencia-- este último caso están las oficinas de protección del consumidor, al menos ahí donde existen).

En lo que respecta a mi persona tengo un buen par de especulaciones o ideas bien educadas de cual, o cuales podrían ser las soluciones posibles a este tema (y hay muchas más que se están pensando, o que hasta son compatibles con las presentadas a continuación). Algunas más prometedoras que otras. Algunas más factibles que otras, pero no por ello imposibles a corto o mediano plazo. Una vez más, todo depende de como responda la industria en general y la porción que diseña y desarrolla software en particular. A no olvidar es que son soluciones que permiten un trabajo eficiente y efectivo con un número de núcleos creciente, no que sólo sirve para cuatro u ocho. Veamos.

Con el poder de procesamiento disponible una de las alternativas más sencillas y con menos rodeos es ya no ver a la PC como tal, una máquina personal, sino más bien como una de orden familiar o grupal dependiendo el caso y el contexto. Con hardware o periféricos especiales se puede establecer una lógica de máquinas tontas y una máquina central que es la que procesa todas las tareas. El mayor problema con esta idea es que además de procesar información, datos y ejecutar aplicaciones hay que presentar información visual, misma que en nuestros tiempos ya es más complicada y sofisticada de lo que se veía en la epoca de las terminales tontas tal cual y sus pantallas de texto. Aún así, tener un equipo con más de cuatro núcleos cumpliendo con las necesidades de un par de terminales extras sin CPU tendría que ser algo viable sin demasiadas complicaciones técnicas a nivel hardware y/o software.

Un ejemplo de que la alternativa precedente tiene sentido es aquel ofrecido por una presentación en un evento afin donde un equipo portatil, de baja capacidad de procesamiento, le permitía a su usuario jugar Crysis aprovechando el poder de procesamiento de un equipo anfitrión, mucho más poderoso, cercano (la idea era usar WiMAX para mandar la información --procesada-- a una UMPC de Samsung sprovechando el software StreamMyGame). El portatil estaba reducido sólo a computar imágenes recibidas como respuesta y enviar entradas del usuario. Obviamente que varias preguntas vienen a la mente, más aún considerando que lo que se deseaba mostrar era el potencial de la conexión inalámbrica en uso; pero, aunque no con la misma forma, la idea está ahí.

Otras soluciones posibles, que se me ocurren en este momento (algunas las comente en artículos anteriores también), ya requieren de que la industria del software cambie paradigmas, métodos de diseño, desarrollo, programación e implementación. Esto desde las bases, es decir, el sistema operativo. Una de estas es el aprovechar mejor de todo lo que encierra el concepto de máquina virtual (como es el caso de Java). De tal manera que una aplicación puede ser desarrollada con las mismas ideas de hoy, en el lenguaje aceptado por esa MV optimizada para multi-core y que en su momento será esta última la que tendrá que ejecutar el código propiamente dicho usando al máximo el CPUmc presente en el equipo anfitrión.

Aunque sin MV, un ejemplo de como añadir un nivel de abstracción a ciertos procesos permite aprovechar mejor y más dinámicamente el hardware es la manera en que el producto SwiftShader de TransGaming ejecuta las llamadas a instrucciones DirectX sin utilizar el GPU. Lo que dependiendo como se mire puede ser una idea extraña, pero no hay dudas de que utiliza conceptos de programación muy interesantes y con gran potencial en otras áreas.

También una solución a nivel software, pero que en este caso requiere cierto nivel de cambio en como se diseña, desarrolla, programa e implementa, es separar aquellas librerías de funciones con potencial para el paralelismo y que las mismas sean compiladas en tiempo de instalación. Lo que esto permitiría, al menos en teoría, es optimizar al grupo de librerías en cuestión para el CPUmc presente en el equipo anfitrión. Esta idea podría no ser práctica para todo tipo de software, pero si para aquel de naturaleza compleja con gran potencial para ejecución concurrente de ciertas tareas, o hilos. Si todavía no lo imaginaron, este podría ser un buen mecanismo para hacer a los videojuegos más compatibles y escalables con multi-core. De forma natural cualquier videojuego tiene muchas tareas que pueden ser idóneas para la ejecución concurrente, ahí tenemos sistemas de física, IA, generación de animaciones dinámicas, componente simulación, incluso el engine gráfico con --o sin-- GPU, y un largo etcétera. Aquí hay mucho potencial para explorar y de decenas de maneras.

Una última idea que tengo formada en este momento, y que en cierta medida también es aplicada por el arriba nombrado SwiftShader es el uso de compilación en tiempo real. Esto viene a ser un siguiente paso, si se quiere, de la idea expuesta en el párrafo anterior. Lo dije en algún otro artículo, ahora lo que nos sobra son cíclos de procesador, así que la mal vista idea de compilar, o interpretar si se quiere, algo en tiempo de ejecución podría servir para aprovechar a presente y futuro de microarquitecturas multi-core (lo que por cierto, si somos estrictos, hasta podría ser visto como una contradicción del concepto de compilación).

De forma sencilla, compilar es agarrar las instrucciones humanamente entendibles de un lenguaje de programación, revisarlas, analizarlas, y de ser posible optimizarlas, para luego traducirlas a las microinstrucciones simples que entiende de forma directa un CPU (las famosas instrucciones x86 en este caso en particular) y unirlo todo, compilarlo, en un archivo ejecutable dado. Así la ejecución misma es más rápida y directa. Valga la pequeña nota salida por la tangente que los famosos archivos .com y .exe pertenecen sólo al mundo de Windows, para Unix, Linux e incluso el Mac OS cualquier archivo que se diga es binario ejecutable, puede ser visto como una aplicación o programa (sólo las adecuadas realmente ejecutan).

Compilar en tiempo real permitiría optimizar la ejecución de instrucciones, o tareas, que se puede enviar a un número n de núcleos presente en el CPUmc anfitrión --obviamente a aplicaciones debidamente diseñadas utilizando un hipotético lenguaje de programación (o una extensión a algo ya conocido y existente) capaz de ser optimizado para multi-core de forma escalable y dinámica--. Dependiendo el caso, la aplicación y el trabajo que se realiza éste concepto puede que no sea tan eficiente, o viable, como el uso de la idea previa con máquinas virtuales. Además que desde cierto punto de vista hasta podrían ser equivalentes, sólo que en el caso presente se tiene librerías que están en código de alto nivel que es optimizado y traducido en tiempo de ejecución para acomodarse mejor a entornos de hardware con un número de núcleos desconocido (o en todo caso que no se desea asumir para no limitar las posibilidades).

Lo que no hay que olvidar aquí, cualquiera sea la solución afin pero relacionada con software, es que no toda aplicación y mucho menos toda posible tarea se da para ser ejecutada en paralelo. Al menos no dentro lo que permite un CPUmc que es concurrencia física, verdadera y en tiempo real. Tampoco hay que dejar de lado las restricciones implícitas por periféricos de entrada/salida, o los procesos de acceso/escritura a memoria, GPU o discos duros. No es por nada que cuando se habla del tema se sabe que se está lidiando con un dilema de gran envergadura desde donde se le mire, y como se le mire.

Obviamente, parte del dilema es el factor negocio que existe entre líneas. Si el software que utilizamos en el día a día es incapaz de aprovechar de un número creciente de cores el cíclo de renovación del hardware, que por cierto se ha ido acelerando estos últimos 10 a 15 años, va sufrir una seria y brusca desaceleración durante los próximos cinco años, o menos, que podría afectar mucho a las empresas involucradas (y por extensión a la economía en general a nivel local y global).

Forzar ideas o funcionalidad como el reconocimiento de voz y el de escritura-a-mano puede sonar a una manera interesante de poner en uso cíclos de procesador que de otra forma no hacen nada, pero no es beneficioso, al menos no aún que su uso en la práctica es mínimo y poco eficiente.

Al parecer con los nuevos CPUmc de cuatro cores tanto Intel como AMD se han topado con un límite, una barrera (una reluctancia) a partir de la cual el usuario promedio se pregunta ¿para qué necesito más? Y ambas compañías, en conjunción con toda la industria (hardware y software), tienen que saber como responder bien a esa pregunta si no quieren estancarse en la efectividad de sus propios logros. Soluciones artificiales, y en cierta medida muy fáciles para ellos, hay muchas más que prácticas y realistas que benefician a todos. Esperemos sepan poner las mentes y hombros en obtener aquellas que van más allá de sólo mantenerlos funcionando.

Sobre el tema tratado en este artículo y sus ramificaciones hay mucho, pero mucho más para decir. En estos momentos la industria está llena de señales que dependiendo como se las mira van por buen camino, o dan indicios de que se está por dar el giro al malo. Podría seguir y seguir, pero prefiero dar el punto final aquí. La industria tiene mucho que pensar ahora y lamentablemente en su afán de no quedar atrás de la competencia podrían dejarnos a todos rezagados y darse cuenta muy tarde. Confiemos que no.

( - de -) SIGUIENTE >>
Sobre J de Juegos | Información Copyright | Contacto [ 11/Julio/2008 ]