Hace 16 años | Por jfabaf a kriptopolis.org
Publicado hace 16 años por jfabaf a kriptopolis.org

Kriptópolis nos dice que ya no tiene sentido aumentar más allá de los 3GB la RAM mientras sigamos utilizando sistemas operativos de 32 bits. Ni siquiera Vista se salva de la quema con su supuesto parche. Eso sí, si utilizamos linux no tendremos esos problemas utilizando versiones compiladas para 64 bits.

Comentarios

Kartoffel

O versiones sin compilar para 64 bits (léase Gentoo) lol

D

Soy #10. A todos los que me contestaron: tenéis razón, he metido la pata. Tenía el chip puesto en modo monousuario sin memoria virtual. Un 0xA para los que me corrigieron.

D

#10 pos como el spectrum 128, con paginación, aunque con páginas de algo mas que 16K lol lol lol lol

difuso

#19, eso no es totalmente cierto. Todo depende del modelo de memoria que uses. Lo que sí va a ocupar seguro 64 bits es un puntero, pero en C, por ejemplo, hay modelos de 64 bits que usan enteros de 32 (creo que en linux es así). Echa un ojo => http://www.unix.org/version2/whatsnew/lp64_wp.html y http://developers.sun.com/solaris/articles/solarisupgrade/64bit/Convert.html ;).

D

#51 desde el 386 y el 486 ha llovido mucho. 21 años ya...

http://en.wikipedia.org/wiki/Physical_Address_Extension

Sin acritud, todos nos equivocamos de vez en cuando.

D

Pero hay windows Xp 64 bits, no?

D

Dios, que harto estoy de que kriptopolis haga FUD, es patético, estoy totalmente convencido de que el software libre es mejor que el software privativo de microsoft, y no necesito tantas mentiras, para demostrarlo.

Creo que es desconcertante que haya un blog como este, que MIENTE Y MIENTE y se pasa el dia con las medias tintas, recuerdo el caso de como trataron lo de la rutwoska, que encontró un bug en un procesador (un procesador experimental, además) y ellos lo enfocaron como un bug en windows (blue pill) patético.

D

