El desarrollador de GNOME Georges Basile Stavracas es el que se ha zambullido de cabeza para resolver el problema de la fuga de memoria en GNOME y es el que ha dado con la raíz del mismo: parece ser que era el garbage collector, la pieza de software que se encarga de liberar la memoria que ya no está siendo usada, el que tenía un comportamiento extraño. La solución todavía no ha sido publicada.
Un recolector de basura ya es una mala idea en si, siempre ha sido el talón de Aquiles de Java y también de ActionScript.
Un recolector de basura es una automatización de un proceso que antes hacían los humanos, y que hace el desarrollo de software económicamente más eficiente sin prácticamente ninguna desventaja.
Lenguajes modernos y muy, muy avanzados como Go, tienen también recolector de basura. De hecho, no queda nada moderno sin recolector de basura.
Pero en los tiempos que corren es la solución más rápida para lenguajes de tipado débil.
Madre mía... Que tendrá que ver el tipado débil con el GC (recolector de basura en adelante)?
Pese a no existir una definición única de tipificación dura o blanda, existe consenso que java es de tipificación dura, igual que go. Y ambos tienen recolector de basura.
Nunca he entendido la obsesión con los malditos recolectores, sobre todo porque ni siquiera sirven, se pueden tener fugas de memoria en Java de muchas formas.
En ninguna plataforma con un recolector de basura que funcione puedes tener fugas de memoria. Entendiendo fugas de memoria como memoria que ya no es utilizada por la aplicación pero el sistema operativo piensa que si.
Y eso es imposible por qué cualquier GC lo que hace de una forma u otra, es contar las referencias que existen a una variable y si no existe ninguna referencia la libera. Los GC modernos además detectan sin problemas referencias circulares y no las tienen en cuenta.
Entonces, si tu programa en Go, java, php, perl, python , Ruby, c# o JavaScript pierde memoria, es por qué te estás guardando referencias a esas variables, y por ende, no tiene sentido liberar esas memoria, por qué literalmente la estás usando.
Si por lo menos los lenguajes con GC te permitiesen liberar la memoria a mano si así lo deseases... Pero no, no tienes ningún control
No tiene sentido que te deje liberar memoria a mano, ya que como te he explicado, no ha liberado esa memoria por qué tú has mantenido una referencia a ella, por lo que si la liberas, tu programa mal hecho petara por otro sitio. La memoria que el GC no ha liberado es un síntoma de que tu programa está mal hecho, ya que existe una memoria que tú como programador consideras liberable, pero en realidad sigues apuntando a ella desde otros sitios de tu programa, y si la liberas, esos sitios apuntarán a una memoria liberada, por lo que tendrás una violación de segmento tarde o temprano.
y a veces es muy frustrante porque sabes que el mismo programa en c++ te funcionaría con 10 veces menos memoria
Eso desmuestra que no sabes programar. La única memoria extra en plataformas modernas es el runtime, que en Go es pequeñísimo.
(o incluso 100 veces menos en programas pequeños donde la JVM, el JIT, el propio GC, etc son un lastre y se llevan solitos el 90% de la memoria).
Que tiene que ver churras con merinas? Estamos hablando del GC, no de java, ni de JIT etc. Esos programas tan pequeños de los que hablas, en la informática moderna no importa agregarle unos poco megas de memoria extra actu programa. Hacer programas que solo consumen 1k de RAM es hoy en día frikismo y no ingeniería, al menos en la muy inmensa mayoría de los casos.
Me gustaría que me expliques de qué forma el recolector de basura de Go está haciendo tus programas más lentos.
Luego, explicame lo del propio creador de B, predecesor de C y aclamado hacker de unix:
Creo que os habéis quedado en java como único lenguaje con GC. Y que además en una versión antigua de java, y que además según explicáis, ni siquiera sabéis programar en java, por qué si su GC os leakea, es por qué os vais dejando referencias por ahí.
#21:
#4 kde es el mejor, este año 2001 va a ser el año de kde en linux
Yo soy muy fan de lxde. Sobrevivo con gnome, pero no me gusta. Tengo la impresión constante se que gnome cree que soy idiota, y por ello necesita ocultarme cosas.
#26:
#23 Un Windows limpio no suele gastar 2'5GB, otra cosa son los programas que arrancan al inicio (y en los PC de los usuarios con pocos conocimientos suelen ser muchos ya que le dan a todo que sí).
De todas formas Windows tiene servicios de prefetching que cargan cosas en memoria antes de que las uses, pero si necesitas esa memoria las borra, te la asigna y listo. No tiene sentido tener la memoria sin usar.
#1 pues yo acabo de aterrizar en gnome. Estoy encantado, todavía adaptándome a gnome-shell.
He instalado Ubuntu Gnome 17.10 para probar.
Lo único que no me ha gustado es lo lentísimo que cambia la sesión entre usuarios. No sé si será cosa de gdm o qué, pero si tengo sesión iniciada con el usuario A y quiero abrir una sesión con el usuario B tarda una barbaridad (más de 2 min) en mostrar la pantalla de login. Increíble.
#2 se me olvidaba. La otra cosa que no me ha gustado es lo mal que va Wayland con algunos programas cuando se ejecutan con privilegios de administrador. Ejemplo: synaptic. Imposible ejecutarlo, ni desde la interfaz gráfica ni al lanzarlo desde terminal (sudo synaptic).
Solución: volver a Xorg.
#3 2 minutos en cambiar de usuario no es normal, algo te va mal.
Wayland lo van a quitar este año, creo.
Instala KDE, no hay necesidad de pasar por todo eso.
#4 kde es el mejor, este año 2001 va a ser el año de kde en linux
Yo soy muy fan de lxde. Sobrevivo con gnome, pero no me gusta. Tengo la impresión constante se que gnome cree que soy idiota, y por ello necesita ocultarme cosas.
#4 yo sobrevivo con mate a pesar de ser una involucion. Kde me cansa con tanta mierda innecesaria. Un dia le di a un combo de teclas que no recuerdo y me aparecio el escritorio sin iconos y una foto con unos colegas yendo de vinos que no tengo ni puta idea de qué hacía ahí.
Sobre gustos no hay nada escrito, pero después de usar varios escritorios a lo largo de los años incluyendo enlightenment, fluxbox, gnome, etc. La cosa está clara:
KDE, i3, xfce4. Son las mejores opciones. Si te gusta Cinnamon usa xfce4 y fuera.
#6 el fallo de xfce4 es depender de ls paquetes d gnome, que al final tienes instalados miles d paquetes entre xfce y gnome. Poco limpio. Prefiero lxde.
#22 XFCE4 no tiene ninguna dependencia de gnome, la tienes tu.
XFCE
Este es un entorno de escritorio muy ligero para sistemas Unix. Según palabras de su creador Olivier Fourdan, XFCE (XForms Common Environment) está “diseñado para la productividad, las apliacciones se cargan y se ejecutan rápidamente, mientras se conserva recursos del sistema“. Creado en 1996, está basado en la biblioteca GTK y utiliza el gestor de ventanas Xfwm.
XFCE es un entorno muy ligero, y resulta ideal para equipos como menos recursos ya que el no ser un entorno visualmente tan potente como pueden ser los anteriores, hace que no consuma tantos recursos. También hay que apuntar que el no ser tan potente visualmente no le impide que pueda ser muy personalizable, pudiendo cambiar temas de ventana, fondos de escritorio, protectores de pantalla, tipos de letras o cualquier aspecto visual del mismo.
#76 estás totalmente seguro? He pasado por cienmil linux, y otros tantos escritorios. Cuando instalaba adornos a xfce siempre era conectado a paquetes gnome.
Instalando xbuntu, venia por defecto con paquetes gnome también, que al intentar quitar te quitaban medio entorno gráfico.
Hace años que no uso xfce, pero cuando me fui fue precisamente por eso.
#42 Eso depende de todos los procesos y programas que tengas cargados al inicio. Yo arranco con "relativamente" poco, pero sí que necesito Tilix, Nextcloud para mi nube personal, Seafile para la de trabajo, Synapse como lanzador y alguna cosilla más. En todo caso lo que tienes que mirar es el consumo de memoria de Gnome Shell.
#10 Windows traga bastante al arrancar pero luego en mi experiencia trabaja mejor con el swap y puedes tener bastantes más aplicaciones abiertas sin que el rendimiento se vaya a la mierda. Y ojo que Ubuntu ya está cerca teniendo la mitad de funcionalidad.
#19 mi ubuntu 11.10 al arrancar gastaba 600 MiB o incluso 400 MiB
2.5 GiB me parece una burrada de dimensiones de supercúmulo galáctico.
Y el como gnome3 devora memoria y no la libera es demencial. Antes podía tener 70 pestañas navegando. Ahora no puedo pasar de 30 sin que llegue la swap (que encima ed mas lenta que en mi portátil)... Y tengo 5 GiB de RAM principal...
#23 Un Windows limpio no suele gastar 2'5GB, otra cosa son los programas que arrancan al inicio (y en los PC de los usuarios con pocos conocimientos suelen ser muchos ya que le dan a todo que sí).
De todas formas Windows tiene servicios de prefetching que cargan cosas en memoria antes de que las uses, pero si necesitas esa memoria las borra, te la asigna y listo. No tiene sentido tener la memoria sin usar.
#26 sí, lo último que hice fue deshabilitar el prefecthing. Tengo que volver a mirar si ha mejorado la cosa. Si fuera un ordenador de hace años diría que necesita desfragmentarse pero ahora lo hacen automático, creo.
Sobre la memoria sin usar, yo prefiero gestionar la memoria a mi gusto. En Ubuntu quitaba servicios que no estuviera usando para tener más memoria. A mis padres les da igual usar más o menos, lo que no puede ser es que vaya lento (y por eso me he enterado yo, si no podían estar usando la memoria que fuera sin yo saberlo).
#23 Es el proceso de Gnome Shell lo que tiene fugas de memoria. Más o menos hasta 250MB, que tampoco es tan grave. Lo que tú comentas tiene más que ver con el navegador. ¿Has probado usar otro?
#41 Yo uso firefox, que tampoco es que sea muy conservador con la memoria, pero es que hoy en día con todo lo que llevan las webs es imposible serlo. Con un ublock y un nocoin y poco más. Supongo que habrá extensiones tipo NoScript para limpiar bastante, pero también quitarán contenido de las páginas.
#54 Es que ya no se hacen webs como se hacian antes que se picaba practicamente todo. Ahora se instala un CMS que tiene un monton de cosas que la gente no es que no usen, es que no saben ni para que son. E instalar un plugin para cada chorrada que queiren hacer. Uno para hacer los formularios de forma visual, otro para cambiar la iconografía, otro para la gestión de usuarios, otro para los botones de redes sociales, otro para las camapñas de mailchimp, otro para..., etc. Suma y sigue. Cantidades ingentes de código ejecutandose porque no ha querido pasarse unas horas programando.
A eso sumale la invasión de efectos con jQuery, si no tienes en el index un slider de imagenes que ocupe el 50% de la pantalla y se vea de puta madre (pese a que no muestre información relevante) nadie quiere la web. Antes las webs eran pro-contenido y pro-funcionalidad, ahora parecen la medida de la poya del diseñador. Webs muy bonitas, pero que por dentro son una puta basura. El contenido y la eficiencia han quedado relegadas a segundo plano.
#72 Supongo que te referirás a los grandes sitios como Facebook que precisamente no usan CMS como wordpress y lo desarrollan todo (hasta sus frameworks JS). La gran mayoría de webs de empresas pequeñas o particulares siguen un patron. Con el tiempo ves que lo unico que cambia es la plantilla y las imagenes usadas (y no siempre, ya que la gente compra los packs de imagenes en los mismos sitios). Y en una web comercial eso no tiene ningun puto sentido, porque precisamente Google una de las cosas que valora, es que tu web sea diferente a la de los demás a la hora de posicionarte en los resultados.
#23 ¿Y la memoria para qué esta? Para ocuparla. No es malo utilizar la memoria si se hace conscientemente y con un buen fin.
Es ridículo que e sistema use poca memoria pero tenga que cargarla frecuentemente desde disco para ciertas tareas, cuando si el sistema es medianamente inteligente tener ciertas aplicaciones en memoria, si tengo 8 GB, ¿por qué no ocupar 2,5 para el sistema operativo si eso me permite mayor desempeño? ¿Que resulta que abro varias aplicaciones o una gorda que me ocupa el resto o necesito más? Pues ya veré lo que hago y si tengo que hacer limpieza la hago.
#57 no tengo 8 GiB. tengo 3 o 4 GiB en ese ordenador. (W10)
En un ordenador con 8 GiB está claro que no molesta.
En mi ordenador donde uso Manjaro Gnome3 sí me molesta que llegue hasta 5 GiB de memoria ram enseguida. En mi experiencia, debido a que el sistema devora la RAM, hay menos espacio para los programas que uso por lo que lo que provoca es un menor desempeño.
Un recolector de basura ya es una mala idea en si, siempre ha sido el talón de Aquiles de Java y también de ActionScript. Pero en los tiempos que corren es la solución más rápida para lenguajes de tipado débil.
#12 Nunca he entendido la obsesión con los malditos recolectores, sobre todo porque ni siquiera sirven, se pueden tener fugas de memoria en Java de muchas formas. Si por lo menos los lenguajes con GC te permitiesen liberar la memoria a mano si así lo deseases... Pero no, no tienes ningún control, y a veces es muy frustrante porque sabes que el mismo programa en c++ te funcionaría con 10 veces menos memoria (o incluso 100 veces menos en programas pequeños donde la JVM, el JIT, el propio GC, etc son un lastre y se llevan solitos el 90% de la memoria).
Un recolector de basura ya es una mala idea en si, siempre ha sido el talón de Aquiles de Java y también de ActionScript.
Un recolector de basura es una automatización de un proceso que antes hacían los humanos, y que hace el desarrollo de software económicamente más eficiente sin prácticamente ninguna desventaja.
Lenguajes modernos y muy, muy avanzados como Go, tienen también recolector de basura. De hecho, no queda nada moderno sin recolector de basura.
Pero en los tiempos que corren es la solución más rápida para lenguajes de tipado débil.
Madre mía... Que tendrá que ver el tipado débil con el GC (recolector de basura en adelante)?
Pese a no existir una definición única de tipificación dura o blanda, existe consenso que java es de tipificación dura, igual que go. Y ambos tienen recolector de basura.
Nunca he entendido la obsesión con los malditos recolectores, sobre todo porque ni siquiera sirven, se pueden tener fugas de memoria en Java de muchas formas.
En ninguna plataforma con un recolector de basura que funcione puedes tener fugas de memoria. Entendiendo fugas de memoria como memoria que ya no es utilizada por la aplicación pero el sistema operativo piensa que si.
Y eso es imposible por qué cualquier GC lo que hace de una forma u otra, es contar las referencias que existen a una variable y si no existe ninguna referencia la libera. Los GC modernos además detectan sin problemas referencias circulares y no las tienen en cuenta.
Entonces, si tu programa en Go, java, php, perl, python , Ruby, c# o JavaScript pierde memoria, es por qué te estás guardando referencias a esas variables, y por ende, no tiene sentido liberar esas memoria, por qué literalmente la estás usando.
Si por lo menos los lenguajes con GC te permitiesen liberar la memoria a mano si así lo deseases... Pero no, no tienes ningún control
No tiene sentido que te deje liberar memoria a mano, ya que como te he explicado, no ha liberado esa memoria por qué tú has mantenido una referencia a ella, por lo que si la liberas, tu programa mal hecho petara por otro sitio. La memoria que el GC no ha liberado es un síntoma de que tu programa está mal hecho, ya que existe una memoria que tú como programador consideras liberable, pero en realidad sigues apuntando a ella desde otros sitios de tu programa, y si la liberas, esos sitios apuntarán a una memoria liberada, por lo que tendrás una violación de segmento tarde o temprano.
y a veces es muy frustrante porque sabes que el mismo programa en c++ te funcionaría con 10 veces menos memoria
Eso desmuestra que no sabes programar. La única memoria extra en plataformas modernas es el runtime, que en Go es pequeñísimo.
(o incluso 100 veces menos en programas pequeños donde la JVM, el JIT, el propio GC, etc son un lastre y se llevan solitos el 90% de la memoria).
Que tiene que ver churras con merinas? Estamos hablando del GC, no de java, ni de JIT etc. Esos programas tan pequeños de los que hablas, en la informática moderna no importa agregarle unos poco megas de memoria extra actu programa. Hacer programas que solo consumen 1k de RAM es hoy en día frikismo y no ingeniería, al menos en la muy inmensa mayoría de los casos.
Me gustaría que me expliques de qué forma el recolector de basura de Go está haciendo tus programas más lentos.
Luego, explicame lo del propio creador de B, predecesor de C y aclamado hacker de unix:
Creo que os habéis quedado en java como único lenguaje con GC. Y que además en una versión antigua de java, y que además según explicáis, ni siquiera sabéis programar en java, por qué si su GC os leakea, es por qué os vais dejando referencias por ahí.
Ninguna, salvo un consumo de memoria y CPU completamente innecesarios, vamos, casi nada. El GC es una puta mierda, decir que es un proceso que antes hacían los humanos y ahora es automático es como decir que un taxi es mejor que un coche porque es un proceso que antes lo hacías tú y ahora lo hace el taxista. En ocasiones un taxi vale, pero en general es más caro, más lento, más torpe y te da menos libertad que tener carnet de conducir con coche propio. Si quieres un programa de verdad aprende a conducir e invierte en un coche y déjate de taxis.
"En ninguna plataforma con un recolector de basura que funcione puedes tener fugas de memoria"
Hay mil formas de tener fugas de memoria. Empezando por lo más básico: el heap sin usar consume memoria del SO, por lo que a la que tienes dos procesos Java ya tienes una fuga de memoria, debido a que no pueden compartir el heap. Por no hablar de cosas como referencias a objetos perdidas, objetos que sólo crecen a no ser que los serialices y deserialices (esto pasa en node por ejemplo), referencias circulares, y cosas más oscuras que sé que existen aunque ahora no recuerdo.
“Eso desmuestra que no sabes programar."
Dime cómo evito que esto me llene el heap de basura en Java sin llamar manualmente al recolector de basura, todavía nadie me ha contestado nunca:
MyObject foo = null;
for (muchas iteraciones sobre i)
En un lenguaje como c++ usas sólo un cachito de memoria, en Java va apilando toneladas de MyObject inútiles hasta que se pone en marcha el gc.
Por cierto yo hablo de los recolectores en general, no he probado el de Go en particular.
"No tiene sentido que te deje liberar memoria a mano, ya que como te he explicado, no ha liberado esa memoria por qué tú has mantenido una referencia a ella, por lo que si la liberas"
La memoria se mantiene hasta que se ejecuta el recolector, dentro de bucles se puede acumular una buena cantidad de basura que sería conveniente limpiar ya que sabes perfectamente que la referencia ha desaparecido. Podría reutilizarse el mismo trocito de heap en vez de llenarlo de porquería. Hay veces que hasta te puede saltar un OOM si pones un heap máximo muy pequeño y metes un new en un bucle. Te remito al pequeño ejemplo sin solución del comentario anterior.
"en la informática moderna no importa agregarle unos poco megas de memoria extra actu programa"
No importa al principio. Luego tienes 80 pequeños procesos Java en un servidor haciendo distintas tareas y resulta que no te da la ram y tienes que ponerle más. (Aunque en mi opinión no tiene sentido tener tantos procesos Java, pero es lo que tiene usar una arquitectura de microservicios y basarla en Java...).
"Creo que os habéis quedado en java como único lenguaje con GC"
Javascript también tiene sus problemas. Y python. Yo tengo un proceso en python que encontré en algún sitio que termina petando toda la memoria del PC si lo dejas unos días en marcha. Y Go me imagino que también será menos eficiente que una buena gestión de la memoria manual, aunque quizás sea mejor que estos dos.
Y, ¿sabes qué es lo peor de una fuga de memoria en un lenguaje con GC? Que en ocasiones, aunque sea memoria muerta, el SO no la manda al swap tan fácilmente como lo hace con un proceso sin GC, porque el GC hace cosas con el heap. El mencionado proceso Python me jodía todo el sistema, mientras que una fuga de memoria en C acaba paginada y no molesta salvo que se te llene el swap.
En primer lugar, las fugas de memoria son mucho más comunes en lenguajes donde el programador es el responsable de la gestión de la memoria: obviamente.
Solo dejarte un delete o un free, y pam, memory leak.
En las plataformas son recolector de basura , como Go, eso no puede suceder, a no ser que tú activamente dejes un apuntador a esa variable.
Obviamente, si haces un bucle invocando objetos sin parar, se va a llenar la memoria, igual que sucede en cualquier lenguaje, en C++ tendrias que ir haciendo delete, y en java te recomendaría encapsular ese bucle en una función, para que entre el return y el siguiente call, se ejecute el recolector de basura más fácilmente. De todas formas, eso ya son detalles implementativos de casos exóticos. En los programas de alto rendimiento que desarrollo, el recolector de basura no es ningún problema.
Lo bueno que tiene el recolector de basura es que un novato obtiene unos resultados aceptables y no la lía parda, y un experto, sabe cómo montalro, para los casos límite o más especiales. Mientras que sin recolector de basura , solo el experto puede conseguir resultados aceptables. ¿De verdad no ves la superioridad del GC? Es obvia.
#87 "Lo bueno que tiene el recolector de basura es que un novato obtiene unos resultados aceptables y no la lía parda"
Y lo malo es que el novato no aprende y es descuidado forever. Es como usar una bici con ruedicas para que el niño no se caiga. Que no te digo que en algunos casos un lenguaje con GC no sea lo ideal, pero empeñarse en usarlo para hacer aplicaciones me parece horrible. Scripts sí, aplicaciones no.
#90 donde ves el problema? La inmensa mayoría de aplicaciones van a obtener más rendimiento con un GC que sin el. Gestionar la memoria de manera manual es un capricho de ingeniero, que tiene sentido en contadas ocasiones y que la inmensa mayoría de las veces va a suponer un sobrecoste innecesario.
#95 "La inmensa mayoría de aplicaciones van a obtener más rendimiento con un GC que sin el"
"Gestionar la memoria de manera manual es un capricho de ingeniero, que tiene sentido en contadas ocasiones y que la inmensa mayoría de las veces va a suponer un sobrecoste innecesario." -> "Poner parquet en el suelo es un capricho de arquitecto, que tiene sentido en contadas ocasiones, y que la inmensa mayoría de las ocasiones va a suponer un sobrecoste innecesario."
Vamos a ser claros: para una nave industrial dedicada a fabricar coches no quieres suelo de parquet. Lo mismo pasa con un servidor que se dedica a gestionar pedidos de venta. Pero una aplicación para usuarios, para que la ejecuten en sus dispositivos, el GC es una guarrada.
#96 creo que estás muy muy confundido. La inmensa mayoría de aplicaciones con un GC van a ir más rápidas por qué se puede hacer economía de escala y optimizar al máximo esa pieza, frente a tu trabajo de artesanía de la memoria aplicacion por aplicación.
Dicho esto, yo soy más del show me the code.
Yo soy autor de un cliente web de spice. Básicamente una tarjeta gráfica en 2 dimensiones implementada 100% en JavaScript client side.
La implementación de LZ77 que hay ahí dentro, descomprime un bitmap full HD en menos de 8ms. El cliente web de spice en general, en casi todo, es más rápido que el original, escrito en C++.
Cómo puede ser? Pues por dos razones.
La primera, es que al apoyarte en abstracciones correctas, estás pueden ser optimizadas haciendo economía de escala: cada nuevo Chrome, más rápido va el cliente web de spice.
La segunda razon, es que los Juniors creen que lo que hace más rápido o lento un programa son ese tipo de optimizaciones micro, cómo optimizar la memoria a mano. En realidad, lo que hace más rápido o lento a un programa es la gestión de la entrada y salida y una buena implementación de la concurrencia para poder paralelizar.
Créeme, no vas a hacer un programa completo user facing más rápido en C++ que un experto lo hace en Go (para comparar manzanas con manzanas) y además, el que lo hace en Go, lo va a hacer más rápido que tú, va a ser más difícil que tenga leaks y no va a segfaultear.
Pero en serio, puedes seguir con tu new y delete, y obviar 25 años de ciencias de la computación.
#97 La recolección de basura es más rápida en algunos casos porque evita tener que pedir memoria al sistema. Eso nunca lo he negado. Pero eso no sirve de nada cuando llenas la memoria y el PC empieza a tirar de swap. Tampoco sirve de nada cuando tienes una aplicación que es intensiva en memoria. Además, si quieres que una aplicación corra, nunca usas new y delete. Yo por ejemplo tenía un pequeño proceso en c que rellenaba una estructura en un bucle, iba lento porque usaba malloc en el bucle. Pero en cuanto reemplacé el malloc por mi propio getMem, que me devolvía memoria de un pool de memoria, volaba. Por lo que cuando dices que JavaScript es más rápido comparas peras con manzanas. En C++ también puedes pedir la memoria por adelantado para evitar esperar al sistema. Y seguramente hay librerías que lo hacen. Por ejemplo con QT nunca usarás un delete, ya lo hace QT.
Y la recolección de basura añade overhead que penaliza la velocidad. Por no hablar de la cantidad de memoria que traga para toda esa optimización.
Si JavaScript fuese más rápido que C++ no habría programas hechos en C++.
En cuanto a las abstracciones de las que hablas, JavaScript precisamente falla estrepitosamente por la falta de estructura que tiene. Para algunas cosas funcionará bien, pero el interprete nunca sabe si le vas a añadir a un objeto 400 propiedades o ninguna.
En cuabto a Go, ya te digo que no lo he usado nunca.
Pero ya que hablamos de velocidad, si bien es cierto que un lenguaje con GC puede mejorar la aproximación ingenua de usar new y delete conforme se necesitan, nunca, nunca podrá ni acercarse al rendimiento que obtiene un programa con la memoria bien organizada. Porque en un caso tienes una colección de objetos relacionada por numerosos punteros, con huecos libres para poder modificar los objetos sin reubicarlos, ya que el sistema no sabe qué vas a hacer con ellos, y en el otro, con una gestión manual de la memoria puedes organizar los objetos perfectamente empaquetaditos, sin punteros, con el espacio justo, en una zona de memoria contigua, de tal forma que minimizas los fallos de caché del procesador al recorrerlos. Y teniendo en cuenta que un fallo de caché noquea al procesador varios ciclos, no es moco de pavo.
Decir que usar un lenguaje con recolección de basura te lleva a un mejor producto es como decir que con un puñado de plástico y un par de moldes puedes superar a una carcasa unibody de aluminio, porque es más fácil y da menos problemas.
En cuanto a las abstracciones de las que hablas, JavaScript precisamente falla estrepitosamente por la falta de estructura que tiene. Para algunas cosas funcionará bien, pero el interprete nunca sabe si le vas a añadir a un objeto 400 propiedades o ninguna.
javascript hace años que tiene typed arrays, es decir, estructuradas de tamaño fijo y tipado, que permiten trabajar con memoria de alto rendimiento.
Además, eso que dices es falso, depende de como programes tu función, el optimizador de v8 (o el que sea, depende para que vm estés optimizando) la conseguirá optimizar o no. Optimizarla significa pasarla a nativo. A veces ciertos usos de javascript impiden hacer eso, y se ejecuta en el entorno JIT, y entonces mas lenta: el 99% de hacer javascript de alto rendimiento consiste en paralelizar con web workers, usar arrays tipados y escribir las cosas de forma que sean optimizables.
Pero ya que hablamos de velocidad, si bien es cierto que un lenguaje con GC puede mejorar la aproximación ingenua de usar new y delete conforme se necesitan
Es decir, un programador novato o normalito conseguirá mejor rendimiento con GC que con gestión de memoria manual, y a un coste mucho mas bajo. El programa será mas simple, por ende, mas mantenible y extensible.
Un programador experto, podrá gestionarse su memoria guardandose punteros a estructuras que no quiere que el gc libere y crearse object pools (técnica que uso en el cliente web de spice), de esta forma, reutilizo los objetos sin pasar por el gc. Es decir, un programador novato lo hace mejor y mas barato con gc, y un programador experto, como es experto, sabe buscarse la vida con y sin gc.
Con gc siempre es mas barato (en tiempo de desarrollo) y el programa siempre queda mas simple, hace menos cosas tu código, y es mas mantenible que un programa que tiene la complejidad agregada de gestionar memoria.
nunca, nunca podrá ni acercarse al rendimiento que obtiene un programa con la memoria bien organizada. Porque en un caso tienes una colección de objetos relacionada por numerosos punteros, con huecos libres para poder modificar los objetos sin reubicarlos, ya que el sistema no sabe qué vas a hacer con ellos, y en el otro, con una gestión manual de la memoria puedes organizar los objetos perfectamente empaquetaditos, sin punteros, con el espacio justo, en una zona de memoria contigua, de tal forma que minimizas los fallos de caché del procesador al recorrerlos. Y teniendo en cuenta que un fallo de caché noquea al procesador varios ciclos, no es moco de pavo.
Eso que tu dices que no es moco de pavo, en mi experiencia si lo es. Casi nunca he tenido que optimizar hasta ese nivel para un cliente. Es interesante por que parece que te interesa el tema, yo me dedico profesionalmente a esto, es decir, como consultor he cobrado mucho dinero por optimizar programas en todo tipo de plataformas y entornos. En mi experiencia del mundo real, casi nunca (por no decir nunca), los problemas venían por tener huecos entre la memoria del heap (por poner un ejemplo) y casi siempre, implementar esos mecanismos que propones, acarreaba muchas complejidad y costes en el programa (fuentes de bugs, etc) que benificios perceptibles proporcionaba. Cuando era joven tiraba mucho por ahí, hoy en día, a base de aprender, mi intuición me lleva a optimizar otro tipo de cosas, donde obtengo muchos mas puntos por un coste mucho mas bajo, que de eso va esto.
Decir que usar un lenguaje con recolección de basura te lleva a un mejor producto es como decir que con un puñado de plástico y un par de moldes puedes superar a una carcasa unibody de aluminio, porque es más fácil y da menos problemas.
El problema es que tu comparación con la carcasa unibody es incorrecta: una vez producida la carcasa unibody es un objeto bastante simple, que le va a dar incluso menos problemas al dueño que el plastico. Pero un programa que además gestiona la memoría por su cuenta, sin automatismos, es un programa obviamente mas caro de producir, que tiene mas componentes que hacen mas cosas. Tiene mas fuentes de posibles bugs etc. Entonces, es un programa mas caro de producir, y mas caro de mantener. Además, la mayoría de las veces, como ya he dicho, conseguirás mejoras de rendimiento imperceptibles en el mejor caso, y un rendimiento incluso peor en el peor caso (dependiendo del nivel del equipo de programadores).
Además, algo que no has comentado... los programas a veces se mantienen años, y no los mantienes siempre tu, ni siempre un equipo experto. Entonces, dentro de 10 años, mi programa con GC es mas probables que siga teniendo un rendimiento aceptable, comparado con tu gestión casera de la memoria, que la habrán tocado ya 20 manos, y la habrían liado parda
Por cierto no entiendo a qué te refieres con lo de una tarjeta gráfica
Una tarjeta gráfica es un dispositivo que recibe ordenes de pintado en forma de expresiones sobre un modelo de datos y genera imagenes rasterizadas de 2 dimensiones sobre un dispositivos de salida de imagen o sobre un fichero. En este caso, el cliente web de spice es un cliente de un protocolo de escritorio remoto llamado SPICE, de red hat. Este protocolo captura las ordenes de pintado en 2 dimensiones, y en lugar de procesarlas en local, las redirecciona hacía otro ordenador, que las procesa y genera la imagen resultante. Esta es la misma forma en que funciona citrix, rdp (rdesktop, ts) etc. Es mucho mas barato envíar ordenes de pintado de bajo nivel que imagenes rasterizadas.
No existía hasta que implementé ese, un cliente web de spice de alto rendimiento por que procesar las ordenes de pintado y descomprimir los modelos de datos en caliente y en javascript en un navegador se consideraba demasiado lento como para usos reales.
Desarollé ese cliente superando en performance no solo al cliente web de spice anterior (otro proyecto, que no tiene nada que ver con mi implementación), sino en varias cosas al propio cliente nativo, en c++, escrito por expertos de red hat.
Y no lo digo para decir "oh que crack que soy", sino para demostrarte que una plataforma de alto nivel, con recolector de basura, bien utilizada puede llegar a ser muy, muy performante.
#97 Otro ejemplo: elasticsearch (escrito en Java): tras una agregación gorda (con éxito irónicamente) se queda tonto y responde a trancas y barrancas, mensajes sobre los intentos del recolector de basura en el log, va como el culo, deja de responder peticiones a ratos... reinicias y todo va de nuevo a las mil maravillas, pero has tenido que reiniciar todo un motor de indexado y búsqueda, del que dependen un montón de procesos, ¿Por qué? ¿Por qué no puede simplemente liberar la memoria que había usado para la agregación y seguir funcionando? ¿Cómo hacen los desarrolladores para decirle al GC que no comprometa los recursos básicos para mantener la estabilidad?
#97 >En realidad, lo que hace más rápido o lento a un programa es la gestión de la entrada y salida y una buena implementación de la concurrencia para poder paralelizar.
Básicamente las directrices de Unix desde hace 50 años
Apliqué esa política no en programación, pero si en un script con 10Gigas de logs binarios de Windows con find, strings y xargs. En 5 minutos literalmente parsée cientos de miles de entradas e hice un listado.
#86 has hablado muy poco de ellos, básicamente los has mencionado y has dicho que tenías un programa en Python que te llenaba la memoria: felicidades, Python es Turing complete y como consecuencia, puede llenar la memoria si quieres.
#17 Si tienes memory leaks en Java no es por el GC, es porque tu programa esta mal hecho. Y eso de que te permitiese liberar memoria "a mano" es una burrada.
#65 No es una burrada. ¿De dónde te sacas que es una burrada? Yo sé mejor que el GC cuándo un objeto ya no va a ser usado. El peor caso es cuando los creas dentro de un loop, es horrible, se puede llegar a acumular un montón de basura.
#78 Como ya he dicho, si instancias un objeto dentro de un bucle (a veces no queda más remedio) al final de el bucle se podría eliminar, teniendo un sólo objeto por iteración en vez de cientos o incluso cientos de miles. Pero en Java toca ir acumulando objetos en el heap hasta que se despierte el GC. Y si lo llamas a mano adiós CPU.
#83 No acumula cientos de objetos en el heap. Si lo que quieres es que se borren, se borraran incluso antes de que la funcion acabe. La GC va ejecutandose para los young generation objects y puedes crear millones de objetos en un bucle si quieres que puedes correr el programa con 20MB de memoria para la JVM, no se quedan todos los objetos ahi esperando a que acabe el metodo para que luego la GC haga un borrado masivo.
La GC de la JVM no es ninguna tonteria ni ningun juguete, ha mejorado MUCHISIMO con el paso del tiempo y borrar objetos a mano (con lo que eso conlleva y la de bugs/leaks que puedes crear) VS tener una GC de esta calidad, gana por goleada usar una GC. Ya ni hablamos de la productividad y calidad del software que tenemos gracias a un lenguaje como Java y su GC.
#89 Que te explique el que? Seras al unico que no le pasa, que version de la JVM estas usando?
La JVM esta optimizada para operar con objetos de corta vida (a veces milisegundos). Se guardan en la parte del heap llamada "Young Generation". Cuando se llena, se ejecuta lo que se llama un "Minor Garbage Collector", que es muy rapido. Los objetos van moviendose a generaciones mas viejas si van sobreviviendo a las recolecciones. Vamos, que en el caso que comentas, a efectos practicos, es como si las referencias se liberasen "gratis" sin tu hacer nada y teniendo el mismo efecto que si tu lo haces manualmente. El problema que mencionas de que se quedan en la Heap durante un largo tiempo y luego la CPU "se muere", simplemente no ocurre.
No he dicho que todo el software de calidad sea en Java, pero Java esta muy bien considerado y su rendimiento no es comparable a hace años. La gente sigue repitiendo las mierdas como si fueran un dogma porque queda bien y hace gracia, pero si te paras a leer te daras cuenta de que no.
Lo que si es verdad es la mayoria de las empresas para todo tipo de proyectos (incluidos los low latency systems), por temas de rendimiento, ecosistema, fiabilidad, calidad y productividad, escogen Java en un altisimo porcentaje de los casos.
#31 a mi parece inferior a gnome3 y te estoy contando la cantidad de problemas que me da manjaro con gnome3...
Pero quizás son equipos muy malos, yo que se...
Con un ordenador que no fuese del año de la polka reconvertido (en el que tengo gnome3 fácil es un sobremesa de cuando salió el windows7) pues a lo mejor iría todo bien. Y lo de windows no me lo explico porque le he quitado tropecientas cosas de que se arranquen al inicio... (es del año de windows 8 ).
Pero ya digo que lo he visto con muchos ordenadores y algunos son nuevos del año pasado, se queda pillado si cambias el foco muy rápido. Por suerte suelen ser menos de 10 segundos.
#33 Es cierto que windows 10 se deja en controladores casi 2gb de ram, tampoco veo razón para no hacerlo y también es cierto que nunca he visto interfaz más rápida. Por mucha perreria que hagas, gestiona la ram de manera genial, nada que ver con anteriores windows, instantáneo siempre, en un pc con 8gb de ram. También tengo un pc con 4gb y en cuanto acaba de cargar al inicio también va sin ningún tirón, ni tarda más de un segundo en cambiar ventana.
#37 qué suerte. Yo nunca he visto eso. Si acaso cuando usaba 9.10 iba todo súper fluido. Los ordenadores que uso de 8GB de RAM usan windows 8 creo o 7, no 10 y el que gasta 2.5 de inicio tiene apenas 4 gib de RAM.
Por otro lado, quien redacta el articulo no tiene mucha idea de que es lo que habla, suelta los términos al azar casi. Es una traducción un tanto renqueante.
#29 ese chiste es un poco viejo y repetitivo. Los informáticos hoy en día no son 4 frikis vírgenes. Son gente normal, con conocimientos avanzados sobre una temática.
Noto un poco de complejo de inferioridad siempre que leo esa broma.
Un Sistema Operativo (y su interfaz) debería gestionar la memoria correctamente y punto.
Mi experiencia con Linux en comparación con Windows es horrible y probablemente se debe a este tipo de cosas, cuando sólo tienes un par de terminales y el correo electrónico no pasa nada, pero cuando eres como yo, que tiene decenas de programas abiertos de forma permanente, se ven en seguida los fallos.
#15 windows es aun peor en estos temas. Si pones un programa a full hay una gran probabilidad de que el resto no tiren. No puedes comprimir 7 cosas a la vez, renderizar 3 y escuchar musica a la vez.
Haciendo eso en Ubuntu se me entrcortaba a veces la música.
En windows pones un fractal a renderizar y te has quedado sin ordenador, la ventana se pone blanca y no responde y la música se entrecorta.
Leí un estudio que soy incapaz de encontrar que hacia una comparativa en velocidad de memoria , liberación etc. Creo que era sin efectos ni nada, el kernel a pelo de ambos.
El resultado es que windows liberaba memoria y movía memoria mas rápido que windows en cantidades medias y pequeñas mientras que linux tardaba menos en cantidades mayores.
Hablaban también de que si se hacia un gráfico , el comportamiento de reserva, movimiento y liberación de memoria tenía una gráfica continúa en linux de tiempo/memoria mientras que la de Windows era mas impredecible y asociaban eso a una gestión mas errática de la memoria y auna menor estabilidad.
Es una pena que nunca lo haya vuelto a encontrar, estaba bastante bien el estudio y daba resultados que a mi me parecieron inesperados.
#20 Lo que dices es precisamente lo que hago mucho mejor en Windows que en Linux. ¿En qué versión de Windows te quedaste?
A mi Windows siempre me ha funcionado bien viendo por ejemplo una peli fullHD mientras Matlab anda a todo trapo con el 100% de la CPU. Nunca jamás se me ha entrecortado la música.
Y la razón es que en Linux se usa un CFS (completely fair scheduler) como aproximación al reparto de tiempo de la cpu, que funciona bien en entornos multiusuario como los servidores, pero que no tiene los ajustes concretos que tiene Windows para priorizar la ventana que tiene el foco, o la reproducción de música (entre otras cosas porque Linus no quería mantener dos schedulers).
#24 windows 10. Pero sí luego me he dado cuenta que es el scheduler, no la memoria.
Pues tendrás mucha suerte porque yo estoy acostumbrado a usar todo deprisa (cambiar de ventana rápido, moverme con el teclado) y lo de ver ventanas que dejan de responder es lo mas habitual del mundo aunque no hagas nada pesado. Son fallos que se aceptan, no me pondría a hacer las burradas que te he descrito arriba en un windows y lo segundo es moverte más despacio, pero sí que me he fijado que pasa en ordenadores que no deberían tener problema alguno en mover absolutamente nada. Así que yo creo que es algún cuello de botella. Lo he visto en Vista, en 7 , en 8 y en 10. Cuando usaba XP eran otros tiempos y uno tenia paciencia (era increíble la paciencia que había que tener...).
Pero ya digo, gnome3 está siendo una dcepciin también en esto que te comento porque aunque un renderizado o dos los soporta en cuanto empieza a devorar RAM y mandarla a la swap empiezan a aparecer los cartelitos de no responde. Ya digo, como si fuera un windows o ¡peor!
#30 Pues yo me muevo a toda hostia con decenas (y hasta un centenar) de ventanas y el que responde al instante es Windows. He llegado a usar el paint con atajos del teclado Los linux que he probado todos tienen ciertos retrasos al hacer alt+tab, especialmente cuando tienes muchos procesos tragando CPU y el scheduler no prioriza el alt+tab. Suelo usar Mate btw. Unity es horrible.
No sé qué ventanas te dejan de responder a ti. Windows 10 es una mierda por su política de actualizaciones y privacidad (y por sospechas mías de que están descuidando algunas cosas) pero en tema de rendimiento de la interfaz de usuario es muy bueno.
#15 Los autores de Vala intentaron que se usase su lenguaje, que tiene gestión automática de memoria sin necesidad de GC, pero la idea no cuajó y se fueron a Javascript... Sí, Gnome Shell está escrito en Javascript. Y lo he sufrido. Me gusta Gnome Shell, pero pero fuera; sus tripas las odio con fuerza.
Curioso, parecido a lo que me ocurre en W10. A veces la RAM va aumentando su uso hasta que llega al 98% aprox y hasta que no reinicio no se limpia la RAM. No se exactamente cuando o por que. Sí he comprobado qie teniendo algún programa torrent descargando sea el que sea, se va llenando. He leído que si incompatibilidades con tarjeta de sonido y varias cosas raras pero sin solución.
Yo de gnome solo se que es feo de cojones...Lo he visto y ya tiene que ser la bomba a la hora de abrir cosas y configurar hasta las cortinas de las ventanas...Por que si no no lo entiendo...Yo he visto kde y se parece mas a la idea que yo tengo de un escritorio "moderno", eso si, falla mas que una escopeta de feria en el tema de las actualizaciones, las notificaciones y correrlo sobre un virtualbox es para juaquer, pero aun asi no puedo con gnome.
En mis tiempos mozos era responsable de limpiar lo que había desordenado de mi habitación, de limpiar lo que el perro hacía y de liberar la memoria que usara.
Linux es bueno en entorno servidor, eso nadie lo duda, pero en escritorio, en mi opinión no deja de ser un juguete (mejor dicho, mil juguetes, porque hay un follón de escritorios o entornos visuales)
Es obvio que si cualquier empresa como Windows o Apple quieren lo dejan en pañales. Para mi, siempre han estado por encima en ese aspecto de GNU/Linux. Que no deja de ser un juguete de ciertos programadores, algunos de ellos muy buenos y con una finalidad sin duda encomiable, pero eso de por sí no te garantiza un buen resultado.
#11 gnome shell (gnome 3) tiene un bug, en el que va aumentando la memoria que va usando, poco a poco, sin liberarla, por algo tan sencillo como pulsar los iconos, se coge un trocito mas de ram.
Esta solución, hará, o debería hacer que consumiese muchisima menos ram, y si, algo se notará en el rendimiento. El principal problema de gnome-shell, es el lenguaje en el que está escrito, javascript, que no es una maravilla...
#52 Me retracto. No había visto el enlace al pie del arti'culo que dice "original". Veni'a de leer el arti'culo original y al buscar la palabra "omgubuntu" no la encontre'.
Dicho esto, creo que seri'a mejor que se dejara claro que el arti'culo es una traduccio'n al principio, por si alguien quisiera leer el original su lugar.
Comentarios
Aún le queda la fuga de usuarios. Abro flame.
#1 pues yo acabo de aterrizar en gnome. Estoy encantado, todavía adaptándome a gnome-shell.
He instalado Ubuntu Gnome 17.10 para probar.
Lo único que no me ha gustado es lo lentísimo que cambia la sesión entre usuarios. No sé si será cosa de gdm o qué, pero si tengo sesión iniciada con el usuario A y quiero abrir una sesión con el usuario B tarda una barbaridad (más de 2 min) en mostrar la pantalla de login. Increíble.
#2 se me olvidaba. La otra cosa que no me ha gustado es lo mal que va Wayland con algunos programas cuando se ejecutan con privilegios de administrador. Ejemplo: synaptic. Imposible ejecutarlo, ni desde la interfaz gráfica ni al lanzarlo desde terminal (sudo synaptic).
Solución: volver a Xorg.
#3 2 minutos en cambiar de usuario no es normal, algo te va mal.
Wayland lo van a quitar este año, creo.
Instala KDE, no hay necesidad de pasar por todo eso.
#4 kde es el mejor, este año 2001 va a ser el año de kde en linux
Yo soy muy fan de lxde. Sobrevivo con gnome, pero no me gusta. Tengo la impresión constante se que gnome cree que soy idiota, y por ello necesita ocultarme cosas.
#4 yo sobrevivo con mate a pesar de ser una involucion. Kde me cansa con tanta mierda innecesaria. Un dia le di a un combo de teclas que no recuerdo y me aparecio el escritorio sin iconos y una foto con unos colegas yendo de vinos que no tengo ni puta idea de qué hacía ahí.
#47
Reconfigura wine.
#3 Prueba Mate, o Cinnamon. Cualquiera de los dos va mucho mejor hoy por hoy.
#5 Cinnamon ? for real.
https://www.techrepublic.com/article/why-the-linux-mint-hack-is-an-indicator-of-a-larger-problem/
Sobre gustos no hay nada escrito, pero después de usar varios escritorios a lo largo de los años incluyendo enlightenment, fluxbox, gnome, etc. La cosa está clara:
KDE, i3, xfce4. Son las mejores opciones. Si te gusta Cinnamon usa xfce4 y fuera.
#6 el fallo de xfce4 es depender de ls paquetes d gnome, que al final tienes instalados miles d paquetes entre xfce y gnome. Poco limpio. Prefiero lxde.
#22 XFCE4 no tiene ninguna dependencia de gnome, la tienes tu.
XFCE
Este es un entorno de escritorio muy ligero para sistemas Unix. Según palabras de su creador Olivier Fourdan, XFCE (XForms Common Environment) está “diseñado para la productividad, las apliacciones se cargan y se ejecutan rápidamente, mientras se conserva recursos del sistema“. Creado en 1996, está basado en la biblioteca GTK y utiliza el gestor de ventanas Xfwm.
XFCE es un entorno muy ligero, y resulta ideal para equipos como menos recursos ya que el no ser un entorno visualmente tan potente como pueden ser los anteriores, hace que no consuma tantos recursos. También hay que apuntar que el no ser tan potente visualmente no le impide que pueda ser muy personalizable, pudiendo cambiar temas de ventana, fondos de escritorio, protectores de pantalla, tipos de letras o cualquier aspecto visual del mismo.
#76 estás totalmente seguro? He pasado por cienmil linux, y otros tantos escritorios. Cuando instalaba adornos a xfce siempre era conectado a paquetes gnome.
Instalando xbuntu, venia por defecto con paquetes gnome también, que al intentar quitar te quitaban medio entorno gráfico.
Hace años que no uso xfce, pero cuando me fui fue precisamente por eso.
#79 Prueba a instalar el sistema sin escritorio y luego apt install xinit xfce4
#3 Sabes que tienes que dar permisos via xhost + con wayland, no?
Anda que si ese era todo tu problema...
#64 mirando por ahí he encontrado...
https://ask.fedoraproject.org/en/question/102936/graphical-applications-cant-be-run-as-root-in-wayland-eg-gedit-beesu-gparted-nautilus/
https://askubuntu.com/questions/961967/why-dont-gksu-gksudo-or-launching-a-graphical-application-with-sudo-work-with-w
Y si con eso se arregla, pues vale. Pero no parece lo más intuitivo del mundo para alguien como yo, que uso GNU/linux y algo sé sobre el sistema, aunque poco. A más de uno le dan ganas de correr cuando le pasan cosas como esta.
Sobre Gnome (y he sido usuario de KDE durante años) solo puedo decir que me encanta, pero que para hacerlo usable al nivel de otros escritorios (KDE e incluso escritorios más básicos como Mate o XFCE) necesita instalar unas cuantas extensiones. Deberían venir de serie con Gnome.
#2 a mi me pasa que ni siquiera me deja cambiar de sesión...
#1 KDE mejora con los años, GNOME se avinagra con los años.
Antes que volver a GNOME me instalo LXDE, XFCD, LXQt, FluxBox...
#25 Chrome y Firefox siguen usando gtk, ¿no?
Ese era el motivo fundamental para mí para no usar KDE
#48 Sí, al menos firefox, pero no le encuentro mayor problema en KDE.
#49 Yo soy muy purista y quiero el mismo estilo en todo. Si firefox o chrome estuvieran o pudieran ponerse en qt, me pasaba ipso facto.
#1 Mis Gigas se fugaron a KDE hace ya unos cuantos años.
1 GiB de memoria comida al arrancar no es buena señal. Parece un puto Windows. Tuve el error de poner gnome3 cuando me hice con Manjaro.
Por otro lado el otro día arranque el windows 10 de mis padres y chupaba 2.5 GiB de RAM sin hacer nada de nada...
Los cangrejos ya no les ganan a ir para atrás.
Eso si, la búsqueda recursiva del nuevo nautilus es una delicia (aunque estaría bien poder desactivarla a veces).
Busco documentos en cualquier otro entorno y me parece primitivísimo. De hecho he encontrado varias cosas extraviadas que no aparecían con locate
#10 De todas formas me da a mí que es bug no afecta a todo el mundo. Habla de 250mb cuando gasta mi Manjaro gnome3 1gib...
#16 Yo estoy con Manjaro y Gnome Shell comienza con 90MB+- y llega hasta 250-300.
#38 y la sesión entera con cuanto comienza? No me he fijado en el proceso concreto cuanto gasta al inicio. El 1GiB es sin abrir ningún programa.
#42 Eso depende de todos los procesos y programas que tengas cargados al inicio. Yo arranco con "relativamente" poco, pero sí que necesito Tilix, Nextcloud para mi nube personal, Seafile para la de trabajo, Synapse como lanzador y alguna cosilla más. En todo caso lo que tienes que mirar es el consumo de memoria de Gnome Shell.
#53 gracias.
#10 Windows traga bastante al arrancar pero luego en mi experiencia trabaja mejor con el swap y puedes tener bastantes más aplicaciones abiertas sin que el rendimiento se vaya a la mierda. Y ojo que Ubuntu ya está cerca teniendo la mitad de funcionalidad.
#19 mi ubuntu 11.10 al arrancar gastaba 600 MiB o incluso 400 MiB
2.5 GiB me parece una burrada de dimensiones de supercúmulo galáctico.
Y el como gnome3 devora memoria y no la libera es demencial. Antes podía tener 70 pestañas navegando. Ahora no puedo pasar de 30 sin que llegue la swap (que encima ed mas lenta que en mi portátil)... Y tengo 5 GiB de RAM principal...
Yo sospechaba que había algo ahí.
#23 Un Windows limpio no suele gastar 2'5GB, otra cosa son los programas que arrancan al inicio (y en los PC de los usuarios con pocos conocimientos suelen ser muchos ya que le dan a todo que sí).
De todas formas Windows tiene servicios de prefetching que cargan cosas en memoria antes de que las uses, pero si necesitas esa memoria las borra, te la asigna y listo. No tiene sentido tener la memoria sin usar.
#26 sí, lo último que hice fue deshabilitar el prefecthing. Tengo que volver a mirar si ha mejorado la cosa. Si fuera un ordenador de hace años diría que necesita desfragmentarse pero ahora lo hacen automático, creo.
Sobre la memoria sin usar, yo prefiero gestionar la memoria a mi gusto. En Ubuntu quitaba servicios que no estuviera usando para tener más memoria. A mis padres les da igual usar más o menos, lo que no puede ser es que vaya lento (y por eso me he enterado yo, si no podían estar usando la memoria que fuera sin yo saberlo).
#23 Es el proceso de Gnome Shell lo que tiene fugas de memoria. Más o menos hasta 250MB, que tampoco es tan grave. Lo que tú comentas tiene más que ver con el navegador. ¿Has probado usar otro?
#39 que navegador usas? Yo uso chromium.
#41 Yo uso firefox, que tampoco es que sea muy conservador con la memoria, pero es que hoy en día con todo lo que llevan las webs es imposible serlo. Con un ublock y un nocoin y poco más. Supongo que habrá extensiones tipo NoScript para limpiar bastante, pero también quitarán contenido de las páginas.
#54 Es que ya no se hacen webs como se hacian antes que se picaba practicamente todo. Ahora se instala un CMS que tiene un monton de cosas que la gente no es que no usen, es que no saben ni para que son. E instalar un plugin para cada chorrada que queiren hacer. Uno para hacer los formularios de forma visual, otro para cambiar la iconografía, otro para la gestión de usuarios, otro para los botones de redes sociales, otro para las camapñas de mailchimp, otro para..., etc. Suma y sigue. Cantidades ingentes de código ejecutandose porque no ha querido pasarse unas horas programando.
A eso sumale la invasión de efectos con jQuery, si no tienes en el index un slider de imagenes que ocupe el 50% de la pantalla y se vea de puta madre (pese a que no muestre información relevante) nadie quiere la web. Antes las webs eran pro-contenido y pro-funcionalidad, ahora parecen la medida de la poya del diseñador. Webs muy bonitas, pero que por dentro son una puta basura. El contenido y la eficiencia han quedado relegadas a segundo plano.
#68 Bueno, y también tienen más funcionalidades...
#72 Supongo que te referirás a los grandes sitios como Facebook que precisamente no usan CMS como wordpress y lo desarrollan todo (hasta sus frameworks JS). La gran mayoría de webs de empresas pequeñas o particulares siguen un patron. Con el tiempo ves que lo unico que cambia es la plantilla y las imagenes usadas (y no siempre, ya que la gente compra los packs de imagenes en los mismos sitios). Y en una web comercial eso no tiene ningun puto sentido, porque precisamente Google una de las cosas que valora, es que tu web sea diferente a la de los demás a la hora de posicionarte en los resultados.
#23 ¿Y la memoria para qué esta? Para ocuparla. No es malo utilizar la memoria si se hace conscientemente y con un buen fin.
Es ridículo que e sistema use poca memoria pero tenga que cargarla frecuentemente desde disco para ciertas tareas, cuando si el sistema es medianamente inteligente tener ciertas aplicaciones en memoria, si tengo 8 GB, ¿por qué no ocupar 2,5 para el sistema operativo si eso me permite mayor desempeño? ¿Que resulta que abro varias aplicaciones o una gorda que me ocupa el resto o necesito más? Pues ya veré lo que hago y si tengo que hacer limpieza la hago.
#57 no tengo 8 GiB. tengo 3 o 4 GiB en ese ordenador. (W10)
En un ordenador con 8 GiB está claro que no molesta.
En mi ordenador donde uso Manjaro Gnome3 sí me molesta que llegue hasta 5 GiB de memoria ram enseguida. En mi experiencia, debido a que el sistema devora la RAM, hay menos espacio para los programas que uso por lo que lo que provoca es un menor desempeño.
#10
Por otro lado el otro día arranque el windows 10 de mis padres y chupaba 2.5 GiB de RAM sin hacer nada de nada...
Windows 10 tiene caché de memoria, no está consumiendo 2.5gb sin hacer nada, los está preallocateando para otorgarlos después rápidamente.
#55 eso leí y deshabilité esa función. Iba todo super lentísimo por esa función.
#10 A mi locate me vuelve loco a veces. Cuando lo uso en fedora no tengo ningun problema, pero en ubuntu por ejemplo encuentra lo que le apetece.
#67 sí, me ha pasado mucho.
Con lo fácil que era echar la culpa a Intel
Desde que salió el nuevo Firefox, al cabo de un rato y con una docena de pestañas ya empieza a tirar de swap tengo 4 GB de RAM. Ubuntu Gnome 14.04
#35 Nada que ver con lo que menciona la noticia...
#35 pero eso es un bug en Firefox, ya esta registrado como tal.
reconocerlo es señal de mejorar ...
Un recolector de basura ya es una mala idea en si, siempre ha sido el talón de Aquiles de Java y también de ActionScript. Pero en los tiempos que corren es la solución más rápida para lenguajes de tipado débil.
#12 Nunca he entendido la obsesión con los malditos recolectores, sobre todo porque ni siquiera sirven, se pueden tener fugas de memoria en Java de muchas formas. Si por lo menos los lenguajes con GC te permitiesen liberar la memoria a mano si así lo deseases... Pero no, no tienes ningún control, y a veces es muy frustrante porque sabes que el mismo programa en c++ te funcionaría con 10 veces menos memoria (o incluso 100 veces menos en programas pequeños donde la JVM, el JIT, el propio GC, etc son un lastre y se llevan solitos el 90% de la memoria).
#c-12" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2926577/order/12">#12 #17 no habéis entendido nada...
Un recolector de basura ya es una mala idea en si, siempre ha sido el talón de Aquiles de Java y también de ActionScript.
Un recolector de basura es una automatización de un proceso que antes hacían los humanos, y que hace el desarrollo de software económicamente más eficiente sin prácticamente ninguna desventaja.
Lenguajes modernos y muy, muy avanzados como Go, tienen también recolector de basura. De hecho, no queda nada moderno sin recolector de basura.
Pero en los tiempos que corren es la solución más rápida para lenguajes de tipado débil.
Madre mía... Que tendrá que ver el tipado débil con el GC (recolector de basura en adelante)?
Pese a no existir una definición única de tipificación dura o blanda, existe consenso que java es de tipificación dura, igual que go. Y ambos tienen recolector de basura.
Nunca he entendido la obsesión con los malditos recolectores, sobre todo porque ni siquiera sirven, se pueden tener fugas de memoria en Java de muchas formas.
En ninguna plataforma con un recolector de basura que funcione puedes tener fugas de memoria. Entendiendo fugas de memoria como memoria que ya no es utilizada por la aplicación pero el sistema operativo piensa que si.
Y eso es imposible por qué cualquier GC lo que hace de una forma u otra, es contar las referencias que existen a una variable y si no existe ninguna referencia la libera. Los GC modernos además detectan sin problemas referencias circulares y no las tienen en cuenta.
Entonces, si tu programa en Go, java, php, perl, python , Ruby, c# o JavaScript pierde memoria, es por qué te estás guardando referencias a esas variables, y por ende, no tiene sentido liberar esas memoria, por qué literalmente la estás usando.
Si por lo menos los lenguajes con GC te permitiesen liberar la memoria a mano si así lo deseases... Pero no, no tienes ningún control
No tiene sentido que te deje liberar memoria a mano, ya que como te he explicado, no ha liberado esa memoria por qué tú has mantenido una referencia a ella, por lo que si la liberas, tu programa mal hecho petara por otro sitio. La memoria que el GC no ha liberado es un síntoma de que tu programa está mal hecho, ya que existe una memoria que tú como programador consideras liberable, pero en realidad sigues apuntando a ella desde otros sitios de tu programa, y si la liberas, esos sitios apuntarán a una memoria liberada, por lo que tendrás una violación de segmento tarde o temprano.
y a veces es muy frustrante porque sabes que el mismo programa en c++ te funcionaría con 10 veces menos memoria
Eso desmuestra que no sabes programar. La única memoria extra en plataformas modernas es el runtime, que en Go es pequeñísimo.
(o incluso 100 veces menos en programas pequeños donde la JVM, el JIT, el propio GC, etc son un lastre y se llevan solitos el 90% de la memoria).
Que tiene que ver churras con merinas? Estamos hablando del GC, no de java, ni de JIT etc. Esos programas tan pequeños de los que hablas, en la informática moderna no importa agregarle unos poco megas de memoria extra actu programa. Hacer programas que solo consumen 1k de RAM es hoy en día frikismo y no ingeniería, al menos en la muy inmensa mayoría de los casos.
Me gustaría que me expliques de qué forma el recolector de basura de Go está haciendo tus programas más lentos.
Luego, explicame lo del propio creador de B, predecesor de C y aclamado hacker de unix:
https://en.m.wikipedia.org/wiki/Ken_Thompson
Uno de los arquitectos de Go, lenguaje con GC.
Creo que os habéis quedado en java como único lenguaje con GC. Y que además en una versión antigua de java, y que además según explicáis, ni siquiera sabéis programar en java, por qué si su GC os leakea, es por qué os vais dejando referencias por ahí.
#17 Prueba D
Edito: y lee lo que te ha puesto #60 que es muuuuuy interesante.
#60 "sin prácticamente ninguna desventaja."
Ninguna, salvo un consumo de memoria y CPU completamente innecesarios, vamos, casi nada. El GC es una puta mierda, decir que es un proceso que antes hacían los humanos y ahora es automático es como decir que un taxi es mejor que un coche porque es un proceso que antes lo hacías tú y ahora lo hace el taxista. En ocasiones un taxi vale, pero en general es más caro, más lento, más torpe y te da menos libertad que tener carnet de conducir con coche propio. Si quieres un programa de verdad aprende a conducir e invierte en un coche y déjate de taxis.
"En ninguna plataforma con un recolector de basura que funcione puedes tener fugas de memoria"
Hay mil formas de tener fugas de memoria. Empezando por lo más básico: el heap sin usar consume memoria del SO, por lo que a la que tienes dos procesos Java ya tienes una fuga de memoria, debido a que no pueden compartir el heap. Por no hablar de cosas como referencias a objetos perdidas, objetos que sólo crecen a no ser que los serialices y deserialices (esto pasa en node por ejemplo), referencias circulares, y cosas más oscuras que sé que existen aunque ahora no recuerdo.
“Eso desmuestra que no sabes programar."
Dime cómo evito que esto me llene el heap de basura en Java sin llamar manualmente al recolector de basura, todavía nadie me ha contestado nunca:
MyObject foo = null;
for (muchas iteraciones sobre i)
En un lenguaje como c++ usas sólo un cachito de memoria, en Java va apilando toneladas de MyObject inútiles hasta que se pone en marcha el gc.
Por cierto yo hablo de los recolectores en general, no he probado el de Go en particular.
#60 (sigue de #81)
"No tiene sentido que te deje liberar memoria a mano, ya que como te he explicado, no ha liberado esa memoria por qué tú has mantenido una referencia a ella, por lo que si la liberas"
La memoria se mantiene hasta que se ejecuta el recolector, dentro de bucles se puede acumular una buena cantidad de basura que sería conveniente limpiar ya que sabes perfectamente que la referencia ha desaparecido. Podría reutilizarse el mismo trocito de heap en vez de llenarlo de porquería. Hay veces que hasta te puede saltar un OOM si pones un heap máximo muy pequeño y metes un new en un bucle. Te remito al pequeño ejemplo sin solución del comentario anterior.
"en la informática moderna no importa agregarle unos poco megas de memoria extra actu programa"
No importa al principio. Luego tienes 80 pequeños procesos Java en un servidor haciendo distintas tareas y resulta que no te da la ram y tienes que ponerle más. (Aunque en mi opinión no tiene sentido tener tantos procesos Java, pero es lo que tiene usar una arquitectura de microservicios y basarla en Java...).
"Creo que os habéis quedado en java como único lenguaje con GC"
Javascript también tiene sus problemas. Y python. Yo tengo un proceso en python que encontré en algún sitio que termina petando toda la memoria del PC si lo dejas unos días en marcha. Y Go me imagino que también será menos eficiente que una buena gestión de la memoria manual, aunque quizás sea mejor que estos dos.
Y, ¿sabes qué es lo peor de una fuga de memoria en un lenguaje con GC? Que en ocasiones, aunque sea memoria muerta, el SO no la manda al swap tan fácilmente como lo hace con un proceso sin GC, porque el GC hace cosas con el heap. El mencionado proceso Python me jodía todo el sistema, mientras que una fuga de memoria en C acaba paginada y no molesta salvo que se te llene el swap.
#82
Estás diciendo tonterías sin parar.
En primer lugar, las fugas de memoria son mucho más comunes en lenguajes donde el programador es el responsable de la gestión de la memoria: obviamente.
Solo dejarte un delete o un free, y pam, memory leak.
En las plataformas son recolector de basura , como Go, eso no puede suceder, a no ser que tú activamente dejes un apuntador a esa variable.
Obviamente, si haces un bucle invocando objetos sin parar, se va a llenar la memoria, igual que sucede en cualquier lenguaje, en C++ tendrias que ir haciendo delete, y en java te recomendaría encapsular ese bucle en una función, para que entre el return y el siguiente call, se ejecute el recolector de basura más fácilmente. De todas formas, eso ya son detalles implementativos de casos exóticos. En los programas de alto rendimiento que desarrollo, el recolector de basura no es ningún problema.
Lo bueno que tiene el recolector de basura es que un novato obtiene unos resultados aceptables y no la lía parda, y un experto, sabe cómo montalro, para los casos límite o más especiales. Mientras que sin recolector de basura , solo el experto puede conseguir resultados aceptables. ¿De verdad no ves la superioridad del GC? Es obvia.
#87 "Lo bueno que tiene el recolector de basura es que un novato obtiene unos resultados aceptables y no la lía parda"
Y lo malo es que el novato no aprende y es descuidado forever. Es como usar una bici con ruedicas para que el niño no se caiga. Que no te digo que en algunos casos un lenguaje con GC no sea lo ideal, pero empeñarse en usarlo para hacer aplicaciones me parece horrible. Scripts sí, aplicaciones no.
#90 donde ves el problema? La inmensa mayoría de aplicaciones van a obtener más rendimiento con un GC que sin el. Gestionar la memoria de manera manual es un capricho de ingeniero, que tiene sentido en contadas ocasiones y que la inmensa mayoría de las veces va a suponer un sobrecoste innecesario.
#95 "La inmensa mayoría de aplicaciones van a obtener más rendimiento con un GC que sin el"
"Gestionar la memoria de manera manual es un capricho de ingeniero, que tiene sentido en contadas ocasiones y que la inmensa mayoría de las veces va a suponer un sobrecoste innecesario." -> "Poner parquet en el suelo es un capricho de arquitecto, que tiene sentido en contadas ocasiones, y que la inmensa mayoría de las ocasiones va a suponer un sobrecoste innecesario."
Vamos a ser claros: para una nave industrial dedicada a fabricar coches no quieres suelo de parquet. Lo mismo pasa con un servidor que se dedica a gestionar pedidos de venta. Pero una aplicación para usuarios, para que la ejecuten en sus dispositivos, el GC es una guarrada.
#96 creo que estás muy muy confundido. La inmensa mayoría de aplicaciones con un GC van a ir más rápidas por qué se puede hacer economía de escala y optimizar al máximo esa pieza, frente a tu trabajo de artesanía de la memoria aplicacion por aplicación.
Dicho esto, yo soy más del show me the code.
Yo soy autor de un cliente web de spice. Básicamente una tarjeta gráfica en 2 dimensiones implementada 100% en JavaScript client side.
https://github.com/eyeos/spice-web-client
La implementación de LZ77 que hay ahí dentro, descomprime un bitmap full HD en menos de 8ms. El cliente web de spice en general, en casi todo, es más rápido que el original, escrito en C++.
Cómo puede ser? Pues por dos razones.
La primera, es que al apoyarte en abstracciones correctas, estás pueden ser optimizadas haciendo economía de escala: cada nuevo Chrome, más rápido va el cliente web de spice.
La segunda razon, es que los Juniors creen que lo que hace más rápido o lento un programa son ese tipo de optimizaciones micro, cómo optimizar la memoria a mano. En realidad, lo que hace más rápido o lento a un programa es la gestión de la entrada y salida y una buena implementación de la concurrencia para poder paralelizar.
Créeme, no vas a hacer un programa completo user facing más rápido en C++ que un experto lo hace en Go (para comparar manzanas con manzanas) y además, el que lo hace en Go, lo va a hacer más rápido que tú, va a ser más difícil que tenga leaks y no va a segfaultear.
Pero en serio, puedes seguir con tu new y delete, y obviar 25 años de ciencias de la computación.
#97 La recolección de basura es más rápida en algunos casos porque evita tener que pedir memoria al sistema. Eso nunca lo he negado. Pero eso no sirve de nada cuando llenas la memoria y el PC empieza a tirar de swap. Tampoco sirve de nada cuando tienes una aplicación que es intensiva en memoria. Además, si quieres que una aplicación corra, nunca usas new y delete. Yo por ejemplo tenía un pequeño proceso en c que rellenaba una estructura en un bucle, iba lento porque usaba malloc en el bucle. Pero en cuanto reemplacé el malloc por mi propio getMem, que me devolvía memoria de un pool de memoria, volaba. Por lo que cuando dices que JavaScript es más rápido comparas peras con manzanas. En C++ también puedes pedir la memoria por adelantado para evitar esperar al sistema. Y seguramente hay librerías que lo hacen. Por ejemplo con QT nunca usarás un delete, ya lo hace QT.
Y la recolección de basura añade overhead que penaliza la velocidad. Por no hablar de la cantidad de memoria que traga para toda esa optimización.
Si JavaScript fuese más rápido que C++ no habría programas hechos en C++.
En cuanto a las abstracciones de las que hablas, JavaScript precisamente falla estrepitosamente por la falta de estructura que tiene. Para algunas cosas funcionará bien, pero el interprete nunca sabe si le vas a añadir a un objeto 400 propiedades o ninguna.
En cuabto a Go, ya te digo que no lo he usado nunca.
Pero ya que hablamos de velocidad, si bien es cierto que un lenguaje con GC puede mejorar la aproximación ingenua de usar new y delete conforme se necesitan, nunca, nunca podrá ni acercarse al rendimiento que obtiene un programa con la memoria bien organizada. Porque en un caso tienes una colección de objetos relacionada por numerosos punteros, con huecos libres para poder modificar los objetos sin reubicarlos, ya que el sistema no sabe qué vas a hacer con ellos, y en el otro, con una gestión manual de la memoria puedes organizar los objetos perfectamente empaquetaditos, sin punteros, con el espacio justo, en una zona de memoria contigua, de tal forma que minimizas los fallos de caché del procesador al recorrerlos. Y teniendo en cuenta que un fallo de caché noquea al procesador varios ciclos, no es moco de pavo.
Decir que usar un lenguaje con recolección de basura te lleva a un mejor producto es como decir que con un puñado de plástico y un par de moldes puedes superar a una carcasa unibody de aluminio, porque es más fácil y da menos problemas.
#98
En cuanto a las abstracciones de las que hablas, JavaScript precisamente falla estrepitosamente por la falta de estructura que tiene. Para algunas cosas funcionará bien, pero el interprete nunca sabe si le vas a añadir a un objeto 400 propiedades o ninguna.
javascript hace años que tiene typed arrays, es decir, estructuradas de tamaño fijo y tipado, que permiten trabajar con memoria de alto rendimiento.
Además, eso que dices es falso, depende de como programes tu función, el optimizador de v8 (o el que sea, depende para que vm estés optimizando) la conseguirá optimizar o no. Optimizarla significa pasarla a nativo. A veces ciertos usos de javascript impiden hacer eso, y se ejecuta en el entorno JIT, y entonces mas lenta: el 99% de hacer javascript de alto rendimiento consiste en paralelizar con web workers, usar arrays tipados y escribir las cosas de forma que sean optimizables.
Pero ya que hablamos de velocidad, si bien es cierto que un lenguaje con GC puede mejorar la aproximación ingenua de usar new y delete conforme se necesitan
Es decir, un programador novato o normalito conseguirá mejor rendimiento con GC que con gestión de memoria manual, y a un coste mucho mas bajo. El programa será mas simple, por ende, mas mantenible y extensible.
Un programador experto, podrá gestionarse su memoria guardandose punteros a estructuras que no quiere que el gc libere y crearse object pools (técnica que uso en el cliente web de spice), de esta forma, reutilizo los objetos sin pasar por el gc. Es decir, un programador novato lo hace mejor y mas barato con gc, y un programador experto, como es experto, sabe buscarse la vida con y sin gc.
Con gc siempre es mas barato (en tiempo de desarrollo) y el programa siempre queda mas simple, hace menos cosas tu código, y es mas mantenible que un programa que tiene la complejidad agregada de gestionar memoria.
nunca, nunca podrá ni acercarse al rendimiento que obtiene un programa con la memoria bien organizada. Porque en un caso tienes una colección de objetos relacionada por numerosos punteros, con huecos libres para poder modificar los objetos sin reubicarlos, ya que el sistema no sabe qué vas a hacer con ellos, y en el otro, con una gestión manual de la memoria puedes organizar los objetos perfectamente empaquetaditos, sin punteros, con el espacio justo, en una zona de memoria contigua, de tal forma que minimizas los fallos de caché del procesador al recorrerlos. Y teniendo en cuenta que un fallo de caché noquea al procesador varios ciclos, no es moco de pavo.
Eso que tu dices que no es moco de pavo, en mi experiencia si lo es. Casi nunca he tenido que optimizar hasta ese nivel para un cliente. Es interesante por que parece que te interesa el tema, yo me dedico profesionalmente a esto, es decir, como consultor he cobrado mucho dinero por optimizar programas en todo tipo de plataformas y entornos. En mi experiencia del mundo real, casi nunca (por no decir nunca), los problemas venían por tener huecos entre la memoria del heap (por poner un ejemplo) y casi siempre, implementar esos mecanismos que propones, acarreaba muchas complejidad y costes en el programa (fuentes de bugs, etc) que benificios perceptibles proporcionaba. Cuando era joven tiraba mucho por ahí, hoy en día, a base de aprender, mi intuición me lleva a optimizar otro tipo de cosas, donde obtengo muchos mas puntos por un coste mucho mas bajo, que de eso va esto.
Decir que usar un lenguaje con recolección de basura te lleva a un mejor producto es como decir que con un puñado de plástico y un par de moldes puedes superar a una carcasa unibody de aluminio, porque es más fácil y da menos problemas.
El problema es que tu comparación con la carcasa unibody es incorrecta: una vez producida la carcasa unibody es un objeto bastante simple, que le va a dar incluso menos problemas al dueño que el plastico. Pero un programa que además gestiona la memoría por su cuenta, sin automatismos, es un programa obviamente mas caro de producir, que tiene mas componentes que hacen mas cosas. Tiene mas fuentes de posibles bugs etc. Entonces, es un programa mas caro de producir, y mas caro de mantener. Además, la mayoría de las veces, como ya he dicho, conseguirás mejoras de rendimiento imperceptibles en el mejor caso, y un rendimiento incluso peor en el peor caso (dependiendo del nivel del equipo de programadores).
Además, algo que no has comentado... los programas a veces se mantienen años, y no los mantienes siempre tu, ni siempre un equipo experto. Entonces, dentro de 10 años, mi programa con GC es mas probables que siga teniendo un rendimiento aceptable, comparado con tu gestión casera de la memoria, que la habrán tocado ya 20 manos, y la habrían liado parda
#98 Olvidas las optimizaciones JIT usadas en emuladores. De hecho el emulador Ruyjinx de Switch en .NET es más rápido que Yuzu en C++.
#97 Por cierto no entiendo a qué te refieres con lo de una tarjeta gráfica
Aunque igual le echo un vistazo al proyecto ese, que soy muy friki del rendimiento y últimamente me estoy volviendo bastante friki de JavaScript
#99
Por cierto no entiendo a qué te refieres con lo de una tarjeta gráfica
Una tarjeta gráfica es un dispositivo que recibe ordenes de pintado en forma de expresiones sobre un modelo de datos y genera imagenes rasterizadas de 2 dimensiones sobre un dispositivos de salida de imagen o sobre un fichero. En este caso, el cliente web de spice es un cliente de un protocolo de escritorio remoto llamado SPICE, de red hat. Este protocolo captura las ordenes de pintado en 2 dimensiones, y en lugar de procesarlas en local, las redirecciona hacía otro ordenador, que las procesa y genera la imagen resultante. Esta es la misma forma en que funciona citrix, rdp (rdesktop, ts) etc. Es mucho mas barato envíar ordenes de pintado de bajo nivel que imagenes rasterizadas.
No existía hasta que implementé ese, un cliente web de spice de alto rendimiento por que procesar las ordenes de pintado y descomprimir los modelos de datos en caliente y en javascript en un navegador se consideraba demasiado lento como para usos reales.
Desarollé ese cliente superando en performance no solo al cliente web de spice anterior (otro proyecto, que no tiene nada que ver con mi implementación), sino en varias cosas al propio cliente nativo, en c++, escrito por expertos de red hat.
Y no lo digo para decir "oh que crack que soy", sino para demostrarte que una plataforma de alto nivel, con recolector de basura, bien utilizada puede llegar a ser muy, muy performante.
#97 Otro ejemplo: elasticsearch (escrito en Java): tras una agregación gorda (con éxito irónicamente) se queda tonto y responde a trancas y barrancas, mensajes sobre los intentos del recolector de basura en el log, va como el culo, deja de responder peticiones a ratos... reinicias y todo va de nuevo a las mil maravillas, pero has tenido que reiniciar todo un motor de indexado y búsqueda, del que dependen un montón de procesos, ¿Por qué? ¿Por qué no puede simplemente liberar la memoria que había usado para la agregación y seguir funcionando? ¿Cómo hacen los desarrolladores para decirle al GC que no comprometa los recursos básicos para mantener la estabilidad?
#97 >En realidad, lo que hace más rápido o lento a un programa es la gestión de la entrada y salida y una buena implementación de la concurrencia para poder paralelizar.
Básicamente las directrices de Unix desde hace 50 años
Apliqué esa política no en programación, pero si en un script con 10Gigas de logs binarios de Windows con find, strings y xargs. En 5 minutos literalmente parsée cientos de miles de entradas e hice un listado.
#81 perdona, pero no estás hablando de los recolectores de basura en general, estás hablando todo el tiempo de los detalles implementations de java.
Madre mía, te tiras todo el post hablando de la JVM y luego dices que hablas en general, vaya tela.
Me queda bastante claro que no has visto nada que no sea la JVM.
#85 También he hablado de JavaScript y de Python.
#86 has hablado muy poco de ellos, básicamente los has mencionado y has dicho que tenías un programa en Python que te llenaba la memoria: felicidades, Python es Turing complete y como consecuencia, puede llenar la memoria si quieres.
#85 no merece la pena que sigas, le sobra soberbia y le faltan conocimientos.
#17 Si tienes memory leaks en Java no es por el GC, es porque tu programa esta mal hecho. Y eso de que te permitiese liberar memoria "a mano" es una burrada.
#65 No es una burrada. ¿De dónde te sacas que es una burrada? Yo sé mejor que el GC cuándo un objeto ya no va a ser usado. El peor caso es cuando los creas dentro de un loop, es horrible, se puede llegar a acumular un montón de basura.
#77 Claro, mas listo que el GC de Java. Viniendo de un tio que ha escrito el comentario en #17 parece totalmente fiable.
#78 Como ya he dicho, si instancias un objeto dentro de un bucle (a veces no queda más remedio) al final de el bucle se podría eliminar, teniendo un sólo objeto por iteración en vez de cientos o incluso cientos de miles. Pero en Java toca ir acumulando objetos en el heap hasta que se despierte el GC. Y si lo llamas a mano adiós CPU.
#83 No acumula cientos de objetos en el heap. Si lo que quieres es que se borren, se borraran incluso antes de que la funcion acabe. La GC va ejecutandose para los young generation objects y puedes crear millones de objetos en un bucle si quieres que puedes correr el programa con 20MB de memoria para la JVM, no se quedan todos los objetos ahi esperando a que acabe el metodo para que luego la GC haga un borrado masivo.
La GC de la JVM no es ninguna tonteria ni ningun juguete, ha mejorado MUCHISIMO con el paso del tiempo y borrar objetos a mano (con lo que eso conlleva y la de bugs/leaks que puedes crear) VS tener una GC de esta calidad, gana por goleada usar una GC. Ya ni hablamos de la productividad y calidad del software que tenemos gracias a un lenguaje como Java y su GC.
#84 "Si lo que quieres es que se borren, se borraran incluso antes de que la funcion acabe."
Explícame cómo. Porque no es eso lo que a mi me pasa.
"Ya ni hablamos de la productividad y calidad del software que tenemos gracias a un lenguaje como Java y su GC."
Sí, porque todo el software de calidad está hecho en Java
#89 Que te explique el que? Seras al unico que no le pasa, que version de la JVM estas usando?
La JVM esta optimizada para operar con objetos de corta vida (a veces milisegundos). Se guardan en la parte del heap llamada "Young Generation". Cuando se llena, se ejecuta lo que se llama un "Minor Garbage Collector", que es muy rapido. Los objetos van moviendose a generaciones mas viejas si van sobreviviendo a las recolecciones. Vamos, que en el caso que comentas, a efectos practicos, es como si las referencias se liberasen "gratis" sin tu hacer nada y teniendo el mismo efecto que si tu lo haces manualmente. El problema que mencionas de que se quedan en la Heap durante un largo tiempo y luego la CPU "se muere", simplemente no ocurre.
No he dicho que todo el software de calidad sea en Java, pero Java esta muy bien considerado y su rendimiento no es comparable a hace años. La gente sigue repitiendo las mierdas como si fueran un dogma porque queda bien y hace gracia, pero si te paras a leer te daras cuenta de que no.
Lo que si es verdad es la mayoria de las empresas para todo tipo de proyectos (incluidos los low latency systems), por temas de rendimiento, ecosistema, fiabilidad, calidad y productividad, escogen Java en un altisimo porcentaje de los casos.
#92 En mi experiencia en mitad de un bucle no se libera nada. Quizás metiendo el cuerpo del bucle en una función mejora, tendré que probar.
#93 Para probar, ejecuta el programa con un comando parecido a este:
java -Xmsm -Xmxm -verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails TuPrograma
Y veras todas las veces que se ejecuta la GC, cuanto tarda y cuanto libera.
#12 Más bien es la solución rápida para programadores o sus respectivos jefes de capacidad débil.
#12 Sabes lo que estas diciendo? Hacia tiempo que no leia tantas burradas juntas en un solo comentario
#31 a mi parece inferior a gnome3 y te estoy contando la cantidad de problemas que me da manjaro con gnome3...
Pero quizás son equipos muy malos, yo que se...
Con un ordenador que no fuese del año de la polka reconvertido (en el que tengo gnome3 fácil es un sobremesa de cuando salió el windows7) pues a lo mejor iría todo bien. Y lo de windows no me lo explico porque le he quitado tropecientas cosas de que se arranquen al inicio... (es del año de windows 8 ).
Pero ya digo que lo he visto con muchos ordenadores y algunos son nuevos del año pasado, se queda pillado si cambias el foco muy rápido. Por suerte suelen ser menos de 10 segundos.
#33 Es cierto que windows 10 se deja en controladores casi 2gb de ram, tampoco veo razón para no hacerlo y también es cierto que nunca he visto interfaz más rápida. Por mucha perreria que hagas, gestiona la ram de manera genial, nada que ver con anteriores windows, instantáneo siempre, en un pc con 8gb de ram. También tengo un pc con 4gb y en cuanto acaba de cargar al inicio también va sin ningún tirón, ni tarda más de un segundo en cambiar ventana.
#37 qué suerte. Yo nunca he visto eso. Si acaso cuando usaba 9.10 iba todo súper fluido. Los ordenadores que uso de 8GB de RAM usan windows 8 creo o 7, no 10 y el que gasta 2.5 de inicio tiene apenas 4 gib de RAM.
Por fin. Ahora otros 18 años para publicar la solución.
Para mi lo que en su dia fue Gnome ahora lo es XFCE.
#18 Amen, hermano
Por otro lado, quien redacta el articulo no tiene mucha idea de que es lo que habla, suelta los términos al azar casi. Es una traducción un tanto renqueante.
#29 ese chiste es un poco viejo y repetitivo. Los informáticos hoy en día no son 4 frikis vírgenes. Son gente normal, con conocimientos avanzados sobre una temática.
Noto un poco de complejo de inferioridad siempre que leo esa broma.
¿Gnome tiene recolector de basura?
Un Sistema Operativo (y su interfaz) debería gestionar la memoria correctamente y punto.
Mi experiencia con Linux en comparación con Windows es horrible y probablemente se debe a este tipo de cosas, cuando sólo tienes un par de terminales y el correo electrónico no pasa nada, pero cuando eres como yo, que tiene decenas de programas abiertos de forma permanente, se ven en seguida los fallos.
#15 windows es aun peor en estos temas. Si pones un programa a full hay una gran probabilidad de que el resto no tiren. No puedes comprimir 7 cosas a la vez, renderizar 3 y escuchar musica a la vez.
Haciendo eso en Ubuntu se me entrcortaba a veces la música.
En windows pones un fractal a renderizar y te has quedado sin ordenador, la ventana se pone blanca y no responde y la música se entrecorta.
Leí un estudio que soy incapaz de encontrar que hacia una comparativa en velocidad de memoria , liberación etc. Creo que era sin efectos ni nada, el kernel a pelo de ambos.
El resultado es que windows liberaba memoria y movía memoria mas rápido que windows en cantidades medias y pequeñas mientras que linux tardaba menos en cantidades mayores.
Hablaban también de que si se hacia un gráfico , el comportamiento de reserva, movimiento y liberación de memoria tenía una gráfica continúa en linux de tiempo/memoria mientras que la de Windows era mas impredecible y asociaban eso a una gestión mas errática de la memoria y auna menor estabilidad.
Es una pena que nunca lo haya vuelto a encontrar, estaba bastante bien el estudio y daba resultados que a mi me parecieron inesperados.
#20 Lo que dices es precisamente lo que hago mucho mejor en Windows que en Linux. ¿En qué versión de Windows te quedaste?
A mi Windows siempre me ha funcionado bien viendo por ejemplo una peli fullHD mientras Matlab anda a todo trapo con el 100% de la CPU. Nunca jamás se me ha entrecortado la música.
Y la razón es que en Linux se usa un CFS (completely fair scheduler) como aproximación al reparto de tiempo de la cpu, que funciona bien en entornos multiusuario como los servidores, pero que no tiene los ajustes concretos que tiene Windows para priorizar la ventana que tiene el foco, o la reproducción de música (entre otras cosas porque Linus no quería mantener dos schedulers).
#24 windows 10. Pero sí luego me he dado cuenta que es el scheduler, no la memoria.
Pues tendrás mucha suerte porque yo estoy acostumbrado a usar todo deprisa (cambiar de ventana rápido, moverme con el teclado) y lo de ver ventanas que dejan de responder es lo mas habitual del mundo aunque no hagas nada pesado. Son fallos que se aceptan, no me pondría a hacer las burradas que te he descrito arriba en un windows y lo segundo es moverte más despacio, pero sí que me he fijado que pasa en ordenadores que no deberían tener problema alguno en mover absolutamente nada. Así que yo creo que es algún cuello de botella. Lo he visto en Vista, en 7 , en 8 y en 10. Cuando usaba XP eran otros tiempos y uno tenia paciencia (era increíble la paciencia que había que tener...).
Pero ya digo, gnome3 está siendo una dcepciin también en esto que te comento porque aunque un renderizado o dos los soporta en cuanto empieza a devorar RAM y mandarla a la swap empiezan a aparecer los cartelitos de no responde. Ya digo, como si fuera un windows o ¡peor!
#30 Pues yo me muevo a toda hostia con decenas (y hasta un centenar) de ventanas y el que responde al instante es Windows. He llegado a usar el paint con atajos del teclado
Los linux que he probado todos tienen ciertos retrasos al hacer alt+tab, especialmente cuando tienes muchos procesos tragando CPU y el scheduler no prioriza el alt+tab. Suelo usar Mate btw. Unity es horrible.
No sé qué ventanas te dejan de responder a ti. Windows 10 es una mierda por su política de actualizaciones y privacidad (y por sospechas mías de que están descuidando algunas cosas) pero en tema de rendimiento de la interfaz de usuario es muy bueno.
#20 windows liberaba memoria y movía memoria mas rápido que linux*
#15 Los autores de Vala intentaron que se usase su lenguaje, que tiene gestión automática de memoria sin necesidad de GC, pero la idea no cuajó y se fueron a Javascript... Sí, Gnome Shell está escrito en Javascript. Y lo he sufrido. Me gusta Gnome Shell, pero pero fuera; sus tripas las odio con fuerza.
Este es el año Linux sin memoria
Curioso, parecido a lo que me ocurre en W10. A veces la RAM va aumentando su uso hasta que llega al 98% aprox y hasta que no reinicio no se limpia la RAM. No se exactamente cuando o por que. Sí he comprobado qie teniendo algún programa torrent descargando sea el que sea, se va llenando. He leído que si incompatibilidades con tarjeta de sonido y varias cosas raras pero sin solución.
Yo de gnome solo se que es feo de cojones...Lo he visto y ya tiene que ser la bomba a la hora de abrir cosas y configurar hasta las cortinas de las ventanas...Por que si no no lo entiendo...Yo he visto kde y se parece mas a la idea que yo tengo de un escritorio "moderno", eso si, falla mas que una escopeta de feria en el tema de las actualizaciones, las notificaciones y correrlo sobre un virtualbox es para juaquer, pero aun asi no puedo con gnome.
En mis tiempos mozos era responsable de limpiar lo que había desordenado de mi habitación, de limpiar lo que el perro hacía y de liberar la memoria que usara.
Linux es bueno en entorno servidor, eso nadie lo duda, pero en escritorio, en mi opinión no deja de ser un juguete (mejor dicho, mil juguetes, porque hay un follón de escritorios o entornos visuales)
Es obvio que si cualquier empresa como Windows o Apple quieren lo dejan en pañales. Para mi, siempre han estado por encima en ese aspecto de GNU/Linux. Que no deja de ser un juguete de ciertos programadores, algunos de ellos muy buenos y con una finalidad sin duda encomiable, pero eso de por sí no te garantiza un buen resultado.
Esto que significa? Va a ser más rápido ahora ? Consumir menos RAM ? Que mejoras supone esto ?
#11 gnome shell (gnome 3) tiene un bug, en el que va aumentando la memoria que va usando, poco a poco, sin liberarla, por algo tan sencillo como pulsar los iconos, se coge un trocito mas de ram.
Esta solución, hará, o debería hacer que consumiese muchisima menos ram, y si, algo se notará en el rendimiento. El principal problema de gnome-shell, es el lenguaje en el que está escrito, javascript, que no es una maravilla...
#11 Si no te has enterado, enhorabuena. No quedarás virgen.
Aunque no se menciona la fuente es una traducción (mala) de omgubuntu:
https://www.omgubuntu.co.uk/2018/03/gnome-shell-memory-leak-is-being-fixed
#36 La traducción puede que no sea buena pero por favor, no digas que no se menciona la fuente pues siempre los artículos son enlazados al original.
#52 Me retracto. No había visto el enlace al pie del arti'culo que dice "original". Veni'a de leer el arti'culo original y al buscar la palabra "omgubuntu" no la encontre'.
Dicho esto, creo que seri'a mejor que se dejara claro que el arti'culo es una traduccio'n al principio, por si alguien quisiera leer el original su lugar.