Como usuarios finales con lo que más lidiamos en un entorno PC es el software, se le denomine aplicación o programa. Sea con fines de trabajo o de ocio, sea editando un texto simple en el NotePad o el WordPad o dando los toques finales a un libro de mil páginas en el Adobe InDesign. Software es software y mientras funcione correctamente porque o cómo lo hace nos es irrelevante, pero debería.

A la par con diseños de ingeniería de alto nivel, estructuras arquitectónicas de grandes dimensiones y proyectos multidiciplinarios de envergadura el desarrollo de software está entre lo más sofisticado, avanzado y complicado que existe en nuestro tiempo. Ver y utilizar el resultado final nos hace insensibles para con el trabajo subyacente que consta de cientos de miles cuando no millones de líneas de código; esto, claro, a menos que aparezca un bug y nos devuelva a la cruda realidad del asunto.

Como suele suceder con muchos procesos creativos cuyo elemento tangible es mínimo (cuando no nulo), el software es algo en nuestras vidas que damos prácticamente por sentado. Su importancia se escapa cuando estamos escribiendo frente a un monitor y las letras aparecen una tras de otra, o cuando estamos moviendo el ratón con la mayor agilidad posible para derribar oponentes virtuales. Nos olvidamos que es software lo que controla en gran medida el flujo de aviones en el aire, software el que controla su vuelo y sus instrumentos, software el que ayuda al análisis de las imágenes de un cat scan. Software es el elemeno que nos permite usar, entender y trabajar con el hardware. Una burda analogía es decir que software es el lenguaje de las máquinas, y como todos bien sabemos es el lenguaje el que nos permite transmitir y recibir información con el objetivo final de comprender algo.

En términos computacionales software es el componente dinámico y programable que nos permite controlar al componente estático que es el hardware. Todo CPU es un procesador de propósito general, su microarquitectura incluye instrucciones elementales la combinación adecuada de las cuales permite extender y diversificar sus capacidades. La velocidad a la que estas instrucciones, conocidas en el mundo de la programación como Assembler, son ejecutadas (millónes por segundo) permite que a vista del usuario las cosas transcurran de manera instantánea.

Desde que Intel saca al mercado sus primeros CPU 8086/8087 y luego IBM diseña y presenta al consumidor la primera PC, y no mucho después Apple aparece con su Macintosh y Microsoft con su sistema operativo MS-DOS las cosas han cambiado poco en el mundo del software. Si bien los paradigmas de programación han evolucionado, de los por función y proceso a los por objetos, el concepto intrínseco sobre el que existen ha permanecido casi sin alteraciones.

La evolución continua y líneal de los procesadores hasta hace un par de años ha causado que el desarrollo de software no requiera explorar nuevos horizontes (al menos no fuera de laboratorios o universidades). La imparable necesidad de continuar desarrollando sin dar tiempo a mirar atrás ni mirar adelante ha empezado a demostrar que luego de poco más de un cuarto de siglo el software se está quedando atrás del hardware, y éste no tiene la más mínima intención de esperar o desacelerar, más bien todo lo contrario.

Más allá de los increíbles beneficios y facilidades que ofrece el actual paradigma orientado a objetos (POO) que se utiliza en la programación de software, en sus inicios este venía con un notable defecto: incrementaba el tamaño final del ejecutable al igual que su necesidad de cíclos de procesador. Por suerte la evolución de los CPU permitió un aumento en el número de cíclos por segundo lo que hizo de este problemilla algo transitorio.

Llego un punto en el cual un procesador resultaba tan rápido que por la lentitud relativa de otros componentes --como acceso a disco, detección de teclado o mouse, lectura/escritura a memoria-- se veía ante el inevitable caso en que estaba sin hacer nada, ocioso, el estado idle. Para combatir esto y así aprovechar más y mejor los cíclos de procesador nacieron los sistemas operativo capaces de manejar multitarea, y poco después el concepto de hilo (thread of execution) y la ejecución multihilo también entran en escena.

Aunque son similares multitarea y multihilo son un concepto afin en dos contextos totalmente diferentes. Multitarea significa tener trabajando a más de un programa, lo que desde el punto de vista del usuario común siempre es algo transparente cuando no irrelevante. Hilo/multihilo es una técnica de programación que permite a un programa (o aplicación) trabajar más rápido aprovechando aquellos momentos en que un hiloA está esperando por entrada de usuario o periféricos lo que permite a un hiloB usar tiempo de procesador. Por regla general --hoy-- todo sistema operativo multitarea es multihilo porque cada aplicación en ejecución es considerada un hilo de ejecución, lo inverso no es cierto. Cuando cada aplicación puede a su vez crear hilos ya se habla de ambientes multihilo.

