Max RAM

kan du ikke bare køre en "htop" eller "top" og se hvor mange ram den regierstere? :0)



selv køre jeg med Vista 64bit da jeg sider med 8gb ram, men uden at være klog omkring det vil jeg skyde på det er selve 32bit strukturen der ikke kan håndtere mere og ikek selve systemet, men som sagt skal ik gøre mig klog på det.

Et 32 bit system kan max. adressere til ca. 4 GB ram alt inclusive, dvs. ram på grafikkort tæller med!



Et 64 bit system kan teoretisk adressere til ca. 1 ExaByte (1.000.000.000.000.000.000 Byte) men eksempelvis Vista Ultimate, der er det kraftiste har fået sat en begrænsning på 128 GB, men om der er sat begrænsninger ind i Linux / GNU ved jeg ikke



Med venlig hilsen

copycat / Erik

Med en 32-bit Linux-kerne i "PAE-flavour" kan man godt bruge mere end 4 gigs ram.



Skal ikke kunne sige om Mandriva har installeret en PAE-kerne for dig, men det kan du sikkert se ved at køre: 'uname -r'

Jeg ved, at efter min ven opdaterede til SP1 udnyttede Vista x32 4GB ram på hans pc.

psyko, 128gb ram på Vista64bit ;0) jamen så kan jeg roligt opgrasder fra 8 til 16gb så kan jeg høre :P det lyder jo dirakte vandvittet.

#4: Så har manden ikke meget ram på grafikkort o.lign. -- den slags tæller nemlig også med i de 4GB..



Og så er der ikke noget der hedder x32 eller x64.

#6 Jo, 512 tror jeg. Kan godt se regnestykket ikke kan gå op. MEN kan være han har lavet noget i bios - fx sat den lidt højere til 4.5? Ellers har han lavet noget med PAE, på den måde kan han måske godt kunne se, at han har 4gb. De sidste ram er så ikke allokeret. Han sagde dog det skyldes sp1.. Jeg ved det ikke :)



pfft

Spørgsmålet er ikke om systemet 'ser' RAM'ene, men om de rent faktisk kan bruges.. Og begrænsningen ved både XP og Vista 32-bit er 3Gb!

Mandriva 2009 ser også mine 6 Gb RAM, men jeg kan jo ikke vide om jeg udnytter dem. Det er ikke 64-bit jeg kører med..

Men den er dejlig, 2009'eren!

Selv min gamle bærbare (Armada M700) kører fint med den.. :-)

#8

Begrænsningen på 3Gb kommer af at der skal være ledige adresser til resten af hardwaren i systemet (så som cpu, lydkort, grafikkort osv).

En 32 bit arkitektur kan adressere 2^32 adresser, hvilket svarer til 4Gb.



De fleste nyere cpuer har så understøttelse for at bruge 36-bit adresser, og det kan anvendes på de fleste 32-bit systemer som cb400f bl.a. er inde på.



Aktiverer man udvidelsen i 32-bit vista og xp miljøer så kan man bruge op til 4Gb. Hvilket er en "kunstig" begrænsning da man jo ikke udnytter de 36-bit adresser

Så blev jeg lidt klogere :-) -Tak for det.

Jeg er nu ved at hente 64-bit versionen af Mandriva 2009.

Spændende om der er en mærkbar forskel...

Nu skal vi jo lige huske, at det ikke er helt så simpelt som I får det til at lyde..



Ram bliver delt op i sider/dele. Normalt deles ram op i sider af 8 bits eller 1 byte.



Dette kan I ganske nemt regne ud vha.

Max ram størrelse i bits, divideret med adresserum. Det vil give et regnestykke som hedder:

4*1024^3*8/2^32 = 8

Dvs. hvis man har et 32 bit adresserum der højest kan addressere 4 GB, så fylder hver allokeret side 8 bit, eller 1 byte.



Men tænk nu, hvis man ændrer antallet af bits pr. adresse til 2 eller 4 og stadigt kører på en 32 bit arkitektur.. Så har man pludselig et adresserum på:

2 kb sider: 16*2^32/8/1024^3 = 8 GB hukommelse i et 32 bit adresserum

