por
pobrecito hablador
el Sábado, 11 Septiembre de 2010, 22:35h
(#1237979)
Vayamos por partes, parece que el trasto usara una chapucilla a lo PAE y seguira siendo 32 bits [xbitlabs.com]. O sea que 4GB por proceso. No vital para muchos usos, pero si para evolucion futura. Tendrian que sacar un A15+N con 64 bits de verdad, pero no creo que les parezca correcto aun.
Lo de los GHz no lo entiendo, como si va a 100Mhz o a 10THz, lo que importa es lo que puede hacer. En x86 siempre pasa eso, unas veces es Intel y otras AMD el que tiene un procesador superhyperHz pero el otro hace lo mismo con menos Hz, cuando no hace incluso mas.
Pero si la gente deja de obsesionarse con que no corre Windows o que necesita 6GB para su Apache (multiproceso...)... pues si, estaria muy bien. Siempre y cuando no sea un paperlaunch y salga pronto y no en 2015.
La CPU, además de ir a 2.5GHz, y a nivel de ciclo, independientemente del reloj usado, hace: ejecución superescalar fuera de orden (ALU + load/store + SIMD), multi core (hasta 4), 4MB de cache L2. No serán tan buenos como un core2duo pero en principio serían bastante mejores que un Atom (ciclo por ciclo para un núcleo aislado).
Lo de direccionar más de 4GB mediante segmentación (ya sea como el PAE de Intel u otra solución similar), permite evitar tener que cambiar los compiladores y herramientas para el espacio de usuario (continuarían siendo válidas las actuales para ARMv7, incluyendo las que mezclan opcodes ARM clásicos de tres operandos y los nuevos Thumb2 -mejora sobre los Thumb (opcodes de 16 bits de dos operandos)- de dos operandos y 16/32 bits por opcode), además de mantener las estructuras de datos más compacta al continuar usando punteros de 32 bits. Te recomiendo que compiles un mismo programa para instrucciones ARMv7 (p.e. para el ARM Cortex A8 que lleva el Nokia N900, el Palm Pre, o el iPhone 3GS), y luego lo compiles para x86_84... la diferencia es abismal, primero en el tamaño del ejecutable, y después, en el uso de memoria (al ocupar menos el código aprovecha mejor la cache de código de primer nivel, y también la de datos, al usar punteros de 32 bits y menor "padding"/relleno para las estructuras de datos).
Estaria bien
(Puntos:1, Interesante)Lo de los GHz no lo entiendo, como si va a 100Mhz o a 10THz, lo que importa es lo que puede hacer. En x86 siempre pasa eso, unas veces es Intel y otras AMD el que tiene un procesador superhyperHz pero el otro hace lo mismo con menos Hz, cuando no hace incluso mas.
Pero si la gente deja de obsesionarse con que no corre Windows o que necesita 6GB para su Apache (multiproceso...)... pues si, estaria muy bien. Siempre y cuando no sea un paperlaunch y salga pronto y no en 2015.
Re:Estaria bien
(Puntos:3, Interesante)( http://www.voluntariado.net/ | Última bitácora: Domingo, 10 Junio de 2012, 21:48h )
Lo de direccionar más de 4GB mediante segmentación (ya sea como el PAE de Intel u otra solución similar), permite evitar tener que cambiar los compiladores y herramientas para el espacio de usuario (continuarían siendo válidas las actuales para ARMv7, incluyendo las que mezclan opcodes ARM clásicos de tres operandos y los nuevos Thumb2 -mejora sobre los Thumb (opcodes de 16 bits de dos operandos)- de dos operandos y 16/32 bits por opcode), además de mantener las estructuras de datos más compacta al continuar usando punteros de 32 bits. Te recomiendo que compiles un mismo programa para instrucciones ARMv7 (p.e. para el ARM Cortex A8 que lleva el Nokia N900, el Palm Pre, o el iPhone 3GS), y luego lo compiles para x86_84... la diferencia es abismal, primero en el tamaño del ejecutable, y después, en el uso de memoria (al ocupar menos el código aprovecha mejor la cache de código de primer nivel, y también la de datos, al usar punteros de 32 bits y menor "padding"/relleno para las estructuras de datos).