Uso Xp 64 bits con 8 Gb de RAM, y la verdad es que por ahora con 4 Gb sobra para todo, incluso jugar al Crysis (me consume 2'7 Gb mientras juego)

Alvarete

#1 Freak lol

kahun

#10 De primero de carrera son muchas gilipolleces que estan obsoletas o ya no se aplican, si te quedas sólo con lo que has dado en la universidad mal camino llevas.

Si quieres enterarte de cómo funciona la gestión de memoria y la implementación del bigmem en Linux pásate por aquí:
http://kernelnewbies.org

D

#10 cada tarea en ejecución tiene un espacio virtual de 4GB donde han de entrar todos sus datos, las librerias y el kernel. Esto no lo puedes incrementar por que los punteros son de 32 bits, pero el kernel si puede gestionar un espacio de memoria física muy superior a 4GB y mapear allí todas las páginas de memoria que quiera.

Esto lo dí yo en tercero si no recuerdo mal.

D

#19 "tu sistema operativo de siempre con las mismas aplicaciones te ocuparán el doble de RAM"

FALSO
Sólo ocuparán el doble los punteros, incluso las palabras siguen siendo por defecto de 32 bit (int vs. int64/u64 y tal). Además, si te fijas en lo que llevan esas aplicaciónes/sistema operativo, verás que el 95% o más son opcodes y datos que no cambian lo más mínimo al pasar a 64 bit, con lo que sólo habría que sumar un 5% de tamaño (y me da que me estoy pasando casi un 5%).

Sólo en casos muy concretos se llegará a usar casi el doble de RAM (ej: índices de bases de datos).

D

El problema es que ahora estamos en una frontera.

-> Aun no nos sale muy rentable ejecutar SSOO y aplicaciones puras de 64bits ya que cada palabra ocupa EL DOBLE en memoria (un entero, en vez de 32 bits, ocupará 64) por lo que tu sistema operativo de siempre con las mismas aplicaciones te ocuparán el doble de RAM. (Esto no estaría mal, "porque si no nunca hubieramos pasado de 16 a 32", si se notara un incremento de la velocidad y rendimiento notables, pero no es así).

-> La gente que usa 64 lo hace por que le da la gana, pero no hay un mercado amplio y EXIGENTE con hambre de 64bits, por eso la industria no da el salto.

-> La industria no da el salto por la mala propaganda que tendría que su SSOO comiera 2GB de RAM en vez de 1GB.

Pero como no hay necesidad, pues se sigue con los 32bits. Por que el usuario corriente lo que quiere es trabajar como siempre sin tener que gastarse el doble en RAM.

Y creo que de seguir así, el cambio tendremos que hacerlo por inercia, porque si os digo la verdad, los 64 bits no sirven de mucho, da muchísimo mas juego los multiprocesadores (osea integrar varios micros en la pastilla), aunque sean de 32.

D

Me he leído todos los comentarios... Ya no sé si proceso a 32, a 64, si tengo bien puesto el puntero en el kernel ese, si voy a direccionarme a algún lado o si la solución es renderizarme.... Creo que voy a por un trocito de piña...

D

#35, ahí le has dado. Algunos creen que es mejor usar Vista pirata con cracks de activación que te instalan troyanos, que echar dos tardes en configurar un SO GRATUITO Y POTENTE.

a #17: amigo mío, la RAM no es tan decisiva a la hora de jugar. La tarjeta gráfica es lo más importante. Te lo digo por propia experiencia. Hace poco salí del PC Box con los humos muy altos por haberme comprado un AMD 6400+ con 8 GB de RAM y una Geforce 8600. Los humos se me bajaron de golpe cuando vi que el Crysis no me comía ni 3gb de RAM y no lo podía poner todo al máximo (menuda cara de breba se me tuvo que quedar). Fue cambiar la gráfica, y la mejora fue sustancial. Consejo: con 4 GB por ahora, sobra bastante.

D

#22 ¿Por qué?,¿Por qué sólo los punteros tienen que ocupar 64bits?, entonces no es una arquitectura pura de 64bits (que es a lo que yo me refiero).

Si coges una arquitectura, y le cambias del bus de direcciones y el registro de direcciones para que tenga 64 bits. Pero luego direcciones a nivel de 32, y tienes que hacer la chapuza de acceder dos veces para leer punteros (ya que ocuparían 2 direcciones).

Los enteros claro que ocuparían 64bits, otra cosa es que el programador, por cuestiones de eficiencia y porque ve que no va a necesitar mas que 32 bits, decida declararlo como short o algo así.

Si se diseña una arquitectura de 64, todo tiene que ser de 64. Los registros, los buses, la ALU, las palabras de memoria, etc... Si no, entonces son parches y solucinoes guarras para salir del paso. O si no dime, como cojones sumas 2 punteros en una ALU supuestamente preparada para sumar enteros de 32, que haces, ¿Un sumador especial para punteros?. NO se... a lo mejor, pero me parece que eso no es una arquitectura de 64bits.

D

Evidentemente, #42 tiene toda la razón, pero es que esto es básico

D

si claro, 3 gb... y tirarme 10 horas renderizando..

Por cierto, mención especial al redactor del meneo por "los 32 bit no furula pero en 64 bit si" no sa jodio. Mi pregunta es ¿utiliza XP 64, 4 o mas gigas de ram? si los utiliza ¿por que ese desvio del tema o esa lucha entre 2 sistemas incompatibles?

s

vista 64 va perfecto y es bastante compatible con todo
y si quieres un windows de 32 bits con mas de 4GB RAM tienes que usar una version de servidor, mi win2003 server tiene 16GB y va genial

#19: tu te haces la picha un lio, que sea una aplicacion de 64 bits no quiere decir que un entero ocupe 64bits ... solo los punteros tienen que ocupar 64 bits

s

"3 GB de Ram deben ser suficientes para cualquier tipo de actividad". Kriptópolis, 2007

no os recuerda a algo?

D

#38 si los registros son de 32 bits, pero el procesador antes de acceder a memoria utiliza parte de la dirección como índice en una tabla y con esto mapea una dirección de 32 a una de 36, ¿No estamos utilizando más de 4GB de RAM, aunque cada aplicación independiente no pueda direccionar más de 4GB? Suspenso en SSOO y en comprensión lectora

matacca

Falta el comentario "640k son suficientes..."

D

#46 Me refiero a eficiencia en ocupación de memoria.

Osea si tienes un vector de 500 millones de enteros donde su valor no va a ser exesivamente alto, pues en vez de 4GB sólo necesitarías 2GB (con enteros de 32bits). Y sí, por lo que puedas decir, hay aplicaciones que usan semejantes vectores (y mas grandes), sobre todo en el cómputo de datos científicos.

D

#46 Te olvidas de un detalle: en un programa no todos los datos tienen que ser de 64 bits. Un flag sólo necesita un bit, una cadena de caracteres ocupará el mismo tamaño en una arquitectura de 32 que de 64 bits. Una imagen lo mismo. Y un texto... Sólo ciertos programas (por ejemplo, de proceso matemático) ocuparán el doble si se compilan para 64 bits. En general, la versiónde 64 bits necesitará sólo un poco más de espacio que la de 32.

D

#52 vale, eso podías haberlo dicho antes...
pero de todos modos, eso es una ñapa enorme que no me extraña que no venga en los libros de texto lol

D

#16 creo que se paginaban en bloques de 16k entre los 48k y los 64k que es lo máximo que direccionaba el z80, en bloques de 16k con un total de 5 páginas creo...

Cidwel

los que votan negativo a #27 no se a que se debe, tiene razon. Tanto linux como windows tienen sus versiones de 64bits. Simplemente que en una puedes elegir facilmente y sin riesgo a piratear y en la otra, te toca bajar de torrent o emule y/o distintos la correspondiente version de 64bits lol

D

#42 #44 a la tabla de marcos de página se accede con n bits y los m bits restantes (siendo n+m=N y N el número de bits del tamaño de la palabra) se usan para indicar la posición del byte referido dentro de la página, y si es un procesador típico de 32 bit, pues son 32 bit.

si os queda alguna duda, pues miráis un poquito en la wikipedia (ya no digo siquiera un libro de sistemas operativos), que no cuesta nada (bueno, sí, cuesta un poco más que darle al negativo, pero a lo mejor es mucho pedir ese esfuerzo para vosotros) y sobre la arquitectura típica que nos ocupa (i386, i486, etc.) leéis cositas como:
http://en.wikipedia.org/wiki/I386
The 80386 featured three operating modes: real mode, protected mode and virtual mode. In the real mode, the 80386 (like the 80286) would run just as a fast 8086. The protected mode allowed the use of all the possibilities of the 286 and the protected mode extension of the 386, especially addressing up to 4 GB of memory. Finally, the virtual 8086 mode (or VM86) made it possible to run one or more virtual 8086 machines in a protected environment.
http://en.wikipedia.org/wiki/I486
The 486 has a 32-bit data bus and a 32-bit address bus. This requires either four matched 30-pin SIMMs or one 72-pin SIMM. A 32-bit address bus means that 4 GiB of memory can be directly addressed.

Pero claro, a lo mejor también es mucho pedir que reconozcáis que habéis metido la gamba...

D

#25 no necesariamente. Se pueden utilizar registros especiales para punteros de 64 bits y registros de propósito general de 32 bits. No sería la primera arquitectura con punteros de tamaño diferente.

D

#18 lo que quiero decir es que un programa de 32 bits solo puede acceder a 4GB de memoria. Pero esa memoria es virtual. El kernel mantiene unas tablas llamadas LDT y GDT que mapean segmentos de esa memoria a memoria física, y estas direcciones de memoria física sí pueden direccionar más de 4GB. Lo que no se puede es asignar más de 4GB a un proceso de 32 bits, pero si pueden utilizar más memoria entre todos los procesos.

P.D:Esto en ia32

D

#17: Pues ricamente que juego yo con un GB al Quake IV. Claro que si tienes cuarenta cosas en segundo plano, chungo.

D

Yo tengo un AMD-64 con Ubuntu para 64 y el XP más de los mismo, con 2 gigas de ram DDR2; lo máximo que puedo ampliar es 1 giga más ( a 3 ) y aún así me sobraría por todas partes.

A

#15 vamos es como usar la memoria que no se puede direccionar directamente como un disco swap RAM o algo así. no?...como en el spectrum 128k

D

Que se dejen de historias y empiecen a aumentar la comunicación RAM y CPU, que el cuello de botella que hay es de órdago.

D

A mi Debian de 64bits no me arranca lol

u

La tecnología que permite direccionar hasta 64GB en procesadores Intel de 32 bits se llama PAE y no es ninguna novedad: se introdujo con el Pentium Pro hace más de 12 años. Si buscais en la wikipedia viene la lista de sistemas operativos que lo soportan:
- Linux 2.6
- Windows Server 2003 (ni XP ni Vista)
- FreeBSD 4.x y superiores
- Solaris 7 y superiores.

u

#55 los punteros Y los enteros largos. Además, se introducen huecos en las estructuras para mantener la alineación de las estructuras.

Por ejemplo las siguientes estructuras de C:
struct s1
;
struct s2
;

Las dos ocupan 12 bytes en un programa de 32 bits, pero la primera ocupa 24 y la segunda 16 bytes en uno de 64 bits. Si el código está pensado para 64 bits, sí que puede hablarse de penalizaciones entorno al 5%. Pero hoy en día apenas hay código así. Todo está diseñado para 32 bits.

i

Interesante, ya pensaba ampliar RAM, y no contaba con esto

g

¿64 bits? ¡Oh Dios mio!
¿Cuando hemos abandonado los 16? Si ya me dice mi novia que estoy de un despistado..........

d

Yo leí no hace mucho unas estadísticas de unos benchmarks que demostraban que incluso 2Gb de RAM iban muy poco mejor que 1Gb.

k

#34 si, Leopard puede gestionar mas de 4Gb de ram, y Tiger creo que tambien, pero esto ultimo no lo se seguro.

a

#36 Para un procesador de 64bits lo natural es trabajar con enteros de 64. Hacerlo con un short int de 32 en un procesador de 64 no es mas eficiente si no todo lo contrario.

LaInsistencia

#22 si los punteros ocupan 64, entonces los registros tambien ocupan 64. Por lo tanto la unidad basica tambien ocupara 64, a menos que pretendas que los operadores de la cpu puedan hacer dos intrucciones de 32 en paralelo. Otra cosa es que me digas "los procesadores chimpum quad solo empleen 32 bits y los demas son 0", lo cual ademas de inutil es una chapuza...

D

#38: "¿nadie se acuerda de Bill Gates con sus "64kb serán suficientes para todo el mundo"(no sé si era esa cantidad exacta, pero por ahí andaba)?"

Dijo 6.4kb y es exactamente eso. Lo sé porque yo estaba allí. Y ví a Bill Gates y Steve Ballmer haciendo bebés, y yo vi a los bebés, y uno de ellos se quedó mirándome.

Neofito

tb puedes tener leopard, un sistema de 64 bits y sin problemas para ver flash etc y le puedes meter todos los gigas que te de el bolsillo (si tienes un mac pro)

D

EL hardware siempre ha ido muy por delante del software, sobre todo en el mundo del PC.

Lo que hace falta es aprovechar mejor los recursos hardware, pero claro, los fabricantes prefieren venderte más hierro cada año para que no se les hunda el negocio.

A

#11 las páginas eran de 64Kb

I

y con Leopard tampoco se puede gestionar mas de 4gb????

D

Siempre sale algún iluminado diciendo que X cantidad de RAM es suficiente... y obviamente, al final se acaban mordiendo la lengua... ¿nadie se acuerda de Bill Gates con sus "64kb serán suficientes para todo el mundo"(no sé si era esa cantidad exacta, pero por ahí andaba)?

#15 En un micro de 32 bit, los punteros del kernel seguirán teniendo 32 bit y podrán direccionar como máximo 4GB, otra cosa es que la memoria virtual total (la suma de la memoria virtual de todas las aplicaciones en ejecución) sea superior, pero no la física. Suspenso en SSOO

D

Amos a ver, que esto de primero de carrera: 32 bits para direccionar bytes nos dan un total de 2^32 direcciones de byte que son 4 Gigabytes. Más de 4Gigas con 32 bits es imposible. Y si se hace con un parche del SO es una chapuza.

A

yo como siempre al igual que con linux, los putos drivers, no los encuentro ni para linux ni para XP 64...de momento tengo sólo 1 giga pero se queda corto para juegos como el quake 4, que no es que vaya mal, es que es inviable jugar.

drogalinski

"Eso sí, si utilizamos linux no tendremos esos problemas utilizando versiones compiladas para 64 bits."

O sea, tiene el mismo "problema" de Windows. Es el comentario más prejuicioso del año...

D

Pues si 4 usan Xp 64 bits... Gentoo ¿? Por que no es precisamente SENCILLO...

(Aupa Debian!!!)