4 kb sider: 32*2^32/8/1024^3 = 16 GB hukommelse i et 32 bit adresserum



Ved ikke om dette faktisk er muligt med nutidens memory controllere osv - er det sikkert ikke -, men kom blot lige til at tænke på det..



Forresten, så er det muligt i Windows, ligesom Linux har PAE, som anvender et 36 bit adresserum [1], at benytte mere end 4 GB ram.. De kalder det blot Adress Windowing Extension [2].



[1] http://en.wikipedia.org/wiki/Physical_Address_Extension

[2] http://en.wikipedia.org/wiki/Address_Windowing_Extensions

Et hurtigt spørgsmål til alle 64bit brugere der skifter platform på grund af ram.



Hvor ofte benytter i mere end 4GB ram?

Hvem i alverden (Af private), har et behov for 6+ GB Ram?

Hehe rigtigt godt spørgsmål, dk_zero-cool :D



Har selv kun 1 GB i min bærbar, samt 1 GB swap så jeg kan hibernate, og har kun yderst sjældent været ude for at der skulle bruges blot en KB swap :D



Normalt i Debian med lxde bruger jeg omkring 100 MB uden programmer åbne..



Det kunne måske være, man fik brug for det, hvis man skulle virtualisere 4 Vista installationer samtidigt :P

Ja jeg kunne også godt tænke mig at vide hvilken software det er at #0 bruger, som kan bruge 4, 8 eller endda 16 gb ram, og som både kører på windows og linux.

Så lige et andet spørgsmål. Jeg er rimelig meget inde i hardware og funktionen af det, lige på nær denne del.



Hvis man har en maskine med, lad os sige 8GB ram. Man køre derfor et 64bit system, og på en eller anden måde, laver man de mest sindsyge ting på denne maskine, så man næsten udnytter de 8GB fuldt ud (Måske installere man OSer på sine ram, ved det ikke) ... Nu er det så bare lige, at mange programmer ikke findes i 64bit udgaver, så man egentlig køre 50% 32bit apps.



Ligenu bruger maskinen 4,5gb af sine ram. Vil ens 32bit firefox så overhovedet kunne starte op?

Normalt kan du, i Linux, ikke køre et 32 bit program i et 64 bit miljø. Dette simpelthen fordi, programmet er kompilet til 32 bit instruktioner, og dette forstår din 64 bit processor ikke.. Lidt ligesom du forventer et 8 cifret telefonnummer og kun får 4 cifre af en ven. Så vil du også kigge lidt underligt på det og melde en fejl :P



F.eks. derfor flash ikke virker i Linux 64 bit.. Det er ikke compilet til dette, og siden det er closed source, så er det Adobe der bestemmer hvornår dette skal ske (kan godt ske det er kommet).



Men du kan godt lave lidt tricks og køre 32 bit programmer - dette enten via en virtuel 32 bit maskine, via et 32 bit chroot eller ved at bruge ia-32 suite[1]



I Windows er der derimod indbygget en form for 32 bit emulering, så 32 bit programmer fint kan afvikles, også uden større overhead, hvis ikke der opstår fejl.. 32 bit i et 64 bit miljø er (endnu) ikke helt perfekt.

Kort sagt, så kan 32 bit Windows køre 16 og 32 bit applikationer, og 64 bit Windows kan køre 32 og 64 bit applikationer.



[1] http://www.debian-administration.org/articles/534

#12 Code_Aster, Code_Saturne som er computer aided simulation software, er da et godt eksempel. Aner ikke hvor mange gange mit system er gået ned, fordi jeg havde gang i et for stort eksperiment.

3D rendering som jeg også hygger mig med, kan nemt sluge al den ram du kaster efter den.

Gimp, hvis man begynder at gå højt op i opløsning.

Openoffice+firefox+evolution+gimp+div nautilus+alle de småprogrammer man har kørende, kan nemt sluge en del ram, som man så ikke har, når man lige kommer i tanke om at man skal bruge sin VIRTUALBOX.



Mere RAM = ^_^

