|
||
|
#21
|
||||
|
||||
|
Pues lo he puesto en cientos de hilos... Android se decantó por Java como lenguaje para sus aplicaciones, y así captar la mayor cantidad de desarrolladores, poniendo la maldita máquina virtual Davlik como capa de comunicación entre lenguaje y kernel... al principio muy bonito, pero cuando la cosa ha evolucionado y se mueve en estas cotas, la cosa no da para mucho más... es por esto que ahora mismo iOS y Windows Phone necesitan la mitad de hardware para funcionar el doble de rápido que Android.
iOS y Windows Phone (Objetive C y .NET) se comunican de forma nativa con sus respectivos kernels (Linux y Windows NT) sobre el que se asienta el sistema operativo y las aplicaciones, y es mil veces más óptimo. Ni más, ni menos que eso... Android debería remodelarse completamente para quitarse de encima Java... o al menos para que solo hiciese falta en las aplicaciones que se basen en Java, y contase con un SDK para programar en otros lenguajes nativos como todas las variantes orientadas a objetos de C. Saludos. ![]() Por cierto, ya se pueden compilar aplicaciones en c++ para android desde hace tiempo, asi que se deverian poner las pilas los desarrolladores de aplicaciones. A y ios no usa un kernel Linux como as puesto arriba, sino que deriva de unix, el padre de Linux. Por cierto, estos procesadores hoy en día son inútiles, haber si empieza a moverse esto de los 64 bits y en un par de años ya son algo útil en móviles. |
|
|
|
#22
|
||||
|
||||
|
Pues lo he puesto en cientos de hilos... Android se decantó por Java como lenguaje para sus aplicaciones, y así captar la mayor cantidad de desarrolladores, poniendo la maldita máquina virtual Davlik como capa de comunicación entre lenguaje y kernel... al principio muy bonito, pero cuando la cosa ha evolucionado y se mueve en estas cotas, la cosa no da para mucho más... es por esto que ahora mismo iOS y Windows Phone necesitan la mitad de hardware para funcionar el doble de rápido que Android.
iOS y Windows Phone (Objetive C y .NET) se comunican de forma nativa con sus respectivos kernels (Linux y Windows NT) sobre el que se asienta el sistema operativo y las aplicaciones, y es mil veces más óptimo. Ni más, ni menos que eso... Android debería remodelarse completamente para quitarse de encima Java... o al menos para que solo hiciese falta en las aplicaciones que se basen en Java, y contase con un SDK para programar en otros lenguajes nativos como todas las variantes orientadas a objetos de C. Saludos. ![]()
__________________
saludos.
|
|
#24
|
||||
|
||||
|
Pues creo que te equivocas, parece que el A7 vuelve a estar fabricado por Samsung:
http://www.chipworks.com/en/technica...the-iphone-5s En Android es probable que el objetivo de los 64 bits sea aumentar la RAM, en iOS lo dudo, más bien será mejorar la eficiencia del sistema, algo que por desgracia en Android parece que no se sabe lo que significa. El compañero DaSound lo ha expuesto muy bien en el anterior post. ![]() Pero creo que tienes razón... al final puede que haya sido Samsung.
__________________
Apple
|
|
#25
|
||||
|
||||
|
Yo también creo que c++ es una gran alternativa para escribir aplicaciones en android, pero asta ahora no a sido el momento, ya que los smartphones tenían poca memoria y eso java lo solucionaba, y todavía deveria seguir siendo asi en los móviles de gama baja y algunas aplicaciones más genéricas como whasap ya que estas las siguen usando móviles viejos. Eso si, las aplicaciones de sistema deverian estar escritas en su malloria en java para aprovechar mejor la RAM, añ igual que los juegos, el navegador o aplicaciones pesadas, pero la variedad siempre está bien.
Por cierto, ya se pueden compilar aplicaciones en c++ para android desde hace tiempo, asi que se deverian poner las pilas los desarrolladores de aplicaciones. A y ios no usa un kernel Linux como as puesto arriba, sino que deriva de unix, el padre de Linux. Por cierto, estos procesadores hoy en día son inútiles, haber si empieza a moverse esto de los 64 bits y en un par de años ya son algo útil en móviles. ![]() Ventajas: - C++ te permite entrar hasta la cocina... con su código puedes acceder a cualquier parte del dispositivo. - Es rápido como el viento... es una arquitectura sólida y rapidíiiiiiiiisima. - Es nativo, comunica directamente con el kernel de Linux (escrito en c). Desventajas: - Es muy tedioso de programar, ya que no hay tanta API escrita para C++ sobre todo en el mundo smartphone. - Controlar la gestión de memoria. Me ha tocado muchas veces, sobre todo cuando programaba en Visual C++, pero manejar los punteros es una p*t*d* como un templo... si hay que hacerlo se hace, pero nada como un gestor automático de memoria como el de .NET o Java. - No es un lenguaje en alza... lo fue, pero la gente que lo maneja no está por la labor de meterse con dispositivos móviles... el pool de programadores es muy escaso.
__________________
Apple
|
|
#26
|
||||
|
||||
|
Pues sí, podría decirse así... por eso hablo siempre de que se subestima a sistemas emergentes como Ubuntu Touch o Tizen... estos SOs tendrán un framework nativo respecto al kernel y se instalarán en smartphones con hardware Android... si le sacan el jugo esos sistemas volarán!!
__________________
Apple
|
| Gracias de parte de: | ||
|
#27
|
||||
|
||||
|
La de tonterías que hay que leer... los 64bits sirven, entre otras cosas, para poder direccionar 4Gb de RAM, que será lo que posiblemente traiga el S5 o el Note4... no es por otra cosa!!! mañana lo será, hoy es básicamente por eso!!
¿Quién ha dicho que sea para Android?... quizá los fabrican pensando en Tizen que puede ser que sí los aproveche, así como el multihilo... y los montan en los 2, para qué fabricar 2 distintos. Mañana será Qualcomm quien los presente, y será el DIOS!! se celebrarán fiestas, se ofrecerán presentes, se esculpirán estatuas y compondrán canciones y sonetos. Y sino, al tiempo. ![]() No es necesario un procesador de 64 para manejar 4 gb de ram a menos que se quiera superar esa cantidad. Última edición por Birutas Día 23/09/13 a las 19:13:19. |
|
#28
|
||||
|
||||
|
http://www.tecnogeek.com/verpost.php?id_noticia=2102 Esto de los 64 bits es algo evolutivo, siempre hay alguien que lanza primero algo y el hecho de que seas primero no te hará mejor ni peor... desgraciadamente muchos piensan que no es así. Lo molesto es como se juega con la mente de las personas, sobre todo apple, que su manera de vender es siempre "somos los primeros y nos copian" y cuando alguien presenta algo similar se le ataca como perro rabioso. Y cierto, también se hace con apple, pero ellos fueron los que empezaron con este jueguito, son las consecuencias de esto... ![]() El copiar, o imitar, genera competitividad y opciones, y que el mercado progrese con el tiempo. Si prosperaran de más las estrategias comerciales nefastas de la manzanita, de demandar por cualquier estupidez e impedir "copias o imitaciones", el mercado estaría estancado, no habría la cantidad de opciones a elegir que hay, desde xiaomi hasta lg, sony o samsung, o el wp8 de ms. Hay una delgada linea roja entre el copyright, defender la innovación y abusar de esto para querer monopolizar el mercado, y aunque muchos digan que no, lo que es apple tiende más a estar del segundo lado... por lo que se ha visto anteriormente. Dicho sea de paso este tema de 64 bits no se trata de ser el primero, y menos cuando la empresa que hace el diseño para todos ya lo presentó el año pasado, sino de aprovechar bien las cosas, y no presentarlo como un alarde para estrategia de venta... porque prácticamente está siendo así. Las consolas cambiaron la guerra de bits por la de los cores hace años... y es de las apps que mas demandan procesamiento... por algo será. Lo que es seguro es que pronto será necesario cambiar a 64 bits, por los motivos expuestos... lo mismo que pasó en PC. |
| Gracias de parte de: | ||
|
#29
|
||||
|
||||
|
Tampoco veo un problema para android que use java, se pueden ir desarrollando nuevas aplicaciones sin java y así no usa dalvik
|
|
#30
|
||||
|
||||
|
Wao, creo que el S5 si esto es cierto será más rápido que mi computadora jaja.
Espero que refinen lo del big little, con ese A53 los 4 procesadores menos potentes serán como 4 núcleos A9 jaja más potente que muchos gama media. A ver que pasa
__________________
![]() |
|
#31
|
||||
|
||||
|
- que el procesador soporte la tecnologia de direccion ampliada, es decir, que tenga esas lineas extra - que el kernel soporte PAE (Physical Address Extension) si hablamos de Linux y AWE (Address Windowing Extensions) si hablamos de windows. Primeramente no es factible limitarse unicamente a kernels que sean compatibles con PAE... y segundo y mas importante, la compatibilidad con la direccion de memoria extendida ha de ser soportada físicamente por el procesador... contando con esas loneas extras. Actualmente solo los cortex A15 son compatibles, y no tiene porque serlo mas adelante. Si ARM es precisamente quien antepone la arquitectura de 64bits sobre la de 32 con extension PA... por algo será. Meter PAE seria solo un parche momentáneo a una evolución obligatoria... porque complicarse la vida... se mete x64 y a correr.
__________________
Apple
|
| Gracias de parte de: | ||
|
#32
|
||||
|
||||
|
Por cierto mucho tiros a la línea de flotación de android, samsung saca sus sistema operativo, oppo acaba de sacar ColorOS de Oppo en su oppo one, etc... los fabricantes se esta cansando de android?
__________________
saludos.
|
|
#33
|
||||
|
||||
|
El caso de Samsung no creo que sea aburrimiento de Android, lo que pude leer es que ellos no quieren depender de Google, pero si ese Tizen no pega tendrán que volver a Android, aunque espero que pegue, sería una opción más, pero que sigan con Android también.
__________________
![]() |
|
#34
|
||||
|
||||
|
asu se me aclararon varias dudas que tenia... gracias
|
|
#36
|
||||
|
||||
|
Con un procesador de 32bits se pueden direccionar hasta 64gb de ram... como? Usando la dirección extendida de memoria. Para ello se tienen que cumplir 2 cosas
- que el procesador soporte la tecnologia de direccion ampliada, es decir, que tenga esas lineas extra - que el kernel soporte PAE (Physical Address Extension) si hablamos de Linux y AWE (Address Windowing Extensions) si hablamos de windows. Primeramente no es factible limitarse unicamente a kernels que sean compatibles con PAE... y segundo y mas importante, la compatibilidad con la direccion de memoria extendida ha de ser soportada físicamente por el procesador... contando con esas loneas extras. Actualmente solo los cortex A15 son compatibles, y no tiene porque serlo mas adelante. Si ARM es precisamente quien antepone la arquitectura de 64bits sobre la de 32 con extension PA... por algo será. Meter PAE seria solo un parche momentáneo a una evolución obligatoria... porque complicarse la vida... se mete x64 y a correr. ![]() |
|
#37
|
||||
|
||||
|
Con 4Gb se direccionan 4Gb TEÓRICAS, no físicas ni prácticas, porque la RAM no es lo único que hay que direccionar... los recursos de la placa y otros componentes también ocupan direccionamiento, por lo que la dirección de la RAM se limita y no es capaz de direccionar las 4Gb si no se usa el direccionamiento extendido. Aparte de esto, se pretende superar las 4Gb de RAM incluso en el mismo año... no vamos a esperar al límite para implementar la arquitectura. Parece que no queda claro como funciona el tema de los procesadores... ARM desarrolla los esquemas de los procesadores, y las marcas lo adoptan para fabricar cada uno el suyo... si la siguiente generación con los ARM A57 y A53 son 64bits, todas las marcas que quieran fabricar sus procesadores con arquitectura ARM, tendrán que ser x64, es que nos creemos que las marcas hacen los procesadores así porque les da la gana!! pues no! así dan lugar las discusiones absurdas sobre si uno copia y el otro lo saca porque este lo saca... las arquitecturas las marca ARM, y cada uno lo scará a su ritmo. Aparte de todo esto, va a ser un cambio forzoso... ARM va a fabricar los A50 con arquitectura de 64bits, así que todos los nuevos terminales montarán SoC 64bits... los programadores tendrán que empezar a pensar si desdoblan las aplicaciones o solo programan para 32bits... pero desde ya te digo que los buenos juegos empezarán a usar 64.
__________________
Apple
Última edición por DaSound Día 24/09/13 a las 08:55:30. |
| Gracias de parte de: | ||
|
#38
|
||||
|
||||
|
Sí, sé que desde hace tiempo se pueden escribir en C++, pero esto tiene ventajas y virtudes, por ejemplo...
Ventajas: - C++ te permite entrar hasta la cocina... con su código puedes acceder a cualquier parte del dispositivo. - Es rápido como el viento... es una arquitectura sólida y rapidíiiiiiiiisima. - Es nativo, comunica directamente con el kernel de Linux (escrito en c). Desventajas: - Es muy tedioso de programar, ya que no hay tanta API escrita para C++ sobre todo en el mundo smartphone. - Controlar la gestión de memoria. Me ha tocado muchas veces, sobre todo cuando programaba en Visual C++, pero manejar los punteros es una p*t*d* como un templo... si hay que hacerlo se hace, pero nada como un gestor automático de memoria como el de .NET o Java. - No es un lenguaje en alza... lo fue, pero la gente que lo maneja no está por la labor de meterse con dispositivos móviles... el pool de programadores es muy escaso. ![]() Soy de los de la "vieja escuela" que ha programado casi todo en C y C++ pero que también he programado bastante en ASM y he visto la brutal diferencia de eficiencia que hay entre capas de software. Entiendo que no se puede programar todo en ASM porque sería poco menos que inviable pero tampoco me parece bien el enorme despilfarro de recursos de que hay actualmente. Me da la sensación de que hoy día ya no se programa sino que se "diseña" software, todo a partir de "módulos prefabricados" que a la vez enlazan con otras capas modulares y al final para ir de A hasta B se dan un millón de vueltas y con un montón de problemas por el camino. Desde mi punto de vista Java sobra y se tendría que ir a C++ no solo mirando el diseño y funcionalidad del software sino también la eficiencia del mismo dándole como mínimo la misma importancia que al diseño. Pero bueno, parece que a día de hoy es la mentalidad que hay, crecer y crecer, pero siempre ir a lo fácil no a la calidad. Que van lentas las aplicaciones.. pues a meter más máquina en vez de optimizar el software. En fin, bienvenidos sean los 64bits, pero seguro que serían mejor recibidas las optimizaciones de software y aquí Apple creo que si da un gran ejemplo a seguir. |
|
#39
|
||||
|
||||
|
Si a día de hoy parece que lo que prima en todas partes y en todos los segmentos de la sociedad es ir a lo fácil y rápido sin pensar en que es "pan para hoy y hambre para mañana".
Soy de los de la "vieja escuela" que ha programado casi todo en C y C++ pero que también he programado bastante en ASM y he visto la brutal diferencia de eficiencia que hay entre capas de software. Entiendo que no se puede programar todo en ASM porque sería poco menos que inviable pero tampoco me parece bien el enorme despilfarro de recursos de que hay actualmente. Me da la sensación de que hoy día ya no se programa sino que se "diseña" software, todo a partir de "módulos prefabricados" que a la vez enlazan con otras capas modulares y al final para ir de A hasta B se dan un millón de vueltas y con un montón de problemas por el camino. Desde mi punto de vista Java sobra y se tendría que ir a C++ no solo mirando el diseño y funcionalidad del software sino también la eficiencia del mismo dándole como mínimo la misma importancia que al diseño. Pero bueno, parece que a día de hoy es la mentalidad que hay, crecer y crecer, pero siempre ir a lo fácil no a la calidad. Que van lentas las aplicaciones.. pues a meter más máquina en vez de optimizar el software. En fin, bienvenidos sean los 64bits, pero seguro que serían mejor recibidas las optimizaciones de software y aquí Apple creo que si da un gran ejemplo a seguir. ![]() Efectivamente, o incluso me atrevería a decir que en C#/VB.NET tal y como propone la gente de Xamarin, que es un lenguaje que sería nativo para el kernel y es de última generación igual que Java... bueno, realmente mucho mejor porque es rápido como él solo. Capas, capas y más capas... más código autogenerado que no genera nada más que paja y mierda que no vale para nada... es peor que la crisis del software!! En ese aspecto, tal y como cuentas iOS, Windows Phone y próximamente Ubuntu Touch, Jolla y Tizen le lleva la delantera a Android en ese aspecto tan inmensamente importante. Y ya no hablemos como otros sistemas como los anteriormente citados implementen multihilo... entonces ya apaga y vámonos.
__________________
Apple
|
|
|
|
#40
|
||||
|
||||
|
Pues lo he puesto en cientos de hilos... Android se decantó por Java como lenguaje para sus aplicaciones, y así captar la mayor cantidad de desarrolladores, poniendo la maldita máquina virtual Davlik como capa de comunicación entre lenguaje y kernel... al principio muy bonito, pero cuando la cosa ha evolucionado y se mueve en estas cotas, la cosa no da para mucho más... es por esto que ahora mismo iOS y Windows Phone necesitan la mitad de hardware para funcionar el doble de rápido que Android.
iOS y Windows Phone (Objetive C y .NET) se comunican de forma nativa con sus respectivos kernels (Linux y Windows NT) sobre el que se asienta el sistema operativo y las aplicaciones, y es mil veces más óptimo. Ni más, ni menos que eso... Android debería remodelarse completamente para quitarse de encima Java... o al menos para que solo hiciese falta en las aplicaciones que se basen en Java, y contase con un SDK para programar en otros lenguajes nativos como todas las variantes orientadas a objetos de C. Saludos. ![]() A que no sabes que las aplicaciones mas pesadas y serias web corren en servidores de aplicaciones JEE? |
![]() |
Estás aquí
|
||||||
|
||||||