Desktoppens ram-forbrug.

Ud fra figuren kan jeg se 42 MB ud fra Mate som du nok forestiller dig er Gnome2. Men det tal er ret lavt.
Googlede også lige og fandt https://flexion.org/posts/2014-03-memory-consumption-of-linux-desktop-e….

Ligemeget hvad er der vel mere end et år mellem hver kde/gnome/... og ifølge Moores lov må de bruge dobbelt op for hvert år, så det er vel ok :-)

#0
Jeg synes så ikke det er nogen særlig god oversigt og jeg ville nok foretrække du linkede til artiklen hvor du har fundet figuren frem for bare at linke til figuren. Det er ganske enkelt ikke muligt at bruge figuren hvis ikke man ved hvilken test der er benyttet ved hver desktop. Artiklen som #1 linker til er langt bedre og forklarer også hele problemstilling med "æv bæv min desktop bruger mindre ram end din desktop" da det ikke er rimeligt udelukket at måle desktoppen og ikke de programmer du bruger samtidig.

Fx er det jo meget fedt at du kan have en lækker desktop med dwm men du har så heller ikke indlæst GTK så når du skal bruge et GTK program så vil du opleve en langt større stigning i RAM forbrug end hvis du brugte fx Gnome som allerede benytter GTK og derfor har GTK i sit "ram forbrug". Alene problemstillingen med delte biblioteker gør at det ikke er meget værd at lave sådan et billede som #0 kommer med uden testresultater.

Og i sidste ende er det ikke RAM forbruget du bør vælge desktop ud fra med mindre du er meget presset men derimod hvilken desktop der opfylder dine behov. De desktops der er listet i billedet har alle fordele/ulemper der er meget bedre at snakke om end RAM forbruget. :)

(jeg er klar over jeg siger desktop her men at der er tale om en blanding af Desktops og VM'er. Dette gør det dog endnu værre at lave billedet der diskutteres eftersom det gør vi sammenligner motorer op imod hele biler).

#1
Dine 2014 tal fra
https://flexion.org/posts/2014-03-memory-consumption-of-linux-desktop-e…
viser det samme "mønster" som mine fra https://l3net.wordpress.com/lightweight-linux/
MATE 123.0 MiB / GNOME3 245.3 MiB.
Lavede man en 2015 test, vil man få lidt højere tal, men det samme mønster.
Og nej det handler ikke om "æv bæv min desktop....", men om "at få meget ud af lidt".

Nå, men "Pingvinen sover" > tilbage til stilheden.

Ok. Kan godt se det kommer til at fylde meget mere, Gnome og KDE. Men som der også nævnes, er det vigtigste for mange at de har nok RAM til at starte programmerne når Desktoppen er loadet. Og at det er nogenlunde stabil og forudsigelig.

Jeg har for nyligt afprøvet Mate og længtes kortvarigt tilbage til gamle dage. Indtil der kom flere dejavu fra Gnome2 med bla. mate-settings-daemon.

Jeg har nok RAM til KDE4 til min arbejdspc, så det er mit primære valg. Kan huske den var ustabil for et par år siden, men det er fortid. Hurra.
På mine gamle pcere er det efterhånden kun LXDE der regerer. Men friheden til at skifte desktop efter hvad man nu har lyst til er en af Linux fedeste features.

Unity og Gnome3 er IMO noget for de unge. Mate for den nostalgiske og tålmodige. XFCE og LXDE for den travle ejer af en gammel PC.

Folk går for meget op i RAM forbrug. Et eller andet sted, så er ubrugt ram jo spild.
Jeg mener ikke man kan stille det så sort/hvidt op som det her diagram viser det. Mange programmer gør jo det, at de reserverer noget ram, så de kan performe bedre - ikke at jeg siger at det nødvendigvis er grunden til at KDE og GNOME er så ram-sultne ;)

#5
Men der er også det element at de letvægtige VM'er ikke har indlæst de libs der bruges af de store DE'er således når du så starter et program op der skal bruge fx QT eller GTK så vil du hurtigt se en stigning af RAM forbrug ved letvægtige VM'er end ved de store DE'er.

