A raíz de este cambio los chicos de Learn OpenGL han decidido crear diversas apps para probar la velocidad de los distintos idiomas de programación y hasta qué punto aprovechan la velocidad de la CPU para ofrecer un mejor rendimiento.
Comparación de rendimiento entre ART, Dalvik y C en un Nexus 5
No entraremos en detalles técnicos, pero el autor crea un filtro DSP para generar código con mkfilter. Este se implementa de tres formas; uno en C, otra en Java y otra en Java con algunas optimizaciones manuales para aprovechar donde este idioma puede ser mejor. Unas optimizaciones que la mayoría de apps no introducen.
Los resultados se muestran en la siguiente tabla y han sido realizados sobre un Nexus5.
Como vemos, la diferencia entre C y Java (ART y Dalvik) es enorme. Hasta casi 18 veces más lento Java en Dalvik que con apps en C.
También podemos ver como se ha mejorado mucho ART respecto a Dalvik, aunque esta diferencia sería menor si los programadores aprovechasen todas las virtudes de Java, y es que en los resultados optimizados manualmente, no se percibe tanta diferencia entre Dalvik y ART. Esta diferencia de esfuerzo no solo es cuestión de microsegundos, sino de energía utilizada por las CPUs, lo que al final se traduce en batería para nuestros dispositivos.
Unos resultados que demuestran lo increíblemente rápido que es C, el gran trabajo a pesar de ser una beta todavía que se ha hecho con ART y como de lenta es la ya algo antigua Dalvik.
Java, no tan mala elección
El autor, no contento con esto continúa su pequeño experimento y prueba el mismo código pero en un PC con un procesador Intel Core i7 a 2,6GHz, mucho más potente que el Snapdragon800 del Nexus5, pero, y aquí está lo interesante, solo se consiguen resultados 2 o 3 veces más rápido en Java, a pesar de que la CPU sea considerablemente muchísimo más rápida. Parece ser que Java no está tan mal implementado en Android.
¿Cómo sería Android escrito en C? Muchísimo más rápido, con interfaces que se abren al instante y un rendimiento muchísimo mayor. ¿Por qué no entonces se apuesta por ese idioma? La razón es práctica, al ser un lenguaje de programación de bajo nivel la dificultad para crear apps en C es enorme, crear una simple app de un botón o una pantalla con un mensaje sería un verdadero quebradero de cabeza, ya no digamos apps más complejas.
Y es que al final no todo es velocidad, también el sentido práctico. Aún así una bonita comparativa que queríamos compartir con vosotros y que pone en contexto el porqué de Java como lenguaje preferido de Android.
Más información Learn OpenGL
no entendi ni madres
Es un tema complejo, pero creo que te puedo «resumir»: en C un programa hay que traducirlo para cada CPU, esto se llama compilar (cosas de GCC y CLANG en la tabla). En java (usa davilk y art) el programa se compila una vez y vale para todas las demás. Lo que pasa es que si abarcas mucho… pues te irá más lento, pues no aprovecharas los detalles especiales de cada cpu
Y si inventasen un lenguaje para basar a android, que esté basado en C pero que sea mucho más simple de utilizar? :O
Ok, no, estoy soñando.
Dirán que eres un soñador, pero no eres el unico
-Johh Lennon
Entonces sera lento igual o peor que Java al inicio.
Ya está java. El problema de java es implementar una máquina virtual decente, que es lo que se está haciendo con ART. Si mejoras ART mejoras el rendimiento de todo android
El problema es que un código que tenga que pasar por una máquina virtual nunca va a ser tan rápido como uno que no tenga que pasar por la misma, aún así el rendimiento actual de android no es para nada deplorable
Si quieres la eficiencia de C, tienes que lidiar con punteros. Si quieres hacer subfunciones que simplifiquen ese trabajo acabas recogiendo ineficiencia por todos lados. Algo así sucede con objetive C (el lenguaje que se utiliza en IOS) que no es tan tedioso como C, pero a cambio de ello sacrifica rendimiento (aunque no tanto como java, pero sacrificar, sacrifica)
Otro tema sería que los desarrolladores aprendieran a programar decentemente, pero por desgracia eso no está al alcance de todos ya que lleva bastante trabajo y tiempo.
Todo es ver como evoluciona ART, desde dalvik JIT en Android 2.2 han evolucionado una barbaridad en esos temas donde flaquea Java.
De todos modos, viendo lo fácil que evoluciona el HW es normal que no se centren tanto en la optimización. Al final optimizar te sale más caro que mejorar el HW
En Java sigues usando punteros, no me vas a decir que todos los datos de una instancia de clase la guardas en la stack, guardas en el stack la dirección del objeto que creas (cuando usas el operador new) y en la memoria guardas el objeto completo.
Siguen siendo punteros, disfrazados, pero al fin y al cabo son punteros.
De hecho, ahi está el problema. En java practicamente todo son punteros, pero no tienes un control real y eficiente como en C/C++
¿Más intuitivo para el programador estándar? Si
¿Más eficiente? Ni de coña
La gracia está en que la máquina virtual es la que controla los punteros. Eso permite, por ejemplo, utilizar un recolector de basura, que libera memoria cuando los punteros dejan de estar usados. Eso evita muchos problemas como te olvides hacer un free después de un malloc, y evita corrupción de memoria por desbortamiento de punteros.
El problema es que se usa más memoria y cuando el recolector de basura se pone en marcha, hay un pequeño parón.
No obstante, para móviles sería un infierno hacer las cosas en C/C++, habría que compilarlo para cada procesador diferente y cada partición de memoria distinta, y probablemente para cada versión de Android, para que las shared library fueran correctas (seguro que no usan el mismo glibc en android 2.3 que en 4.4.2). Eso implicaría tener que subir a la tienda 20 o 30 versiones distintas, y con nuevos modelos de móvil, recompilar y subir las nuevas versiones. ¡Un infierno!
Pues no habría beneficio de ningún tipo..absolutamente ninguno
Hagan un tema sobre Art y las apps que tienen o no conflicto con este, sería muy interesante yo queria cambiar a Art pero dicen que son varias las apps que no funcionan y no hay mucha información sobre ello
En el primer mes había muchas, pero yo lo tengo activado y hace muchos meses que no me da absolutamente ningún fallo.
Amigo pero con la app de Whatsapp no te dio problemas ¿? la verdad esta app fue la que no me dejo cambiar porque lo haría pero la mayoría de mis contactos se comunican por esta y según después ya no se podía ni instalar.
Eso fue hace tiempo, cuando acabó de salir art las aplicaciones no eran compatibles, entre ellas WhatsApp, pero ahora es raro que alguna sea incompatible. Yo lo tengo activado hace un mes en mi nexus 5 y no me falla ninguna aplicación.
En que te mejoro al cambiar a ART? Ahora te dura más la batería? Más rapidez?
Pues la verdad que no he notado mucho, un amigo mio con el nexus 4 sí le va más rápido, pero el nexus 5 va más rápido de por sí. La batería también me dura lo mismo. Quizás me va más rápido la aplicación de Twitter (talon), por lo demás no he notado nada.
como dicen que en las pruebas Java en mejor que C y al final dicen que android con C seria mas fluido?? no entendi ni madres
lamentablemente no eso eso, es que no sabes leer. si supieses leer verias que hablan de que C en las pruebas es mejor que java
Y, si lo leyese todavía mejor, vería que es cierto lo que dice. A pesar de ser más lento, Java es mejor que C (que no C++). ¿Por qué? Porque la diferencia entre los tiempos de respuesta (7,99 microsegundos en Java sin optimizar, frente a 1 de C) no compensan la complejidad de programar en uno u otro lenguaje. A parte de que no congeniaría con la filosofía de Android, que es la de ser compatible con multitud de hardware diferente.
El cuento de C le iría genial a los iPhone porque todos, absolutamente todos los terminales, los fabrica Apple con los mismos procesadores y no Samsung, LG, HTC, Sony, Acer, Xiomi y un larguísimo etc con otro enorme etc de versiones y subversiones. Por lo que ART es la alternativa perfecta a Dalvik y no «reprogramar» un SO completo y todas sus APPs en C.
No es que le iría genial, le va. Bueno en sí es Objective-C y no C puro, pero sigue siendo un hijo de C y aún así te apuesto que rinde mejor que los sabores de java.
Por favor no me ataquen de apple fanboy porque tengo un S4 y me voy a comprar un HTC One M8, pero los hechos son lo que son :p
Ahora bien una relación 1:7 yo sí la veo considerable, mucho más en términos de consumo de energía, pero el hecho es que esto no lo vas a notar sino en aplicaciones que demanden demasiado poder computacional, y las únicas que se me ocurren son escasamente los juegos o editores de video, así que como dice extremekhaos no creo que valga la pena re crear todo el código del OS sólo por eso
Perdón. Le va… jejejej
Para que un lenguaje sea mejor que otro para desarrollar aplicaciones, no influye sólo el rendimiento del programa generado, sino la facilidad para desarrollar esos programas. Y luego, si resulta que en las aplicaciones la mayor parte del tiempo se lo pasa interactuando con el usuario en lugar de hacer un montón de cálculos complejos, ahí tiene que no salga a cuenta desarrollarla en el lenguaje más rápido, sino en el más sencillo de programar. ¿O me vas a decir que preferirías invertir 1000 horas en desarrollar un programa para obtener una ligerísima mejora en el rendimiento percibido por el usuario, en lugar de invertir 100 horas en ese mismo programa? Si el programa desarrollado en Java es suficientemente rápido, no es necesario complicar el desarrollo haciéndolo en otro lenguaje más complejo de usar.
Y por eso y mil cosas mas es por lo que no me gusta Java…
Pero su curva de aprendizaje es facilisima, las cosas como son
java tiene un monton de jeroglificos y versiones, c, no los tiene
Para jeroglíficos php D; Y como dice Astur, Java es fácil… «verbouse», pero fácil.
jeroglificos php por favor??? java prima pelada, java moviles, java tu culo, java bragas, java semana santa, java iphone, java android, java tu ano, java pedo… igual que un lenguaje no compilado pero encima peor… C es c en cualquier plataforma, igual que php, java no.
uy perdón……… pues que triste que te tomes tan personal un lenguaje de programación.
Para jeroglíficos, usa Perl XD
«La razón es práctica, al ser un lenguaje de programación de bajo nivel la dificultad para crear apps en C es enorme»
¿Peeeeeeeeeeerdona?
C y Java son ambos de alto nivel, lo que cambia es el paradigma de programación
pueda se que el autor se referia a C y no a C++ que es la versión orientada a objetos, asi como java. por que C puro, si es muy complejo en comparacion con java
Asumo que el tiempo esta medido en milisegundos… la diferencia entre 1 y 17 es casi imperceptible.
Como programador y siendo C++ el lenguague que mas he utilizado en mi vida profesional (y el que mas me gusta) y aparte de ser toda la vida muy critico sobre el lenguague Java, creo que tiene valor que diga que la diferencia en rendimiento entre una aplicacion en C++ o Java en los dispositivos de hoy en dia es practicamente imperceptible y el esfuerzo que implica usar el NDK de Android no lo vale ya que la ganancia en rendimiento seria minima.
Pero es tiempo relativo, en milisegundos no te das cuenta pero si es un juego cuyo codigo en java tarda para ejecutarse 18 segundos, en c sería 1 segundo, ahí si que se notaría la diferencia, solo que en c llevaría mucho mas tiempo programar. En los celulares de gama baja seguro que se notaría la diferencia, donde todas la aplicaciones pesadas tardan unos 5 segundo aproximadamente en abrir
Honestamente en los tiempos de carga dudo que encuentres mucha diferencia entre C++ y Java, no se si Andrioid a la hora de cargar los recursos de la App lo hace a traves de APIs nativas. La diferencia principal se encuentra en la logica de la aplicacion en si.
En las mayorias de las apps al no tener logicas demasiadas complicadas la diferencia seria casi nula, en el unico escenario donde se me ocurre que podria llegar a notarse es en aplicaciones con logica mas compleja como los juegos.
Pero hay que ser realistas, nadie desarrolla para dispositivos de gama baja ni les interesa, la diferencia de tiempos de desarrollo entre Java y C++ es gigante y en los dispositivos de hoy en dia, la diferencia de rendimiento seria casi imperceptible para el usuario.
No creo que haya mucho que discutir sobre el tema, existen en internet un monton de pruebas de rendimiento entre C++ y Java, es una discusion frecuente entre programadores, la unica diferencia es que esta vez se hizo bajo un environment que no es una PC sino un Android
No, una cosa es la optimización y otra cosa son los buses de datos, eso solo es inherente al hardware
A ver, una cosa es el lenguaje y otra muy diferente es el compilador y la máquina virtual sobre la que se ejecuta el programa compilado (para el caso de Java). Android utiliza Java COMO LENGUAJE DE PROGRAMACIÓN porque es de lo más utilizado por los desarrolladores y podrían envolverse rápidamente al mundo de Android, pero sin embargo no es Java de Sun MicroSystems como tal, de hecho los archivos que traduce la máquina virtual son optimizados para móviles comparados con los clásicos .java
La gran idea de Java, cuando surgió, fue que se podría ejecutar en cualquier computadora sin tener que volver a compilar para diferentes procesadores o arquitecturas ya que la máquina virtual lo hacía por nosotros, esta idea se llevó después al mundo del desarrollo web y ahora con los dispositivos móviles.
Por lo que el tiempo en ejecutar una aplicación va a depender más de la máquina virtual y su optimización que del lenguaje en sí. Ahora, ¿Porqué funciona con C? Pues porque se utiliza el gcc. Que es un conjunto de compiladores (entre ellos C) para GNU, y Android dentro de sus más profundos secretos tiene un kernel de Linux, el cuál ejecuta la máquina virtual y esta ejecuta nuestras aplicaciones.
Entonces en teoría, va a ser más rápido ejecutar una aplicación en C porque estas ejecutando directamente sobre el Kernel y no pasa por la máquina virtual que a la vez va a traducir tu código al Kernel.
Resumen, ¿Porqué usar Java en lugar de C? Porqué más desarrolladores están acostumbrados a utilizarlos aunado a que es un lenguaje orientado a objetos contra un lenguaje estructural como C. ¿Porqué ejecutar una máquina virtual y no trabajar directo sobre el kernel? Pues es una de las ventajas de Android, olvidarte del hardware, las direcciones de memoria y las limitantes del dispositivo para programar una aplicación que va a funcionar en todos los dispositivos que corran dicha máquina virtual.
Por eso prefiero .Net, ya viene integrada la maquina virtual en el sistema operativo, lo cual hace una ejecución mas rápida, ademas parte del binario se compila durante la ejecución para el procesador.
Microsoft tendrá sus puntos débiles, pero debo admitir que en una pelea de Java vs C# apuesto hacia C#.
si claro, y corre en linux, mac Os, solaris
¿Has escuchado el proyecto de Mono? (Project Mono)
si, y ¿por lo menos has corrido algún programa de .net fuera de windows y de forma correcta?, ¿sin usar Wine u otro similar?
para no ir tan lejos has usado moonlight, que es el equivalente a silverlight, y que fue un fracaso total
Hasta el Framework 3.5 de .Net si, ya en versiones posteriores no me toco trabajar con Mono.
Java no es más lenta que C#, es más, en ningún benchmark que haya visto supera la plataforma .net a hotspot en velocidad.
Otra cosa es que C# tenga una muy buena integración con entornos windows y, por qué no decirlo, las interfaces gráficas hechas en .Net funcionan bastante mejor que el apestoso swing (y lo digo como programador Java :D)
Y eso que no te toco trabajar con la AWT, pero problema viene al querer visualizar de manera similar en diferentes plataformas un mismo ejecutable. Por eso las librerías de gráficos de .Net son mejores, ya que solo se preocupan en Windows.
¡AWT es el horrooooor!
No tienes ni idea de lo que estás hablando. Cuando se programa en C no se trabaja directamente sobre el kernel. Se trabaja con las librerías del sistema y estas son las que tocan el kernel. Si tocásemos directamente el kernel corromperíamos el sistema. Además de que no se puede, no se tiene ese permiso sobre la memoria. Aunque tal vez si es un microkernel se puedan tocar los módulos de este…
Tienes razon, exagere sobre el trabajar directamente sobre el kernel; sin embargo no quiere decir que no tenga idea de lo que estoy hablando, lo que queria resaltar es que trabajando en C te evitas el tener que pasar por una maquina virtual, que mucho o poco pero va a afectar en el rendimiento a costa de un ambiente de desarrollo mas seguro, bonito y facil de usar.
En mi.moto g sale la opción de vambiar a ART, pero cuando reinicia y veo, sigue en Dalvik
Tienes instalado Xposed?
Me pasa exactamente lo mismo, y tengo instalado Xposed.. Será ese el problema?
Pues sí, Xposed no es compatible con ART, sólo con Dalvik.
Si, ese es el problema, Xposed aún no puede trabajar con ART sino que solo con dalvik, en el caso del moto g si compraste el de 8 gb esta mejor en dalvik ya que en ART ocupan mas espacio las aplicaciones
Sí. Tengo Xposed y cwm de recovery
Pues ahí tienes la razón, shur
igual metrerse con ART a estas alturas que esta en beta es un juego de suerte. algunas apps funcionaran bien, y otras daran muchos problemas o errores inesperados.
Personalmente prefiero C#, su desventaja sería en cuanto a la dependencia de .NET Framework y Microsoft, o sea, la ausencia de soporte multiplataforma.
osea una total mier…. lo único bueno de C# es un interoperatividad con otros lenguajes gracias al código intermedio MSIL, pero como dices, eso solo es posible con el Framework de .NET
De guatemala a guatepeor …
Si por lo menos optimizasen…
C alto nivel? Q diablos estas hablando…
Es de alto nivel C, si quieres bajo nivel usa Ensamblador.
Qué coño ensamblador, ¡usa binario! O eso es demasiado moderno, mejor por pulsos electromagnéticos. Eso sí que es bajo nivel.
Cualquier lenguaje que en vez de «compara estos registros y si el resultado es cero salta a esta dirección de memoria y decrementa el contador» tenga un «haz esto 10 veces» ES de alto nivel :D