Využití RAM v 32bitovém a 64bitovém GNU/Linuxu

14.1.2012 17:46 | Přečteno: 5112× | Linux | | poslední úprava: 14.1.2012 19:03

Vzhledem k diskuzi pod mým posledním blogískem, jsem se rozhodl zopakovat jednoduchý experiment s využitím RAM a jeho výsledky hodit do samostatného zápisku, ať je můžu příště rovnou linkovat.

Metodika

V případě grafických živých CD probíhal test následovně: Nabootoval jsem CD s výchozími volbami, přes spouštěč (ALT+F2) pustil výchozí emulátor konzole (gnome-terminal v případě Ubuntu, konsole v případě Kubuntu a Chakry) a spustil příkazy:

uname -a >> /tmp/distro-bity.txt
free >>  /tmp/distro-bity.txt
    

Poté jsem přes spouštěč pustil výchozí prohlížeč, počkal až došrotuje mechanika a opět zapsal do souboru výsledky free.

Distribuce

Jednak jsem vyhrabal nějaká stará LiveCD, co mi kdysi doručil Canonical, konkrétně šlo o Ubuntu 7.04 a Kubuntu 7.10, poté jsem stáhl aktuální vydání LiveCD Chakry, konkrétně 2011.12 (při jehož vypalování jsem vyhodil dvě zestárlá CD-RW) a oprášil CLI LiveUSB Arch Linuxu 201005. U všech jsem nabootoval do i686 a pak do x86_64 varianty.

Hardware

Test jsem udělal na novém Kanashimi (A64 3000+, 1 GB DDR I, Nvidia 7600 GS), viz přístí zápisek. Na Haku (C2D 2,4 GHz, 3 GB DDR II, Ati HD 3600) stará liveCD nenabootovala a Charku zarazil TPM, nebo co to má za vyfikundaci. Na Hikari (i3 2125, 8 GB DDR III, Intel HD 3000) pak nabootoval jak Arch tak Chakra.

Výsledky

Následující tabulky uvádějí hodnoty udané free, konkrétně položku -/+ buffers/cache (v kilobajtech, Chakra uvádí v megabajtech, takže jsem to do tabulky přepočetl) a jejich podíl 64bit/32bit. Případ prohlížeč- udává stav před spuštěním prohlížeče, případ prohlížeč+ po spuštění prohlížeče. Nejprve Kanashimi:

Distribuce	prohlížeč-			prohlížeč+
	32bit	64bit	poměr	32bit	64bit	poměr
Ubuntu 7.04	124 728	189 588	1,5200115	141 924	215 540	1,5187001
Kubuntu 7.10	107 852	198 756	1,8428587	119 616	211 248	1,7660514
Chakra 2011.12	184 320	296 960	1,6111111	216 064	346 112	1,6018957
Arch Linux 201005	19 272	44 724	2,3206725	–	–	–

Nyní Haku:

Distribuce	prohlížeč-			prohlížeč+
	32bit	64bit	poměr	32bit	64bit	poměr
Arch Linux 201005	30 192	94 092	3,1164547	–	–	–

A konečně Hikari:

Distribuce	prohlížeč-			prohlížeč+
	32bit	64bit	poměr	32bit	64bit	poměr
Chakra 2011.12	204 800	381 952	1,865	236 544	432 128	1,8268398
Arch Linux 201005	26 000	170 536	6,5590769	–	–	–

Následují spojené textové soubory zachycené na LiveCD na Kanashimi:

Linux ubuntu 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       1035784     560032     475752          0      82068     353236
-/+ buffers/cache:     124728     911056
Swap:            0          0          0
             total       used       free     shared    buffers     cached
Mem:       1035784     621292     414492          0      90728     388640
-/+ buffers/cache:     141924     893860
Swap:            0          0          0
Linux ubuntu 2.6.20-15-generic #2 SMP Sun Apr 15 06:17:24 UTC 2007 x86_64 GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       1028120     646504     381616          0      81916     375000
-/+ buffers/cache:     189588     838532
Swap:            0          0          0
             total       used       free     shared    buffers     cached
Mem:       1028120     723472     304648          0      91564     416368
-/+ buffers/cache:     215540     812580
Swap:            0          0          0
Linux ubuntu 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       1035636     488376     547260          0      69152     311372
-/+ buffers/cache:     107852     927784
Swap:            0          0          0
             total       used       free     shared    buffers     cached
