32 bit, a 64 bit

[Gość: muniek]

Jaka jest roznica w dzialaniu 64 bitowego systemu z 64 bitowym prockiem, a
systemem i prockiem 32 bitowym??? Ostatnio duzo o tym slysze, a kompletnie nie
mam pojecia czym to sie rozni, moze mi ktos to wytlumaczyc w jasny sposob?

[Gość: tswiercz]

Ogólnie różnica jest taka:
Procesor 32-bitowy posiada rejestry 32-bitowe (4 bajtowe) na których wykonywane są obliczenia. To znaczy, że procesor może operować na 4 bajtach naraz, np na int'cie, float'cie, które są 4 bajtowe. Natomiast procesor 64 bitowy posiada 2x większe rejestry, dlatego za jednym zamachem może "działać" na 64 bitowych danych (8 bajtowych) - czyli np na double'u. Procesor 32-bitowy aby móc się posłużyć 64- bitową daną, musi ją podzielić na dwie 32-bitowe i dlatego operowanie na takiej danej jest wolniejsze.
Jeżeli jakiś program nie operuje na danych 8 bajtowych, to praktycznie różnicy wogóle nie ma. Co do programów 32 bitowych na 64 bitowej maszynie. One działają tak jakby były uruchomione na 32 bitowej maszynie, bo są tak skompilowane.
pozdr

Przy czym warto

[Gość: Reader]

dodac, ze:

1) procesory obecne (32 bitowe) moga od jakiegos czasu korzystac z rejestrow i
operacji na liczbach nawet 128 bitowych (MMX,SSE itd) - niestety glownie do
obliczen matematycznych

2) wieksz ilosc bitow pociaga za soba (choc nie koniecznie i nie w rownym
stopniu) szersza szyne adresowa, co pozwala na zaadresowanie wiekszej ilosc
pamieci. Jesli sie nie myle (moglo to sie zmienic z wersjami AMD i Intela) w AMD
bylo to 51 bitow (czyli 2 do potegi 51) a w Intelu poczatkowo 41 bitow a nowsze
wersje mialy miec szersza szyne

Problem lezy w dostepnosci systemow operacyjnych prekompilowanych i
optymalizowanych do 64 bitow. Oraz pozniej softu, rowniez kompilowanego i
optymalizowanego do 64 bitow (jak znam zycie pierwszy bedzie i tak Photoshop -
oni najlepiej wykorzystuja mozliwosci prockow :)

[hanatol]

A tu masz testy 4-ech procesorów na 64- i 32- bitowym systemie gentoo linux:

www.linuxhardware.org/article.pl?sid=05/02/24/1747228
Zauważ, ze nie zawsze 64-bity = szybciej.
Jest tam kilka przykładów, gdzie test wypadł lepiej w 32-bitowym środowisku.
Szczególnie dotyczy to pentium.

[blitz667]

hanatol napisał:

> A tu masz testy 4-ech procesorów na 64- i 32- bitowym systemie gentoo linux:
>
> www.linuxhardware.org/article.pl?sid=05/02/24/1747228
> Zauważ, ze nie zawsze 64-bity = szybciej.
> Jest tam kilka przykładów, gdzie test wypadł lepiej w 32-bitowym środowisku.
> Szczególnie dotyczy to pentium.
No właśnie, Pentium. Z powyższych testów wynika, że procesory AMD spisują siębardzo podobnie w obu środowiskach. W 64-bit niznacznie lepiej aż do 20-25% wzrostu wydajności.

PS: Moim zdaniem jak najbardziej warto kupować 64-bit procki(przynajmniej te od AMD), własnie ze wzgledu na to, ze można na nich pracować normlanie w 32-bit, a potem bez problemu przejść na 64-bit jesli tylko będzie to możliwe. Bo wydajności w środowisku 32-bit nie traci sięnic a nic, a nawet zyskuje w porównaniu do Athlona XP.

Dodam jeszcze, że...

[user0001]

Największe różnice w szybkości możemy obserować tam gdzie potrzebne są operacje
na liczbach 64 bitowych, dotyczy to zwłaszcza:

1. operacji na dyskach, szczególnie gdy mamy doczynienia z programami
przygotowanymi do obsługi dużych (>2GB) plików.

2. operacji na bazach danych, serwery na których pracują bazy danych mają już
ponad 4GB RAM, a 32 bitowy system operacyjny pozwala w naturalny sposób
zaadresować jedynie 4GB RAM. (to tylko wytłumaczenie dla laika, wiem że chodzi
tu raczej o wydajność korzystania z plików mmap'owanych, i temu podobne)

3. liczenia czasu w *nix'ach (w tym w GNU/Linuksie). Odpowiednikiem "Milennium
Bug" na platformach *nix'owych jest problem roku 2038, kiedy to w czwartek 19
stycznia o godzinie trzeciej czternaście i 7 sekund, 32-bitowy licznik czasu
przekręci się, i wskaże 13 grudnia 1901 (co ciekawe to jest piątek ;) ). 64
bitowy licznik czasu przeniesie błąd przepełnienia zegara o kilka miliardów lat
w przyszłość.

