El Sun, 31 Jan 2010 02:40:53 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 00:47 -0000, Camaleón escribió:
No es sólo cuestión de colorines, es que hay que analizar el contenido. En cierto sentido, se parece mucho a lo que tiene que hacer el programa analizador de verdad.
Qué va. No, el contenido no.
Sólo tiene que comparar en su bdd de etiquetado interno si coincide con las marcas que lee en el documento y aplicar un formato distinto, pero no analiza el contenido.
En cierto modo, sí. Hay programas que cambia el coloreado si la sintaxis es incorrecta. Lo tipico es comenzar un color en token de apertura, y terminarlo en el de cierre, para lo cual debe analizar el texto, para no disparar el cierre dentro de un comentario o de un string, que parece el token de cierre sin serlo.
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.
Luego están las facilidades de los editores como, dependiendo de en que sección estás, autocompletar, seleccionando lo que puedes añadir dependiendo del contexto, para lo cual debe analizarlo. No es un analizado completo, pero sí parcial; y un análisis aunque sea parcial puede hacerse un lio y colgarse.
El marcado se puede desactivar.
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.
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".
A ver qué dice la wikipedia¹:
*** address is not changed, so regular application software continues to use instructions with 32-bit addresses and (in a flat memory model) is limited to 4 gigabytes of virtual address space.
Eso es lo que digo.
The operating system uses page tables to map this 4 GB address space into the 64 GB of physical memory. The mapping is typically applied differently for each process. In this way, the extra memory is useful even though no single regular application can access it all simultaneously.
Exacto.
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.
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"). 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. *** Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org