Nos ponemos en situación. Cerrad los ojitos y viajad al pasado. 30 añitos solamente. Ni nos imaginábamos Internet, y éramos esclavos de los 8 bits. Los procesadores de aquellas primeras generaciones solían tener una frecuencia de reloj de 1 MHz. Repito. 1 MHz. Avancemos un poco. Abril de 1982. Sinclair Research presenta su ZX Spectrum, con un «potente» procesador Z80 a 3,5 MHz y 48 kB de memoria (aunque el primero tuvo en realidad 16 kB). No había multithreading, ni arquitecturas superescalares. Si una instrucción tardaba 5 ciclos en ejecutarse, eran 5 ciclos. Aquella máquina, que para los estándares actuales es ridícula, demostró algo prodigioso: que con 3,5 MHz de potencia y 48 «kas» se podían lograr juegos increíbles con una fluidez brutal.
Evidentemente el ZX Spectrum 48K tenía limitaciones importantes: su resolución (256×192 píxeles) y sus 4 bits de color (una paleta con 7 colores y dos brillos para cada color, excepto el negro) ofrecían todo un desafío a los desarrolladores de videojuegos, que no obstante alegraron la vida a millones de niños. Yo entre ellos, aunque nunca tuve uno, porque pude presumir de tener un C64, mucho mejor :). Aquellos programadores se sacaban rutinas de la chistera que permitían hacer cosas asombrosas en esa «castaña» de procesador y con esa «castaña» de memoria. Los ejemplos son casi inacabables.
Y seguimos avanzando: 10 años más. Estamos en la época dorada de mi adorado Amiga 1200, recién lanzado y superior en arquitectura y sobre todo en prestaciones de su sistema operativo (con multitarea real) a cualquier PC de la época. Y desde luego, a cualquier Mac, salvo en apartados muy, muy específicos -que alguno me intente discutir esto-. Los juegos para aquella máquina marcaron una época. Y de nuevo, todo fue gracias a aquellos programadores que sacaron todo el jugo a un procesador y a unos chips gráficos y de sonido que tenían muchas limitaciones. Más ejemplos inacabables.
Sigamos viajando en el tiempo.
Otro empujón hacia delante. Estamos en 2012. Ya podéis abrir los ojos. Tenemos micros quad-core con frecuencias de reloj de más de 3 GHz, configuraciones en las que lo normal es contar con 6 u 8 Gbytes de memoria RAM, GPUs que superan en potencia bruta a esas CPUs en varios órdenes de magnitud y sistemas de almacenamiento que nos ofrecen velocidades de transferencia de 400 o 500 Mbytes por segundo.
Pero lo más grave no es eso. Esos procesadores quad-core, esas GPUs y esas memorias de alta gama están disponibles en nuestros flipantes smartphones y nuestros molones tablets. Que por supuesto, hacen cosas muy chulas y que molan un montón para presumir delante de los amigotes. El efecto zoom del iPad cuando uno entra o sale de carpetas de fotos y luego hace zoom en ellas, la fluidez del desplazamiento de las pantallas con iconos o con texto e imágenes, e incluso lo «follao» que van el Call of Duty o el Need for Speed Shift. Cómo mola. Y qué rápido va todo, ¿eh?
Mi pregunta es: ¿cómo coño no van a ir rápido con esos maquinones detrás? ¿Por qué nos asombramos tanto de las cosas que puede hacer un iPad o un Samsung Galaxy Nexus?
Precisamente lo que no es normal es que con esas configuraciones hardware haya muchas cosas que vayan tiradas. Abrir varias pestañas en un navegador o tener varias aplicaciones abiertas en un móvil es sinónimo de problemas en la mayoría de los casos, y es algo que por muchas flores que se le puedan echar a Android o a iOS no acabo de entender.
Porque si hay una cosa clara en el segmento tecnológico hoy en día es esta: que los desarrollos software están muy por detrás del hardware actual. Mirad la carga de vuestros procesadores en prácticamente cualquier momento, y preguntaos porqué seguimos buscando micros y gráficas más potentes, cuando la mayor parte del tiempo las vamos a tener infrautilizadas, sobre todo en informática de sobremesa.
¿Se han vuelto comodones los desarrolladores? ¿Se dirán a sí mismos aquello de «bueno, podría intentar que fuera más eficiente, pero con subir los requisitos ya me justificaré»? Seguro que hay de todo, pero esta reflexión sobre la que ya comentaba algo hace tiempo y que también aparecía en posts muy buenos como este no deja de ser cada vez más una cuestión que genera muchas, muchas, muchas dudas.
Muy interesante Javi. Te voy a hacer una reflexión. Intenta que un programa cualquiera en Windows se ejecute con un uso de CPU del 70%. Haz lo propio en un UNIX. Seguro que notas la mejora, pero sigue siendo ineficiente la manera en que los sistemas operativos adjudican los recursos. Un sistema no debería verse afectado en el rendimiento de la CPU si esta no alcanza el 100%, pero eso es solo en teoría. El sistema operativo emplea muchos ciclos en realizar los cambios de contexto y estos se multiplican con cada grado de paralelismo de las tareas. Con los procesadores multicore hemos multiplicado las UAL, incluso los registros… pero solo hay un bus para acceder a la memoria o a otros recursos externos y por el que compiten los cores. Con las memorias modernas de acceso multipuerta algo se mejoró en el grado de paralelismo pero el cuello de botella sigue estando ahí.
Por que si no los servidores se basan en varios sockets? Porque pueden multiplicar los buses, los accesos a memoria si cada socket controla sus módulos de memoria. Aunque estén todos conectados y compartidos, cuanto mejor se gestione desde el sistema operativo donde se alojan los programas físicamente en memoria y que socket los ejecuta, mejor aprovechamos el hardware.
El problema es que los programadores rara vez piensan en los demás programas, solo en el suyo. Y algunos sistemas operativos no ponen condiciones a los programas para ejecutarse en entornos multitarea, así que muchas veces no es problema del programa que va lento sino de que los recursos que necesita los esta ocupando otro. Y en un móvil esto es importante porque normalmente solo tenemos una aplicación en modo interactivo y el resto en segundo plano. Y queremos que hagan cosas como las hacen los PCs sin que sean la mitad de potentes que son estos.
Hoy va de historietas….
Lo primero que hay que tener cuidado es con los flashback sobre articulos tecnologicos. A mi me ha pasado tres veces. Soy de spectrum y de este pase a pc (amstrad 1640), siempre babeando por el comodores 64, el comodore Amiga 500 de algunas amistades, con su motorola con arquitectura ¿Harward?, con su procesadores especializados y los apple… Pasa el tiempo y tengo mi pc con vga, se me presenta la oportunidad de comprar un maravilloso amiga 500 de segunda mano, lo compro y ¡opssss!, ¿que paso aqui?, es verdad que sigue moviendo los graficos como un diablo, pero esto ya no es tan maravilloso como yo recordaba, no hay tantos colores en movimiento, sencillamente mi pc moderno era un buen trasto pero igual que los otros que existian, no habia nada en pcs que significara un salto bestial frente al mio, bueno si, las sgi y tal, pero eso era inalcanzable. Pasa el tiempo, tengo mi amd 1800 con mi nvidia fx5200, se me presenta la oportunidad de adquirir una sgi octane, con su risc (175 mhz) y su supergraficos opengl, y ¿que paso?, pues si, la maquina es sorprendente, que sus buses, que en realidad son switch son una maravilla, que su opengl es sorprendente, pero que el pc se la lleva de calle, eso si la sgi se relentiza pero suavemente, sin tirones, despues compre un 400 mhz y al final una octane 2 con graficos v6, solo por capricho, pero no, las maquinas antiguas no son ninguna maravilla, ¿que hacen cosas increibles?, no, hacen lo que corresponde a sus caracteristicas y las de hoy hacen lo que corresponde a sus caracteristicas. Para acabar hace un par de años enrede con un apple LC (lc, como yo 🙂 y con un mackintosh de los de pantalla de ¿7? pulgadas, no pretendia comparar nada, pero vamos el system ¿6.5? era como de juquete, vamos que el windows 3.1 hacia mas, peor hecho, eso si, pero mas. Asi que cuidadito con los flashback.
En cuanto a los programadores, te referiras a los de sistemas operativos, porque los de aplicaciones no se que van a hacer, si no se puede acceder al hard, e incluso los de sistemas puede que no puedan hacer mas si les dan las entradas y las salidas, no mas, los cambios de contextos, fallos de pagina y demas esta todo en el hard. En los tiempos de la vga y msdos se podia hacer algunas cosillas, ¿modo x? o algun ciclo que te ahorrabas en ensamblador por hacer alguna genialidad, pero hoy, «na de na», Ademas en el tiempo que piensas la genialidad te sacan un procesador generico o un procesador de grafico que te saca un 500% a tu genialidad, que no, que esto no es como el spectrum.
De todos modos lo que hace un pc de hoy en dia es impresionante y un ipad 2 mas, verdad que hay algun cuello de botella, yo diria que el principal, el disco duro, porque como la memoria de tu aplicacion puede estar paginada en un fichero en memoria porque tienes muuuuchas cosas funcionando en el ordenador o porque hace tiempo que tu aplicacion esta en reposo, porque todo el mundo usa una base de datos en disco duro para guardar cualquier chorrada, eso de las estructuras de datos casi no se lleva,…. en fin, que no, que nada es como antes en programacion, asi que comparar es imposible.
No sigo que aburro…
No sé si he buscado bien, pero creo que el Z80 (microprocesador del Spectrum) contaba con 252 instrucciones nativas (en ensamblador, de las que se ejectuan por hardware.
El basic del spectrum no sé con cuántas contaba, pero creo que no más de 100.
Un x86, cualquiera cuenta con sus intrucciones nativas (no sé exactamente cuántas son ahora mismo, pero unas cuantas) si pasamos a los 386 DX y 486 DX y sucesivos, contaban con coprocesador matemáticos, el cual añadía otro juego de instrucciones más para operaciones de coma flotante, en los 386 y 486 SX se podría meter un 387 o 487 (que eran los copros físicos, los DX estaban integrados en el mismo procesador)
El pentium no aportó mucho en este ámbito hasta que aparecieron los MMX, que implementaban por hardware las 57 (creo recordar) nuevas instrucciones multimedia, (solo una de las MMX podía sustituir a más de 200 de las X86 estándar.
AMD sacó las 3DNow!, luego vinieron SSE, SSE2, SSE3, SSE4 y SSE5. Cada cual con sus más y sus menos, las SSE5 creo que no se llegan a usar, y se propone en su lugar las AVX o algo así, es un pedazo de lío.
SOLO para el procesador, cuántas instrucciones nativas tenemos? Un cojón.
Pasamos a las gráficas? Pues otro tanto de instrucciones.
Para aprovechar bien todo este hardware tan potente, necesitamos muuuuuchas instrucciones no nativas que hagan las llamadas pertinentes, unos compiladores muy bien hechos, muchas librerías intermedias para ir haciendo el acceso al hardware más sencillo para un programador que tiene que estar también preocupándose por la lógica del juego, la limpieza del código, el ahorro de memoria y sus leaks, la herencia, el polimorfismo, y un largo etc de cosas. Al final, emplear a fondo un ordenador y sacarle todo el jugo es TERRIBLEMENTE complicado. Y hay muuuuchas capas de por medio para facilitar las cosas (sería completamente imposible currarse un juego decente programando en ensamblador!!) que pueden ir metiendo lags.
Hacer un juego en spectrum es terriblemente sencillo, apenas tiene 4 cosas en las que nos tenemos que fijar, hay un solo intérprete entre el basic en el que lo programamos y el ensamblador que se ejecuta en el microprocesador, es muy difícil cagarla en algún sitio y no darnos cuenta o que poco a poco se vaya llenando la memoria y vaya bajando el rendimiento, por ejemplo.
Por otro lado, cuando los gráficos eran muy malos, una pequeña mejora, se notaba un cojón. Hoy en día (y ya desde hace bastantes años) una mejora apenas se nota.
Os propongo una prueba:
Cogéis un juego, por ejemplo el PES, os lo instaláis, configuración gráfica, filtro anisotrópico desactivado. Jugáis un betis – valencia (por no decir un madrid – barça :p) y sacáis un pantallazo.
Pegáis el pantallazo en un mspaint.
Ahora volvéis a entrar en el juego, configuración y activáis el filtrado anisotrópico. Jugáis un Depor – Zaragoza. Pantallazo parecido al anterior (os recomiendo en un corner, para que tengáis más o menos lo mismo.
Habéis notado diferencia gráfica entre poner el filtrado anisotrópico y no ponerlo? A que no!!!
Ahora mirád ambos pantallazos, ya verás como hay MUCHA diferencia. Fijáos en la hierba.
Luego por otro lado, efectivamente hay compañías que tienen los juegos vendidos antes incluso de programarlos, y para no perder pasta, sacan una versión del juego al año (léase NFS) les da igual la mierda que hagan, pero lo tienen que sacar en un año, por lo tanto, no se preocupan mucho por optimizar, esto también es un gran problema 🙁
S2!!
Buenassss, creo que todos habéis dado en el clavo. Fundamentalmente creo que no es que los programadores se hayan vuelto vagos, sino que fundamentalmente la optimización de código ha dejado de ser una prioridad desde hace unos años (de hecho, los que llevamos unos años estudiando la carrera por paquetes, nos hemos dado cuenta como al prinpipio la fase de optimización de código era una de las más importantes en el desarrollo de software y ahora ya no lo es). Como indicaba, habéis dado en el clavo ya que considero que este cambio ha sido debido a:
1.- El aumento de capacidades hardware ha sido tan rápido que un software mal optimizado, en poco tiempo mejoraba por sí solo simplemente esperando a Intel y AMD, por ejemplo.
2.- La avaricia de la industria hace que los desarrollos duren un peo, por lo tanto la fase de optimización de código, como tantas otras se acorte drásticamente y dependas de auténticos maquinones para que vaya como debe (aquí tengo que romper una lanza en favor de Blizzard que lleva con el desarrollo de Diablo 3 la hueva de años. Esperemos que no defraude porque ha tenido tiempo de sobra para sacar un producto acojonante).
3.- En cuanto a los Sistemas Operativos, creo que no debería ser una excusa. Recuerdo en la época del MS-DOS, con su limitación de 640 kb, cómo los programadores se buscaron el modo protegido (con el famoso dos4gw.exe) para quitarse ese lastre y permitieron juegos como DOOM (punto de inflexión en la programación de videojuegos sin ninguna duda).
En definitiva, no creo que los programadores se hayan vuelto vagos, sino que las circunstancias les han empujado a olvidar la optimización de código….
P.D.: probablemente alguno me pondrá a parir. No soy programador así que, sed buenos conmigo… ;)))
No seas tan modesto, tirate algun pegotino, como hacemos todos 🙂
Lo de arriba era para kamajii.
Para ti era:
Nada de parir, para no ser programador tienes bastante bien pillado lo que ocurre
Mi verdad es que programar para un determinado hard, en un determinado lenguaje (compilado, por supuesto) hoy en día me cae tan lejos, €¦ que como programador lo único que pretendo es no «poner» muchas estupidedes en mi código.
Hasta donde hago yo, no se el resto de la parroqia, programo con .net 3/4 (VB/C#), contra una JVM o con un lenguaje interpretado de por medio (PHP/ASP) pero el hard no lo «huelo» ni de lejos. Suma mis defectos programando a los probables defectos de las n-capas de software que tengo debajo de mis programas,€¦ ya te puedes imaginar «los milagos» que hace el hardware: aveces incluso hace que mis programas parezcan útiles 😉
lo de arcangel era para ti:
No seas tan modesto, tirate algun pegotino, como hacemos todos
¿Arcangel? No.
No es cuestión de modestia, o de falta de ella,€¦ es que se hasta donde puedo llegar,€¦
Además, sólo se fardar cuando enseño un programa mío 😛 .
A mi me lo dejó muy clarito un antiguo jefe, hace 15 años: Es mucho más barato y sencillo comprar máquinas más potentes que asumir el coste de desarrollar software más eficiente.
Me jode, pero por lo que he visto con el paso de los años, no debe ser el único que piensa así.
Tamos vendíos !
No entiendo por qué se ha borrado el comentario que hice con un enlace en el que Gallir explicaba perfectamente los quebraderos de cabeza que tienen los ingenieros de Android y de IOX para hacer funcionar correctamente esos cacharros que, según tu teoría, están desperdiciados por el malhacer de los programadores.
Pensé que era una lectura interesante. Sobretodo para el que se hace las preguntas que tú planteas aquí.
Creo que la próxima vez me lo voy a pensar dos veces antes de escribir por aquí.