chema.rb escribió:Volvemos a los mismo: RENDIMIENTO.
Tendremos que comprar una procesador con 1TFlop para mover los mismo que puedes obtener con menos de la mitad, pero OPTIMIZANDO el codigo.
Salio Windows95, todo iba a cambiar, todo mas sencilo, capas y capas de abstraccion de hardware, drivers, todo el acceso a graficos a traves del API.... Y hasta que llegó DirectX y permitió un acceso mas "directo" al hardware, se seguia programando en DOS por temas de rendimiento.
Codigo interpretado= perdida de rendimiento.
Es curioso como ahora necesitamos un P4 a 3.0 Ghz y 512 de RAM para mandar al servidor de impresion los mismos documentos que hace años moviamos con un Worperfect en un 486 y 8 Megas de RAM...
Precisamente el rendimiento "Puro" no tiene interés en la mayoría de los casos actuales. En su lugar es preferible maximizar la relación Rendimiento/Tiempo de desarrollo. El uso de entornos de desarrollo amigables, con lenguajes que permitan un sencillo mantenimiento del código permiten que los programas sean más grandes y su algorítmica más sencilla de implementar.
C# (su VM) no es código interpretado!! Se compila justo antes de ejecutarlo, o bien se puede compilar a código nativo en el momento del desarrollo, con lo que se minimiza el tiempo de start-up en tiempo de ejecución, sacrificando la multiplataformidad.
XNA abstrae al desarrollador de un montón de temas de bajo nivel, lo que va a permitir que muchos aficionados puedan hacer sus pinitos con programas relativamente pequeños, sobre todo cuando XNA lleve varios años rodando. Lo digo porque seguramente la 1ª versión que saquen será la peor de todas.
Desde luego que si hemos mejorado en cuanto a ordenadores desde los tiempos del 486 ha sido porque han surgido otras necesidades al margen de los documentos que se generasen en esa época. De ninguna forma un 486 con 8MB "súper optimizado" puede hacer lo que un P4 actual.
Por cierto los compiladores ahora optimizan muuucho más que en esa época, pero ahora cargamos mucho más a los sistemas.
chema.rb escribió:Existe un port de Quake 2 a java...
Tienes razón, no me expresé con claridad. Conocí ese proyecto hace años (creo que era este), cuando tenía un rendimiento penoso. Lo que estaba pensando cuando lo escribí es que "lo pueda mover la Java VM usando C/C++ de origen", no reescribiéndolo en Java.
Una de las ventajas del CLR es que se puede usar por cualquier lenguaje de programación ya que es neutral. Incluso un programa en Java se puede ejecutar bajo la CLR (es decir, sin usar la máquina virtual de Java), usando un compilador como J++. La prueba es que para portar Quake 2 a la CLR sólo tardaron 5 dias, de los cuales 4 fueron para portarlo de C a C++. ¿Cuánto tiempo se han tirando programando una versión en Java? ---> Mucho más, y el tiempo es un factor muy importante. Por otra parte el rendimiento superior a C que se ha conseguido según los autores, me parece exagerado. Si le hubieran dedicado tiempo a optimizar la versión de C seguro que también conseguirían muchos más FPS.
Precisamente ese proyecto hace patente que se puede conseguir un rendimiento "suficientemente bueno" usando entornos JIT en lugar de la compilación tradicional.
El tiempo nos dirá qué entorno es mejor para hacer juegos comerciales si java o c#.
Es más Sony podría plantearse crear una plataforma en Java para hacer la competencia a esta iniciativa de MS, con su particular caja de arena. Aunque por supuesto sería mucho mejor que sacaran un Linux y nos dejaran hacer lo que quisiéramos.
. Y no es que me interese excesivamente, pero no estaba de más echarle un vistazo. 
![[jaja]](/images/smilies/nuevos2/otrasonrisa.gif "otra sonrisa")
![[plas]](/images/smilies/aplauso.gif "Aplausos")
![[cartman]](/images/smilies/nuevos2/cartman.gif "cartman")
![[tadoramo]](/images/smilies/adora.gif "Adorando")
![[qmparto]](/images/smilies/net_quemeparto.gif "Que me parto!")
