Witam,
ostatnio czytałem (przeglądałem ) dokumentacje Intela i wyczytałem, że główna róznica pomiędzy 64 a 32 bitowymi procesorami to to, że te pierwsze mają większy zakres dostępu do pamięci (wirtualnej i fizycznej). Słyszałem to też drogą ploteczkową. I teraz stąd moje pytanie: czy jest to naprawdę jedyna różnica? Warto w takim razie kupować takie procesory (dla mnie i tak już za późno...), jeżeli nie mam zamiaru w ciągu najbliższych pięciu lat mieć więcej jak 4GB pamięci (tym bardziej, że Linux potrafi więcej obsługiwać nawet przy 32-bitowych maszynach, nie wiem jak reszta)?

Pozdrawiam

Jabol chodzi tutaj o błąd roku 2000 któregoś... W 32 bitowym systemie obecna data zmieni się nagle na datę 1970 roku... Bo przejdzie do liczby minusowej...

Ahaaa, i to dlatego takie procki wprowadzili, ciekawe, i czemu dopiero teraz a nie w 1999 kiedy by sie lepiej sprzedaly w zwiazku z Y2K?. A nie prosciej bylo uzyc 8bajtow do przechowywania daty tylko robic nowy procek?


Na powaznie: nie wiem, ponoc maja byc szybsze dla aplikacji pisanych specjalnie pod 64b w porownaniu z aplikacjiami 32b na maszynach 32b (no bo teoretycznie przetwarzaja 2x wiecej danych w rozkazie)

Masz na myśli aplikacje kompilowane specjalnie pod 64 bity? Bo te które pisze się z zachowaniem jakieś przenośności nie powinny zawierać żadnych róznić poza asemblerem.

A tak co do tego co teorii Turgona. Jest ona rzeczywiście mało wiarygodna. Raczej skutkiem ubocznym jest ominięcie końca wyjścia poza możliwości time_t. Swoją drogą, zaciekawiło mnie i sprawdziłem -> time_t jest typu signed!!! Czy ktoś mnie uświadomi why? Przecież to pomylenie jakieś... bład projektowania, założeń. Chyba termin kogoś gonił jak to wymyślał...

http://pl.wikipedia.org/wiki/Problem_roku_2038

Jabol... Czytaj wikipedię! Z resztą zwiększenie z 32 bitów do 64 bitów rozmiar da na pewno większą wydajność, przy mniejszym taktowaniu.

64 bity to int 64 bitowy. To więcej rozkazów. Jest taki program do obróbki/tworzenia muzyki "Sonar", wersja 64 bitowa jest o wiele wydajniejsza od 32 bitowej, sprawdzane doświadczalnie. Tak więc wydaje mi się że wzrost wydajności jest spory pod warunkiem, że aplikacja jest 64 bitowa (no i system operacyjny ) Poczytaj tu: http://en.wikipedia.org/wiki/X86-64

WTF ze znakiem? Kogoś chyba bolała głowa... Chyba, że to wymyślili jeszcze przed 1.1.1970
A tak swoją drogą nie widzę powodu aby samo zwiększenie długości słowa miało dać zwiększenie wydajności

A wracając do tematu: dzięki za odpowiedzi! dochodzę do wniosku, że wygląda na to, że jednak było warto. Co do większej ilości rozkazów to można również więcej rozkazów na 32-bitowcach zaimplementować, to nie kwestia wielkości słowa, a raczej tego, czy kompilator będzie umiał ich użyć (dlatego winy to shit, bo nie używają zupełnie rozszerzeń optymalizacyjnych specyficznych dla danego modelu procesora! a jedynie tylko standardowych operacji i686! chyba, że znają jakąś strasznie sprytną sztuczkę, żeby to obejść?). W każdym razie skoro te aplikacje są wydajniejsze to świetnie. Jednak nie były to wyrzucone pięniądze.

