mina86.com

„Do tego dochodzi jeszcze bardziej skomplikowany, a przez to wolniejszy, proces tłumaczenia adresów logicznych na adresy fizyczne” – skąd masz takie informacje?

mam wrażenie że GCC ma opcję -msse3 ;>

mógłbyś rozwinąć i doprecyzować stwierdzenie: „z SSE3 gcc pewnie i tak nie umie skorzystać” ?

Hmm… http://winforum.pl/showthread.php?t=14385 I weź tu człowieku bądź mąrdy. :)

x86 (z włączonym PSE) potrzebuje dwóch (jednego) odczytów (odczytu), aby przetłumaczyć adres logiczny na fizyczny. Z włączonym PAE mamy trzy (dwa) odczyty. x86_64 natomiast, wymaga czterech (trzech) odczytów. (Źródło: „Intel® 64 and IA-32 Archtiectures Software Developer’s Manual, volume 3A” listopad 2006, sekcje 3.6.2, 3.10.1 oraz 3.10.2)

Jeśli chodzi o SSE3 to zwyczajnie, pomimo wielkiej sympatii dla projektu GNU oraz GCC, nie wierzę, aby ten kompilator potrafił tak zoptymalizować kod, żeby w pełni wykorzystać potencjał jaki daje to rozszerzenie.

zx: Nie twierdzę, że różne konkretne aplikacje nie będą szybsze. Twierdzę, że per saldo, w większości zastosowań 64 bitowy system nic Ci nie da, a raczej tylko zaszkodzi. Kiedy ostatnio liczyłeś silnię ze stu tysięcy?

Mam wrażenie, że najwięcej może zyskać obsługa SSL-a, czy SSH, ale z tego też wcale tak często się nie korzysta (a na pewno rzadko z punktu widzenia procesora, który dostaje prztyczki dwa albo i trzy miliardy razy na sekundę).

Wykonaj sobie polecenie awk 'NR == 1 {print $5 * 100 / ($2+$3+$4+$5)}' /proc/stat (chyba, że masz jakiś dziwny system operacyjny) i zobaczysz ile procent czasu Twój procesor nic nie robi — w moim przypadku jest to ponad 97% (jeżeli w tle, z ustawionym nicem masz coś@Home to z polecenia wyrzuć +$4).

a ja potrzebuje 64 bity do uruchamiania maszyn virtualnych na W2K8 przy uzyciu Hyper-V (wymagane przez system). Na 32-bitowym systemie mozna miec Virtual PC czy Virtual Server 2005 no ale na Hyper-V moge zrobic o wiele wiele wiecej :)

Nie chciałbym się przyczepiać, ale domyślnie w gcc int nawet na maszynach 64 bitowych ma 4 bajty.
Więcej rejestrów wpływa na prędkość wykonania programu, bo więcej zmiennych lokalnych można w nich trzymać i nie trzeba ich wywalać do RAMu (czy tam casha).

Ciekawe, że mój naprędce napisany program korzystający z biblioteki GMP liczy silnię ze stó tysięcy w niecałe 9 sekund (a procesor mam gorszy niż ten wykorzystywany w pomiarach, do których link dał zx). Oczywiście system 32 bitowy.

int i owszem, ale long ma 64, a teraz przypomnijmy sobie jaka te typy są zdefiniowane? Żeby nie wchodzić w zbytnie szczegóły int ma conajmniej 16, a long conajmniej 32 bity. Zatem, jeżeli jakas aplikacja potrzebowała typu, który ma conajmniej 32 bity (czy nawet conajmniej 17 bitów) to jest duża szansa, że wykorzystała typ long, który nagle staje się 64 bitowy i połowa przestrzeni jest marnowana.

O litości, 386 weszło do sprzedaży w 1985 roku.
Halo!! Czy wszyscy już się przestawili, że int ma 32 bity?

int nie ma zdefiniowanej wielkości, zazwyczaj jest równa domyślnej długości słowa dla danego procesora.
short ma 16 bitów, long 32, long long 64 (ale nie mam pewności jak na architekturze 64bit, ale myślę że nic tu nie ruszano – właśnie dla zachowania kompatybilności, za dużo rzeczy mogłoby się posypać)

Caladan, niektórzy nadal lubią pisać przenośne programy i niczego nie przyjmować. Niektórzy np. założyli, że sizeof(int) == sizeof(void*) i w rezultacie taki program przestanie działać na x86_64.

AdamK, niestety mijasz się z prawdą. Wielkość żadnego z typów nie jest zdefiniowana. Wiadomo, że char i short mają przynajmniej 8, int przynajmniej 16, long przynajmniej 32, a long long przynajmniej 64 bity, ale jakie są kokretne wartości nie jest powiedziane.

