Ver Mensaje Individual
  #15 (permalink)  
Antiguo 04/10/2005, 07:00
Avatar de TolaWare
TolaWare
Colaborador
 
Fecha de Ingreso: julio-2005
Mensajes: 4.352
Antigüedad: 18 años, 10 meses
Puntos: 24
la diferencia de rendimineto implícitamente debería estar, ya que no es lo mismo manejar un tamaño de palabra de 32 bits, que de 64 bits.
Con los 64 bits, el procesador puede operar números mas rapido
ej: si queremos inventir(negar) la siguiente cadena:
101110101010100....01101 64bits
el procesador lo carga en un registro, lo manda a la ALU, la ALU lo devuelve negado y listo.
en cambio con un procesador de 32 bits, tenemos que hacerlo en 2 pasos, ya que el número no entra en 32 bits, tiene que negarlo por partes, por lo que se tardaria casi el doble para realizar esta operación.
Explico esta por si alguien que no sabe la diferencia entre 32 y 64 bits, quiere opinar.
Bueno pero aqui radica otro problema. El kernel fue escrito originalmente para 32 bits, es decir pensado que la máquina puede procesar no mas de 32 bits. Por lo que el señor que escribió el código fuente de Linux (Linus Torvalds), estaba pensando en 32 bits, es decir, debe haber usado muchas variables int y float para optimizar el rendimiento del código, pero esta "optimización", no tiene sentido en los 64 bits, por loq ue no le estariamos sacando todo el jugo a los 64 bits. Ya se lo que pueden estar pensando, "los compiladores optimizan el código para llevarlo de la manera más óptima a los 64 bits", esto es tan verdad como "el compilador de C genera el mismo código assembler, que si lo escribiéramos directamente en assembler" Ja, nadie se lo cree eso, y lo he comprobado, el programa "hola mundo" en C, ocupa 1.3 Kb(el .exe), en cambio cuando lo escribí con assembler puro, el ".exe" ocupaba 40 bytes, jeje.
Bueno, me fui por las ramas, obiamente yo opino que el rendimiento va a ser mayor, pero se puede elevar mucho mas si se reescribiera el código fuente del kernel para 64 bits
__________________
http://blog.tolaware.com.ar -> Blog de Java, Ruby y Linux