Det forklarer self. ikke hele RAM forbruget og de store DE'er er mere sultne men det er næppe så galt som billedet viser i #0 og især ikke hvis man i forvejen bruger mange QT og GTK programmer (måske endda begge dele). Derimod hvis du i forvejen bruger meget lidt grafiske programmer og mest holder af at bruge en terminal kan det give god mening med de letvægtige VM'er.

#6: men det er næppe så galt som billedet viser i #0

Min erfaring er at det er så galt med et par modifikationer at du sagtens kan konfiguere både xfce, gnome og KDE til at bruge mere end det viste. og selv KDE. 200mb er lætvægts i sammenligning med webbrowsere(især chrome på trods af dens minimalisitske image), kontorprogrammer og spil.

Der er iøvrigt nogle gode grunde til at vi idag ser øget ram forbrug blandt andet at moore's lov er brudt og du idag ikke får stærkere kerner så du skal finde ny ydelse andre steder og et af de steder er i ram, men svjv er den største af stigningen fordi man har skiftet fra ascii/ISO-8859-1 til Unicode og 64bit integer som native dataformater. hvilket løser en frygteligt masse problemer for lokalisering men koster en smule ram.

QT5 og til nogen grad GTK3 håndtere ting som GTK+ ikke forsøger bland andet touch og alternative grafik motorer og hardware accelleration og det gæres typisk ved at loade index tabeller i ram en strategi moderne JIT runtimes også gør brug af.

Det er altid en balance gang mellem resourcer og funtionalitet og optimering har ofte også sikkerheds implikationer der er svære at håndtere, hvilket er en anden grund til at minimering af ram forbruget sjældent er en målsætning idag.

Det eneste område hvor ram er et problem er med virtialisering og det mest fordi man her er tvunget til at assigne ram statisk, hvilket er grunden til at containere(en gammel unix ide iøvrigt) er på vej frem når det kommer til større systemer.

#7
Beklager men dit indlæg er så fyldt med sludder at jeg bliver nød til at bede dig om at linke til nogle af de påstande du kommer med... fx hvad Moore's lov har med øget RAM forbrug i KDE og GNOME.

Det er også som om folk bliver ved med at tro jeg siger at tallene ikke passer eller er for høje. Du kan nemt få alle miljøer til at bruge mere RAM men jeg siger bare at hvis du starter en GTK applikation i DWM (der står til at bruge 1 MB RAM) så vil du opdage en langt større stigning i RAM forbruget på din maskine end hvis du starter den første GTK applikation i GNOME fordi størstedelen af alle programbiblioteker relateret til GTK applikationer allerede er indlæst (og fylder så som en del af GNOME RAM forbruget hvis man måler på den måde som der er lagt op til).

En stor del af Linux er shared libs som handler netop om at mange applikationer deles om de samme programbiblioteker. Det betyder at hvis to programmer bruger GTK så vil GTK biblioteket ikke blive indlæst dobbelt men de to processer deles om det. Men dette er umådeligt svært at se når du bare laver primitive målinger af RAM forbruget som der er lagt op til i #0 (eller vi aner forresten ikke hvordan dette er målt).

#7: QT5 og til nogen grad GTK3 håndtere ting som GTK+ ikke forsøger bland andet touch og alternative grafik motorer og hardware accelleration og det gæres typisk ved at loade index tabeller i ram en strategi moderne JIT runtimes også gør brug af.

Det lyder mest af alt som om du har læst et par artikler og kun husket 10% af de buzzwords der er blevet fyret af og så opdigtet resten. Jeg anede desuden ikke at KDE brugte JIT men du har måske en artikel jeg kan læse omkring dette? Og hvilke moderne JIT runtimes er det du refererer til (igen gerne med links).

#8:
Beklager men dit indlæg er så fyldt med sludder at jeg bliver nød til at bede dig om at linke til nogle af de påstande du kommer med... fx hvad Moore's lov har med øget RAM forbrug i KDE og GNOME.

Det hele hænger sammen i gamle dage hvor ram var dyrt og CPU'er hurtige var det tradeoff man lavede at lade cpu'en "udpakke data" idag hvor CPU ydelse ikke stiger mens ram er billigt så er valget typisk at have mere data i "raw" format i ram. IE for 10 år siden ofrede du CPU tid for at spare hukommelse idag er det modsatte tilfælde