Zależy na jakie definicje się patrzy – w samym języku C nie, ale ‘poza nim’ są takie definicje, to jest fajny artykuł: http://www.unix.org/whitepapers/64bit.html z którego wynika że może być bardzo różnie.

A Twój przenośny program, używał longa by mieć dla siebie caaaaaałe 32 bity, więc zapewne pisałeś go w latach 90. Od tego czasu masz 10 razy więcej pamięci, dlatego wszystko nagle zacznie mulić gdy program sprzed 10 lat będzie uruchamiany.

Druga sprawa to to, że używam operatora sizeof, więc tak długo, jak z rozmiarem słowa idziemy w górę, nic nie powinno się popsuć. Oczywiście, możesz próbować odpalić coś co było pisane na 32 bity na 8 bitowcu. Ale czy warto? Chyba lepiej napisać od nowa – używając jasno określonych zmiennych typów:
uint8, uint16, uint32, int8, int16, int32 czy jak tam sobie chcesz nazwać.

- mina86, jak chcesz pisac przenosne programy to korzystasz z <stdint.h>

- jak piszesz przenosne programy, to wlasnie nie rzutujesz z int, na void *, ani w druga strone.

- /me szczesliwy posiadasz x86_64, z 2 GB pamieci i
dziala swietnie!

Dobra. Czy jest ktoś w stanie jednoznacznie stwierdzić czy x32 będzie szybszy dla mnie (kodowanie, gdy i reszta standardowo) niż x64?

Wątpię :D Będzie zapewne tak samo szybki. Ale z drugiej strony, chciałbym zobaczyć, czy może te nowe rejestry są w stanie pomóc w szybkości. Zreszta, jakie x64? :D To jest x86-64…

Wiem, wiem. Przyjął się zapis x64, więc nie widzę sensu marnować klawiszy.

darkjames, ależ ja korzystam z stdint.h jak i nie rzutuję ze wskaźników na liczby, co nie zmienia faktu, że nie każdy tak robi. Zresztą odchodzimy od tematu. Fakt faktem, że zużycie pamięci wzrasta z różnych powodów, czy to większych wskaźników, czy wyrównywania struktur, które mają w sobie 32 bitowego inta oraz 64 bitowy wskaźnik, czy zrzucanie nawet 32 bitowych danych na stos w postaci 64 bitowych liczb.

Piszesz, że działa Ci świetnie — pojawia się pytanie: A czy działa Ci lepiej niż 32 bitowy system? Może wręcz przeciwnie?

No wiesz, x86 jest skrótem określającym całą rodzinę zaczętą przez 8086 (a w sumie nawet 8080). Żeby było śmieszniej,była też rodzina 8032 (bazowana na 8031), więc jeszcze trochę i nie bedzie x86 a x32 i wrócimy do 8bitów ;-)

@Mina86:
Pomyśl, jak nędznie czuli się ci piszący programy na 286, którzy przesiedli się ze swoimi programami na 386. Boże! Tyle niepotrzebnego miejsca na stosie zmarnowanego, tyle wskaźników za długich! Wtedy RAM był droższy.
Przejdź już nad tym do porządku dziennego ;-)

Jakoś nie widziałem żadnej płyty głównej (pod c2d i wyższe), która obsługuje <4GB RAM (mówię o standardowych, w formacjie ATX, bo te mniejsze lubią czasami mieć jakieś dziwne ograniczenia, np. jeden slot pamięci). Standardem raczej jest obsługa do 8GB, czasami do 16.

Caladan, tyle że przejście z 16 bitowych na 32 bitowe wskaźniki dawało zauważalne korzyści, bo posiadanie więcej niż 64 KiB pamięci nie było rzadkością. Tak samo przejście z 16 bitowej na 32 bitową arytmetykę dawało zauważalne korzyści. Przy przejściu 32 -> 64 te korzyście nie są wcale tak zauważalne.

moher, np. moja obsługuje 3GiB. W robocie mam komputer, który niby pozwala na włożenie 4GiB, ale ucina ostatnie 0,5GiB.

Płyta ucina czy Windows ucina? Przekroczenie 4GB pamięci znów przywraca do życia stare cyrki – segmentację pamięci, chociaż już nie taką jawną. Czy musimy mieć znów jakieś magiczne technologie adresów 48-bitowych?
A tak w ogóle to x86-64, jak i cała wcześniejsza x86 jest do dupy. ;-)

Mi standardowo widzi 4GB, a dostępne jest 3,5GB (tak jest napisane w informacjach w menu BIOS-a), po włączeniu opcji, nie pamiętam dokładnej nazwy, „Memory Remap Feature” dostępny jest cały RAM.

