-----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. Y se dice que el problema de la memoria del mozilla es más bien problema de gestión de la memoria del Linux: carga una pagina, ocupa memoria, libera memoria, dejando agujeros detrás que no se usan más, aunque están libres. Eso es una barbaridad. Hay lenguajes que hacen colección de la memoria liberada, de los agujeros. ¿garbage collection? Me parece que es eso. En C estas cosas no son nativas. Es indecente que el firefox ocupe medio giga cuando lleva unos días funcionando. O mucho antes si te dedicas a navegar a conciencia. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 5374 cer 20 0 372m 172m 23m S 7.6 17.1 523:11.59 firefox
Gracias a Dios, los Netbooks han salido y muchos usuarios, desarrolladores y empresas se han dado cuenta que el sw consume mucho de forma innecesaria porque no se pule bien. Espero que se lo tomen en serio y dediquen más tiempo a reducir los consumos.
Pues ya podrían haberse dado cuenta hace milenios. Los demás sí nos hemos dado cuenta, lo que pasa es que como los programadores gastan máquinas ultimo modelo con cientos y cientos de megas, pues no les importaba. Ellos no lo notaban. 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). Es cierto para las que no sirven para el vista, pero poco más. Se diseña para lo último, para los ricos del primer mundo. A mi ya me empiezan a rechazar bugzillas porque dicen que mi hardware es antiguo... :-/ 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
Bueno, en la noticia dice que sólo entre Intel y MS iban a destinar $20 millones de dólares en programas de investigación universitarios, que no es poco. Pero es cierto, parece que hoy día sólo se preocupan de que todo (componentes y software) sea "verde", ecológico y económico y para de contar, como si la eficiencia se midiera sólo en vatios/hora >:-)
Cierto. Si optimizas bien el código: consumirá menos o bien, con el mismo consumo haces más y mejor.
La eficiencia en un centro de datos pesado sí se mide en vatios. Vatios totales gastados para una tarea: puede merecer la pena ir más despacio si el coste en pesetas es menor. Me pregunto si hay datos o estadísticas de eso. - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAknHk+wACgkQtTMYHG2NR9VWfQCfWK43Z18KvzB++V4j5Vn5fy1F CAwAn3yeRwuLHShiGxcCNEk5j49KDwyT =/0/3 -----END PGP SIGNATURE-----