De datatyper du idag operere med er også mere ram tung et bogstav er f.eks. mindst 16bit og ikke 8bit som standard og et heltal er gået fra 32 til 64tbit. Og det er før vi blander mere komplekse datatyper ind i det. Det er som jeg nævner hvor en masse af det nye overhead kommer fra.

JIT reffere mere til hvordan browsere levere ydelse i dag, og browsere er typisk de mest ram tunge applikationer på en alm desktop. ikke DE'erne.

Du finder browser componenter frygteligt mange steder uden for de traditionelle browsere.

#8: Det betyder at hvis to programmer bruger GTK så vil GTK biblioteket ikke blive indlæst dobbelt men de to processer deles om det.

Med mindre du har virutelle namespace/filsystem(cgroups,chroot etc) for programmet så ender du ofte med at miste memmory fordelen af shared libaries. men du vinder en masse i form af sikkerhed.

Chrome er det mest kendte eksempel på et linux program der bruger virtuelle namespaces(chroot) men både fedora, redhat og ubuntu investere tung i henholdvis SELINUX og apparmor der er næste genneration af isolerings teknikker.

Når det kommer til at issolere processer så kan det gøres på 2 måder ved at kernen agere mellemmand for kald til shared bibilioteker(koster cpu) ved at kernen giver dem en selvstending kopi af systembiblioteket(koster ram) hvilket er hvor moore's lov spiller ind i forhold til hvordan man håntere shared libaries i praksis.

Kan ikke direkte citere artikler på stående fod, meget af det kommer fra foredrag og erfaring med fejlsøgning på flakehalse.

#9
Du påstår altså at på en alm. desktop i 2015 vil have en kopi af GTK biblioteket for hver eneste program du har kørende? Ved du overhovedet hvordan SELINUX og AppArmor fungerer eller er det også du bare har "hørt"?

#9: Når det kommer til at issolere processer så kan det gøres på 2 måder ved at kernen agere mellemmand for kald til shared bibilioteker(koster cpu) ved at kernen giver dem en selvstending kopi af systembiblioteket(koster ram) hvilket er hvor moore's lov spiller ind i forhold til hvordan man håntere shared libaries i praksis.

Dette er direkte forkert og viser du har misforstået konceptet omkring virtuelt adresserum som hver process har. Må jeg anbefale dig at læse op på Memory Mapped IO og så komme igen? To processer der bruger samme bibliotek på Linux indlæser ikke biblioteket to gange uanset hvad du måtte bruge af isolering eftersom det aldrig giver mening at lave en kopi af read-only data (hvilket et bibliotek er). Der er jo en grund til at Linux vælger at bruge alt ledig RAM som IO buffer og det er ikke for at lave komplette kopierer for hver eneste process. Det kan godt være hver process i sit virtuelle adresserum kan se en fil men det betyder ikke at filen rent faktisk ligger flere gange i RAM'en.

Og så er jeg sådan set ligeglad med hvad du måtte kalde "agere mellemmand" men du må gerne komme med en artikel der beskriver at man i dag anser memory mapped IO som performance tungt i forhold til at smide en kopi af alle biblioteker ind i hver kørende process.

"JIT reffere mere til hvordan browsere levere ydelse i dag, og browsere er typisk de mest ram tunge applikationer på en alm desktop. ikke DE'erne."

Jeg ved hvad en JIT er og hvordan den fungerer men jeg har stadig ingen ide om hvad du forsøger at komme frem til med den beskrivelse og hvordan det på nogen måde har en relevans omkring RAM forbrug.

"De datatyper du idag operere med er også mere ram tung et bogstav er f.eks. mindst 16bit og ikke 8bit som standard og et heltal er gået fra 32 til 64tbit. Og det er før vi blander mere komplekse datatyper ind i det. Det er som jeg nævner hvor en masse af det nye overhead kommer fra. "

Lad os nu bare sige du har ret (hvilket ikke er tilfældet) hvorfor skulle dette så have vildt meget at sige i den test #0 linker til når man må gå ud fra man har testet alle VM'er og DE'er på samme setup og derfor kører de alle med 32-bit eller 64-bit?

#10: Memory Mapped IO
Hvad har memmory mapped io af gøre med C++ objekter og heap? jeg tror vi snakker forbi hinanden her. vi taler absplut ikke om ficache eftersom jeg har antaget den allerede er ekskluderet. vi taler heap og objecter ikke filer her.