Mem:       1035636     509352     526284          0      71236     318500
-/+ buffers/cache:     119616     916020
Swap:            0          0          0
Linux ubuntu 2.6.22-14-generic #1 SMP Sun Oct 14 21:45:15 GMT 2007 x86_64 GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       1029488     595600     433888          0      69028     327816
-/+ buffers/cache:     198756     830732
Swap:            0          0          0
             total       used       free     shared    buffers     cached
Mem:       1029488     612324     417164          0      70244     330832
-/+ buffers/cache:     211248     818240
Swap:            0          0          0
Linux chakra 3.1-CHAKRA #1 SMP PREEMPT Wed Dec 7 11:05:16 UTC 2011 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
             total       used       free     shared    buffers     cached
Mem:          1004        699        305          0         85        433
-/+ buffers/cache:        180        824
Swap:            0          0          0
             total       used       free     shared    buffers     cached
Mem:          1004        762        242          0         91        459
-/+ buffers/cache:        211        792
Swap:            0          0          0
Linux chakra 3.1-CHAKRA #1 SMP PREEMPT Tue Dec 6 22:49:14 UTC 2011 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
             total       used       free     shared    buffers     cached
Mem:           999        824        175          0         86        447
-/+ buffers/cache:        290        708
Swap:            0          0          0
             total       used       free     shared    buffers     cached
Mem:           999        902         96          0         91        472
-/+ buffers/cache:        338        660
Swap:            0          0          0
Linux archiso 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 12:06:25 CEST 2010 i686 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       1028796      63780     965016          0       9112      35396
-/+ buffers/cache:      19272    1009524
Swap:            0          0          0
Linux archiso 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 11:32:37 CEST 2010 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       1025280      92888     932392          0       9784      38380
-/+ buffers/cache:      44724     980556
Swap:            0          0          0
    

Následují spojené textové soubory zachycené na LiveCD na Haku:

Linux archiso 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 12:06:25 CEST 2010 i686 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       3093688      83652    3010036          0      10948      42512
-/+ buffers/cache:      30192    3063496
Swap:            0          0          0
Linux archiso 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 11:32:37 CEST 2010 x86_64 Intel(R) Core(TM)2 Duo CPU P8600 @ 2.40GHz GenuineIntel GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       3083352     152400    2930952          0      11584      46724
-/+ buffers/cache:      94092    2989260
Swap:            0          0          0
    

Následují spojené textové soubory zachycené na LiveCD na Hikari:

Linux chakra 3.1-CHAKRA #1 SMP PREEMPT Wed Dec 7 11:05:16 UTC 2011 i686 Intel(R) Core(TM) i3-2125 CPU @ 3.30GHz GenuineIntel GNU/Linux
             total       used       free     shared    buffers     cached
Mem:          3447        786       2661          0         87        498
-/+ buffers/cache:        200       3247
Swap:            0          0          0
             total       used       free     shared    buffers     cached
Mem:          3447        852       2595          0         93        527
-/+ buffers/cache:        231       3216
Swap:            0          0          0
Linux chakra 3.1-CHAKRA #1 SMP PREEMPT Tue Dec 6 22:49:14 UTC 2011 x86_64 Intel(R) Core(TM) i3-2125 CPU @ 3.30GHz GenuineIntel GNU/Linux
             total       used       free     shared    buffers     cached
Mem:          7900        972       6928          0         87        511
-/+ buffers/cache:        373       7527
Swap:            0          0          0
             total       used       free     shared    buffers     cached
Mem:          7900       1062       6838          0         93        546
-/+ buffers/cache:        422       7477
Swap:            0          0          0
Linux archiso 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 12:06:25 CEST 2010 i686 Intel(R) Core(TM) i3-2125 CPU @ 3.30GHz GenuineIntel GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       3528008      73104    3454904          0       9468      37636
-/+ buffers/cache:      26000    3502008
Swap:            0          0          0
Linux archiso 2.6.33-ARCH #1 SMP PREEMPT Thu May 13 11:32:37 CEST 2010 x86_64 Intel(R) Core(TM) i3-2125 CPU @ 3.30GHz GenuineIntel GNU/Linux
             total       used       free     shared    buffers     cached
Mem:       8093896     221396    7872500          0      10136      40724
-/+ buffers/cache:     170536    7923360
Swap:            0          0          0
    

Závěr