#17 Ok, jeg har åbnet firefox, tilda, nautilus, OOo write og calc, thunderbird, photoshop, deluge, emesene, fuld loadet compiz med det hele, samt gnome og dens services, ftp server, www server, ssh server mm...



Forbrug af ram = 530mb (Gnome alene tager over 350mb)



Der er sku lang vej til de 6gb ...

#18 tja, jeg er vel så ikke en almindelig bruger - men hvordan var det nu man mistolkede BG og de 640kb i sin tid >_o

#19 Jeg siger ikke at mange ram ikke er godt. Men en computer med 1gb ram, og 256mb gfx kommer man langt med. Så 3gb ram og 512mb gfx skulle da være mere end rigeligt. Hvorfor overdrive? Og du skal ikke komme og påstå at en bruger der surfer på nettet og ind imellem starter WOW op, har brug for mere end det...



Ja, hvis man skal køre en større server, så er det da helt klart et 64bit miljø man skal bruge. Men man skal da være usædvanligt unormal, hvis man ikke kan klare sig med de resurcer et 32bit miljø kan byde på (No offence)

#20 usædvanlig unormal ville jeg nok ikke gå så langt at kalde det, men jo, hvis jeg skulle købe en computer til min kære gamle mor, ville der heller ikke komme mere end 2gb i etc.



Grunden til jeg reagerede var, at hver gang der er tale om nye cpu'er med flere kerner, større harddiske, vildere gfx eller større RAM-mængder, er der altid en der siger: "Hvem har dog brug for al det" - sådan har det været alle de år jeg har interesseret mig for hardware :) - hmm man kunne overveje om jeg ikke snart skulle lære at ignorere det heh.

#11

Nu ved jeg ikke helt hvad du mener med en side, men det kan vidst ikke helt være en "page".



Vores almindelige processorer adressere man efter en byte, og med en 32-bit maskine har man plads til 2^32 (4.294.967.296)adresser. Hvilket giver plads til at adressere 4GB hukkommelse såfremt hele adresse rummet anvendes til hukkommelsen.



Hvis man tog en processor som adresserede på words (et multiplum af bytes), så kunne man ændre den adresserbar mængde hukkommelse med samme multiplum. Altså hvis processoren adresserede efter words med en længte på 2 byte, så ville det være muligt at adressere op til 8GB. Hvis word længden var 4 kunne man komme op på 16GB.



Efter Pentium Pro hvor man tilføjede mulighed for 36-bit adresser, vil man kunne adressere op til 64GB hukkommelse (ved at adressere efter byte).

#21 Det er sandt nok. Folk har svært ved at følge tiden, mens andre ser for langt frem. Krav for maskiner ændre sig løbende, og det er altid godt at være et skridt foran. Men faktum er stadig at der går meget lang tid, før der på det private område, er behov for f.eks. 8 kernede CPUer, 12gb ram, 4gb 4 kernede gfx kort osv. (Ja man kan ligeså godt overdrive lidt) ... Så hvorfor ikke lige falde ned på jorden, og lade være med at forsøge at overgå en af de super computere man har læst om. Firefox stiller slet ikke så store krav :)



Dernæst var mit spørgsmål i #12 faktisk hellere ikke ironisk ment. Er egentlig lidt interesseret i hvad folk med disse krav benytter deres maskine til. Jeg bruger min maskine til mange ting, men jeg når aldrig tæt på grænsen, hverken ram mæssigt eller andre resurcer...

#16:

passer ikke..



linux har samme form for 32bit support som winblows(formentlig bedre), kernen er 100% kompatibel med 32bit binaries på en 64bit kerne, og grunden til at flash ikke virker 64bit linux er ikke som du siger - det virker skam(hvis man kan kalde det bræk virke), det du ikke kan, er at bruge 32bit shared libraries i en 64bit executable - dette vil ikke være muligt uden meget stort overhead, ligeledes kan du ikke bruge 64bit shared libraries i en 32bit executable.



#20:

du glemmer at x86_64 har adskillige andre forbedringer over x86.. for eksempel er nogle ting stort set dobbelt hastighed..

#24 Hey redeeman, troede ikke man hørte mere til dig :)



