Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Prawdy i mity o 64-bitowym Linuxie

Na wstępie zacznę od tego, że ten wpis to tak na prawdę tłumaczenie (i trochę streszczenie (i trochę moich trzech groszy)) prezentacji "Myths and facts about 64-bit Linux" dostępnej na http://www.amd64.org/publications.html

Mity

- Nie potrzeba 64-bitowego systemu gdy ma się mniej niż 3 GB RAMu
- Jest mniej driverów na 64-bitowy OS
- Cały software musi być 64-bitowy
- 64-bitowy software jest 2 razy szybszy

Prawdy

Architektura x86_64
W porównaniu z architekturą 32-bitową zmiany nastąpiły za równo pod względem jakościowym jak i ilościowym. Innymi słowy jest lepiej i więcej :) Do rzeczy:

Procesor 64-bitowy ma 2 tryby działania: Long i Legacy, gdzie każdy ma swoje pod-tryby, których jest w sumie 5:
- "Long" dla 64-bitowego OS
--- "64-bit" dla aplikacji 64-bitowych
--- "Compat" dla aplikacji 32-bitowych
- "Legacy" dla mniej-bitowych OS
--- "Protected" dla aplikacji 32-bitowych na 32-bitowym OS
--- "Virtual 8086" dla aplikacji 16-bitowych na 32-bitowym OS
--- "Real" dla aplikacji 16-bitowych na 16-bitowym OS (kto tego używa?)

Podobnie jak miało to miejsce we wcześniejszych powiększeniach bitowości procesorów, wielkość rejestrów została zwiększona dwukrotnie. Tak więc teraz na przykład jest 64-bitowy rax, którego 32 młodsze bity są dostępne pod nazwą (znaną z architektury 32-bitowej) eax. Dalszy podział na ax, ah i al jest nadal wspierany. Poza tym dodano 8 nowych rejestrów, które nazywają się po prostu r8, r9, ..., r15. Analogicznie dodano rejestry SSE xmm8, xmm9, ..., xmm15, ale ich rozmiar pozostał bez zmian.

Poza tym została powiększona przestrzeń adresowa. Dzięki 64-bitowym adresom można zaadresować 16EB pamięci (na 32-bitach można było 4GB).

gcc na 64-bitach
Krótko i punktach:
- Typy danych i ich rozmiary (w bitach) to: int = 32, long = 64, wskaźnik = 64
- Przy optymalizacji -O2 pierwsze 6 argumentów całkowitoliczbowych i 8 zmiennoprzecinkowych jest przekazywane w rejestrach (a nie przez stos).
- wykorzystuje zwiększoną liczbę rejestrów
- jeżeli możliwe, wykorzystuje 32-bitowe operandy dla zaoszczędzenia miejsca
- potrafi kompilować dla architektury 32-bitowej (wystarczy dodać -m32)

Przykład:uint64_t do_add (uint64_t a, uint64_t b) { return a+b; }gcc -S -m32 -O2 add.c (-m32 czyli 32-bity)do_add: pushl %ebp # pierwsze odwołanie do pamięci movl %esp, %ebp movl 16(%ebp), %eax # drugie odwołanie do pamięci movl 20(%ebp), %edx # trzecie odwołanie do pamięci addl 8(%ebp), %eax # czwarte odwołanie do pamięci adcl 12(%ebp), %edx # piąte odwołanie do pamięci popl %ebp # szóste odwołanie do pamięci retgcc -S -m64 -O2 add.c (-m64 czyli 64-bity)do_add: leaq (%rdi,%rsi), %rax # argumenty przekazane w rejestrach rdi i rsi. zero odwołań do pamięci ret

Kompatybilność z architekturą 32-bitową
Co może procesor? W trybie "Compat" pozwala na uruchamianie niezmienionych aplikacji 32-bitowych w 64-bitowym systemie. Dla programu taki tryb niczym się nie różni od trybu "Protected". Poza tym choć program może zaadresować tylko 4GB pamięci, to system operacyjny może ją zamapować w dowolne inne miejsce.
Co może Linux? Po pierwsze i chyba najważniejsze: automatycznie przełącza procesor pomiędzy trybami "64-bit" i "Compat", co pozwala na jednoczesne działanie programów 32 i 64-bitowych. Niestety 32-bitowy program musi mieć 32-bitowe biblioteki, więc niektóre z nich muszą być dublowane na każdą architekturę.