Jedyne co mnie irytuje to to, że muszę działać na systemie w profilu multilib, bo inaczje połowa aplikacji by mi nie działa (na windowsach też by nie działały, nie łudźcie się. jeżeli Wam 32-bitowe aplikacje działają to znaczy, że Wasz win to multilib!). Teraz rozumiem, czemu wszyscy tak swojego czasu jechali win 95 i 98 (pamiętam te czasy, tylko wtedy jeszcze nie wiedziałem o co chodzi).

Inna sprawa, że w 64 bitowych maszynach int ma 4 bajty. long ma dla odmiany 8 bajtów oraz pointer. A long long to po prostu long (tutaj na pewno jest przyśpieszenie). Czy to znaczy też szybsze działania zmiennoprzecinkowe? Tutaj małe podsumowanie.Mógły ktoś na 32-bitowcu odpalić?

Zaraz odpale, ale z tego co wiem to tylko void* bedzie 4B

edit: hehe, a u mnie:



edit:

gcc version 3.3.6
Linux localhost 2.4.31 #6 Sun Jun 5 19:04:47 PDT 2005 i686 unknown unknown GNU/Linux


"Moje long double jest lepsze niz twoje long double"

A może by tak podać kompilator i OS panowie?

Cygwin@XP

PS. Szybka Instalka i nauka Cygwina Czemu ja się z VS męczyłem?

BCB@XP u mnie było widze że moj long duble nie domaga

Baleron D 2,93 GHZ i Kubuntu 6.10 Edgy Efts

Tak naprawdę jedyna odczuwalna różnica dla użytkownika widoczna jest przy operacjach na dużych plikach. Ponad 2gb i posiadanie równie dużo pamięci ram.

Stawianie systemów 64'bitowcych też pociąga za sobą pewne konsekwencje, a wzrost wydajności dla normalnego użytkownika jest praktycznie nie odczuwalny. Koniec końców jak każdy sobie kompiluje wszystko sam, odpowiednio dla 64bitów to wszystko śmiga ładnie, część osób tak działa na linuxie. Co do windows'a to już gorzej ale stopniowo pojawiają się biblioteki 64bitowe (jeżeli masz odtwarzacz, to musisz mieć do niego kodek skompilowane dla 64bitów, ect)

No rzeczywiście u Was ten long double nie domaga. U mnie
Teraz wychodzę, jak wróce przygotuje jakieś testy na tego long double i zobaczymy jak to wygląda w prawdziwym życiu.

Pozdrawiam

No dobra, mam następujący kod:I za każdym razem difference = 0.000000000
Ktoś mi wytłumaczy *czemu to działa*?
Przetestujcie to też na jakimś 32 bitowym, może wtedy coś się wyjaśni..

A tak swoją drogą to co 64-bitowych linuxów to właśnie sam jestem taki okaz. Wszystko oprócz plugina do flasha mam 64-bitowe (a firefox działa z tym pluginem, bo jest napisany wrapper jakiś...). Wszystko compilowane z -march=nocona (czyli Core 2 Duo). Muszę przyznać, że śmiga nieźle, ale inna sprawa to są po prostu mocne procesory, także sam nie wiem czego to wina..


Btw. Wiecie, jak teraz się nazywa instrunction pointer register? RIP (sic!)! Mogli wybrać jakąś inną literkę do prefiksowania 64bitowych rejestrów

Procki 64-bit przydają się, jeśli ktoś chce mieć więcej niż 3GB ramu,
ponieważ w 32bitach można zaadresować tylko 4GB. Dlaczego w takim razie 3 a nie 4? Bo Procesor musi też adresować pamięć karty graficznej (i kilku innych, mniej znaczących duperołów). Jeśli ktoś kupuje 4gb ramu, to jest wysoce prawdopodobne, że ma kartę z min. 512mb na pokładzie.
Dlatego za kilka lat systemy i procki na 32bit wyginą, nie będzie można dokupić do nich sprzętu.