#10: To processer der bruger samme bibliotek på Linux indlæser ikke biblioteket to gange uanset
Nej men det er heller ikke min påstand, faktisk er der ingen programmer der nogen sinde indlæser et helt biblitotek i sin egen hukommelse(ingen gode programmer i det mindste det er sikkert mugligt) hvad du istedet taler om er afledte objekter og datastrukturer og de skal isoleres fra hinanden hvis du vil have en håndhævet sikkerhedsmodel.

Husk også at datatyper og cpu bitness intet direkte har med hinanden at gøre længere. i.e. jeg snakker absolut ikke om skiftet fra 32bit til 64bit CPUer direkte men skiftet fra ascii til unicode som default datatype for strenge, begge er tilstede på både 16bit, 32bit og 64bit, men tidligere har man holdt sig til simple men ukomplette typer med mindre programøren eksplitcit har bedt om noget andet.

Kernen memmory manager er heller ikke direkte bevist om bibliotekter efter som de faktisk ikke eksistere i de forskellige processers "hukommelse" i deres rå form for objektorienterede frameworks. Vi snakker simpelthen ikke om samme ting her.

Der er også meget mere ikke C-C++ i KDE og Gnome eftersom begge gør kraftigt brug af højnivou sprog som python eller vala for deres system applikationer mens LXDE og XFCE ofte holder sig til compilerede programmer som default. hvilket også har en betydning.

Jeg indrømmer at jeg er på dybt vand her men jeg har fingrende så dybt nede i stacktraces og kernel dump at jeg ved det er vådt og har en half fornemelse af hvad der forgået inden bag de fine abstractioner, men ikke dybt nok til at vide precist hvad der foregår. Det kræver nok et par årtiers studie at nå til. Og jeg er absolut ikke ekspert her men der langt mere i det end du giver udtryk for.

apparmor og selinux er ikke magi, og det er chroot heller ikke, hvor firefox der har sin egen sandbox kan dele objekter imellem tabs så kan chrome der afhænger af rå process isolering ikke rigtigt gøre det uden om et fil handle eller socket, hvilket koster lidt i hukommelse(at firefox så har en tendense til ikke at kunne garbage collecte orderntligt er en anden sag.)

Det siger sig selv, uanset DE, at jo mere der indlæses i RAM fra progs med v., jo mere RAM skal der installeres. Også at DE og OS kan have problemer med at frigive RAM når den ikke længere bruges.

Men helt overordnet er det lige så logisk at jo mere letvægt et DE er, jo mindre RAM er krævet for at håndtere de grundlæggende funktioner. Derfor er f.eks. Xfce hurtigere end diverse andre DE. KDE klarer meget ved at cache, og det samme gør andre DE.

Jeg har lige købt en spritny Macbook. Den har 8 GB RAM (med SSD), og den bruger ressourcerne ligeså hurtigt som en anden med kun 4 GB RAM (64 bit). Derfor har jeg installeret et prog. der frigiver RAM efter kommando. Det er nødvendigt for at køre f.eks. virtuelle OS. Ellers kommer der fejlmeddelser.

Helt overordnet kan det da ikke være et problem at erkende, at tiden kræver mere RAM. Jo mere jo bedre, men er maskinen ikke udstyret, eller det er for dyrt at installere ældre RAM klodser, så er et letvægt DE naturligvis nødvendigt. Resten bør håndteres af den virtuelle hukommelse.

Hvad er problemet?

#12
Hvad er det helt præcist du hentyder til med sætningen "Også at DE og OS kan have problemer med at frigive RAM når den ikke længere bruges."? Hvor er det lige du synes Linux skulle have problemer med at frigive RAM og hvordan har du foretaget disse målinger?

Og det samme gælder ved "KDE klarer meget ved at cache, og det samme gør andre DE". Hvad er det helt præcist du mener her? Fordi umiddelbart giver det ikke meget mening uden at definere hvad denne "cache" indeholder. Hvis det er en cache over tidligere indlæste filer så er det en Linux feature og ikke KDE men jeg gætter på du mener noget andet.

