Historias
Slashboxes
Comentarios
 
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Estaria bien

    (Puntos:1, Interesante)
    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.

    [ Padre ]
    Puntos de inicio:    0  puntos
    Moderación   +1  
    Modificador extra 'Interesante'   0  

    Total marcador:   1  
  • Re:Estaria bien

    (Puntos:3, Interesante)
    por faragon (17575) el Sábado, 11 Septiembre de 2010, 22:59h (#1237980)
    ( http://www.voluntariado.net/ | Última bitácora: Domingo, 10 Junio de 2012, 21:48h )
    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).
    [ Padre ]