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

[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ý.