Du skriver ikke hvad din Mac har installeret for et OS men jeg må forvente det er en eller anden form for Linux siden du nævner den som eksempel. Jeg vil meget gerne have et link til det omtalte program da den slags programmer umiddelbart ikke skulle være nødvendigt men eftersom du siger du får en fejl ved brug af virtuelle maskiner uden dette program virker det da interessant.

#12: Helt overordnet kan det da ikke være et problem at erkende, at tiden kræver mere RAM. Jo mere jo bedre, men er maskinen ikke udstyret, eller det er for dyrt at installere ældre RAM klodser, så er et letvægt DE naturligvis nødvendigt. Resten bør håndteres af den virtuelle hukommelse.

Du misforstår diskussionen da det overhovedet ikke handler om at nogen ikke vil erkende at der er brug for mere RAM og hvor meget RAM de enkelte VM'er og DE'er bruger. Min pointe i diskussionen er bare at du aldrig kan nøjes med at starte en DE eller WM og så måle RAM forbruget og skrive en artikel ud fra dette da det er lige så vigtigt at starte en række programmer op samtidig da det samlede RAM forbrug her vil være noget anderledes. Og her pointere jeg så at hvis du tager Fluxbox og starter Pidgin (der bruger GTK) så vil du se en større stigning i systemets samlede RAM forbrug end hvis du brugte GNOME fordi GTK her allerede er indlæst og Pidgin derfor kan gøre brug af dette bibliotek. Og når dette er tilfældet er det så overhovedet brugbart at skrive Fluxbox kun bruger 16 MB ram og GNOME bruger 155 MB?

Diskussionen var derfor mere værdien i den slags artikler og målinger. Jeg tror ikke der er nogen der har stillet spørgsmålstegn ved at GNOME bruger mere RAM end fx Fluxbox. :)

#13

Ikke andet end det kan ske. Især efter en nyligt udkommet distro. Der vil altid ske fejl som først skal rettes før de implementeres. Det er jo netop formålet med at diskutere eventuelle problemer.

Beklager hvis jeg har misforstået diskussionen. Måske er jeg påvirket af andre diskussioner. Det er ikke hensigten. Jeg ved at alle her, i forvejen er klar over at DE betyder noget for RAM forbruget, såvel som et nylig udgivet OS kan påvirke samme. Blandt andet derfor mener jeg det vigtigt, ikke at anbefale opgradering lige efter udgivelsen på produktions systemer.

#13: Du skriver ikke hvad din Mac har installeret for et OS men jeg må forvente det er en eller anden form for Linux siden du nævner den som eksempel.

Det bliver svært fordi Yosemite først lige er udkommet stable. Ligeledes er programmet Memory Optimizer nyligt opdateret, og det har ikke mere med Linux at gøre end Darwin har, men problemet er så sandelig velkendt også på Windows. Fejl i DE, uanset platform, kan resultere i RAM problemer. Af samme grund med flere, skal man ikke bare implementere ...

KDE cacher for at håndtere DE hurtigere. Sletter du alle cache i KDE, skal de indlæses igen ved genstart. Det kan mærkes på opstartstiden. Når alt ved DE er indlæst, så fungere KDE superhurtigt hvis der er RAM nok. Det er vel igen hemmelighed, at KDE er temmelig ressourcekrævende i forhold til f.eks Xfce.

Jeg havde for nylig en diskussion på Google+, hvor jeg spurgte til, hvem der faktisk bruger alle funktionerne i DEerne. Jeg har for eksempel svært ved at omsætte KDEs Activities og de ganske vist lovende ting, der ligger i KDEConnect.
Jeg kan se, at det er et tradeoff, man kan have glæde af, hvis man bruger funktionerne, men min egen tilgang er på kanten til det banale. Jeg husker som nævnt ovenfor i tråden, at jeg dengang jeg stadig brændte CDer ville starte K3B op, og det ville tage en menneskealder, fordi den skulle indlæse en masse, som man på en KDE-desktop ville have kørende i baggrunden uanset.
Derfor har jeg Openbox på mine to Slackwareinstallationer - nærmest en spejling af hinanden på en T60 og en X60 - Xfce under Fedora og Cinnamon under Mint til min kone. Når jeg siger "derfor" mener jeg ikke for at spare RAM - jeg siger det, fordi det passer mig ret fint, at min desktop dybest set bare er en brugerflade til at starte programmer med et lille panel, der kan fortælle mig, hvad der kører.