Jest jeszcze druga strona medalu — obecne procki 64-bitowe są wielordzeniowe. I o ile nawet 64 bity mogą nie być specjalnie pociągające, o tyle już te gratisowe rdzenie…

(mam w domu 64 bitowy procesor, używam na nim 32 bitowego OS-a z 4GB ramu :)

W sumie autor tekstu ma rację... Ja bym nawet się pokusił o stwierdzenie.. po co nam 32 bitowe? Przeciez tyle pamięci zżerają... w sumie moglibyśmy zostać przy 16 bitówkach..hm… albo lepiej przy 8 bitach? Hm.. Mi tam commodore się podobało :D
//Oczywiscie jest to ironia

Jak zawsze możemy liczyć na autorów softu. W przeciągu paru lat sprawią, że zwiększona przestrzeń adresowa, dodatkowe rejestry i instrukcje staną się niezbędne.

Software zawsze puchnie by wypełnić całą dostępną przestrzeń ;)

Oczywiscie najlepiej to widać jeśli chodzi o wolną przestrzeń na dyskach twardych (do diaska!)

A dla mnie 64 bity to zbawienie. Vmplayer odpala jeden proces i w żaden sposób nie chciał odpalić więcej niż 4 maszyny po 1GB pamięci. A na x86_64 jest odpalone 7 sztuk na 8GB QuadCore, wirtualny cluster i nie ma problemu.

jo, zaloze sie, ze tacy jak Ty pracuja w ZUSie:)

Dobra. Czy jest ktoś w stanie jednoznacznie stwierdzić czy x32 będzie szybszy dla mnie (kodowanie, gdy i reszta standardowo) niż x64?

Przy dużej ilości RAM-u (powiedzmy więcej niż 2GiB) negatywne skutki, opisane w tym wpisie, zwiększenia podstawowych typów nie będą raczej zauważalne, zatem z tego punktu widzenia można bez obaw przechodzić na 64-bity.

Co więcej, w komputerach gdzie RAM-u jest więcej niż 4GiB chyba też już nie warto bawić się w PAE, szczególnie, że Windows tego nie obsługuje.

W zasadzie każdy program skompilowany pod x86_64 będzie przyśpieszał z racji większej liczby rejestrów, ale skoro mówisz o grach to pojawia się pytanie czy będą to gry 64 bitowe czy 32 bitowe, bo jeżeli te drugie to w żadnym stopniu z 64 bitowego systemu nie skorzystają.

Trzeba sobie też zdawać sprawę, iż na szybkość pracy komputera procesor często ma coraz mniejszy wpływ — coraz bardziej istotne są inne podzespoły takie jak np. pamięć i właśnie dlatego odradzam 64 bity w komputerach z małą (jak na obecne czasy) ilością RAM-u.

Reasumując, jako ogólną zasadę przyjmowałbym co następuje: jeżeli masz RAM-u mniej niż 2GiB zostań przy 32 bitach, jeżeli masz RAM-u więcej niż 4GiB przejdź na 64 bity, w pozostałych przypadkach rób co wygodniejsze.

Przede wszystkim co za idiota instaluje 64 bity na systemie z 512 MB RAM?? 64 bitowe systemy powstały aby rozwiązać problem głównie w serwerach gdzie wielkie ilości RAM są normalne.

Co nie oznacza, że na wszystkich innych maszynach wszystko popsują. Samochody combi są zaprojektowane do przewozu większego bagażu, a mimo to jedna osoba też takimi może z powodzeniem jeździć. Większa liczba rejestrów i bardziej rozbudowane instrukcje SIMD dawały pewne nadzieję, że nawet przy 512MiB nie będzie źle — okazało się, że jest tragicznie (w kwestii czego kolega zdaje się zgadzać).

X86_64 przyda się programiście SQLPlusa piszącego w Oracle. Baza danych nawet taka mała – 1 GB potrafi podczas przetwarzania zakleić prawie cały RAM (3,50 GB) a zużycie procesora potrafi wskoczyć na 90%. Nie jestem programistą, ale na moim kompie w pracy (Pentium D, 2 × 3400 GHz, Fedora 10 ×86_64) widziałem wskaźniki podczas przetwarzania na takiej bazie.

W zastosowaniach domowych, nawet podczas przetwarzania grafiki/filmów i innych zasobożernych akcji wysarczy 32-bitowy system. Natomiast w przypadku aplikacji wielowątkowych jakimi są relacyjne bazy danych przestanie nas to zadowalać. Wzrost wydajności może przekroczyć 50%. Tak było w moim przypadku. Zadania na x86_64 średnio były szybsze w zakresie 40-60 %.