Co si mám myslet o číslech samotného CLI Archu (de facto jen Linux a Bash), opravdu nevím. Na druhou stranu by to vysvětlovalo značný nárůst využití RAM pozorovaný mezi 32bitovým netbookem Kanashimi a 64bitovým Hikari, kde provozuji systém s téměř stejnou konfigurací i běžícími službami. Zajímavé je také porovnání GNOME–KDE, kde to vypadá, že u KDE je záměna 32bit za 64bit systém cítit více. Rozdíl mezi 32bit a 64bit systémem se zdá také záviset na konkrétním hardwaru a to poměrně značně (viz rozdíly u Chakry mezi Kanashimi a Hikari. Celkově to na mém hardwaru vypadá tak, že rozdíly ve využití RAM mezi 32bit a 64bit systémem jsou v řádu 50–80 %.

       

Obrázky

Komentáře

[User682]

zdravim,

dekuju. To jsem shanel delsi dobu. Dobra prace.

gf

[kralyk z abclinuxu]

+1

[kotyz]

Pěkný, ale ocenil bych to v lidsky čitelnejch jednotkách (celý megabajty) a úplně nejlepší by bylo to závěrečný porovnání zapracovat do sloupcovýho grafu, jak je bežný třeba v benchmarcích na diitu a pctuningu ...

Tyhle hromady čísel sou pro mě (asi nebudu sám) težko stravitelný.

[kralyk z abclinuxu]

Hele ty si nestěžuj, když jsem navrhoval, abys tenhle benchmark provedl, nechtělo se ti vůbec

[=^..^= AmigaPower®]

To je klasika! On by chtěl leda kdyby čekala na konci výpočtu klobása

[kotyz]

Nebo lahváč, ten by taky šel ...

[Bedňa]

Tak to sprav viacero výpočtov

[kotyz]

Jo, v dohledný době. A asi to dam sem jako komentář, nechce se mi vymejšlet nějaká ta omáčka okolo aby to stačilo na blog ...

[kotyz]

Už sem se na to chystal (bylo by to jen pár screenshotů ze system monitoru případně z konzole), na grafy bych se vysral taky, ale když už to teď udělal kolega tak se nebudu namáhat (stejně by to šlo až večer až budou děcka spát, protože teď na tom hrajou nějaký flashový hry, nebo nejlíp v pondělí až budou zase pryč). Což mi ale nebrání v kritizování

[=^..^= AmigaPower®]

děti... vyhnat do závějí a nahradit kočkama!

[kotyz]

Nechci na ně šahat, sou infekční (jedno má údajně neštovice). Počkam až zejtra odtáhnou domů, bude to jednodušší.

[Nicky726]

Zapomněl jsem tam naházet zúžené mezery…

Ad graf… Jak vůbec v Linuxu na grafy mimo LibreOffice? Dělání grafů není zrovna moje branže.

[=^..^= AmigaPower®]

Vine a excel pyčo!

[kotyz]

Jestli ne LO (to by bylo asi lehčí), tak třeba gnuplot. A možná bude přímo nějaký pěkný udělátko na grafy ...

[=^..^= AmigaPower®]

máte to přímo pod nosem volove...

[kotyz]

Jó, to je přesně ten správnej program, kterej sem nikdy nepoužil a hodlam v tom pokračovat!

[Nicky726]

Díkes za připomenutí, dokonce to mám nainstalovaný jako závislost KDE klikátka…

[Nicky726]

Které nechce fungovat a tváří se, že jde o grafy z teorie grafů a ne sloupčeky, které kolega chce.

[=^..^= AmigaPower®]

Tak jinej, ne?!

[kralyk z abclinuxu]

Jj, graphviz je afaik zaměřen na grafy z teorie grafů.

[Tomáš Heger (geckon)]

gnuplot by měl být na ty správné grafy.

[kotyz]

Jo to byl muj druhej návrh po LO.

[Nicky726]

Tak jsem graf nakonec vyplodil v LibreOffice.

[Bedňa]

Dík že si spravil to na čo som sa ja nakoniec vykašlal, pretože som sa rozhodol s 64bitom naďalej bojovať a už sa nevrátiť späť na 32bit. Je pravda, že budem musieť investovať do RAM, tak aspoň spravím test či stúpne spotreba elektrickej energie s ďalšími GB. Moja osobná skúsenosť je nárast spotreby RAM od 50% do 100%, čo sa od tvojho moc nelíši.

[=^..^= AmigaPower®]

Mam teď 2.5GB Ještě sehnat něco do ntb a sem spokojenej...

[Bedňa]

Ja mám len 2GB pre 32bit to úplne stačí, pri tom som mal vždy pustených viac ako 5aplikácií čo slušne žerú pamäť.

[kotyz]

Blbý je že do tý mý low-end desky s tim 64bit Sempronem nejde dát víc jak 2 GB paměti a ještě z toho bude užírat integrovaná grafika (teď je tam jen 1 GB, tolik mi zůstalo po upgradu mýho hlavního kompu a víc tam dát nejde, sou tam jen dva sloty a větší moduly nemam a kupovat je by bylo vyhazování peněz a beztak na tom kompu nikdo ani nic nedělá, je tam jako taková záloha kdyby bylo třeba). Tam nemá cenu 64bit OS vůbec instalovat, nicméně sem to zkoušel, když už se mi takový železo dostalo do pracek. Škoda, kdyby to bylo aspoň se socketem 939 tak sem z toho udělal svuj hlavní kepl, tam by ještě bylo co upgradovat ...

Konečně bych měl na čem počítat BOINC přes CUDA na grafice a skóre by mi rostlo 10x rychlejš! A ten účet za elektriku potom No ještě si budu muset na takovej luxus chvíli počkat ...

[Bedňa]

Integrovaná grafika je shit, pokiaľ to nemá svoju ram a nevieto VDPAU je to k ničomu.

[kotyz]

Njn, jenže já nemam žádnou do PCI-e a ani se mi nechce žádnou kupovat. Do obyváku to stačí.

[=^..^= AmigaPower®]

Mně to chrchlá max do 800MB (že by to začínalo osmičkou sem ještě neviděl), spíš s tim notebookem se furt seru, ten má 256...

[kotyz]

Nekecej, tak to máš víc než já! (pokud je to v jednom počítači)

[XXX]

Bylo by zajimavy v tomto srovnat s Windowsy. Ale to se asi nikomu chtit nebude ...

[kotyz]

Podruhý už ne.

[Nicky726]

AFAIK nemají LiveCD… Nemluvě o tom, že mám tak možná nějaká OEM XP, i když mám pocit, že jsem je vyhodil.

[=^..^= AmigaPower®]

Já mam nálepku

[kotyz]

Já taky, win 98 second edition

[kotyz]

Konečně graf, ten to potřebovalo.

[=^..^= AmigaPower®]

Já chci koláč jako měl Železný na Nově!

[kotyz]

Makovej nebo tvarohovej?

[=^..^= AmigaPower®]

barevnej

[kotyz]

To jako multikulturní?

[=^..^= AmigaPower®]

jj, něcojako z pandy, černá, bílá a z asie...

[Bedňa]

Tvarohový, alebo mákový, ale hlavne nalej mi.

[kotrcka]

Vieš urobiť len seba a maslový chleba...

[=^..^= AmigaPower®]

Od obojího má manželku

[kotyz]

A Jílek služku

[Bedňa]

[foldy]

Není problém v tom, že jsou v těch distribucích libcompat librarys z 32bit systému? Mám skušenosti s tím, že pokud mám Slackware 32 a 64only tak je rozdíl skoro minimální, ale pokud do Slackwaru nahraju libcompat library a použiju v nějakém softu (virtualbox to třeba potřebuje) tak je nárůst ram velký. Pokud vezmu Debian na x86 32bit a IA64 tak je to taky stejné nebo dosti podobné. (IA64 32bit neumí) I když to je jiná archytektura.

[Nicky726]

Co by to ale potřebovalo na LiveCD, kde pouštím pouze DE a poté prohlížeč? Žádný nárůst v poměru tam vidět není, takže by musely být načtené už v okamžiku startu. LiveUSB CLI Archu pak žádné libcompat knihovny nemá. Na Hikari mám nějaké 32bit věci, které ale běžně nepouštím (Skype, Virtualbox), přece se to nenačítá už jen kvůli tomu, že je to nainstalované?

[foldy]

No to ne, to máš pravdu, nevím co je na slackwaru tak odlišného...

[Michal Kubeček]

Není problém v tom, že jsou v těch distribucích libcompat librarys z 32bit systému?

To je docela dobře možné. Směrodatnější by bylo porovnání konkrétní aplikace se stejnou konfigurací a stejnými daty, třeba právě toho prohlížeče.

(IA64 32bit neumí)

Spíš konkrétní distribuce, architektura jako taková ano (i když v SW emulaci).

[lertimir]

Hezké srovnání. Více méně to ilustruje to, že pokud stroj nemá opravdu hodně paměti, tak 64 bitová architektura je nevýhodná.

[disorder]

ja som prechadzal z 1.5G na 1G a nic mi na 64b nechybalo.

[lertimir]

No já jsem přecházel na 64bit při 8G. Nicméně i tak jsou problémy. Např jsem ještě nerozběhl 64bitový Goggle Earth. A před 2 lety jsem rozbíhal na 64 bitovém debianu SAS Enterprise Miner a bylo to celkem drsné. Takové množství 32 bitových knihoven jsem tam musel dodat, že jsem si říkal jak to vlastně dodává RedHat, když to byla instalace v podstatě na něj.

[SPM]

naproti tomu u 64b máš nějaké další instrukce, takže cpu může pracovat rychleji... porovnání paměti u je/není výhodné tak úplně nestačí...

[lertimir]

Jsem si toho vědom. Porovnání rychlosti dělá často phoronix. A výsledky bývají už dost dlouho stejné. algoritmy využívající šifrování (openSSL), kódování videa a audia a některé komprese mají výhodu 64bit architektury ostatní se zlepší málo. Nicméně i z těch vyplývá, že s malou pamětí. (4G) ty výhody nejsou tak silné jako s větší (8G)

[Michal Kubeček]

Nejen instrukce, ale hlavně registry. Takhle třeba vypadá funkce sčítající čtyři čísla na x86_64:

   0x0000000000400560 <+0>:     add    %rsi,%rdi
   0x0000000000400563 <+3>:     add    %rdi,%rdx
   0x0000000000400566 <+6>:     lea    (%rdx,%rcx,1),%rax
   0x000000000040056a <+10>:    retq

a takhle na i586:

   0x08048450 <+0>:     mov    0x4(%esp),%edx
   0x08048454 <+4>:     mov    0x8(%esp),%eax
   0x08048458 <+8>:     add    %edx,%eax
   0x0804845a <+10>:    mov    0xc(%esp),%ecx
   0x0804845e <+14>:    add    %ecx,%eax
   0x08048460 <+16>:    mov    0x10(%esp),%edx
   0x08048464 <+20>:    add    %edx,%eax
   0x08048466 <+22>:    ret

[lertimir]

V reegistrech bych očekával hlavní nárust zisku. Mohu přehazovat na jeden takt 2x více dat. Dotaz: Ty uvodní čísla jsou program counter? add na 64 bitech jsou 3 bytové instrukce? A ještě tohle je standardní funkce kterou kompilátor zařadí do kódu z přiřazení a=b+c+d+e?

[Michal Kubeček]

V reegistrech bych očekával hlavní nárust zisku. Mohu přehazovat na jeden takt 2x více dat.

Jde hlavně o to, že jich je víc, takže se spousta věcí dá udělat v registrech a nemusí se tak často sahat do paměti. Třeba v případě celočíselných nebo pointerových parametrů se na x86_64 se prvních šest parametrů předává v registrech, zatímco na i586 jen 0-3.

Ty uvodní čísla jsou program counter? add na 64 bitech jsou 3 bytové instrukce?

Ano, jsou to adresy, na kterých je příslušná instrukce. Délka instrukce bude IMHO záviset na tom, co s čím se sčítá.

A ještě tohle je standardní funkce kterou kompilátor zařadí do kódu z přiřazení a=b+c+d+e?

Je to reálně přeložený prográmek

#include <stdio.h>

long sum4(long a, long b, long c, long d)
{
  return a + b + c + d;
}

int main()
{
  printf("%ld\n", sum4(1,2,3,4));
  return 0;
}

pomocí

  gcc -O3 -fomit-frame-pointer -fno-inline -m64 -march=k8 -o reg-64 reg.c
  gcc -O3 -fomit-frame-pointer -fno-inline -m64 -march=i586 -o reg-32 reg.c

Výpis funkce byl získán pomocí gdb (disassemble sum4). Samotné přiřazení uprostřed funkce by bylo implementováno různě podle toho, kam zrovna optimalizátor uloží příslušné proměnné; obecně ale platí, že na x86_64 je větší šance, že proměnná bude v registru.

[Bedňa]

V praxi som nepostrehol žiadne zlepšenie, skôr mám pocit o opaku súvisiacim so zaplňovaním pamäte.

[pedro]

Tak to koukám, docela brutální nárůst. No, ještě že jedu na Gentoo x86, tak mi to může být ukradený.