[Gość: tswiercz]

> 3. liczenia czasu w *nix'ach (w tym w GNU/Linuksie). Odpowiednikiem "Milennium Bug" na platformach *nix'owych jest problem roku 2038, kiedy to w czwartek 19 stycznia o godzinie trzeciej czternaście i 7 sekund, 32-bitowy licznik czasu przekręci się, i wskaże 13 grudnia 1901 (co ciekawe to jest piątek ;) ). 64 bitowy licznik czasu przeniesie błąd przepełnienia zegara o kilka miliardów lat w przyszłość.

Nie rozumiem tego fenomenu. Mógłbyś mi bliżej przybliżyć sposób przechowywania tejże danej??

[Gość: diabeł]

unix liczy datę w sekundach, 2^32 sekund = około 137 lat

[Gość: tswiercz]

No ale to wystarczy zmienić tą zmienną na long long int'a i już mamy ładnych pare latek więcej. Więc co ma sprzęt do tego??

[user0001]

Sprzęt ma całkiem sporo do tego. Zmiana definicj typu time_t spowodowała bym
utratę kompatybilności ABI, tym samym wszystkie programy korzystające z typu
time_t musiały by zostać zrekompilowane.
Co gorsza problem dotknąłby najbardziej podstawowej biblioteki libc. ABI C++
zmieniało się bardzo często w historii GCC, ale ABI języka C zmienia się
niezmiernie żadko, ostatnią poważną zmianą na GNU/Linuksie było przejście z
libc5 na glibc2. Wymuszona została by wymiana wszystkich programów o zamkniętych
źródłach, nikt nie chce ponosić takich kosztów.
Przejście na inną platformę sprzętową stwarza doskonałą okazję do poprawienia
takich błędów, typ 64bitowy będzie obsługiwany bardzo szybko dzięki 64bitowym
rejestrom, a wszystkie nowe aplikacje będą musiały korzystać z nowego,
64bitowego ABI.

(ABI - Application Binary Interface, określa dostępne wywołania funkcji, oraz
definicje typów wszystkich argumentów, sposoby przekazywania argumentów do
funkcji i ich zwracania)

[kell99]

... nalezy tylko dodac, ze jako 64bitowe liczby nie biora sie z niczego i system
operacyjny nie jest w stanie przewidziec ile bitow bedzie potrzebne, mozna
przyjac, ze 64bitowy os i 64bitowe programy beda potrzebowac 2x wiecej pamieci....
biorac pod uwage w jak nieumiejetny sposob win xp marnuje pamiec to bez 1GB nie
ma co sie bawic
co do daty w uniksach to akurat dzisiaj przypada interesujaca data:
slashdot.org/articles/05/03/17/169200.shtml?tid=130

[tswiercz]

kell99 napisał:

> ... nalezy tylko dodac, ze jako 64bitowe liczby nie biora sie z niczego i system
> operacyjny nie jest w stanie przewidziec ile bitow bedzie potrzebne, mozna
> przyjac, ze 64bitowy os i 64bitowe programy beda potrzebowac 2x wiecej pamieci.

Tego nie rozumiem. Dlaczego wszystko ma zajmować dwa razy większą pamięć?
No chyba, że wszyscy się rzucą i pozamieniają 4 bajtowe zmienne na 8 bajtowe, co
w sumie jest możliwe, ale nie bez przesady. Nie zawsze jest konieczna taka
precyzja. A po drugie, przecież system operacyjny wie ile pamięci musi
przydzielić danej zmiennej.

[user0001]

Programi*ci nie "rzuc* si*" na nowe 64bitowe zmienne, po prostu przekompiluj*
swoje programy, a kompilator uzna *e int ma by* w najdogodniejszym rozmiarze
(64bit). Dodatkowo wska*nki stan* si* dwukrotnie wi*ksze (bez interwencji
programisty).

Programi*ci pami*taj*cy czasy DOS, kojarz* zapewnie piekie*ko zwane
segmentacj*, "modele pami*ci" i wykorzystywanie wska*nik*w maj*cych rozmiar
po*owy s*owa, kiepsk* wydajno** 16bitowego kodu na 32bitowych procesorach.
Dwukrotnie wi*ksze wymagania na ilo** pami*ci (pami*ci kt*ra stale tanieje), s*
znacznie bardziej op*acalne ni* zawalone terminy, i *ciganie b**d*w.
Wyb*r rozmiaru zmiennych b*dzie dotyczy* jedynie programuj*cych w C/C++. Reszta
korzystaj*ca z j*zyk*w interpretowanych mo*e nawet nie zda* sobie sprawy z
przej*cia.