Cuando hablamos de sistemas operativos multitarea, ejecución multihilo, y caemos en que resulta que nuestro CPU sólo posee una única cola de ejecución, nace la pregunta ¿y como parece que todo ocurre de manera simultánea? El secreto es la velocidad de ese solitario CPU y sofisticados algoritmos de asignación de tiempo que existen en el SO pero que son transparentes para el usuario. Estos schedulers toman en cuenta prioridad de la aplicación, número de programas en ejecución, disponibilidad de cíclos y hasta interrupciones para mantener la sensación de que todo ocurre a la vez. Cuando por algún motivo un programa falla es que este falso paralelismo, o ejecución concurrente virtual, pierde su antifaz.

El primer Windows poseeía un mal esquema de control de aplicaciones y asignación de tiempos, cualquier programa que fallará afectaba al resto, su capacidad para recuperarse de errores era malísma. En comparación Windows 95 era toda una revelación, se podía tener varios programas funcionando con apenas problemas; era viable escuchar música y trabajar sin que la primera suene a los saltos. Windows 98 y Windows XP mejoran sobre sus puntos fuertes pero tampoco mucho más, sobre Windows Vista todavía me reservo la opinión.

Sistemas operativos alternativos como Linux, basado en Unix, poseen mecanismos de control de tareas y programas mucho más efectivos y mucho más eficientes. Esto se debe en gran parte a diseños más modulares y una mentalidad multiusuario y multitarea (y multihilo) que se maneja desde los componentes elementales hasta los más avanzados. Multiusuario en éste contexto sólo quiere decir que un mismo equipo puede atender las necesidades de procesador y periféricos de más de un usuario simultáneamente. Esto aprovechando velocidades de CPU y algoritmos mejorados de asignación de cíclos y control.

Puesto de la manera más simple posible, en un entorno multiusuario cada nuevo usuario es visto como un hilo de ejecución independiente y cada programa o tarea que ejecuta como un (sub)hilo de la misma. Entonces el sistema operativo sólo tiene que asignar apropiadamente tiempo de ejecución a cada usuario y tiempo de ejecución para sus tareas[1]. Este esquema es aprovechado por sistemas operativos compatibles para, cuando presente(s), utilizar entornos multi-CPU para relegar hilos/usuario e hilos/tarea a otros procesadores y así mantener al máximo posible ocupado un máximo de tiempo evitando que estén en estado ocioso. Por ejemplo, un estado ideal es dos CPU, dos usuarios, un usuario por CPU, todo controlado por el sistema operativo (si por ejemplo un CPU dejara de funcionar ninguno de los usuarios debería notar cambio alguno en el ritmo en que se ejecutan sus tareas, a menos que alguna sea muy pesada).

Antes de que la Internet esté al alcance del usuario promedio o que las redes locales sean algo común, la idea de multiusuario estaba normalmente relegada a centros de computo de universidades o instituciones donde se tenía un servidor de gran poder y capacidad, al cual se conectaban decenas de terminales tontas (sólo teclado y pantalla, luego mouse más). Cuando el equipo cliente deja de ser una terminal tonta es que se empieza a hablar con mayor frecuencia del concepto de aplicaciones cliente/servidor. Ejemplos son los navegadores (Firefox, Netscape, Internet Explorer), gestores de correo electrónico (Outlook Express), sistemas de chat y juegos masivos multiusuario.

Un aspecto interesante de la lógica multiusuario es que a pesar de todo se sigue trabajando con una mentalidad lineal en cuanto a la ejecución misma del software. Una vez más, el concepto de hilo en programación permite aprovechar de tiempo ocioso de un procesador y en condiciones controladas hasta dar la sensación de ejecución simultánea en tiempo real. Obviamente no hay que quitar la relevancia del hecho de que como usuarios, y más si se cae en la categoría de usuario común, la cantidad de programas en tiempo real con los que nos topamos está reducida a los videojuegos. Ver vídeos y escuchar música son casos especiales de tiempo real, y con la excepción de cuando se trata de algo de extrema muy alta calidad y se está haciendo otras cosas, cualquier procesador de los últimos 10 años los ejecuta sin problema alguno.