Nu køre jeg selv 32bit på en 64bit processer, da jeg endnu ikke (på nær ram) har fundet nogen fordele ved at skulle rodde med 64bit, og gennemgå en masse besvær mm. med programmer der endnu ikke er lavet til det.



Men hvis du mener at der er flere fordele ved 64, der er værd at skifte for, må du da gerne komme med et par eksempler? Har aldrig hørt at der skulle være noget hastigheds øgelse ved det, og kan hellere ikke se hvordan...

#25:

glemte også lige at svare fra #15: det passer overhovedet ikke det med 50% 32bit programmer. Du må hellere liste nogle af de angiveligt mange programmer det er der ikke er "lavet" til 64bit.. husk på, vores software er skrevet ret standard og multiplatform, det compiler til en række arkitekturer, bare der er en compiler, og nu er vi så heldig at langt det meste af vores software er skrevet i c/c++, og compiler med en standard C/C++ toolchain - GCC, som findes til... tadaa, x86_64.



hvorfor det er hurtigere og bedre? well.. for eksempel er der ikke så meget grimhed som for eksempel highmem shit. Ydermere er der dobbelt antal sse registre tilgængelige osv.



for eksempel kan vi tage nogle benchmarks med gmp



for at udregne 3 millioner digits af pi med gmp-chudnovsky, på en 3.16ghz core2, tager med standard gmp, 8.29sec på 32bit, og 6.34sec på 64bit - bruger vi en totalt core2 asm optimeret version af gmp, opnår vi 6.10sec på 32bit, og 3.09sec på 64bit.



gmpbench(multiply, divide, rsa):

gmp 32bit normal: 23646, 10776, 850

gmp 32bit core2asm: 33707 14229 1320

gmp 64bit normal: 40401 21876 2226

gmp 64bit core2asm: 69251 33601 3273



desuden kører ting som java, kryptering, mysql, video codecs osv ligeledes hurtigere under x86_64 kontra x86..

#26 Ok, jammen så kunne det være man skulle prøve at smide en 64'er Arch på, og se hvordan det ruller :O)

du mangler stadig at nævne nogle eksempler på "50% som 32bit" - eller havde du bare misforstået det? husk, vores software er ikke crappy lukket winblows lort..

#28 Misforstået tror jeg. Har ikke prøvet 64bit længe nok til at vide det selv. Har blot hørt en del folk snakke om 64bit soft. mangel. Men som du selv kommer ind på, så er det to forskellige platforme der er tale om, da de fleste af dem er windows brugere...

#29

Kører selv 64 bit Arch på min bærbar og det eneste software jeg har haft problemer med er java i firefox og flash i firefox. Dog har jeg fået flash til at virke ved brug af nogle pakker fra aur og java måtte jeg fixe ved at installere en 32 bit version af firefox (som fint kan ligge ved siden af firefox64).



For at kunne køre en række skolerelateret software samt diverse spil i binær form (og wine) har jeg måtte installere en lang række 32 bit lib filer. Disse ligger i community og aur.



Har aldrig kørt i686 Arch på maskinen så kan ikke rigtig sammenligne men det kører rigtigt godt nu efter en smule konfiguration. Forvent dog ikke at det bliver helt så nemt som i686. :)



PS. Der er dog en del AUR pakker rundt omkring hvor de har "glemt" at tilføje x86_64 tag hvilket gør at makepkg brokker sig. I langt de fleste tilfælde virker det dog fint hvis man manuelt skriver x86_64 inde PKGBUILD filen. Antallet af pakker i de forskellige repo. er stort set det samme ved i686 og x64_86 hvor der dog er lidt færre ved x86_64 hvor det fx er pakker der bygges ud fra lukket kode.

#30 "Forvent dog ikke at det bliver helt så nemt som i686"



Nice, lidt flere udfordringer :)

Dem er jeg efterhånden ved at løbe tør for i Arch, da skidtet bare køre derud af, uden at skabe blot et lille bitte problem jeg kan lege lidt med...

#31

Hehe jeg skal nok lige sige at de fleste af mine problemer kom af jeg købte mig en ret så ny computer med en del nyt hardware der ikke var understøttet ordentligt før 2.6.27. :)