[Gość: tswiercz]

A rzeczywiście. Int tak samo jak long jest teraz 4 bajtowy, mimo iż wcześniejsza
wersja int'a była dwubajtowa (borland c++ 2.0). Ze wskaźnikami napewno będzie
identycznie, bo już nie będzie limitu 4 GB. OK dzięki bardzo za odpowiedź.

Zgodnie z norma

[Gość: Reader]

ISO99 int POWINIEN miec wielkosc (w bitach) odpowiadajaca architekturze systemu ;)

[kell99]

no i tak jest. nie zauwazyles, ze wiele programow ma w makefile sprawdzanie
wielkosci podstawowych typow danych? tylko czy to, ze zadeklarujesz sobie int o
odpowiedniej dlugosci, bedzie znaczyc, ze kompilator i twoj system operacyjny
tak samo to przetworza? a co z wiekszoscia nowszych jezykow (nowszych od c/c++)
gdzie czesto nie sposob okreslic czy chcesz short int, int, a moze long int?
masz int i koniec... kompilator nie jest imho w czasie kompilacji stwierdzic co
bedzie potrzebne i tak jak bylo juz powiedziane, jezeli bedzie tylko int to
wstawi int zgodny z architektura, czyli 64bity..

poza tym polecam mase juz artow o roznicach miedzy 32 i 64 bity i o tej
mitycznej predkosci, ktora jest mityczna tylko dlatego, ze 64 bity natywnie
wspieraja 64bitowe liczby zmiennoprzecinkowe, ktore obecnie musza byc "skladane"
i stad ten caly zysk wydajnosci (imho w grach dokladnosc wymagana nie jest, wiec
i zysk bedzie np w koderach video i audio.. co pokrywa sie z testami)

[tswiercz]

Ale sama ilość bitów jeszcze nie oznacza, że na każdej platformie dany program będzie działał identycznie. Napisałem taki program, nic wielkiego, poprostu wylicza kolejne elemnty prostego ciągu. Testowałem to na normalnym x86 i SPARC'u (SUN). I wyniki mnie rozwaliły. Już przy 3 iteracji były różnice pomiędzy wartościami ciągu. Mimo że na obu platformach float ma tą samą ilość bitów na ceche i mantyse. A gry są bardzo optymalizowane , więc pewnie dlatego nie używają 8 bajtowych zmiennych.

[blitz667]

tswiercz napisał:

> Ale sama ilość bitów jeszcze nie oznacza, że na każdej platformie dany program
> będzie działał identycznie. Napisałem taki program, nic wielkiego, poprostu wyl
> icza kolejne elemnty prostego ciągu. Testowałem to na normalnym x86 i SPARC'u (
> SUN). I wyniki mnie rozwaliły. Już przy 3 iteracji były różnice pomiędzy wartoś
> ciami ciągu. Mimo że na obu platformach float ma tą samą ilość bitów na ceche i
> mantyse. A gry są bardzo optymalizowane , więc pewnie dlatego nie używają 8 ba
> jtowych zmiennych.
No przepraszam, ale ameryki nie odkryłeś :) Sądzę że na Alphach miałbyś jeszcze inne wyniki...

[tswiercz]

No wiem że nie odkryłem ;-), tylko trochę mnie to zdziwiło.

Dla nieswiadomych czy zainteresowanych:

[Gość: Reader]

www.intel.com/design/pentium4/manuals/index_new.htm#1

[kell99]

kup sobie jakas powazna ksiazke z dziedziny metod numerycznych, o ile nie masz
co z zyciem robic, jest sporo prostych sposob w ktory mozna znaczaco zmniejszyc
bledy (zaokraglenia, czy niedokladnosci notacji zmiennoprzecinkowej). tutaj to i
64bity moga byc za malo, bo zawsze znajdziesz liczbe, ktora rozwali wynik calkowicie

[kell99]

odpowiedz na forum.gazeta.pl/forum/72,2.html?f=34&w=21586171&a=21830932 ;)

[tswiercz]

Można zawszu użyć z gotowych bibliotek, które liczą poprawniej :-)
A książkę już mam, tylko wybrałem chyba jedną z najgorszych pozycji, bo tam głównie majca jest.

[kell99]

huh, a jakie gotowe biblioteki czuwaja by wynik dzielenia byl poprawny?

[tswiercz]

A to muszę się spytać kolegi, on wykorzystał jakąś i nawet wyniki jakoś wyglądały normalnie. Ale i tak pewnie to wszystko jest do pewnego momentu. Zwlaszcza jak wynik będzie bliski zeru.

GNU Multi Precision Arithmetic Library?

[user0001]

www.swox.com/gmp/

[kell99]

ciekawe, ciekawe... thx;)

[tswiercz]

To chyba nawet to było i też thx, napewno się przyda.