Ahora, ¿a qué viene todo esto? Todo lo precedente permite establecer dos hechos: (1) para lo que califica como consumidor común el software comercial no posee capacidades reales para ejecución concurrente en tiempo real, (2) para el más de los usuarios (quizá hasta se puede especular que un 99,9% de la población mundial con ordenador) el único momento en que se requiere tiempo real es con el software de entretenimiento electrónico. Esto permite notar algo muy interesante en la industria del hardware, su movida hacia arquitecturas multi-core aunque necesaria y seguro innevitable agarro, por decirlo así, a la industria del software con los pantalones abajo.

No hay que ser ningún especialista para notar que en cuanto salen al mercado los primeros procesadores multi-core, como los Pentium-D, no había programa alguno que agradeció el segundo núcleo de procesador. El sistema operativo podía jugar con la presencia de más de un core para asignarle tareas pero esto no quiere decir que un programa (aún con varios hilos) haya estado usando los cíclos adicionales de procesador. Bastaba con ver los diagramas del Administrador de Tareas, dos CPU pero sólo uno parecía trabajar el más de las veces. Ahora que estamos ya acostumbrados a tener dos núcleos y el movimiento a cuatro o más está casi asegurado seguimos con que el software comercial de uso general capaz de explotar ejecución concurrente real es escaso, por no decir casi inexistente.

Más de un especialista, programador y analista asegura que la industria del software está ante una revolución, quizá una evolución, y si somos sinceros una que le fue forzada. Al punto que tanto Intel como AMD ofrecen en sus sitios Web archivos F.A.Q., documentos, blogs, foros para ayudar a la comunidad desarrolladora a ver, aprender y entender la mejor manera de diseñar sus productos para que puedan aprovechar de la nueva generación de CPU.

Aquí, una vez más, hay que destacar dos hechos sumamente importantes y relevantes a los que el más de la gente parece no estar prestando la suficiente atención (aunque si somos sinceros, tampoco tiene porque hacerlo). (1) Cualquiera el paradigma de programación --actual o futuro-- todo software --con contadas excepciones-- posee un límite a partir del cual los beneficios de la ejecución concurrente se ven opacados por la complicación de su codificación y mantenimiento; (2) a medida que aumentan el número de núcleos y con tecnologías adicionales que permite a cada uno ejecutar dos o más hilos de forma simultánea el número de cíclos de procesador, y por ende la capacidad total de procesamiento, se incrementa de forma exponencial, ya no líneal como cuando sólo aumentaba la velocidad del CPU.

Para el siguiente ejemplo pongamos las cosas en claro: 1 Hz (un hercio) es un cíclo por segundo que simplificando[2] al máximo implicaría una microinstrucción por segundo. 1 GHz es igual a 1.000'000.000 (mil millones de hercios o instrucciones). En notación científica esto es 1 GHz = 1xE9 hercios (un uno seguido de nueve ceros). Ahora si el ejemplo. Un CPU a, por decir algo, 3,0 GHz, ejecuta 3xE9 microinstrucciones por segundo. Si incremento su velocidad a 3,5 GHz hablamos de 3,5xE9 lo que no es un incremento muy wow que digamos y hoy por hoy el más de este tiempo está siendo consumido por la instrucción nula de tiempo ocioso. Si tengo dos núcleos, aunque sea a 1 GHz hablamos de 2xE9 instrucciones por segundo, lo que se puede inclusive duplicar gracias a tecnologicas como el Hyper Threading, es decir, 4xE9. En promedio los multi-core dobles actuales rondan los 3,0 GHZ por núcleo, con capacidad de ejecutar dos hilos por cíclo cada núcleo, son 12xE9. No hay que ser un matemático para entender que con cuatro hablamos de 3,0 GHz x 4 cores = 3xE9 x 2 x 4. A medida que incrementan los núcleos el incremento es exponencial, por mil millones cada vez, ya no por simple aumento de la velocidad.