@fridek: z pamięcią to już wiemy. teraz szukam jakiś innych różnic.

Dobra, udało mi się ten test stworzyć który chciałem. Mógłby to ktoś przetestować u siebie? Porównamy sobie i zobaczymy jak te procki na działania zmiennoprzecinkowe wpływają:Moje wyniki to:

cygwin(g++)@XP

hmmm... ciekawy, long double ma dokładnie tą samą dokładność, a double jest u mnie o połowe bardziej dokładny...

To po zmianie testu:

U mnie:

Pierwsze
Drugie:

@sztosz: nie zmieniałem tego testu . Porównaj dokładnie, jeżeli masz starą wersję i znasz troszkę C.
@Turgon: ten pierwszy wykonuje się chwilkę. A tak swoją drogą to i tak jest skopany i go nie róbcie!

U mnie na tym się kończy

Nie przypatrywałem się A teraz nie mam jak bo mi poszedł cały dysk i walczę o życie

@sztos: tylko mi nie mow ze znow dla ciekawosci kliknales w "link"

Fajna walka skoro skoro masz okazje wpaść na forum . Teraz to sie ciesze, że te programiki co udostępniłem były w formie źródłowej a nie binarnej

@dr_bonzo: Nie, instalowałem Gentoo, spytało się czy nadpisać istniejącą strukturę partycji tym co sobie wymysli. Pomyslałem NIE!!! kliknąłem TAK. Po 5 sec. twardy reset, ale bawie się z odzyskiem do teraz A noc długa...

++

Aspekt nie dokonany!

Ale mów do jakich wniosków doszedłeś. Jakie są różnice.

M$ wypowiada się na ten temat tak:

http://www.microsoft.com/windowsxp/64bit/facts/top10.mspx

http://www.microsoft.com/windowsxp/64bit/facts/benefit.mspx

http://www.microsoft.com/windowsxp/64bit/overview.mspx

Wynika z tego mniej więcej to, że zmiana na 64 wnosi na razie nie za wiele, jednak jak już się ma takie procesory - warto korzystać z systemu 64 bitowego.
I tak właśnie zrobiłem, co sobie chwalę, bo jednak nawet sam system pracuje wyraźnie "przyjemniej". Nie są to jednak różnice, dla których warto by się było "zabijać".

@DeyV: walnij ten test co przygotowałem (ten ostatni) u siebie jeśli masz jakiś kompilator zainstalowany. Jestem ciekaw, czy moje spostrzeżenia są prawidłowe.

@sztosz: tak więc ten test sprawdzał tylko różnice dokładności działań na liczbach zmiennoprzecinkowych. Wygląda na to, że przy long double nie ma *żadnej* różnicy, podczas gdy zwykły double jest u mnie ciutkę dokładniejszy (niedokładność jest u mnie o 1/3 mniejsza niż u Was). Ciekawie byłoby powtórzyć testy ze znienną test ustawioną np do 1<<64, wtedy pewnie byśmy zobaczyli zmianę dokładności.

Testy wydajnościowe raczej są niemożliwe do przeprowadzenia, bo tutaj chyba bardziej liczy się taktowanie niż wielkość słowa

Osobiście z innych różnic jakie zauważyłem to to, że np. za pierwszym razem i bez problemów skompilował mi się Open Office, podczas gdy na moim x86 było to tak niewyobrażalne, że używałem wersji binarnej (inna sprawa mam raczej mało agresywne CFLAGS, -O2 tylko z optymalizacji).

a tak dorzucę swoje 3 grosze

wyniki drugiego kodu identyczne jak Jabola natopias 1 nie chcial mi sie skompilowac

To tylko gorzej. Bo to znaczy ni mnie ni więcej, że w sumie niewiele się zyskuje na 64-bitach... Trudno. Conajmniej się będe pocieszał, że nie muszę używać specjalnych bibliotek do obliczeń rzędu 1<<63 ;P.