Testy wydajności
Jako testy sprawdzono czas działania povray, oggenc i mencoder, oraz czas kompilacji Firefoxa i GTK+. Poprawa (albo pogorszenie) wydajności, względem wersji 32-bitowej, to odpowiednio 7%, 24.5%, 3.5%, 19.8% i -14.4%. Testowano też czas kompilacji jądra Linux dla różnych kombinacji architektury hosta i architektury docelowej. Zmiany, względem kombinacji 32-bitowy host i 32-bitowy wynik, wynosiły od 2% do -8%.

Podsumowanie, czyli obalanie mitów

- Nie potrzeba 64-bitowego systemu gdy ma się mniej niż 3 GB RAMu
Nie samym RAMem żyje komputer. Warto mieć 64-bitowy system dla lepszej wydajności.

- Jest mniej driverów na 64-bitowy OS
W przypadku Linuxa to raczej nieprawda (hail Open Source!)

- Cały software musi być 64-bitowy
Tryb kompatybilności działa bardzo sprawnie i nie zakłóca działania innych programów.
Jest nawet program nspluginwrapper, który pozwala na uruchamianie 32-bitowych pluginów (np. flash) w 64-bitowych przeglądarkach.

- 64-bitowy software jest 2 razy szybszy
Dwa razy to nie, ale 20% może się trafić.

Wniosek

Najlepiej jest używać systemu 64-bitowego i uruchamiać w nim 32-bitowe programy, jeżeli tylko jest taka konieczność.

Zachęcam do przejrzenia głównego źródła tego wpisu 64bit_Linux-Myths_and_Facts.pdf. Można tam znaleźć trochę szczegółów, które pominąłem, słupki z benchmarków oraz wskazówki dla portujących aplikacje na 64-bity. 

Komentarze

0 nowych
Olbi   10 #1 12.06.2010 12:43

Dobrze, że dystrybucje linuksowego 64 bitowe dobrze działają na 512MB Ram, gdzie Windows 7 64bity musi mieć przynajmniej 2GB RAM.
Za to lubię dystrybucje Linuksowe. MS nie potrafi nawet zoptymalizować swojego durnego systemu :P

trux   11 #2 12.06.2010 13:32

Użytkownicy już dawno temu dostrzegli zalety 64 bitów. Natomiast producenci oprogramowania dalej żyją w prehistorii (Adobe, Skype, itp.).

RubasznyRumcajs   6 #3 12.06.2010 14:07

hm... fajny artykul, a raczej jego zalazek- brakuje tylko informacji o NX (NonExecute)- ktore to, w linuksach 64 bitowych jest obslugiwane bez utraty wydajnosci (w porownaniu do 64bitowcow bez obslugi NX- oczywiscie na prockach obslugujacych go /tj. na wszystkich nowszych niz ostatnie serie P4).
Rowniez co do GCC- testow tutaj nie podam, bardziej jako anegdotke- na starym lapku (ok, technologicznie toto stare nie jest)- core2duo 2ghz, 2g ramu ddr2 uzywalem sobie debiana lennego (wtedy toto jeszcze nie byl stabilny). jak najbardziej standardowa kompilacja jajka "sposobem debiana" (czyli z utworzeniem paczki .deb i zainstalowaniem jej) na standardowych ustawieniach (zminilem tylko pare ustawien w jajku) na 32bitach zajela... 1 godzine (dokladniej: jakies 57 minut)- na 64 bitach (ta sama wersja i jajka, i gcc- ten sam system, te same ustawienia) zajela nieco ponad 30 minut- a wiec roznica jest, jak najbardziej, zauwazalna.
Inna sprawa jest to, ze standardowo architektura 64bitowa (amd64) zawiera w sobie okreslone flagi i 'zestawy instrukcji' /sse2 bodajze/- tak wiec, jesli mamy 64bitowy procesor i takiz system, to owe instrukcje beda obslugiwane- i bedzie toto szybsze niz w przypadku 32bitowych systemow, gdzie domyslna konfiguracja programu moze nie przewidywac istnienie owych instrukcji (po to by byc kompatybilna ze starszymi prockami).
Inna sprawa jest rowniez to, ze uzywajac 32bitowych programow, trza uzywac 32bitowych bibliotek (tak jak juz zostalo to napisane)- co moze znaczyc, ze jednoczesnie zaladowane beda 2 wersje (32 i 64bitowe) owej biblioteki, co z kolei oznacza zwiekszenie zapotrzebowania na pamiec.

@Orion
puki co ow 'durny system', bedac jeszcze w fazie testowej (publiczne bety) uzyskal wieksza ilosc uzytkownikow na desktopach niz linux ma po -nastu latach (i 10 'latach linuksa na desktopie') :)

  #4 12.06.2010 14:31

