[opensuse-es] Crear archivos de gran tamaño para Gedit
Hola, Me he topado con un ¿bug? muy feo en gedit ("tranquis", no lo he probado en suse :-P) y para hacer más pruebas, me gustaría saber cómo podría crear varios archivos de distinto tipo, por ejemplo, texto plano o html (cualquier formato que pueda leer el gedit), pero de gran tamaño (>100 MiB). ¿Cómo podría hacerlo? :-? ... El problema es el siguiente: el otro día abrí un archivo en formato xml de unos 100 y pico megas el en Gedit y me dejó colgado ("seco", sin recursos, sin ram) el equipo¹. Al reiniciarlo, en el registro me encontré con un bonito mensaje "OOM-killer" (out of memory killer), supongo que para poder liberar memoria. Al hacer algunas pruebas, vi que el gedit empezaba a consumir ram² de forma desmesurada. Este comportamiento no sucede con otros editores (como el mcedit o el OOo Writer) que abrían el mismo archivo sin problemas. ¹ El equipo tiene 8 GiB de ram + 2 GiB de swap. ² Imagen: http://picpaste.com/gedit.png 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-30 a las 11:55 -0000, Camaleón escribió:
Me he topado con un ¿bug? muy feo en gedit ("tranquis", no lo he probado en suse :-P) y para hacer más pruebas, me gustaría saber cómo podría crear varios archivos de distinto tipo, por ejemplo, texto plano o html (cualquier formato que pueda leer el gedit), pero de gran tamaño (>100 MiB).
Fácil, para uno de texto. Partes de un fichero de texto grande, del tamaño que quieras. Luego haces correr un script como este: rm salida.txt for X in `seq 1 1000`; do cat origen.txt >> salida.txt echo "===== trozo $X =========================== " >> salida.txt done Eso concatena 1000 veces el fichero original con una linea en medio de cada trozo, con un contador. Para ficheros con formato especial, como xml, pues no te puedo decir, porque ya sabes que no me llevo bien con ese formato y no sabría como concatenar trozos congruentes.
¿Cómo podría hacerlo? :-?
...
El problema es el siguiente: el otro día abrí un archivo en formato xml de unos 100 y pico megas el en Gedit y me dejó colgado ("seco", sin recursos, sin ram) el equipo¹. Al reiniciarlo, en el registro me encontré con un bonito mensaje "OOM-killer" (out of memory killer), supongo que para poder liberar memoria.
Al hacer algunas pruebas, vi que el gedit empezaba a consumir ram² de forma desmesurada. Este comportamiento no sucede con otros editores (como el mcedit o el OOo Writer) que abrían el mismo archivo sin problemas.
Un bug como una casa, claro. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktkMBoACgkQtTMYHG2NR9W3pACffMfwU38oAY4kk7n7QNft+q8w TCAAn0aZNiakqz2x8Ls4zXYihTBGElJb =sxE3 -----END PGP SIGNATURE-----
El Sat, 30 Jan 2010 14:11:48 +0100, Carlos E. R. escribió:
El 2010-01-30 a las 11:55 -0000, Camaleón escribió:
Me he topado con un ¿bug? muy feo en gedit ("tranquis", no lo he probado en suse :-P) y para hacer más pruebas, me gustaría saber cómo podría crear varios archivos de distinto tipo, por ejemplo, texto plano o html (cualquier formato que pueda leer el gedit), pero de gran tamaño (>100 MiB).
Fácil, para uno de texto. Partes de un fichero de texto grande, del tamaño que quieras. Luego haces correr un script como este:
rm salida.txt for X in `seq 1 1000`; do cat origen.txt >> salida.txt echo "===== trozo $X =========================== " >> salida.txt done
Eso concatena 1000 veces el fichero original con una linea en medio de cada trozo, con un contador. Para ficheros con formato especial, como xml, pues no te puedo decir, porque ya sabes que no me llevo bien con ese formato y no sabría como concatenar trozos congruentes.
Hummm, sí, vale. Algo así pero más automatizado, del tipo: "dd if=/dev/zero of=bigfile bs=1024 count=148576" "Pa" no tener que estar buscando contenido extra que pasar al archivo original y calculando el tamaño de la salida hasta que alcance el tamaño deseado O:-) 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
El Sat, 30 Jan 2010 16:41:47 +0000, Camaleón escribió:
El Sat, 30 Jan 2010 14:11:48 +0100, Carlos E. R. escribió:
rm salida.txt for X in `seq 1 1000`; do cat origen.txt >> salida.txt echo "===== trozo $X =========================== " >> salida.txt done
Eso concatena 1000 veces el fichero original con una linea en medio de cada trozo, con un contador. Para ficheros con formato especial, como xml, pues no te puedo decir, porque ya sabes que no me llevo bien con ese formato y no sabría como concatenar trozos congruentes.
Hummm, sí, vale. Algo así pero más automatizado, del tipo:
"dd if=/dev/zero of=bigfile bs=1024 count=148576"
El comando "yes" parece que me vale. *¡¡OJO, NO ejecutar!!* genera un archivo enorme (gigas) en pocos segundos. *** yes I want a BIG file > output.txt *** Hay que matarlo muy rápido con "Control+C". 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-01-30 20:03, Camaleón wrote:
El Sat, 30 Jan 2010 16:41:47 +0000, Camaleón escribió:
El Sat, 30 Jan 2010 14:11:48 +0100, Carlos E. R. escribió:
rm salida.txt for X in `seq 1 1000`; do cat origen.txt >> salida.txt echo "===== trozo $X =========================== " >> salida.txt done
Eso concatena 1000 veces el fichero original con una linea en medio de cada trozo, con un contador. Para ficheros con formato especial, como xml, pues no te puedo decir, porque ya sabes que no me llevo bien con ese formato y no sabría como concatenar trozos congruentes.
Hummm, sí, vale. Algo así pero más automatizado, del tipo:
"dd if=/dev/zero of=bigfile bs=1024 count=148576"
Pero eso es un archivo de ceros, no de texto.
El comando "yes" parece que me vale.
*¡¡OJO, NO ejecutar!!* genera un archivo enorme (gigas) en pocos segundos.
*** yes I want a BIG file > output.txt ***
Hay que matarlo muy rápido con "Control+C".
Ese sí es de texto, aunque repitiendo muchísimo una misma frase. Y de tamaño no controlado. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAktkhsoACgkQU92UU+smfQUFtQCfbgdy54W3s9EsZs+P+MN2xCLX yO0AoJSyZSnsUtttxlrFHDURJOtmOHBT =JL2i -----END PGP SIGNATURE----- -- 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
El Sat, 30 Jan 2010 20:21:46 +0100, Carlos E. R. escribió:
On 2010-01-30 20:03, Camaleón wrote:
Eso concatena 1000 veces el fichero original con una linea en medio de cada trozo, con un contador. Para ficheros con formato especial, como xml, pues no te puedo decir, porque ya sabes que no me llevo bien con ese formato y no sabría como concatenar trozos congruentes.
Hummm, sí, vale. Algo así pero más automatizado, del tipo:
"dd if=/dev/zero of=bigfile bs=1024 count=148576"
Pero eso es un archivo de ceros, no de texto.
Claro, lo he puesto como ejemplo de lo que buscaba.
El comando "yes" parece que me vale.
(...)
Ese sí es de texto, aunque repitiendo muchísimo una misma frase. Y de tamaño no controlado.
Lo bueno que tiene es que es genera el archivo al instante y automáticamente. Ya tengo un archivo de 50 MiB, otro de 134 MiB y otro de 265 MiB. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-30 a las 11:55 -0000, Camaleón escribió:
Al hacer algunas pruebas, vi que el gedit empezaba a consumir ram² de forma desmesurada. Este comportamiento no sucede con otros editores (como el mcedit o el OOo Writer) que abrían el mismo archivo sin problemas.
Hay un truco para evitar que una aplicación se desborde tirando el sistema: ~> ulimit -v 300000 ~> gedit lo que sea. Si supera esa cantidad de memoria, muere asesinada; y probablemente genere un dump que se pueda usar para reportar el bug (depende). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktkMQAACgkQtTMYHG2NR9U9NgCdGEI0owMXWxYdQRNU1jWQZ4+M h00An2h3LX1Q+5bJnX3oEx5OsGi9Q83r =MxD5 -----END PGP SIGNATURE-----
El Sat, 30 Jan 2010 14:15:41 +0100, Carlos E. R. escribió:
El 2010-01-30 a las 11:55 -0000, Camaleón escribió:
Al hacer algunas pruebas, vi que el gedit empezaba a consumir ram² de forma desmesurada. Este comportamiento no sucede con otros editores (como el mcedit o el OOo Writer) que abrían el mismo archivo sin problemas.
Hay un truco para evitar que una aplicación se desborde tirando el sistema:
~> ulimit -v 300000 ~> gedit lo que sea.
Si supera esa cantidad de memoria, muere asesinada; y probablemente genere un dump que se pueda usar para reportar el bug (depende).
No se me había ocurrido que un "archivito" de 100 MiB pudiera generar tal colapso en un equipo con 8 GiB de ram y 4 núcleos O:-). Veamos como tengo los límites predeterminados: stt008:~# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 73728 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 73728 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Huys, esto parece que está un poco "ilimitao". ¿Cómo lo tenéis configurado en "suselandia"? :-) Pues es una buena idea. Usaré ese límite para hacer las pruebas, así al menos se suicidará el solito cuando llegue a los 3 GiB. Hum, para 3 GiB sería "ulimit -v 3146000" ¿no? porque veo que está expresado en kbytes. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-01-30 17:53, Camaleón wrote:
El Sat, 30 Jan 2010 14:15:41 +0100, Carlos E. R. escribió:
Hay un truco para evitar que una aplicación se desborde tirando el sistema:
~> ulimit -v 300000 ~> gedit lo que sea.
Si supera esa cantidad de memoria, muere asesinada; y probablemente genere un dump que se pueda usar para reportar el bug (depende).
No se me había ocurrido que un "archivito" de 100 MiB pudiera generar tal colapso en un equipo con 8 GiB de ram y 4 núcleos O:-).
Probablemente no sea el fichero en sí, sino el contenido del fichero, que como es de sintaxis, intentará parsearlo para colorearlo y tal, y entrará en un bucle o algo. Podrías intentar verlo con strace y familia - y ojo, esa familia genera ficheros de texto muy grandes, por cierto. Yo tuve un problema similar con el kbabel, que me tomó varios gigas de memoria, teniendo sólo uno. O sea, swap...
Veamos como tengo los límites predeterminados:
stt008:~# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 73728 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 73728 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Huys, esto parece que está un poco "ilimitao". ¿Cómo lo tenéis configurado en "suselandia"? :-)
Casi igual (32 bits): cer@bombadillo:~> ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 64217 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 64217 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
Pues es una buena idea. Usaré ese límite para hacer las pruebas, así al menos se suicidará el solito cuando llegue a los 3 GiB.
Hum, para 3 GiB sería "ulimit -v 3146000" ¿no? porque veo que está expresado en kbytes.
Sí, pero da igual que pongas 3 GiB exactos o aproximados. 3 GiB = 3072 MiB = 3145728 KiB = 3221225472 bytes. Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-) - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAktkiPkACgkQU92UU+smfQVjOQCcCk8Pa/fRNH0EfP66jKTGTTfz ow8An3CEUaVlYfkxDOVQotr4FV+nd/nN =+qAx -----END PGP SIGNATURE----- -- 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
El Sat, 30 Jan 2010 20:31:05 +0100, Carlos E. R. escribió:
On 2010-01-30 17:53, Camaleón wrote:
No se me había ocurrido que un "archivito" de 100 MiB pudiera generar tal colapso en un equipo con 8 GiB de ram y 4 núcleos O:-).
Probablemente no sea el fichero en sí, sino el contenido del fichero, que como es de sintaxis, intentará parsearlo para colorearlo y tal, y entrará en un bucle o algo. Podrías intentar verlo con strace y familia - y ojo, esa familia genera ficheros de texto muy grandes, por cierto.
Puede ser, pero vaya tela. Si casca por activar la sintaxis coloreada es peor aún >:-)
Yo tuve un problema similar con el kbabel, que me tomó varios gigas de memoria, teniendo sólo uno. O sea, swap...
Veamos como tengo los límites predeterminados:
stt008:~# ulimit -a
(...)
Casi igual (32 bits):
cer@bombadillo:~> ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 64217 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 64217 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
"Tamos apañaos", pues :-)
Pues es una buena idea. Usaré ese límite para hacer las pruebas, así al menos se suicidará el solito cuando llegue a los 3 GiB.
Hum, para 3 GiB sería "ulimit -v 3146000" ¿no? porque veo que está expresado en kbytes.
Sí, pero da igual que pongas 3 GiB exactos o aproximados.
3 GiB = 3072 MiB = 3145728 KiB = 3221225472 bytes.
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-30 a las 19:50 -0000, Camaleón escribió:
El Sat, 30 Jan 2010 20:31:05 +0100, Carlos E. R. escribió:
No se me había ocurrido que un "archivito" de 100 MiB pudiera generar tal colapso en un equipo con 8 GiB de ram y 4 núcleos O:-).
Probablemente no sea el fichero en sí, sino el contenido del fichero, que como es de sintaxis, intentará parsearlo para colorearlo y tal, y entrará en un bucle o algo. Podrías intentar verlo con strace y familia - y ojo, esa familia genera ficheros de texto muy grandes, por cierto.
Puede ser, pero vaya tela. Si casca por activar la sintaxis coloreada es peor aún >:-)
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.
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktkwvUACgkQtTMYHG2NR9UQAQCglI3i/4vZzC1g5HRlEfENC4o3 PosAoJS6qumdLuW3glBbh8YxxiIncAVl =aGrc -----END PGP SIGNATURE-----
On Domingo, 31 de Enero de 2010 00:38:21 Carlos E. R. escribió:
El 2010-01-30 a las 19:50 -0000, Camaleón escribió:
El Sat, 30 Jan 2010 20:31:05 +0100, Carlos E. R. escribió:
No se me había ocurrido que un "archivito" de 100 MiB pudiera generar tal colapso en un equipo con 8 GiB de ram y 4 núcleos O:-).
Probablemente no sea el fichero en sí, sino el contenido del fichero, que como es de sintaxis, intentará parsearlo para colorearlo y tal, y entrará en un bucle o algo. Podrías intentar verlo con strace y familia - y ojo, esa familia genera ficheros de texto muy grandes, por cierto.
Puede ser, pero vaya tela. Si casca por activar la sintaxis coloreada es peor aún >:-)
No sé si llego mi mensaje pero me refería a esto.. un aeditor de texto es presumible que "pinte" directamente desde un segmento mmaped pero cuando usas librerias especiales y coloredo y tal puede que el archivo se convierta en una estructura muchos más pesada por lo que 100Mb de nada se pueden ir a.... En erlang por ejemplo, si no usas binarios las estrcuttras de datos no solo coupan un huevo (comparado con un char * de C) sino que se copian una y otra vez... es decir un editor de texto debe estar muy bien pensado para mantener el tipo. Podria pasar los mismo con KDE y GNOME
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.
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no.
-- 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
El Sun, 31 Jan 2010 00:38:21 +0100, Carlos E. R. escribió:
El 2010-01-30 a las 19:50 -0000, Camaleón escribió:
Puede ser, pero vaya tela. Si casca por activar la sintaxis coloreada es peor aún >:-)
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.
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
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 :-? De hecho, de eso mismo estuvimos hablando en el hilo del test de rendimiento que llevaron a cabo los de Phoronix sobre kernels de Ubuntu de 32 bits, 32 bits PAE (aguachinado) y 64 bits. Las variables eran estas dos: CONFIG_HIGHMEM4G CONFIG_HIGHMEM64G A ver qué dice la wikipedia¹: *** x86 processor hardware architecture is augmented with additional address lines used to select the additional memory, so physical address size is increased from 32 bits to 36 bits. This, theoretically, increases maximum physical memory size from 4 GB to 64 GB. The 32-bit size of the virtual 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. 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. 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. *** El último párrafo parece indicar que una aplicación sí puede acceder a más de 4 GiB. mediante la función mmap() :-? ¹ http://en.wikipedia.org/wiki/Physical_Address_Extension 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 00:47 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 00:38:21 +0100, Carlos E. R. escribió:
El 2010-01-30 a las 19:50 -0000, Camaleón escribió:
Puede ser, pero vaya tela. Si casca por activar la sintaxis coloreada es peor aún >:-)
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. 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. 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.
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
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.
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.
***
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. Son trucos muy viejos: recuerda que hubo un tiempo en que los procesadores eran de 8 bits y sólo podían redireccionar 64 kilobits. El mapeo podía hacerse con registros de memoria externos, multiplexadores, y otros trucos "horribles". El procesador podía pedir una dirección 32000, y en su lugar recibía la 132000, sin saberlo, porque un chip cambiaba los cables del bus de direcciones de memoria en la placa. Ahora son más limpios, pero la idea básica es parecida. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktk36wACgkQtTMYHG2NR9WEWgCfU/rmjEYSsics+pdUwgL2hn7c 5AgAn1XuV2Hu9Ko/8+8migSL7jB5bsDr =y6DO -----END PGP SIGNATURE-----
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
On Domingo, 31 de Enero de 2010 11:40:12 Camaleón escribió:
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,
Efectivamente, La "tiranía" de linus está muy bien fundamentada, me recuerda al caso de Drepper. Pero se conoce la arquitectura al dedillo y tiene mas razón que un santo... estamos otra vez con la EMS y la XMS si seguimos apretandole a los 32 bits. -- Most people know C is not so high level.... ...Everybody else just got assembler overdose -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 13:22 +0100, Angel escribió:
Efectivamente, La "tiranía" de linus está muy bien fundamentada, me recuerda al caso de Drepper. Pero se conoce la arquitectura al dedillo y tiene mas razón que un santo... estamos otra vez con la EMS y la XMS si seguimos apretandole a los 32 bits.
Pero desgraciadamente, los sistemas de 64 bits siguen estando verdes en algunas cosas. Codecs, por ejemplo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktlfywACgkQtTMYHG2NR9XqyACgj2dk+SHffT3+WzDAWvg9Q8YC 1NAAn34Dbg8sJ0/qPTAOyv3CEMBxQqX/ =KBd/ -----END PGP SIGNATURE-----
El Sun, 31 Jan 2010 14:01:31 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 13:22 +0100, Angel escribió:
Efectivamente, La "tiranía" de linus está muy bien fundamentada, me recuerda al caso de Drepper. Pero se conoce la arquitectura al dedillo y tiene mas razón que un santo... estamos otra vez con la EMS y la XMS si seguimos apretandole a los 32 bits.
Pero desgraciadamente, los sistemas de 64 bits siguen estando verdes en algunas cosas. Codecs, por ejemplo.
¿Qué tipo de vídeos te has encontrado que no puedas reproducir en un sistema de 64 bits? 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 15:12 -0000, Camaleón escribió:
Pero desgraciadamente, los sistemas de 64 bits siguen estando verdes en algunas cosas. Codecs, por ejemplo.
¿Qué tipo de vídeos te has encontrado que no puedas reproducir en un sistema de 64 bits?
Yo no lo he probado todavia, pero aqui se ha dicho. Cuando instale el bombadil definitivo, tengo reservada una particion para probarlo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktlu6gACgkQtTMYHG2NR9UCzgCfd5/6NGU+R8kZaRHIE5CCZ9lI 57YAn3kJX4hAsAUy8HWSKLJecAtE/HpT =eJ+R -----END PGP SIGNATURE-----
El Sun, 31 Jan 2010 18:19:33 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 15:12 -0000, Camaleón escribió:
Pero desgraciadamente, los sistemas de 64 bits siguen estando verdes en algunas cosas. Codecs, por ejemplo.
¿Qué tipo de vídeos te has encontrado que no puedas reproducir en un sistema de 64 bits?
Yo no lo he probado todavia, pero aqui se ha dicho. Cuando instale el bombadil definitivo, tengo reservada una particion para probarlo.
Cuando encuentres/éis alguno nos lo dices/decís. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 17:52 -0000, Camaleón escribió:
¿Qué tipo de vídeos te has encontrado que no puedas reproducir en un sistema de 64 bits?
Yo no lo he probado todavia, pero aqui se ha dicho. Cuando instale el bombadil definitivo, tengo reservada una particion para probarlo.
Cuando encuentres/éis alguno nos lo dices/decís.
Preguntale a Juan, creo que lo dijo él. Pero echa un vistazo: existe "w32codec-all", pero no "w64codec". - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktl16kACgkQtTMYHG2NR9XNpQCfbz40dZtYU6fstvDe21KJZHVv ao0An13Ip5AoQYbdxJvL2v1jw/RPgVUH =8wBt -----END PGP SIGNATURE-----
El Sun, 31 Jan 2010 20:19:03 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 17:52 -0000, Camaleón escribió:
¿Qué tipo de vídeos te has encontrado que no puedas reproducir en un sistema de 64 bits?
Yo no lo he probado todavia, pero aqui se ha dicho. Cuando instale el bombadil definitivo, tengo reservada una particion para probarlo.
Cuando encuentres/éis alguno nos lo dices/decís.
Preguntale a Juan, creo que lo dijo él. Pero echa un vistazo: existe "w32codec-all", pero no "w64codec".
La mayor parte de los codecs se incluyen en los paquetes como "gstreamer", o en soluciones como Videolan que los llevan de serie, por eso lo preguntaba. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 20:11 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 20:19:03 +0100, Carlos E. R. escribió:
Cuando encuentres/éis alguno nos lo dices/decís.
Preguntale a Juan, creo que lo dijo él. Pero echa un vistazo: existe "w32codec-all", pero no "w64codec".
La mayor parte de los codecs se incluyen en los paquetes como "gstreamer", o en soluciones como Videolan que los llevan de serie, por eso lo preguntaba.
Pero no todos. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktmD+QACgkQtTMYHG2NR9UPCgCfW1Mag8BFcaYCNAtl79OIN3rP 3q8Anjy5Vyp0auu2B0hz8HgsyMEVGf/e =E/0f -----END PGP SIGNATURE-----
El Mon, 01 Feb 2010 00:18:58 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 20:11 -0000, Camaleón escribió:
La mayor parte de los codecs se incluyen en los paquetes como "gstreamer", o en soluciones como Videolan que los llevan de serie, por eso lo preguntaba.
Pero no todos.
Pues ya nos dirás cuáles no. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.1002020037480.20885@nimrodel.valinor> El 2010-02-01 a las 06:47 -0000, Camaleón escribió:
El Mon, 01 Feb 2010 00:18:58 +0100, Carlos E. R. escribió:
La mayor parte de los codecs se incluyen en los paquetes como "gstreamer", o en soluciones como Videolan que los llevan de serie, por eso lo preguntaba.
Pero no todos.
Pues ya nos dirás cuáles no.
Ya te lo he dicho, los w32codec-all, para empezar. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktnZesACgkQtTMYHG2NR9UIpgCePEMz0sbZhrco8mWAsdNO/ggI AqMAn1GcnQXFSe2N7AVv0ou0DOne6jB6 =L99Q -----END PGP SIGNATURE-----
El Tue, 02 Feb 2010 00:38:17 +0100, Carlos E. R. escribió:
El 2010-02-01 a las 06:47 -0000, Camaleón escribió:
El Mon, 01 Feb 2010 00:18:58 +0100, Carlos E. R. escribió:
La mayor parte de los codecs se incluyen en los paquetes como "gstreamer", o en soluciones como Videolan que los llevan de serie, por eso lo preguntaba.
Pero no todos.
Pues ya nos dirás cuáles no.
Ya te lo he dicho, los w32codec-all, para empezar.
Ese pack ya no es necesario, salvo que necesites algún codec extraño que no esté soportado por "libavcodec". Lo pone en la misma página del MPlayer. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-02-02 a las 08:49 -0000, Camaleón escribió:
El Tue, 02 Feb 2010 00:38:17 +0100, Carlos E. R. escribió:
Pues ya nos dirás cuáles no.
Ya te lo he dicho, los w32codec-all, para empezar.
Ese pack ya no es necesario, salvo que necesites algún codec extraño que no esté soportado por "libavcodec".
Lo pone en la misma página del MPlayer.
No todo es mplayer. Yo uso xine. Ahora mismo estoy instalando la de 64 en el de al lado. Ya veremos. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktomYkACgkQtTMYHG2NR9W6wwCdGXtjqTIuqEF8qJZeFKZG05uE BjcAn05eumMT3e3v3hcISqS8hbZ89R28 =cmx+ -----END PGP SIGNATURE-----
El Tue, 02 Feb 2010 22:30:38 +0100, Carlos E. R. escribió:
El 2010-02-02 a las 08:49 -0000, Camaleón escribió:
Ya te lo he dicho, los w32codec-all, para empezar.
Ese pack ya no es necesario, salvo que necesites algún codec extraño que no esté soportado por "libavcodec".
Lo pone en la misma página del MPlayer.
No todo es mplayer. Yo uso xine. Ahora mismo estoy instalando la de 64 en el de al lado. Ya veremos.
Cierto, no todo es MPlayer. Si he dicho MPlayer es porque es uno de los reproductores que más tipos de codecs admite sin necesidad de añadidos. Si quieres usar un reproductor concreto, tendrás que ver qué soporte tiene de códecs y si están disponibles en ambas plataformas. Pero siendo traductor de xine, lo mejor sería que preguntaras directamente a los desarrolladores a ver en qué estado se encuentra actualmente y así no te llevas sorpresas. Lo que vengo a decir es que basar la elección de una arquitectura u otra en base a la disponibilidad de codecs multimedia, a día de hoy creo que ya no tiene mucho sentido (hace unos años no hubiera dicho lo mismo), salvo claro está, que tengas unas necesidades muy concretas. 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
-----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-----
El Sun, 31 Jan 2010 13:59:50 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 10:40 -0000, Camaleón escribió:
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.
Con un kernel de 32 bits sin PAE, no.
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.
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.
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.
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.
Pues eso es lo que estaban discutiendo. Que el mero hecho de compilar el kernel con esa opción del HIGHMEM ralentiza las operaciones de memoria una barbaridad. 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
-----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-----
El Sun, 31 Jan 2010 16:15:48 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 13:30 -0000, Camaleón escribió:
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.
Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005... *** tub -- evade TASK_UNMAPPED_BASE http://www.bitwagon.com/tub.html "(...) tub is a user-mode hack which works around the problem on today's Linux for x86. When linked into the application, then tub intercepts all mmap(0, ...), chooses from its master list the page frames to be used, and calls the kernel with mmap(frame_address,,,MAP_FIXED,,). In effect, tub allows the application to set task_unmapped_base to any address. Setting task_unmapped_base = brk(0); allows for maximum contiguous address space." 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
On Domingo, 31 de Enero de 2010 17:17:30 Camaleón escribió:
El Sun, 31 Jan 2010 16:15:48 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 13:30 -0000, Camaleón escribió:
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.
Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005...
*** tub -- evade TASK_UNMAPPED_BASE http://www.bitwagon.com/tub.html
"(...) tub is a user-mode hack which works around the problem on today's Linux for x86. When linked into the application, then tub intercepts all mmap(0, ...), chooses from its master list the page frames to be used, and calls the kernel with mmap(frame_address,,,MAP_FIXED,,). In effect, tub allows the application to set task_unmapped_base to any address. Setting task_unmapped_base = brk(0); allows for maximum contiguous address space."
Saludos,
jeje ! igualito que antes ... interceptas la INT21H y hala!! (bueno será la INT 80H), parace que volvemos a MSDOS... Salu2 -- Most people know C is not so high level.... ...Everybody else just got assembler overdose -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 16:17 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 16:15:48 +0100, Carlos E. R. escribió:
Pues eso, que *sí* pueden.
Que no.
Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005...
Que no, que no lo entiendes. No puedes hacer: mov ax,[5000000000] - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktluxsACgkQtTMYHG2NR9VvXwCfcppeI6owWgtygd72zY0HLEVf fHIAn25n+LVW3Um6U+E5wWymuNK21HZ3 =qUPr -----END PGP SIGNATURE-----
El Sun, 31 Jan 2010 18:16:58 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 16:17 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 16:15:48 +0100, Carlos E. R. escribió:
Pues eso, que *sí* pueden.
Que no.
Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005...
Que no, que no lo entiendes.
Eso explícaselo al autor del "tub", no a mí ;-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 17:49 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 18:16:58 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 16:17 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 16:15:48 +0100, Carlos E. R. escribió:
Pues eso, que *sí* pueden.
Que no.
Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005...
Que no, que no lo entiendes.
Eso explícaselo al autor del "tub", no a mí ;-)
El del tub concuerda con lo que yo digo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktl1soACgkQtTMYHG2NR9X93wCeOLkQHF17fqjqZ9MZlhJ+Efbp WK4AnjoLQIYTdvn+N8Xc6AJ4CEbPw6H/ =tYbn -----END PGP SIGNATURE-----
El Sun, 31 Jan 2010 20:15:20 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 17:49 -0000, Camaleón escribió:
Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005...
Que no, que no lo entiendes.
Eso explícaselo al autor del "tub", no a mí ;-)
El del tub concuerda con lo que yo digo.
Entonces es que no lo has entendido o es que no lo quieres entender. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 20:02 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 20:15:20 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 17:49 -0000, Camaleón escribió:
Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005...
Que no, que no lo entiendes.
Eso explícaselo al autor del "tub", no a mí ;-)
El del tub concuerda con lo que yo digo.
Entonces es que no lo has entendido o es que no lo quieres entender.
No, eres tú quien no lo entiende. Simplemente intenta compilar en assembler de una máquina de 32 bits la instrucción que te puse, y verás como no puedes. Con pae y sin pae, es así. Limite estructural o lo que quieras llamarlo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEUEARECAAYFAktl/ywACgkQtTMYHG2NR9VhBQCY61XfvFe2O91v6Z4aaGsGz9Ai jgCggN3BnBfzCDxBbiYPMaO5yJAKHqk= =/5t2 -----END PGP SIGNATURE-----
El Sun, 31 Jan 2010 23:07:34 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 20:02 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 20:15:20 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 17:49 -0000, Camaleón escribió:
Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005...
Que no, que no lo entiendes.
Eso explícaselo al autor del "tub", no a mí ;-)
El del tub concuerda con lo que yo digo.
Entonces es que no lo has entendido o es que no lo quieres entender.
No, eres tú quien no lo entiende. Simplemente intenta compilar en assembler de una máquina de 32 bits la instrucción que te puse, y verás como no puedes. Con pae y sin pae, es así. Limite estructural o lo que quieras llamarlo.
A ver, Carlos, que esto tiene visos de alargarse más de la cuenta y no quiero líos ni tampoco quiero discutir contigo. Prefiero entender las cosas, así que si digo algo que no sea cierto, me lo dices y ya está. En la Wikipedia (en relación al PAE), decía lo siguiente: *** (...) 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. *** Es decir, entiendo que lo quiere decir es que para que una aplicación -de 32 bits- pueda acceder a más de esos 4 GiB. (2 GiB.) de memoria, además de tener habilitado el PAE, hace falta utilizar un "añadido", como es el caso del AWE (en sistemas Windows) y de mmap() en sistemas Linux. ¿Correcto? Sigo. Leyendo la documentación del AWE -que lo explica bastante bien, por cierto- me da entender que esta "extensión", al igual que el mmap() en Linux, lo que permite es que una aplicación (o un proceso) pueda acceder a mayor cantidad de memoria, siempre en función de la cantidad de RAM física que se tenga instalada. *** http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx Address Windowing Extensions Address Windowing Extensions (AWE) is a set of extensions that allows an application to quickly manipulate physical memory greater than 4GB. Certain data-intensive applications, such as database management systems and scientific and engineering software, need access to very large caches of data. In the case of very large data sets, restricting the cache to fit within an application's 2GB of user address space is a severe restriction. In these situations, the cache is too small to properly support the application. AWE solves this problem by allowing applications to directly address huge amounts of memory while continuing to use 32-bit pointers. AWE allows applications to have data caches larger than 4GB (where sufficient physical memory is present). AWE uses physical nonpaged memory and window views of various portions of this physical memory within a 32-bit virtual address space. *** Y pongo el ejemplo del AWE porque se entiende perfectamente el concepto de lo que hace, cómo lo hace y de para qué sirve. Y lo pongo porque es exactamente en lo que estaba pensando: que no tiene mucho sentido que una aplicación de 32 bits no pueda acceder a más RAM cuando se tiene instalado un sistema operativo que soporte PAE. Ahora bien, si me dices que el mmap() NO sirve para hacer esto mismo pero en entornos Linux -que es básicamente lo que he interpretado que permitía hacer ese "tub"-, entonces: a) El texto de la Wikipedia está equivocado al pretender englobarlos los dos conceptos (AWE y mmap) cuando obviamente son distintos y cada uno tiene funcionalidades diferentes. b) Tampoco he entendido para qué sirve el AWE :-) 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
On Lunes, 1 de Febrero de 2010 00:19:51 Camaleón escribió:
El Sun, 31 Jan 2010 23:07:34 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 20:02 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 20:15:20 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 17:49 -0000, Camaleón escribió:
> Aquí explicaban cómo hacerlo, con las "artimañas" del mmap(), una > pizca de C y ensamblador. En apenas 62 KiB. Y es del año 2005...
Que no, que no lo entiendes.
Eso explícaselo al autor del "tub", no a mí ;-)
El del tub concuerda con lo que yo digo.
Entonces es que no lo has entendido o es que no lo quieres entender.
No, eres tú quien no lo entiende. Simplemente intenta compilar en assembler de una máquina de 32 bits la instrucción que te puse, y verás como no puedes. Con pae y sin pae, es así. Limite estructural o lo que quieras llamarlo.
A ver, Carlos, que esto tiene visos de alargarse más de la cuenta y no quiero líos ni tampoco quiero discutir contigo. Prefiero entender las cosas, así que si digo algo que no sea cierto, me lo dices y ya está.
En la Wikipedia (en relación al PAE), decía lo siguiente:
*** (...) 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. ***
Es decir, entiendo que lo quiere decir es que para que una aplicación -de 32 bits- pueda acceder a más de esos 4 GiB. (2 GiB.) de memoria, además de tener habilitado el PAE, hace falta utilizar un "añadido", como es el caso del AWE (en sistemas Windows) y de mmap() en sistemas Linux.
¿Correcto?
Sigo.
Leyendo la documentación del AWE -que lo explica bastante bien, por cierto- me da entender que esta "extensión", al igual que el mmap() en Linux, lo que permite es que una aplicación (o un proceso) pueda acceder a mayor cantidad de memoria, siempre en función de la cantidad de RAM física que se tenga instalada.
*** http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
Address Windowing Extensions
Address Windowing Extensions (AWE) is a set of extensions that allows an application to quickly manipulate physical memory greater than 4GB. Certain data-intensive applications, such as database management systems and scientific and engineering software, need access to very large caches of data. In the case of very large data sets, restricting the cache to fit within an application's 2GB of user address space is a severe restriction. In these situations, the cache is too small to properly support the application.
AWE solves this problem by allowing applications to directly address huge amounts of memory while continuing to use 32-bit pointers. AWE allows applications to have data caches larger than 4GB (where sufficient physical memory is present). AWE uses physical nonpaged memory and window views of various portions of this physical memory within a 32-bit virtual address space. ***
Y pongo el ejemplo del AWE porque se entiende perfectamente el concepto de lo que hace, cómo lo hace y de para qué sirve.
Y lo pongo porque es exactamente en lo que estaba pensando: que no tiene mucho sentido que una aplicación de 32 bits no pueda acceder a más RAM cuando se tiene instalado un sistema operativo que soporte PAE.
Ahora bien, si me dices que el mmap() NO sirve para hacer esto mismo pero en entornos Linux -que es básicamente lo que he interpretado que permitía hacer ese "tub"-, entonces:
a) El texto de la Wikipedia está equivocado al pretender englobarlos los dos conceptos (AWE y mmap) cuando obviamente son distintos y cada uno tiene funcionalidades diferentes.
b) Tampoco he entendido para qué sirve el AWE :-)
Saludos,
yo creo haber entendido que AWE = EMS mas o menos o XMS si me apuras que para el caso era igual. Yo he hecho aplicaciones con EMS/XMS y no variaba muchos mas que la posisicon de buffer(window en AWE) y las llamadas a gestor de memeoris extendida o al limulador. Salu2 -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-31 a las 23:19 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 23:07:34 +0100, Carlos E. R. escribió:
A ver, Carlos, que esto tiene visos de alargarse más de la cuenta y no quiero líos ni tampoco quiero discutir contigo. Prefiero entender las cosas, así que si digo algo que no sea cierto, me lo dices y ya está.
Es que como no eres programadora (assembler), no lo entiendes.
En la Wikipedia (en relación al PAE), decía lo siguiente:
*** (...) 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. ***
Es decir, entiendo que lo quiere decir es que para que una aplicación -de 32 bits- pueda acceder a más de esos 4 GiB. (2 GiB.) de memoria, además de tener habilitado el PAE, hace falta utilizar un "añadido", como es el caso del AWE (en sistemas Windows) y de mmap() en sistemas Linux.
¿Correcto?
Sí, todo eso es correcto.
Sigo.
Leyendo la documentación del AWE -que lo explica bastante bien, por cierto- me da entender que esta "extensión", al igual que el mmap() en Linux, lo que permite es que una aplicación (o un proceso) pueda acceder a mayor cantidad de memoria, siempre en función de la cantidad de RAM física que se tenga instalada.
*** http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
Address Windowing Extensions
Address Windowing Extensions (AWE) is a set of extensions that allows an application to quickly manipulate physical memory greater than 4GB. Certain data-intensive applications, such as database management systems and scientific and engineering software, need access to very large caches of data. In the case of very large data sets, restricting the cache to fit within an application's 2GB of user address space is a severe restriction. In these situations, the cache is too small to properly support the application.
AWE solves this problem by allowing applications to directly address huge amounts of memory while continuing to use 32-bit pointers. AWE allows applications to have data caches larger than 4GB (where sufficient physical memory is present). AWE uses physical nonpaged memory and window views of various portions of this physical memory within a 32-bit virtual address space. ***
Y pongo el ejemplo del AWE porque se entiende perfectamente el concepto de lo que hace, cómo lo hace y de para qué sirve.
Pero fíjate bien: hablan de manipular memoria y tal, no de "direccionar" memoria. Lo que hacen es ver la memoria a través de la ventana. La ventana está limitada a cuatro gigas (o menos si el sistema se reserva un cacho, que lo hace). Pero la ventana se mueve por toda la memoria, por encima de ese limite. Una instrucción del procesador, para acceso a memoria, sólo puede acceder a cuatro gigas, estrictamente dentro de la ventana vigente; lo que pasa es que esa ventana de cuatro gigas puede empezar en el punto 3G u 7G o donde sea, lo cual se hace mediante funciones de librerías especiales. ¿Me entiendes ahora? - -----memoria 16 gigas------------------------------- ·················[-vent-4GiB-]······················ < Lo que ve | el programa es sólo | el interior de la ventana | activa ahora mismo. El truco <--+--> es mover la ventana. O agarrador para mover la ventana No es que los textos que has leido esten mal. Están perfectos, pero escritos en "programese". Hace falta conocer su modo de hablar y ciertos principios. Te falta esa base y no pillas el matiz de lo que digo. Y el mover esa ventana supone una penalización para el proceso, y para el kernel (que también necesitará ventanas, a no ser que cambien el procesador de modo 32 a 64 y viceversa, que no se si se puede), y para el resto de procesos. Es una solución temporal mientras todo el mundo migra a 64 bits. Y parte de ese mundo no tiene intención de migrar mientras no les obliguen a la fuerza. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktmFdcACgkQtTMYHG2NR9VJ0ACfX2zmU9qy3ap1hyjOVdqOU2p0 QAAAoIJPfS8FKceMOv/+0QOL6tE6h6uc =jOTn -----END PGP SIGNATURE-----
El Mon, 01 Feb 2010 00:44:21 +0100, Carlos E. R. escribió:
El 2010-01-31 a las 23:19 -0000, Camaleón escribió:
El Sun, 31 Jan 2010 23:07:34 +0100, Carlos E. R. escribió:
A ver, Carlos, que esto tiene visos de alargarse más de la cuenta y no quiero líos ni tampoco quiero discutir contigo. Prefiero entender las cosas, así que si digo algo que no sea cierto, me lo dices y ya está.
Es que como no eres programadora (assembler), no lo entiendes.
No, pero sé leer.
En la Wikipedia (en relación al PAE), decía lo siguiente:
(...)
¿Correcto?
Sí, todo eso es correcto.
Ah, menos mal.
Sigo.
Leyendo la documentación del AWE -que lo explica bastante bien, por cierto- me da entender que esta "extensión", al igual que el mmap() en Linux, lo que permite es que una aplicación (o un proceso) pueda acceder a mayor cantidad de memoria, siempre en función de la cantidad de RAM física que se tenga instalada.
*** http://msdn.microsoft.com/en-us/library/aa366527(VS.85).aspx
(...)
Y pongo el ejemplo del AWE porque se entiende perfectamente el concepto de lo que hace, cómo lo hace y de para qué sirve.
Pero fíjate bien: hablan de manipular memoria y tal, no de "direccionar" memoria.
(...)
No es que los textos que has leido esten mal. Están perfectos, pero escritos en "programese". Hace falta conocer su modo de hablar y ciertos principios. Te falta esa base y no pillas el matiz de lo que digo.
No hay ningún matiz que se escape ni la explicación está escrita en algún lenguaje "oculto". La respuesta sólo admite /sí/ (un programa de 32 bits puede acceder a más de 2 GiB) o /no/ (un programa de 32 bits no puede acceder a más de 2 GiB). Y la respuesta es que sí. Si quieres marear la perdiz para intentar justificar tu argumentación, eso es problema tuyo :-) 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-02-01 a las 07:02 -0000, Camaleón escribió:
No hay ningún matiz que se escape ni la explicación está escrita en algún lenguaje "oculto". La respuesta sólo admite /sí/ (un programa de 32 bits puede acceder a más de 2 GiB) o /no/ (un programa de 32 bits no puede acceder a más de 2 GiB).
Acceder, sí. Direccionar, no. Si no entiendes la diferencia, es que no entiendes de programación. Angel me ha entendido perfectamente. Intenta simplemente hacer cosas en C como crear un array de 4.5 GiB, verás como no te deja. Luego repitelo en un SO de 64, y verás como sí te deja. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktnZYwACgkQtTMYHG2NR9WWSACeLoeuJpal8N7qxKBf2hd7/BV5 tuwAnAkSc9ffK0ocELMJCCMgN8yfDBoq =5+LM -----END PGP SIGNATURE-----
El Tue, 02 Feb 2010 00:36:42 +0100, Carlos E. R. escribió:
El 2010-02-01 a las 07:02 -0000, Camaleón escribió:
No hay ningún matiz que se escape ni la explicación está escrita en algún lenguaje "oculto". La respuesta sólo admite /sí/ (un programa de 32 bits puede acceder a más de 2 GiB) o /no/ (un programa de 32 bits no puede acceder a más de 2 GiB).
Acceder, sí. Direccionar, no.
Ya te ha costado. Te recuerdo el origen de la discusión: ***
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no. *** Un sistema con PAE y mediante mmap() *puede* pasar de los 4 GiB/proceso. No te estaba diciendo más que eso. Cómo lo gestione el sistema operativo es "transparente" para el proceso. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.00.1002030238320.20885@nimrodel.valinor> El 2010-02-02 a las 08:23 -0000, Camaleón escribió:
El Tue, 02 Feb 2010 00:36:42 +0100, Carlos E. R. escribió:
El 2010-02-01 a las 07:02 -0000, Camaleón escribió:
No hay ningún matiz que se escape ni la explicación está escrita en algún lenguaje "oculto". La respuesta sólo admite /sí/ (un programa de 32 bits puede acceder a más de 2 GiB) o /no/ (un programa de 32 bits no puede acceder a más de 2 GiB).
Acceder, sí. Direccionar, no.
Ya te ha costado.
Te recuerdo el origen de la discusión:
***
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no. ***
Un sistema con PAE y mediante mmap() *puede* pasar de los 4 GiB/proceso.
No te estaba diciendo más que eso. Cómo lo gestione el sistema operativo es "transparente" para el proceso.
Sigues sin entenderlo :-( En 32 bits (con PAE) puedes hacer estas cosas: #include <stdio.h> #define TAM 2047*1024*1024-1 char b[TAM]; main() { printf("El tamaño de b es %u bytes (en %u registros de %i bytes)\n", sizeof(b), TAM, sizeof(char)); } Y al ejecutarse responde: El tamaño de b es 2146435071 bytes (en 2146435071 registros de 1 bytes) Y no es posible aumentar el indice: cer@nimrodel:~/bin/C> gcc hello.c hello.c:9: warning: integer overflow in expression hello.c:9: error: size of array ‘b’ is too large hello.c: In function ‘main’: hello.c:14: warning: integer overflow in expression ni el tamaño del registro: hello.c:9: error: size of array ‘b’ is too large O puedo definir el arreglo así: #include <stdio.h> #define TAM_LL 255*1024*1024-1 long long int a [TAM_LL]; long long int i; main() { printf("El tamaño de a es %u bytes (en %u registros de %i bytes)\n", sizeof(a), TAM_LL, sizeof(i)); } Y al ejecutarse responde: El tamaño de a es 2139095032 bytes (en 267386879 registros de 8 bytes) Y no es posible aumentar el tamaño, ni el indice, como antes. Tenemos un limite de tamaño de 2 gigas. Es más, si creo dos arreglos, compila, pero no ejecuta: cer@nimrodel:~/bin/C> ./a.out Killed Lo máximo que puedo poner es: #define TAM 2047*1024*1024-1 #define TAM2 896*1024*1024-1 char b[TAM]; char c[TAM2]; main() { printf("El tamaño de b es %u bytes (en %u registros de %i bytes)\n", sizeof(b), TAM, sizeof(char)); printf("El tamaño de c es %u\n", sizeof(c)); } Puedo añadir una tercera variable: char d[760000]; y en ese tamaño peta, con 740000 funciona: cer@nimrodel:~/bin/C> gcc hello.c ; ./a.out El tamaño de b es 2146435071 bytes (en 2146435071 registros de 1 bytes) El tamaño de c es 939524095 El tamaño de d es 740000 Es decir, el tamaño máximo por variable es de 2 gigas, y por programa de 3. Y puedo direccionarlos: b[15324]='b'; printf("compruebo que puedo direccionar %c\n", b[15324]); Y, si pongo un bucle tonto: for (ii=0;ii<TAM;ii++) { b[ii]='c'; } puedo verlo en top durante su ejecución: Mem: 1034864k total, 1020260k used, 14604k free, 14828k buffers Swap: 12594880k total, 912268k used, 11682612k free, 16696k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 17105 cer 20 0 2945m 778m 112 R 60.8 77.1 0:14.22 a.out Ahora, te reto a aumentar ese tamaño en una variable, en un 32 bits con pae. >>>:-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkto4kUACgkQtTMYHG2NR9WVZQCcCns6BK+bLBYsSdbiYDl/KFkm 7osAoIqp9GxAVxwGudJquIXyZhPjpmcK =3kve -----END PGP SIGNATURE-----
El Wed, 03 Feb 2010 03:41:00 +0100, Carlos E. R. escribió:
El 2010-02-02 a las 08:23 -0000, Camaleón escribió:
Te recuerdo el origen de la discusión:
***
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no. ***
Un sistema con PAE y mediante mmap() *puede* pasar de los 4 GiB/proceso.
No te estaba diciendo más que eso. Cómo lo gestione el sistema operativo es "transparente" para el proceso.
Sigues sin entenderlo :-(
Y tu sigues empeñado en argumentar absurdos y llevarlos hasta las últimas consecuencias. No es la primera vez que lo haces, por cierto.
En 32 bits (con PAE) puedes hacer estas cosas:
No se trata de eso.
Ahora, te reto a aumentar ese tamaño en una variable, en un 32 bits con pae. >>>:-)
Así no estás demostrando que un proceso no pueda tener acceso a >4GiB. Y yo te reto a que preguntes a cualquier programador del kernel sobre este asunto porque me parece que tampoco eres un experto en esto :-). No es que no me fíe de ti, es de tu "cabezonería" de la que no me fío. 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
El Miércoles, 3 de Febrero de 2010 12:15:46 Camaleón escribió:
El Wed, 03 Feb 2010 03:41:00 +0100, Carlos E. R. escribió:
El 2010-02-02 a las 08:23 -0000, Camaleón escribió:
Te recuerdo el origen de la discusión:
***
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no. ***
Un sistema con PAE y mediante mmap() *puede* pasar de los 4 GiB/proceso.
No te estaba diciendo más que eso. Cómo lo gestione el sistema operativo es "transparente" para el proceso.
Sigues sin entenderlo :-(
Y tu sigues empeñado en argumentar absurdos y llevarlos hasta las últimas consecuencias. No es la primera vez que lo haces, por cierto.
En 32 bits (con PAE) puedes hacer estas cosas:
No se trata de eso.
Ahora, te reto a aumentar ese tamaño en una variable, en un 32 bits con pae. >>>:-)
Así no estás demostrando que un proceso no pueda tener acceso a >4GiB.
Y yo te reto a que preguntes a cualquier programador del kernel sobre este asunto porque me parece que tampoco eres un experto en esto :-).
No es que no me fíe de ti, es de tu "cabezonería" de la que no me fío.
Saludos,
-- Camaleón
teneis razón ambos a la vez si estás en modo kernel puedes "acceder" a mas memoria - tocando la MMU "x86 processor hardware architecture is augmented with additional address lines used to select the additional memory, so physical address size is increased from 32 bits to 36 bits. This, theoretically, increases maximum physical memory size from 4 GB to 64 GB. The 32-bit size of the virtual 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. 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." luego cada proceso direcciona max 4GB pero el kernel puede acceder a mas memoria 46GB porque hay dos bits mas disponible. como puede acceder cada proceso a esa memoria extra? pidiendole al kernel que le mapée dentro de sus espacion direccionable de 32bits esto es AWE, o mmap Tu produces una direccion de 32bits y la MMU la traduce a 32 bits con PAE Tu produces una direccion de 32 bits y la MMU la traduce a 36 bits. se ve bien en los graficos de la wikipedia: http://en.wikipedia.org/wiki/Physical_Address_Extension Asi el proceso sigue pensando en 32bits y sigue constreñido a "direccionar" max 4 GB pero puede "acceder" a más. Lo que yo decia que viene siendo la versión modena de EMS o XMS. No hace falta programar para saber eso. Cuando yo era becario habia que lidiar con el EMM386.exe y el HIMEM.sys y por tanto saber que que iba la vaina para recolocar cosas del DOS en esas partes. ¿No os acordais que QEMM-386? http://en.wikipedia.org/wiki/QEMM Sed buenos.. Salu2 -- Este correo no tiene dibujos. Las formas extrañas en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Evitar la programación defensiva. Manual de Erlang -- 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
El Miércoles, 3 de Febrero de 2010 13:24:15 Angel Alvarez escribió:
El Miércoles, 3 de Febrero de 2010 12:15:46 Camaleón escribió:
El Wed, 03 Feb 2010 03:41:00 +0100, Carlos E. R. escribió:
El 2010-02-02 a las 08:23 -0000, Camaleón escribió:
Te recuerdo el origen de la discusión:
***
Hipótesis: en oS de 32 bits y 8 GiB, no mataría el sistema, al no poder reservar más de 4 GiB por proceso >:-)
Con el "kernel-pae", lo dudo >>:-)
Precisamente con el pae. El sistema total puede pasar de los 4 gigas, pero cada proceso no. ***
Un sistema con PAE y mediante mmap() *puede* pasar de los 4 GiB/proceso.
No te estaba diciendo más que eso. Cómo lo gestione el sistema operativo es "transparente" para el proceso.
Sigues sin entenderlo :-(
Y tu sigues empeñado en argumentar absurdos y llevarlos hasta las últimas consecuencias. No es la primera vez que lo haces, por cierto.
En 32 bits (con PAE) puedes hacer estas cosas:
No se trata de eso.
Ahora, te reto a aumentar ese tamaño en una variable, en un 32 bits con pae. >>>:-)
Así no estás demostrando que un proceso no pueda tener acceso a >4GiB.
Y yo te reto a que preguntes a cualquier programador del kernel sobre este asunto porque me parece que tampoco eres un experto en esto :-).
No es que no me fíe de ti, es de tu "cabezonería" de la que no me fío.
Saludos,
-- Camaleón
teneis razón ambos a la vez
si estás en modo kernel puedes "acceder" a mas memoria
- tocando la MMU
"x86 processor hardware architecture is augmented with additional address lines used to select the additional memory, so physical address size is increased from 32 bits to 36 bits. This, theoretically, increases maximum physical memory size from 4 GB to 64 GB. The 32-bit size of the virtual 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. 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."
luego cada proceso direcciona max 4GB pero el kernel puede acceder a mas memoria 46GB porque hay dos bits mas disponible.
obviamente me refería a 64GB no 46.. Salu2
como puede acceder cada proceso a esa memoria extra?
pidiendole al kernel que le mapée dentro de sus espacion direccionable de 32bits
esto es AWE, o mmap
Tu produces una direccion de 32bits y la MMU la traduce a 32 bits
con PAE
Tu produces una direccion de 32 bits y la MMU la traduce a 36 bits.
se ve bien en los graficos de la wikipedia:
http://en.wikipedia.org/wiki/Physical_Address_Extension
Asi el proceso sigue pensando en 32bits y sigue constreñido a "direccionar" max 4 GB pero puede "acceder" a más.
Lo que yo decia que viene siendo la versión modena de EMS o XMS.
No hace falta programar para saber eso. Cuando yo era becario habia que lidiar con el EMM386.exe y el HIMEM.sys y por tanto saber que que iba la vaina para recolocar cosas del DOS en esas partes.
¿No os acordais que QEMM-386?
http://en.wikipedia.org/wiki/QEMM
Sed buenos..
Salu2
-- Este correo no tiene dibujos. Las formas extrañas en la pantalla son letras. __________________________________________
Clist UAH a.k.a Angel __________________________________________ Evitar la programación defensiva. Manual de Erlang
-- Este correo no tiene dibujos. Las formas extrañas en la pantalla son letras. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Te has metido en un hipoteca de 70M y encima te roban una panda de Ninjas... Crisis Ninja para Dummies. -- 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-02-03 a las 13:24 +0100, Angel Alvarez escribió:
El Miércoles, 3 de Febrero de 2010 12:15:46 Camaleón escribió:
teneis razón ambos a la vez
si estás en modo kernel puedes "acceder" a mas memoria
- tocando la MMU
"x86 processor hardware architecture is augmented with additional address lines used to select the additional memory, so physical address size is increased from 32 bits to 36 bits. This, theoretically, increases maximum physical memory size from 4 GB to 64 GB. The 32-bit size of the virtual 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. 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."
luego cada proceso direcciona max 4GB pero el kernel puede acceder a mas memoria 46GB porque hay dos bits mas disponible.
Claro.
como puede acceder cada proceso a esa memoria extra?
pidiendole al kernel que le mapée dentro de sus espacion direccionable de 32bits
esto es AWE, o mmap
Exacto.
Tu produces una direccion de 32bits y la MMU la traduce a 32 bits
con PAE
Tu produces una direccion de 32 bits y la MMU la traduce a 36 bits.
se ve bien en los graficos de la wikipedia:
http://en.wikipedia.org/wiki/Physical_Address_Extension
Asi el proceso sigue pensando en 32bits y sigue constreñido a "direccionar" max 4 GB pero puede "acceder" a más.
Pues claro. O sea, puedes hacer un array de 4GiB (2GiB en C, en mis pruebas, por el signo del indice del array, me supongo), y nada más. Podrías, eso sí, posicionar el array más abajo o arriba de un trozo de memoria (externo al programa) de más de 4GiB, mediante alguna llamada al kernel. Son trucos, porque al fin y al cabo, el array manejable por el código tiene el tamaño limitado a 32 bits de direccion. Que es lo que llevo diciendo todo el tiempo.
Lo que yo decia que viene siendo la versión modena de EMS o XMS.
Exacto.
No hace falta programar para saber eso. Cuando yo era becario habia que lidiar con el EMM386.exe y el HIMEM.sys y por tanto saber que que iba la vaina para recolocar cosas del DOS en esas partes.
Claro. Pero si sabes programar, si has estudiado algo de arquitectura de procesadores, sabes perfectamente de lo que hablamos y de porqué, con pae o sin el, tienes unos límites, y lo que supone. Que hay unos trucos para superar los limites, pero que eso no hace que puedas aumentar el tamaño de las variables o sus indices. Es como el "pan & scan" en el cine. Bueno, si programas en cosas de muy alto nivel no lo ves :-p
¿No os acordais que QEMM-386?
Yo si. Creo que hasta lo he usado. Tuve que programar una aplicación que llamaba a otros módulos de la misma como programas independientes, volcandose en disco a si misma y llamando a otra aplicación. La mejora era volcar en memoria "superior" en vez de en disco, lo cual era mucho más rápido. O las librerías que te permitían almacenar algunos datos por encima del límite de "un mega". Tu programa sólo podía leer en el mega de abajo, pero podías traerte o mapear una variable de arriba a abajo para poder leerla. O tempora.
http://en.wikipedia.org/wiki/QEMM
Sed buenos..
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktqJjsACgkQtTMYHG2NR9XBoACfcE/JG4cD/aFRCKNKMU7WH7sU F/8An0khJ4WQuDodCetqKxNAWKLRJNTh =FiG+ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-02-03 a las 11:15 -0000, Camaleón escribió:
El Wed, 03 Feb 2010 03:41:00 +0100, Carlos E. R. escribió:
Sigues sin entenderlo :-(
Y tu sigues empeñado en argumentar absurdos y llevarlos hasta las últimas consecuencias. No es la primera vez que lo haces, por cierto.
Y tu sigues empeñada en argumentar absurdos... etc. Sé de lo que estoy hablando y no tienes razón.
En 32 bits (con PAE) puedes hacer estas cosas:
No se trata de eso.
Ahora, te reto a aumentar ese tamaño en una variable, en un 32 bits con pae. >>>:-)
Así no estás demostrando que un proceso no pueda tener acceso a >4GiB.
Sí lo estoy demostrando. Demuestrame tú que puedes hacer un array mayor. Se trata exactamente de eso.
Y yo te reto a que preguntes a cualquier programador del kernel sobre este asunto porque me parece que tampoco eres un experto en esto :-).
De este detalle del que hablo, sí soy experto. No le voy a preguntar a nadie del kernel, porque SÉ que tengo razón, y no le voy a hacer perder el tiempo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktqINUACgkQtTMYHG2NR9V8MACgjvnXg0rZlNTlVL2uYlsOLjbN 2BcAni5ocLlvlC3KM0dyZSi7XhX/RzX7 =e/Qg -----END PGP SIGNATURE-----
El Thu, 04 Feb 2010 02:20:13 +0100, Carlos E. R. escribió:
El 2010-02-03 a las 11:15 -0000, Camaleón escribió:
El Wed, 03 Feb 2010 03:41:00 +0100, Carlos E. R. escribió:
Sigues sin entenderlo :-(
Y tu sigues empeñado en argumentar absurdos y llevarlos hasta las últimas consecuencias. No es la primera vez que lo haces, por cierto.
Y tu sigues empeñada en argumentar absurdos... etc.
Sé de lo que estoy hablando y no tienes razón.
Ese es el problema, que uno siempre "cree" que sabe de lo que habla.
En 32 bits (con PAE) puedes hacer estas cosas:
No se trata de eso.
Ahora, te reto a aumentar ese tamaño en una variable, en un 32 bits con pae. >>>:-)
Así no estás demostrando que un proceso no pueda tener acceso a >4GiB.
Sí lo estoy demostrando. Demuestrame tú que puedes hacer un array mayor. Se trata exactamente de eso.
No, no se trata de eso. Yo no estoy hablando de eso.
Y yo te reto a que preguntes a cualquier programador del kernel sobre este asunto porque me parece que tampoco eres un experto en esto :-).
De este detalle del que hablo, sí soy experto. No le voy a preguntar a nadie del kernel, porque SÉ que tengo razón, y no le voy a hacer perder el tiempo.
No, claro que no vas a preguntar porque intuyes la respuesta, la cual no coincide con tu argumentario y no te vas a arriesgar a que nadie te corrija. Eso ya lo sé. 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2010-02-04 08:22, Camaleón wrote:
El Thu, 04 Feb 2010 02:20:13 +0100, Carlos E. R. escribió:
Sí lo estoy demostrando. Demuestrame tú que puedes hacer un array mayor. Se trata exactamente de eso.
No, no se trata de eso. Yo no estoy hablando de eso.
Yo sí, desde el principio. LLamalo array en C, mov en assembler, da igual.
Y yo te reto a que preguntes a cualquier programador del kernel sobre este asunto porque me parece que tampoco eres un experto en esto :-).
De este detalle del que hablo, sí soy experto. No le voy a preguntar a nadie del kernel, porque SÉ que tengo razón, y no le voy a hacer perder el tiempo.
No, claro que no vas a preguntar porque intuyes la respuesta, la cual no coincide con tu argumentario y no te vas a arriesgar a que nadie te corrija.
No pregunto porque la respuesta coincidiría totalmente con lo que yo digo. Sería un inepto en mi profesión de sostener lo que tu dices. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAktq2rIACgkQU92UU+smfQWPEwCdG5QzWCUbNyBKxe8GPK9G8O38 o0wAnA4TcZQURbFdz86qJHaWcCFB2MJI =FKXz -----END PGP SIGNATURE----- -- 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
El Thu, 04 Feb 2010 15:33:22 +0100, Carlos E. R. escribió:
On 2010-02-04 08:22, Camaleón wrote:
El Thu, 04 Feb 2010 02:20:13 +0100, Carlos E. R. escribió:
Sí lo estoy demostrando. Demuestrame tú que puedes hacer un array mayor. Se trata exactamente de eso.
No, no se trata de eso. Yo no estoy hablando de eso.
Yo sí, desde el principio. LLamalo array en C, mov en assembler, da igual.
Entonces estás hablando de otro tema que no se ha tocado en este hilo (para variar)... tú sabrás qué estás defendiendo y por qué. Yo tengo muy clara mi postura.
De este detalle del que hablo, sí soy experto. No le voy a preguntar a nadie del kernel, porque SÉ que tengo razón, y no le voy a hacer perder el tiempo.
No, claro que no vas a preguntar porque intuyes la respuesta, la cual no coincide con tu argumentario y no te vas a arriesgar a que nadie te corrija.
No pregunto porque la respuesta coincidiría totalmente con lo que yo digo. Sería un inepto en mi profesión de sostener lo que tu dices.
No sabía que fueras un experto desarrollador del kernel de linux, especializado en la gestión de la memoria... hum, no, no creo que lo seas, de lo contrario no serías capaz defender esa postura de una forma tan irracional. Tú mismo. 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
Hola :) On Saturday 30 January 2010 12:55:38 Camaleón wrote:
Hola,
Me he topado con un ¿bug? muy feo en gedit ("tranquis", no lo he probado en suse :-P) y para hacer más pruebas, me gustaría saber cómo podría crear varios archivos de distinto tipo, por ejemplo, texto plano o html (cualquier formato que pueda leer el gedit), pero de gran tamaño (>100 MiB).
¿Cómo podría hacerlo? :-?
...
El problema es el siguiente: el otro día abrí un archivo en formato xml de unos 100 y pico megas el en Gedit y me dejó colgado ("seco", sin recursos, sin ram) el equipo¹. Al reiniciarlo, en el registro me encontré con un bonito mensaje "OOM-killer" (out of memory killer), supongo que para poder liberar memoria.
Al hacer algunas pruebas, vi que el gedit empezaba a consumir ram² de forma desmesurada. Este comportamiento no sucede con otros editores (como el mcedit o el OOo Writer) que abrían el mismo archivo sin problemas.
¹ El equipo tiene 8 GiB de ram + 2 GiB de swap. ² Imagen: http://picpaste.com/gedit.png
Lo importante (IMH) no es cómo crear un fichero grande sino, ¿cómo es que trabajáis con un fichero _XML_ de >100 MB? ¿no sería más fácil trabajar con ficheros más pequeños? ¿Menor consumo de recursos? ¿Mayor "rápidez" a la hora de acceder a un dato determinado de ese fichero? ... Me refiero a la hora de "parsearlo", la aplicación que lo haga tardará un "buebo" y consumirá memoria inútilmente (hay que cargar el fichero en memoria, ...). En cuanto a crear ficheros de texto grandes, puedes "strings"ear un fichero binario grande y mandar la salida a un fichero de texto. Obviamente, va a ser un fichero "inútil" en el sentido de información útil. HTH Rafa PS: IMHO, es un bug de gedit o bien de gtk, si otras aplicaciones lo abren. -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- 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
El Sat, 30 Jan 2010 14:16:19 +0100, Rafa Grimán escribió:
On Saturday 30 January 2010 12:55:38 Camaleón wrote:
El problema es el siguiente: el otro día abrí un archivo en formato xml de unos 100 y pico megas el en Gedit y me dejó colgado ("seco", sin recursos, sin ram) el equipo¹. Al reiniciarlo, en el registro me encontré con un bonito mensaje "OOM-killer" (out of memory killer), supongo que para poder liberar memoria.
(...)
Lo importante (IMH) no es cómo crear un fichero grande sino, ¿cómo es que trabajáis con un fichero _XML_ de >100 MB?
Je, con los equipos que tenemos hoy en día, tampoco es un archivo "tan" grande :-)
¿no sería más fácil trabajar con ficheros más pequeños? ¿Menor consumo de recursos? ¿Mayor "rápidez" a la hora de acceder a un dato determinado de ese fichero? ... Me refiero a la hora de "parsearlo", la aplicación que lo haga tardará un "buebo" y consumirá memoria inútilmente (hay que cargar el fichero en memoria, ...).
En este caso, podríamos aplicar el dicho de "la curiosidad mató al gato". El gato bien podría ser yo (o el equipo, que es el que "murió" al fin y al cabo) >:-) No, no era un archivo nuestro con el que tuviera que trabajar, lo bajé de Internet para consultar unos datos (comprimido en zip son unos ~6,5 MiB). Al ver que descomprimido era un poco gordo, pensé "mejor, así pongo a prueba al equipo, que para eso tiene 8 GiB d eram, 4 núcleos y un sistema de 64 bits...). Os podéis imaginar cómo se me quedo la cara al ver el cuelgue... "el tío la vara", parecía <|:-)
En cuanto a crear ficheros de texto grandes, puedes "strings"ear un fichero binario grande y mandar la salida a un fichero de texto. Obviamente, va a ser un fichero "inútil" en el sentido de información útil.
HTH
Rafa
PS: IMHO, es un bug de gedit o bien de gtk, si otras aplicaciones lo abren.
Sí, eso es lo que creo. Fíjate que pensaba que el writer se quedaría tieso, pero qué va, como un tiro que lo abre y apenas aumenta el consumo de ram en ~300 MiB. Tendré que crear un bugzillita... 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
On Sábado, 30 de Enero de 2010 18:06:02 Camaleón escribió:
El Sat, 30 Jan 2010 14:16:19 +0100, Rafa Grimán escribió:
On Saturday 30 January 2010 12:55:38 Camaleón wrote:
El problema es el siguiente: el otro día abrí un archivo en formato xml de unos 100 y pico megas el en Gedit y me dejó colgado ("seco", sin recursos, sin ram) el equipo¹. Al reiniciarlo, en el registro me encontré con un bonito mensaje "OOM-killer" (out of memory killer), supongo que para poder liberar memoria.
(...)
Lo importante (IMH) no es cómo crear un fichero grande sino, ¿cómo es que trabajáis con un fichero _XML_ de >100 MB?
Je, con los equipos que tenemos hoy en día, tampoco es un archivo "tan" grande :-)
¿no sería más fácil trabajar con ficheros más pequeños? ¿Menor consumo de recursos? ¿Mayor "rápidez" a la hora de acceder a un dato determinado de ese fichero? ... Me refiero a la hora de "parsearlo", la aplicación que lo haga tardará un "buebo" y consumirá memoria inútilmente (hay que cargar el fichero en memoria, ...).
En este caso, podríamos aplicar el dicho de "la curiosidad mató al gato".
El gato bien podría ser yo (o el equipo, que es el que "murió" al fin y al cabo) >:-)
No, no era un archivo nuestro con el que tuviera que trabajar, lo bajé de Internet para consultar unos datos (comprimido en zip son unos ~6,5 MiB).
Al ver que descomprimido era un poco gordo, pensé "mejor, así pongo a prueba al equipo, que para eso tiene 8 GiB d eram, 4 núcleos y un sistema de 64 bits...). Os podéis imaginar cómo se me quedo la cara al ver el cuelgue... "el tío la vara", parecía <|:-)
En cuanto a crear ficheros de texto grandes, puedes "strings"ear un fichero binario grande y mandar la salida a un fichero de texto. Obviamente, va a ser un fichero "inútil" en el sentido de información útil.
HTH
Rafa
PS: IMHO, es un bug de gedit o bien de gtk, si otras aplicaciones lo abren.
Sí, eso las es lo que creo. Fíjate que pensaba que el writer se quedaría tieso, pero qué va, como un tiro que lo abre y apenas aumenta el consumo de ram en ~300 MiB.
Tendré que crear un bugzillita...
Saludos,
El problema creo yo es que no está claro si gedit o kate por ejmplo usan mmap o la complejidad de las librerias empieza a comerse las ventajas de ese esquema... No recuerdo pero con mmap y unos 1-2GB de memoria , dependiendo del swap y del esatdo del overcommit de la VM se puede llegara a abrir fichero de 1Giga y pico. Yo he habierto cosas entre los 800 MB y el Giga. -- 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
El Sat, 30 Jan 2010 17:06:02 +0000, Camaleón escribió:
Tendré que crear un bugzillita...
Va a ser que no va a hacer falta. Está reportado en GNOME y en Debian. *** gedit performs very slowly, hogs a ton of memory, and crashes on large datasets without newlines http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=360535 Bug 134682 - gedit needs to implement a workaround to deal with GtkTextView/Buffer inability to handle long lines https://bugzilla.gnome.org/show_bug.cgi?id=134682 *** Y concuerda con las pruebas que he hecho con el archivo de texto auto- generado con "yes": he abierto uno de 200 y pico megas y la memoria sube hasta los 3 GiB pero no se queda colgado. Y el archivo lo abre, voy viendo cómo se van cargando los datos. Y ciertamente, el archivo XML (el que hace reventar al gedit y desboca el consumo de ram) no tiene retornos de carro, es un "amasijo" de datos. Hala, un informe de fallo reportado en el año 2004 en GNOME y en el 2006 en Debian, pero "que si quieres arroz, Catalina" :-( 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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-30 a las 21:29 -0000, Camaleón escribió: ...
Hala, un informe de fallo reportado en el año 2004 en GNOME y en el 2006 en Debian, pero "que si quieres arroz, Catalina" :-(
Vaya. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktkw90ACgkQtTMYHG2NR9WkuQCfRYlkvJIthTcQ8VDBrBCIyP5u p7EAnRwd6KmMTyl/DgkI5QeqT7lHLJPG =pPhX -----END PGP SIGNATURE-----
El 30 de enero de 2010 08:55, Camaleón <noelamac@gmail.com> escribió:
Hola,
Me he topado con un ¿bug? muy feo en gedit ("tranquis", no lo he probado en suse :-P) y para hacer más pruebas, me gustaría saber cómo podría crear varios archivos de distinto tipo, por ejemplo, texto plano o html (cualquier formato que pueda leer el gedit), pero de gran tamaño (>100 MiB).
¿Cómo podría hacerlo? :-?
...
El problema es el siguiente: el otro día abrí un archivo en formato xml de unos 100 y pico megas el en Gedit y me dejó colgado ("seco", sin recursos, sin ram) el equipo¹. Al reiniciarlo, en el registro me encontré con un bonito mensaje "OOM-killer" (out of memory killer), supongo que para poder liberar memoria.
Al hacer algunas pruebas, vi que el gedit empezaba a consumir ram² de forma desmesurada. Este comportamiento no sucede con otros editores (como el mcedit o el OOo Writer) que abrían el mismo archivo sin problemas.
¹ El equipo tiene 8 GiB de ram + 2 GiB de swap. ² Imagen: http://picpaste.com/gedit.png
Y menos mal que las aplicaciones gnome, son mejor que las de KDE4!.............. Salu2 -- 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
El Sat, 30 Jan 2010 18:12:39 -0300, Juan Erbes escribió:
Y menos mal que las aplicaciones gnome, son mejor que las de KDE4!..............
Un bug es un bug, tanto en GNOME como en KDE. 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
participants (7)
-
Angel -
Angel -
Angel Alvarez
-
Camaleón -
Carlos E. R. -
Juan Erbes -
Rafa Grimán