-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 10:40 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 02:40:53 +0100, Carlos E. R. escribió:
Me refería al "contenido", no a las marcas.
En XML el "contenido" del documento es el texto que se encierra entre las etiquetas, o el texto que sirve para marcar un atributo.
No, no pienses en el XML como un lenguaje de programación que usa la formulación habitual (palabras clave, funciones, variables, parámetros...). Un archivo XML es poco más que un documento de texto.
Aún y todo, se hace cierto análisis.
Por otra parte, que parece que es el caso, al diseñar un editor hay dos estrategias principales: estructurar linea a linea (con lo que sueles tener un límite de tamaño de linea, fijo o variable), o estructurar por buffer de caracteres contínuo, con lo que se complica el subir y bajar por el fichero pero minimiza el uso de memoria.
En este caso concreto, el problema era de formato.
El XML, el que fallaba, al abrirlo con mcedit, todo el contenido se queda en una sola línea. Los 100 y picos megas de texto en una sola línea. El mcedit lo abría, el OOo writer, también. Pero el Gedit, debido al bug, pues empezaba a consumir RAM.
Ya.
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no.
No tendría sentido tener 8, 16 o 32 GiB. de RAM y sólo poder destinar 4 GiB a un sólo proceso ¿no...? Estoy pensando en servidores con bases de datos gigantescas o el estaciones de trabajo de renderizado 3D :-?
Pues tiene sentido, porque es lo que el procesador puede direccionar internamente. Para acceder a más hay que mapear, y el programa ha de ser consciente de que está en ese tipo de sistema.
Y si tienes bases de datos gigantescas (en memoria, ojo), pues es que no te conviene un sistema de 32 bits.
Pero es memoria virtual, no física, lo que no puede direccionar. Puede hacer un intercambio entre ambas, ambas memorias pueden "complementarse".
Da igual. El programa no distingue si es física o virtual. Simplemente acceden a la posicion de memoria trea millones, y el procesador se la da, esté donde esté. Si está en disco, pues el programa se interrumpe, y un proceso del kernel se encarga de leerla del disco y guardarla en memoria física. Cuando el programa continua, lee la memoria, y ni se entera de lo que ha pasado.
For application software which needs access to more than 4 GB of RAM, some special mechanisms may be provided by the operating system in addition to the regular PAE support. On Microsoft Windows this mechanism is called Address Windowing Extensions, while on Unix-like systems a variety of techniques are used, such as using mmap() to map regions of a file into and out of the address space as needed.
Eso son los trucos que digo de los que el programa ha de ser consciente.
Pues eso es lo que digo. Que sí pueden acceder a más de 4 GiB. Y ese remapeo es el que hace el PAE lento. Y a mayor cantidad de memoria ram física, peor >:-)
El último párrafo parece indicar que una aplicación sí puede acceder a más de 4 GiB. mediante la función mmap() :-?
Sí, indirectamente, y con perdida de eficacia.
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. 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. O sea, que no. Si tienes programas que necesiten más de cuatro gigas, emplea procesadores y sistemas de 64. 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.
Exacto, que es lo que precisamente estaba criticando Linus. Retomo del correo antiguo:
*** http://lwn.net/Articles/356724/ (...)
And for the kernel, the bigger virtual address space really is a _huge_ deal. HIGHMEM accesses really are very slow. You don't see that in user space, but I really have seen 25% performance differences between non-highmem builds and CONFIG_HIGHMEM4G enabled for things that try to put a lot of data in highmem (and the 64G one is even more expensive). And that was just with 2GB of RAM.
(inciso de Camaleón: nótese el "and the 64G one is even more expensive. And that was just with 2GB of RAM").
No le veo el sentido a codificar para 64 gigas cuando sólo tienes dos. Eso hay que probarlo en un sistema con 64 gigas de verdad.
And when it makes the difference between doing IO or not doign IO (ie caching or not caching - when the dentry cache can't grow any more because it _needs_ to be in lowmem), you can literally see an order-of- magnitude difference.
With 8GB+ of ram, I guarantee you that the kernel spent tons of time on just mappign high pages, _and_ it couldn't grow inodes and dentry caches nearly as big as it would have wanted to. Going to x86-64 makes all those issues just go away entirely.
So it's not "you can save a few instructions by not spilling to stack as much". It's a much bigger deal than that. There's a reason I personally refuse to even care about >2GB 32-bit machines. There's just no excuse these days to do that. ***
Pues claro. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktlfs4ACgkQtTMYHG2NR9U3VwCfcP1oWBQtArxuB7kAZSIEg3TT DOcAoIg9IV0RbnoAAGusoeQTTDzu4Eqp =/eDN -----END PGP SIGNATURE-----