Orion, na leciwym lapku mojego brata z 2004 roku zainstowałem W7. 1,2GHZ proc, 512SDRAM, Dysk 40gb... Po optymalizacji udało mi się zejść do 200MB zajmowanych przez system. I co najważniejsze, śmiga nieźle.... jest responsywniejszy niż XP'eka, a i sterowniki wszystkie są dostępne do niego mimo jego wieku.
Więc takich bzdur nie opowiadaj, bo jak najbardziej mozna na nim pracować (wiadomo, że do kodowania filmu czy niezłego używania photoshopa czy autocada sie nie nadaje). Niestety na Ubuntu (10.04) musiałem używać i915.modeset= 1 vesa by w ogóle odpalić go do trybu live, bo bez tego to czarny ekran był (poczytaj w necie ile osób ma problem z blank/black screen po instalacji/boocie). Nie wspominam, że po tym użycie proca było ciągle na poziomie ok 18 procent. Ubuntu to tylko na nowe kompy, bo na starych to więcej problemów jest.

  #5 12.06.2010 15:21

przykład jest niezły, pokazuje ile zaoszczęda się odwołań do pamięci i z tego co tutaj widzę to ta funkcja niedość, że jest szybka to i jeszcze mała.

Seccoawt   2 #6 12.06.2010 15:35

#mystic000
Próbowałeś może, Slackware + Fluxbox?, ponieważ mówią, że jest bardzo mało wymagające.

etam   10 #7 12.06.2010 16:06

@Seccoawt, mystic000
Jak chcecie kontynuować temat, to proszę nie tutaj.

roobal   15 #8 12.06.2010 19:29

Dodam od siebie jeszcze tyle, że nspluginwrapper oprócz tego co napisałeś pozwala również na uruchomienie linuksowego Flasha w trybie kompatybilności binarnej Linuksa (Linux ABI Compat) pod FreeBSD, dzięki czemu można się cieszyć Flashem pod systemami BSD w natywnych przeglądarkach a sam Flash działa prawie jak natywny ;)

Pozdrawiam!

dragonn   11 #9 12.06.2010 19:57

A najlepsze jest to że adobe zamroziło rozwój flash na 64 bity http://labs.adobe.com/technologies/flashplayer10/64bit.html
Mam taką nadzieje że znowu ruszy.

Kpc21   10 #10 13.06.2010 00:05

Tak poza tym to o ile wiem, to ograniczenie do 3 GB RAM-u w 32-bitowym systemie obowiązuje tylko w systemach Microsoftu.

A po zainstalowaniu 64-bitowej wersji Linuksa miałem problem z instalacją programów przeznaczonych pod 32 bity (nie pamiętam już czy to były paczki DEB czy źródła ale chyba źródła).

n-pigeon   5 #11 13.06.2010 09:34

@ Kpc21

Jeśli instalowałeś z źródeł to nie mogłeś mieć problemów, kod by się skompilował na 64-bity

n-pigeon   5 #12 13.06.2010 09:45

Jeśli instalowałeś z paczki to pewnie biblioteki które ten program używał miałeś zainstalowane w 64 bitach, gdybyś używał menadżera to by rozwiązało zależności.

  #13 08.12.2013 22:41

marny tekst. Zero konkretów, same gdybania i mądrości czytelne dla inżynierów, szkoda czasu na czytanie

  #14 04.11.2016 12:11

Pominięto tu bardzo ważny aspekt systemu 64-bitowego. Zapotrzebowanie aplikacji na pamięć. Niestety większość danych programu to dynamiczne struktury mocno oparte o referencje (pointery), które to w 64 bitach zaczynają zajmować 2 razy więcej miejsca. W zależności od aplikacji powoduje to, że przy dużym rozdrobnieniu struktur i braku optymalizacji refaktoringu danych programu przyrost wymagań na RAM może sięgać 100% dla ekwiwalentnego zadania. Najlepiej widać to w Javie, która przy bardzo rozdrobnionym modelu danych potrafi w trybie 64-bitowym połknąć 2-2.5 x więcej RAM. Dobrym przykładem są również przeglądarki które na aplikacje Javascript i DOM znacząco więcej potrzebują w 64-bitowej wersji. Standardowe (biuro/biznes/net) aplikacje (nie graficzne i nie multimedialne) na ogół używają 32-bitowych liczb i te zyski są dla nich wyraźnie mniejsze. Mój typ - 64 bitowy system i 32-bitowe aplikacje. Szczególnie jeśli maszyna nie ma za dużo RAM.