Siguendo con la simplificación precedente el último prototipo funcional de Intel posee 80 núcleos, asumamos 3,0 GHz, dos hilos por núcleo, hablamos de 480xE9 (o 480.000'000.000) instrucciones por ¡segundo!. Gracias a optimizaciones en su arquitectura y afines este prototipo es en la práctica capaz de ejcutar un Tera FLOPS, o 1xE12, o 1'.000.000'000.000 instrucciones. En este punto lo más fascinante, algo exagerado, y que insisto muy poca gente en verdad está captando es que este tipo de poder de procesamiento estará en nuestras casas, nuestra PC para, según estimados de Intel, antes del 2015. Hablar de las escalas que vienen después del Tera, como Peta, Exa o Zetta FLOPS (1xE15, 1xE18 y 1xE21 rerspectivamente) es equivalente a ponerse a pensar en las escalas de distancia que se utiliza aprovechando de aquella que recorre la luz en un segundo, con la diferencia que en términos de poder de procesamiento es algo que todos, o casi, muy pronto podremos tener sentado sobre el escritorio y consumiendo menos electricidad que un foco corriente. Una súper computadora en cada hogar..

Retomando el tema del software. Con tal poder de procesamiento el software común, las aplicaciones estándar, consumen tanto cíclo de procesador como nuestros viajes a la Luna años luz de distancia. Es decir, prácticamente nada. Donde la comunidad programadora está encontrando bastantes problemas es en diseñar programas que hoy aprovechan de arquitecturas con dos núcleos pero que mañana pueden ser capaces de rendir mejor con cuatro u ocho. En tests oficiales incluso videojuegos de avanzada del estilo de Crysis utilizan bien dos cores pero no se nota mejora real con cuatro.

Lo último que se tiene sobre el Engine Source 2 de Valve era que sería compatible con Core2 Quad pero esto ciertamente no asegura que lo será con las versiones de 8 o 16 núcleos del Nehalem o Sandy Bridge. Si bien es bueno que exista más poder de procesamiento, al menos para videojuegos, la forma en que este se hace disponible complica mucho la vida a los desarrolladores. Pensar, trabajar, diseñar, programar para ejecución concurrente en tiempo real no es algo que venga de forma natural actualmente, y el futuro no está regado de rosas.

En una movida estratégica que otorgue a sus nuevas arquitecturas utilidad desde el punto de vista de los usuarios tanto Intel como AMD andan promocionando, quizá un tanto artificialmente, conceptos como el reconocimiento de voz, reconocimiento facial, reconociemiento de la escritura a mano, algoritmos de búsqueda sofisticados, etcétera. Claro que para el usuario común lo interesante lo están pensando y desarrollando en la industria del software del entretenimiento. Con menos lugar donde crecer en el mundo del foto realismo no les queda otra que enfocarse en el mundo del realismo visual. Mejor animación, IA más sofisticada, uso de simulación para tareas antes trabajadas de forma (semi)estática, simulación física, etcétera.

Por suerte, y a pesar de todo, la industria del software todavía tiene un buen grupo de ases bajo la manga, aunque tendrán que ser re-estudiados a fondo para poder así explotarlos mejor en este mundo donde lo que sobra son cíclos de procesador. Cuando se explora Internet sobre el tema lo que aparece una y otra vez son los conceptos que rodean a las máquinas virtuales (cuyo mejor ejemplo hoy es el entorno Java), y los compiladores e interpretes en tiempo real (idea explotada en el SwiftAsm que es parte de la tecnología que hace posible al SwiftShader). Hay muchos más pero estos son los que destacan.

La idea básica detrás de una máquina virtual es crear un entorno mejor controlado para un software específico que hace aún más transparente al mismo el acceso al hardware subyacente[3]. Una forma algo burda de ver a un MV es como un computador en software que ejecuta dentro un computador de hardware. La mayor ventaja de este entorno, tomando al Java como ejemplo, es permitir al programador trabajar como está acostumbrado, incluso con un enfoque lineal, pero al momento de la ejecución o compilación por la MV su código es optimizado de tal manera que se aprovecha el hardware subyacente al máximo. Esta idea tiene la desventaja de consumir cíclos de procesador adicionales algo relevante años atrás pero que ahora no significa gran cosa, de hecho sería uno de los puntos fuertes detrás el producto de TransGaming Inc..

El mismo argumento de que ahora lo que sobra es poder de procesador se puede utilizar para el uso de compiladores o interpretes dinámicos. Lo que hace un compilador es agarrar el código en un lenguaje de programación específico y transformarlo en las microinstrucciones que el hardware entiende de forma directa. Esto acelera el tiempo de ejecución y por ende optimiza el uso del CPU.

Uno de los conceptos de las MV es que en principio no compilan el código sino que lo interpretan, esto significa lo ejecutan en tiempo real, el detalle es (en realidad era) que hace su ejecución más lenta porque se requiere al CPU primero para convertir código-fuente en instrucciones-hardware y luego ejecutar esto último. En su momento el Java resultaba muy lento hasta que salen los compiladores JIT (Just in Time Compiler) que no hacen otra cosa que compilar Java al denominado bytecode, que viene a ser el conjunto de instrucciones que entiende directamente la máquina virtual de Java.

Actualmente es tema de preocupación como código para ejecutar en un entorno de dos núcleos no puede ser nativamente diseñado para aprovechar de cuatro u ocho[4]. Al menos no sin perder tanto tiempo que ya están disponibles los de 32 o 64. Es por esto, entre otros motivos, que uno de los conceptos de programación que se está buscando hoy en día es uno que posee la capacidad de aprovechar dinámicamente de nuevos núcleos sin que para ello se requiera lanzar patches, nuevas versiones, o diseñarlo sólo para un número mínimo y máximo de núcleos. Aquí se sabe que aún cuando se descubra este concepto no podrá aplicarse a todo programa ni ser eficiente a partir de cierto número de núcleos (esto por el límite intrínseco al diseño de software descrito previamente); aunque hay campo para sorpresas.

Los videojuegos tienen la gran ventaja, en relación a software tradicional, de que poseen un buen número de áreas que se pueden beneficiar de un incremento dinámico de núcleos de ejecución. Como bien lo demuestran los GPU y sus arquitecturas altamente paralelas. El detalle en estos momentos es como unir aquel componente que no puede aprovechar de más y más núcleos y mantenerlo en sincronización con el que si puede, sin romperse el cerebro diseñando algo viable ni haciendo que diferentes usuarios reciben una experiencia distinta del mismo producto.

Es dentro el anterior escenario que ingresa el tema del Ray Tracing y sobre el cual también puede evolucionar la tecnología de renderizado actual --pero, en principio, dejando atrás al GPU como hardware extra necesario--. Dejando de lado los por menores internos y de implementación el método de renderizado por Ray Tracing posee la ventaja de que puede mejorar y evolucionar en paralelo a un incremento de núcleos de ejecución, esto porque la idea básica que maneja es el seguimiento de rayos de luz (que no son otra cosa que vectores) de un punto a otro a lo largo de un espacio tridimensional donde rebota, refracta, refleja u otro. A más núcleos más rayos pueden ser calculados de manera simultánea. El debate actual se centra sobre que este método posee escasa investigación en su viabilidad en tiempo real, porque para renderizar escenas estáticas es indiscutiblemente bueno (esta técnica se utiliza para animaciones y películas animadas por ordenador).

La otra cara del debate alrededor del método Ray Tracing es que por su naturaleza no requiere de núcleos de procesamiento especiales como es el caso del metodo actual que utiliza stream processors[5]. En otras palabras, si RT se viabiliza como un método práctico de ofrecer al videojugador (u otro que utilice renderizado 3D en tiempo real) la necesidad de una tarjeta de aceleración gráfica empezaría a disminuir o tendrían que buscar un otro uso. Lo más interesante y contradictorio de todo el dilema y debate es que al final los stream processors no son otra cosa que núcleos de procesamiento con instrucciones afines a los números reales, y tanto ATI como Nvidia han demostrado que son capaces de ser programados para realizar otra cosa que sólo procesar imágenes. De aquí también deriva el que en un futuro inmediato el método de RT podría inclusive ser aprovechado para aquellos efectos que son su fuerte (refracción y reflejo) creando así un sistema gráfico híbrido que puede muy bien aprovechar de la presencia de un GPU avanzado como de un CPU con muchos núcleos[6].

Lo opuesto también funciona, es decir, llegado el momento un CPU de muchos núcleos con un par de ellos específicos para funciones particulares podría sin problemas lidiar con un engine gráfico de los actuales sin que la presencia de un GPU sea indispensable. Cuando hablamos de una capacidad de ejecución que ronda el millón de millónes de instrucciones por segundo, cientos de miles más o menos realmente es nada. Lo que se tiene que tener en mente de todo esto es que cualquiera el método de renderizado el mismo está entre los componentes de un videojuego que tienen la capacidad, y el potencial, de aprovechar dinámicamente de un incremento en núcleos de procesamiento. Ahora todo gira alrededor de obtener uno que pueda hacerlo sin que sea relevante la presencia de dos, cuatro, 16 o 128 núcleos. Claro que con todos los componentes que hacen a un videojuego más allá de aquel que presenta la imagen existe bastante campo para crecer.

Es obvio que la industria del software está ante la necesidad de evolucionar, mejor si revolucionar, el único aspecto en contra es toda la mentalidad de producto desechable que le rodea, precede y persigue. Si nada más esto reduce drásticamente la necesidad de diseñar algo para que funcione --sin grandes problemas-- dos o cinco años después de su salida al mercado. Esto puede verse inclusive ahora en la manera que productos de hace dos o tres años utilizan un único core, y los productos del año pasado y éste apenas si hacen trabajar a dos núcleos. Habrá que ver si la lógica comercial de hoy, de adquirir un nuevo procesador cada par de años, se convierte en innecesaria[7] y logra que la visión extremadamente mercantilista que maneja la industria se desacelera un poco o cambia su modelo actual. Al menos en la industria del software del entretenimiento veremos más que suficiente avance y novedades.

Notas

[1] Debido a que los usuarios se conectan y desconectan los sistemas de gestión de tareas y asignación de cíclos de procesador son dinámicos, también son capaces de botar a usuarios que actúan como desconectados para recuperar recursos, el famoso timeout. Así mismo son capaces de evitar que cualquier error o problema de un usuario afecte al resto, aunque no siempre.

[2] Digo simplificando al máximo porque la equivalencia (un hercio = una instrucción) no es cierta más que en condiciones ideales. Esto debido a que las microinstrucciones son realmente elementales y en general se requieren entre un par y decenas de ellas para realizar cosas simples como pintar un pixel en pantalla, sumar dos números, grabar y leer de disco, leer y escribir a una posición de memoria, etcétera. Es por este motivo que cuando se quiere destacar una gran capacidad de procesamiento se habla de FLOPS (operaciones de punto flotante por segundo), que son más sofisticadas y usualmente consisten en encadenar varias instrucciones sencillas, a menos que se trate de hardware específico.

[3] Uno de los objetivos de todo sistema operativo es permitir que el software que se ejecuta sobre el no tenga que preocuparse de los detalles específicos del hardware subyacente. Es decir, la aplicación se preocupa de escribir y leer datos del disco duro, no si se trata de un modelo de IBM o de Maxtor; se dedica a imprimir sin que le interese el modelo exacto de la impresora. Este proceso se conoce como abstracción del nivel de hardware, y es una de las ideas cruciales que llevaron al nacimiento de la PC como tal.

[4] Este tema es con seguridad uno de los más cruciales de nuestro siglo en relación a desarrollo de programación de software, sería prácticamente equivalente al Santo Grial en la industria encontrar algoritmos y/o sistemas operativos y/o máquinas virtuales escalables. Es decir, que son capaces de operar y aprovechar al máximo 2, 4, 8, u N núcleos sin por ello requerir altearciones notables, si alguna, en el código fuente/base. Una analogía burda sería encontrar un tipo de motor de auto que funcione con cualquier tipo de combustible que esté disponible sin alterarlo.

[5] Esto discutible porque los stream processors nacen precisamente como componente hardware que acelera el computo de tareas afines al renderizado. De igual forma podriamos hoy contar con rt processors si Ray Tracing se hubiera convertido en el método elegido al momento de entrar en la Era de los sistemas gráficos 3D.

[6] La imagen se pondrá menos borrosa sobre cómo se pinta el futuro una vez ATI y Nvidia presenten su siguiente generación de tarjetas gráficas en las que veremos hacia donde apuntan con su tecnología en pos de sobrevivir y seguir en el mercado. También ayudará a aclarar las cosas el momento en que Intel revele más información sobre su proyecto Larrabee.

[7] Al fin de cuentas no hay software que sepa aprovechar al 100%, o siquiera un 60%-70%, de cuatro núcleos, los podemos esperar dentro de una generación, hablando de videojuegos esto implica entre 2 a 5 años. Esto a su vez significaría saltarse dos Tick y un Tock según el esquema de evolución de Intel (Tick = nuevo proceso de fabricación, Tock = nueva arquitectura). Es decir, adquirir nueva tecnología en un Tock, saltar el siguiente Tick, Tock, Tick y repetir, lo que es equivalente a unos 3 años entre compras.

Artículos y Material de Referencia/Biografía

Artículos afines al tema expuesto encontrados en la Wikipedia(com) - Lenguajes de Programación, Máquinas Virtuales, Paradigmas de Programación, Thread (en Computación), .