Barrapunto

Editor: creo haber encontrado una errata en:

Supongo que quieres decir más recursos para ejecutar lo mismo que los navegadores monoproceso .

De hecho, tras un tiempo usando el navegador abriendo y cerrando pestañas, el uso de memoria será incluso más eficiente que un navegador convencional.[...]Por muy bueno que sea un navegador, el SO siempre será más eficiente, simplemente porque dispone de más herramientas.

¿Dispone de más herramientas? Un poco abstracto, ¿no? Es más, dudo que sea una razón de peso para comparar la eficiencia de uno y otro.

En realidad la mayoría de los supuestos inconvenientes que aparecen mencionados a los navegadores multiproceso (que se puede generalizar a todas las aplicaciones en realidad) son básicamente problemas del sistema operativo más que del "paradigma" en si mismo.

Es decir, que si consumen mucha más memoria debido a que cada proceso debe de tener una copia de la instancia, en realidad es un problema del gestor de memoria que no la gestiona correctamente y no se da cuenta que dos páginas de memoria son idénticas y que por tanto las pueden compartir los dos procesos sin problemas mientras ninguno de los dos no la modifiquen (entonces debería saltar una excepción de acceso de memoria, y entonces si que debería duplicar la página en cuestión, dando una a cada uno de los procesos y dejando que el proceso que lo solicitó pueda modificar dicha página). Así deberían funcionar los gestores de memoria modernos y de esta forma se reduce el consumo global de memoria (sobre todo teniendo en cuenta que la mayor parte de la memoria compartida será código ejecutable y esta raramente se modifica).

De hecho si se mira por ejemplo Apache, que puede funcionar con procesos diferenciados o por hilos, en los sistemas UNIX apenas hay diferencias apreciables entre usar unos u otros (las hay, por supuesto, sino en UNIX simplemente no existirían los hilos y siempre se usarían procesos), y de hecho hasta versiones modernas del servidor en UNIX casi siempre se empleaban exclusivamente procesos, mientras que en Windows, dónde si que se penaliza mucho el uso de procesos en lugar de hilos, Apache suele funcionar en modo multihilo.

Así que en realidad supongo que si los navegadores web han sido tradicionalmente multihilo y no multiproceso ha sido para no penalizar las versiones para Windows (a final de cuentas, las mayoritariamente usadas), a la espera que Microsoft corrigiese su sistema operativo (o que la potencia bruta de los nuevos procesadores hiciese despreciable la diferencia entre los dos sistemas dentro del rango en el que puede trabajar un navegador).

Además hay otra cuestión. Los hilos son claramente efectivos respecto a los procesos cuando los hilos comparten los datos a los que acceder, por ejemplo, en un procesador de textos, dónde un hilo se dedica a "maquetar" el texto, otro (o el mismo) a recibir la entrada de texto del usuario, y otro es el corrector ortográfico y/o gramatical. Al final todos los hilos están trabajando sobre los mismos datos: el documento que esta editando el usuario. En cambio en el navegador cada pestaña (proceso) tiene un documento normalmente independiente del de las demás pestañas (procesos) por lo que la comunicación entre procesos puede ser mínima, y se puede emplear técnicas diferentes a la simple compartición del espacio de memoria.

"Y ni siquiera he hablado de los procesadores multinúcleo: un navegador multiproceso puede aprovecharlos más que los actuales multihilo, y si cada vez tenemos más núcleos habrá que explotarlos más."

Con eso ha desacreditado todo su artículo.

En geeks.ms encontre un articulo sobre esto justamente: http://geeks.ms/blogs/luisguerrero/archive/2008/09 /02/Google_2D00_Chrome.aspx [geeks.ms]

Escrito por un aficionado, supongo.

La informática es una ciencia, funciona porque está basada en unos principios matemáticos sólidos. Aquí no cabe pensar, creer o que dé igual. Guardar lo mismo en memoria varias veces está mal, incumple normas básicas de la informática. Y da igual que tengas 128kb que 4Gb de RAM. Que sea multiproceso no implica que deba estar mal programado, los datos identicos no deben estar repetidos en memoria

Demuéstralo. Esa afirmación por si sola es falsa. Dependerá de si está bien o mal programada la aplicación

Sacado de la manga, ¿alguna explicación de porqué se dice eso? ¿porqué al ser multiproceso está más aislado del SO? ¿qué quiere decir con más aislado?

Sin comentarios. Aquí demuestra que sus conocimientos son limitados. Alguien debería explicarle que un proceso multihilo puede ejecutarse en varios núcleos del procesador, además de forma más sencilla y eficiente que varios procesos a la vez

Los programas informáticos no son entes orgánicos que cambien por sí mismos. Un programa no 'se degrada'. En todo caso un programa mal programado, valga la redundancia, sufrirá problemas de rendimiento al realizar muchas operaciones de reserva y liberación de bloques de memoria. Pero mal o bien programado puede estar un programa multihilo o multiproceso. Es como afirmar que un motor de 6 cilindros es mejor que uno de 4 cilindros, dependerá del motor. No se puede generalizar

Un navegador multiproceso puede ser más eficiente que uno monoproceso y multihilo, que no lo dudo, pero la demostración debe ser algo más científica y menos a la ligera, con comentarios de barra de bar.

Cosa que ya se puede hacer:

-no-remote
        Don't connect to a running iceweasel instance.

Sí, pero la compartición de memoria entre varios procesos no deja de ser más aparatosa y costosa.

Además, no hay que olvidar que tener varios procesos implica un PCB para cada uno de ellos.

Para estas cosas es mejor usar threads, sinceramente. Otra cosa es que los diseñadores quieran trabajar menos y dejar completamente a manos del SO la gestión de memoria.

No sé si me estoy equivocando, pero creo que Konqueror funciona separando ventanas en procesos.

Cada ventana es un proceso diferente, de forma que si cruje alguna pestaña de esa ventana solo se cierra esa ventana, dejando el resto tranquilas. Incluso el plugin de flash debe ser un proceso separado, por que a veces falla, da un aviso de error (como esos de que el programa se va a cerrar) pero solo deja de funcionar el objeto flash, la pestaña afectada sigue funcionando.

También es bastante normal; Konqueror es la navaja suiza de KDE, navegador de archivos y navegador web: si por una puñetera pestaña que produce un error se te cierran todas las ventanas web y de exploración de archivos te puede dar un síncope (a mi por lo menos, que muchas veces tengo muchas ventanas de esas abiertas).

Me suena que en Firefox si falla una ventana o pestaña se cierran todas las ventanas de Firefox, ¿no?

Es curioso como justo en este artículo, en el que no se menciona la pobre puntuación del IE 8 en el test Acid 3, tengas que venir tú a decir que al pobre IE 8 siempre lo acusan de no pasar medianamente bien el test Acid 3.

Multiproceso y multihilo no son mutuamente excluyentes. De hecho en este caso están usando ambos.

Si piensas usar multihilo en C++, te recomiendo Boost.Thread: http://www.boost.org/doc/libs/1_38_0/doc/html/thre ad.html [boost.org]

No voy a hacer click en el mensaje porque me da la sensación de que es un intento de usar el "efecto barrapunto" para ganar clicks en una web apestosa.

Peero, si lo que dices fuera verdad sería difusión de pornografía infantil, y posiblemente barrapunto recibiría un agradable mensaje de un juez pidiendo cualquier dato para identificarte a través de tu ISP y hacerte una visita personal.

Repito que apostaría que es simplemente un intento estúpido de ganar puntos, pero no juguemos con cosas serias o no nos quejemos luego si tenemos el ojete del tamaño de una tubería.

Y en castellano cómo se dice?