-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 13:30 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 13:59:50 +0100, Carlos E. R. escribió:
A ver, que te lias un poco.
Un programa en 32 bits no puede acceder a más de cuatro gigas. Es decir, no puede decir, "dame la posición de memoria 4,5GiB" y quedarse tan ancho. Es que ni siquiera puede escribir la cifra 4,5GiB como número entero en el bus de direcciones.
Con un kernel de 32 bits sin PAE, no.
Y con PAE, tampoco. Son 32 bits de direcciones, no hay más.
No obstante, puede emplear algunas funciones de librería que sí les permitirían acceder a trozos de memoria enormes, mapeandolas, y siendo conscientes de ello de alguna forma. Es decir, podría reservar un trozo de 6 GiB dividiendolo en trozos menores y accediendo a cada trozo por separado. Pero no podría emplear la operación del procesador de buscar un string en todo el trozo de 6 gigas, tendría que hacer varias búsquedas, y usar artimañas para buscar el string en las fronteras entre los trozos divididos.
Pues eso, que *sí* pueden.
Que no.
O sea, que no. Si tienes programas que necesiten más de cuatro gigas, emplea procesadores y sistemas de 64.
Es que no sabes cuándo un programa (o una operación) te va a necesitar más de 4 GiB, bueno, 3 GiB.
Claro que si. Lo puedes suponer. Yo no voy a necesitarlo.
Que es muy distinto de usar un sistema de 32 bits con 8 gigas, como tengo yo, porque esa memoria se emplea para caché principalmente, que por ineficaz que sea siempre será más eficaz que el disco.
Lo que no tiene sentido es tener un procesador de 64 bits, más de 8 GiB de ram y un kernel-pae, porque te penaliza.
Un poco. Es asumible. Sigue siendo más rápido que un sistema con uno o dos gigas solamente. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktlnqoACgkQtTMYHG2NR9WkAgCdHjSHnqvtjyY3VWU12Bbl8XE0 9CsAnAyIGq82b9f2bHZguUjXnX5Ti93c =/eui -----END PGP SIGNATURE-----