El día 23 de marzo de 2009 10:51, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2009-03-23 a las 13:25 +0100, Rafa Grimán escribió:
¿Ein? Al openofice le vendría de perlas y a firefox con lo que tira de cpu y ram... y al plugin de flash ni te digo OX-)
En el OOo (o cualquier paquete ofimático), donde más van a notar mejoras es en en Base y Calc principalmente ya que son los que más procesos en paralelo van a hacer. Writer y Presenter lo podrían utilizar en caso de incrustar vídeo y/o audio.
También hay que tener en cuenta que OOo tiene mucho bloatware, es decir: mucho código que hay que depurar y profile, cosa que no se hace. Por lo que si en vez de sacar versiones nuevas y características nuevas, se dedican a pulirlo ... seguro que no consumía tantos recursos.
Cierto.
A Firefox le ocurre lo mismo: empezó siendo muy liviano y ahora pesa un montón y consume mucha RAM :(
El firefox nunca ha sido liviano. El Netscape 4, sí, comparativamente. El netscape corría en mi máquina de 32 megas de ram, salvo si me topaba con javascript. El mozilla en esa misma máquina tardaba media hora de reloj en sacar el menú de preferencias - por la cantidad de memoria que necesitaba, en swap.
Creo que parte del problema del firefox, es que utiliza sus propias librerias, en vez de las librerias de sistema. En el caso del openoffice, sucede algo similar, y las unicas librerias que utiliza de sistema, son las de java con su JVM. Ambas aplicaciones adolecen de las mismas virtudes y defectos; como virtud, que se pueden compilar para distintos SO, y como defectos, que son demasiado "pesadas". Que alternativas actuales al firefox, hay en navegadores "livianos"?
No se si os habéis dado cuenta de que ya no es cierto que el Linux (y menos el SUSE) funcione en máquinas antiguas, sacándole rendimiento a máquinas que no sirven oficialmente (para Windows).
Hace unos dias, me ha todaco un equipo en el que Opensuse no hay forma de instalarlo (una forma facil, digo, porque quizas recompilando el kernel funcione). y se trata de un servidor Proliant 2500, donde la anteultima versión de Debian va sin problemas.
Antes se diseñaba, directamente en el compilador, para máquinas con poca ram. En dos, como no había swap, se usaba una cosa llamada "overlay": el programa tenía un ejecutable principal y uno auxiliar que se cargaba por trocitos según te hiciera falta. Así, si estás en un editor pues tienes ciertas funciones en memoria; cuando necesitas imprimir, pues se reemplazan en memoria por las funciones de imprimir, minimizando la cantidad de código en memoria por la propia aplicación.
Esa técnica ya no hace falta, pero algo parecido optimizado a lo actual si podría hacerse, usando swap en su lugar. No al tuntún, sino inteligentemente: quien diseña el programa sabe que secciones se pueden sacar con menos impacto.
El programador debería saber lo que está haciendo y no dejar todo en manos del compilador. Está bien que el compilador haga ciertas cosas para facilitarle la vida al programador, pero otras las debería hacer el programador.
No sé cómo irá hoy en día la programación con leguajes actuales de alto nivel, pero yo me fiaría más de las sugerencias del compilador que de las de un humanoide
No sé yo. Con el Itanium, el compilador tenía un peso muy importante y nadie se dio cuenta del todo de que:
- el compilador era muy importante
- que el compilador realmente no es inteligente sino que hace falta una inteligencia suprior (aka Humano)
También hay librerías y herramientas para ayudar a paralelizar código, pero al final tiene que ir un becario a revisar el código porque hay algo en su sistema que los desarrolladores del compilador no han tenido en cuenta :(
Volvemos a los becarios. Son muy útiles para ciertas cosillas >:-P
Si hablamos de paralelizar código, el compilador gcc (no se si lo habran implementado en las ultimas versiones), era el menos indicados ya que no implementaba la API OpenMP, cosa que si la hace le compilador de intel: http://openmp.org/wp/ http://es.wikipedia.org/wiki/OpenMP http://www.coyotegulch.com/reviews/linux_compilers/ He leido en alguna oportunidad de algunos compiladores pagos para Linux, pero ahora no recuerdo cuales eran. 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