Czy programy 64-bitowe są większe i szybsze niż wersje 32-bitowe?

84

Przypuszczam, że skupiam się na x86, ale generalnie interesuje mnie przejście z 32 do 64 bitów.

Logicznie rzecz biorąc, widzę, że stałe i wskaźniki w niektórych przypadkach będą większe, więc programy prawdopodobnie będą większe. A chęć przydzielenia pamięci do granic słów w celu zwiększenia wydajności oznaczałaby więcej odstępów między alokacjami.

Słyszałem również, że tryb 32-bitowy na x86 musi opróżniać swoją pamięć podręczną podczas przełączania kontekstu z powodu możliwego nakładania się przestrzeni adresowych 4G.

Więc jakie są prawdziwe zalety 64-bitowej wersji?

I jako pytanie uzupełniające, czy 128-bitowe byłoby jeszcze lepsze?

Edytować:

Właśnie napisałem mój pierwszy program 32/64 bitowy. Tworzy powiązane listy / drzewa składające się z obiektów 16-bajtowych (wersja 32b) lub 32-bajtowych (wersja 64b) i dużo drukuje na stderr - nie jest to bardzo przydatny program i nie jest to coś typowego, ale jest to mój pierwszy.

Rozmiar: 81128 (32b) v 83672 (64b) - więc nie ma dużej różnicy

Szybkość: 17s (32b) v 24s (64b) - działa na 32-bitowym systemie operacyjnym (OS-X 10.5.8)

Aktualizacja:

Zauważam, że opracowywany jest nowy hybrydowy interfejs binarny x32 (Application Binary Interface), który jest 64b, ale używa wskaźników 32b. W przypadku niektórych testów skutkuje mniejszym kodem i szybszym wykonaniem niż 32b lub 64b.

https://sites.google.com/site/x32abi/

philcolbourn
źródło
1
Wygląda na to, że jest to duplikat stackoverflow.com/questions/324015/ ...
Suma
1
A moje sprzed kilku dni: stackoverflow.com/questions/2334148/…
Mr. Boy
Zgadzam się, że istnieje pewne nakładanie się, ale nie ma jeszcze biorców pamięci podręcznej procesora i 128-bitowych części. Dzięki Sumie i Johnowi za linki.
philcolbourn
„Słyszałem również, że tryb 32-bitowy na x86 musi opróżniać pamięć podręczną podczas przełączania kontekstu z powodu nakładania się przestrzeni adresowych 4G”. Czy możesz wskazać mi odniesienie, które mówi o tym?
gkb0986

Odpowiedzi:

29

O ile nie potrzebujesz dostępu do większej ilości pamięci, na którą pozwala adresowanie 32b, korzyści będą niewielkie, jeśli w ogóle.

Podczas pracy z procesorem 64b otrzymujesz ten sam interfejs pamięci bez względu na to, czy używasz kodu 32b, czy 64b (używasz tej samej pamięci podręcznej i tej samej magistrali).

Chociaż architektura x64 ma kilka więcej rejestrów, co umożliwia łatwiejszą optymalizację, często temu przeciwdziała fakt, że wskaźniki są teraz większe, a użycie jakichkolwiek struktur ze wskaźnikami powoduje większy ruch w pamięci. Szacuję, że wzrost całkowitego zużycia pamięci dla aplikacji 64b w porównaniu do aplikacji 32b wynosi około 15-30%.

Suma
źródło
2
Jakie jest Twoje zdanie na temat proponowanego ABI x32?
philcolbourn
Myślę, że memcpy i strcpy będą szybsze niż 32-bitowy procesor, ponieważ za każdym razem odczytują jedno słowo, ponieważ słowo ma 8 bajtów na 64-bitowym procesorze
Mark Ma
43

Zwykle widzę 30% poprawę szybkości dla kodu wymagającego dużej mocy obliczeniowej na x86-64 w porównaniu do x86. Wynika to najprawdopodobniej z faktu, że mamy 16 x 64-bitowe rejestry ogólnego przeznaczenia i 16 x rejestry SSE zamiast 8 x 32-bitowych rejestrów ogólnego przeznaczenia i 8 x rejestrów SSE. Dzieje się tak z kompilatorem Intel ICC (11.1) na Linuksie x86-64 - wyniki z innymi kompilatorami (np. Gcc) lub z innymi systemami operacyjnymi (np. Windows) mogą oczywiście być inne.

Paul R.
źródło
1
Mówiąc „intensywnie obliczeniowo” masz na myśli grafikę, macierz, DFT?
philcolbourn
4
@phil: tak, głównie przetwarzanie obrazu, głównie liczby całkowite (punkt stały), dużo kodu SIMD itp.
Paul R
Zauważyłem, że kompilatory 64-bitowe używają rejestrów SSE, podczas gdy kompilatory 32-bitowe używają standardowej ALU. To sprawia, że ​​64-bitowy kod jest szybszy dzięki węższej szerokości FP (64 vs 80) oraz dodatkowym instrukcjom.
IamIC
16

Niezależnie od korzyści sugerowałbym, abyś zawsze kompilował swój program dla domyślnego rozmiaru słowa systemu (32-bitowy lub 64-bitowy), ponieważ jeśli kompilujesz bibliotekę jako 32-bitowy plik binarny i udostępniasz ją na 64-bitowym system, zmusisz każdego, kto chce połączyć się z twoją biblioteką, aby udostępnił swoją bibliotekę (i wszelkie inne zależności bibliotek) jako 32-bitowy plik binarny, gdy wersja 64-bitowa jest domyślnie dostępna. Może to być dość uciążliwe dla każdego. W razie wątpliwości podaj obie wersje swojej biblioteki.

Jeśli chodzi o praktyczne zalety 64-bitowego ... najbardziej oczywiste jest to, że dostajesz większą przestrzeń adresową, więc jeśli mmap plik, możesz zaadresować więcej na raz (i załadować większe pliki do pamięci). Inną korzyścią jest to, że zakładając, że kompilator dobrze radzi sobie z optymalizacją, wiele operacji arytmetycznych można zrównoleglać (na przykład umieszczenie dwóch par 32-bitowych liczb w dwóch rejestrach i wykonanie dwóch dodań w operacji pojedynczego dodawania), a duże obliczenia liczbowe będą przebiegać szybciej. To powiedziawszy, cała sprawa 64-bitowa kontra 32-bitowa w ogóle nie pomoże ci w asymptotycznej złożoności, więc jeśli chcesz zoptymalizować swój kod, prawdopodobnie powinieneś patrzeć na algorytmy, a nie na stałe czynniki, takie jak ten.

EDYCJA :
Proszę zignorować moje oświadczenie o równoległym dodawaniu. Nie jest to wykonywane przez zwykłą instrukcję dodawania ... Myliłem to z niektórymi instrukcjami wektoryzowanymi / SSE. Bardziej dokładną korzyścią, oprócz większej przestrzeni adresowej, jest to, że istnieje więcej rejestrów ogólnego przeznaczenia, co oznacza, że ​​w pliku rejestru procesora można przechowywać więcej zmiennych lokalnych, do którego dostęp jest znacznie szybszy niż w przypadku umieszczenia zmiennych w stos programu (co zwykle oznacza wyjście do pamięci podręcznej L1).

Michael Aaron Safyan
źródło
> "na przykład umieszczenie dwóch par 32-bitowych liczb w dwóch rejestrach i wykonanie dwóch dodań w jednej operacji dodawania" Czy jest jakiś kompilator, który to robi? Wydaje się również, że to samo można zrobić na x86 przy użyciu instrukcji SSE.
Suma
Myślenie o takich „dwóch dodaniach w jednym” więcej jest nonsensem i żaden kompilator nie może tego zrobić jako optymalizacji, ponieważ dodanie z niższych 32b mogłoby przelać się na wyższe 32b. Potrzebujesz do tego instrukcji SIMD.
Suma
Myślę, że gdybyś chciał, mógłbyś zrobić wiele 16-bitowych arytmetyki w 64-bitowych rejestrach. Wydawałoby się, że to bałagan, ale założę się, że zostało zrobione.
philcolbourn
„Constant Factors” - brzmi jak coś, co powiedziałby Brian Harvey.
philcolbourn
5

Oprócz posiadania większej liczby rejestrów, 64-bit ma domyślnie SSE2. Oznacza to, że rzeczywiście można równolegle wykonywać pewne obliczenia. Rozszerzenia SSE miały też inne zalety. Ale wydaje mi się, że główną zaletą jest brak konieczności sprawdzania obecności rozszerzeń. Jeśli jest x64, ma dostępne SSE2. ... Jeśli moja pamięć dobrze mi służy.

amokcrow
źródło
4

Koduję silnik szachowy o nazwie foolsmate . Najlepsze wyodrębnienie ruchu przy użyciu wyszukiwania drzewa opartego na minimaksie na głębokość 9 (z określonej pozycji) zajęło:

w Win32konfiguracji: ~ 17.0s;

po przejściu do x64konfiguracji: ~ 10.3s;

To 41% przyspieszenia!

krwawy
źródło
2

Jedynym uzasadnieniem dla przeniesienia aplikacji do wersji 64-bitowej jest potrzeba większej ilości pamięci w aplikacjach, takich jak duże bazy danych lub aplikacje ERP z co najmniej setką jednoczesnych użytkowników, w przypadku których limit 2 GB zostanie przekroczony dość szybko, gdy aplikacje będą buforowane w celu uzyskania lepszej wydajności. Dzieje się tak szczególnie w systemie operacyjnym Windows, w którym liczba całkowita i długość są nadal 32-bitowe (mają nową zmienną _int64. Tylko wskaźniki są 64-bitowe. W rzeczywistości WOW64 jest wysoce zoptymalizowany w systemie Windows x64, dzięki czemu aplikacje 32-bitowe działają z niską karą w 64-bitowym systemie Windows OS. Moje doświadczenie w systemie Windows x64 jest takie, że 32-bitowa wersja aplikacji działa 10-15% szybciej niż 64-bitowa, ponieważ w poprzednim przypadku przynajmniej w przypadku baz danych z zastrzeżoną pamięcią można używać arytmatyki wskaźników do utrzymywania b-drzewa (część systemów baz danych najbardziej obciążająca procesor) . Aplikacje wymagające intensywnych obliczeń, które wymagają dużych miejsc po przecinku w celu uzyskania najwyższej dokładności, której nie zapewnia podwójne w 32-64-bitowym systemie operacyjnym. Te aplikacje mogą używać _int64 w trybie natywnym zamiast emulacji oprogramowania. Oczywiście duże dyskowe bazy danych również wykażą poprawę w stosunku do 32-bitowych, po prostu dzięki możliwości wykorzystania dużej pamięci do buforowania planów zapytań i tak dalej.

GirishK
źródło
Po pierwsze, intpozostaje 32-bitowe wszędzie, niezależnie od rozmiaru słowa środowiska wykonawczego. Który kompilator jest longnadal 32-bitowy podczas kompilacji dla wersji 64-bitowej? Czy twierdzisz, że robi to MSVC? AFAIK, jest to nawet [z grubsza] opisane w standardzie C ++ 11: sizeof(long) == sizeof(void*)Proszę, niech ktoś, popraw mnie, jeśli się mylę, ponieważ nie mam łatwego dostępu do MSVC.
Matthew Hall
3
@Matthew Hall: Jego 64-bitowy standard systemu operacyjnego Windows, a zatem MSVC jest zgodny z tym modelem LLP64 (w porównaniu z LP64 dla wariantów Unix). Patrz ( msdn.microsoft.com/en-us/library/3b2e7499(v=vs.100).aspx ).
GirishK
1

Więcej danych jest przesyłanych między procesorem a pamięcią RAM przy każdym pobieraniu pamięci (64 bity zamiast 32), więc programy 64-bitowe mogą być szybsze, pod warunkiem, że zostaną zapisane, aby właściwie to wykorzystały.

Rune Aamodt
źródło
11
W rzeczywistości tak nie jest: szyna pamięci ma dowolną szerokość, która nie ma nic wspólnego z szerokością rejestrów procesora. Niektóre systemy 32-bitowe pobierają 128 bitów na raz, istnieją systemy 64-bitowe, które pobierają dane z 32 na raz, a nawet systemy 32-bitowe, które pobierają pamięć nie więcej niż 8 bitów na raz.
Andrew McGregor
OK, nie byłem tego świadomy - nadal, czy nie jest prawdą, że pojedyncza instrukcja mov przesyła 64 bity na 64-bitowym procesorze i 32 bity na 32-bitowym procesorze? Zatem podczas kopiowania dużej ilości pamięci z punktu A do punktu B oznaczałoby to przynajmniej konieczność wykonania mniejszej liczby instrukcji mov na 64-bitowym procesorze (nawet jeśli szyna pamięci jest wąskim gardłem)?
Rune Aamodt
2
Przenosząc dużą ilość pamięci, użyjesz 128b instrukcji SIMD zarówno na x86, jak i x64.
Suma
Czym dokładnie są „systemy 64-bitowe, które pobierają 32 na raz”? Wymień kilka. Jeśli tak, to czy naprawdę są to „systemy 64-bitowe”?
Johnny
1

W konkretnym przypadku od x68 do x68_64, program 64-bitowy będzie miał mniej więcej ten sam rozmiar, jeśli nie nieco mniejszy, zużyje trochę więcej pamięci i będzie działał szybciej. Dzieje się tak głównie dlatego, że x86_64 ma nie tylko 64-bitowe rejestry, ale także dwa razy więcej. x86 nie ma wystarczającej liczby rejestrów, aby skompilowane języki były tak wydajne, jak mogłyby być, więc kod x86 zużywa wiele instrukcji i przepustowość pamięci, przenosząc dane między rejestrami i pamięcią. x86_64 ma go znacznie mniej, więc zajmuje trochę mniej miejsca i działa szybciej. Instrukcje dla wektorów zmiennoprzecinkowych i bitowych kręcenia bitów są również znacznie wydajniejsze w x86_64.

Ogólnie rzecz biorąc, 64-bitowy kod niekoniecznie jest szybszy i zwykle jest większy, zarówno w przypadku użycia kodu, jak i pamięci w czasie wykonywania.

Andrew McGregor
źródło
2
Nie do końca rozumiem, o co ci chodzi. Początkowo (pierwsze zdanie) mówisz, że programy 64-bitowe będą generalnie działać szybciej, ale potem twoje ostatnie zdanie wydaje się cofać wszystko, co mówi „nie bardzo”
SN
1

Wszelkie aplikacje wymagające użycia procesora, takie jak transkodowanie, wydajność wyświetlania i renderowanie multimediów, niezależnie od tego, czy są to audio, czy wizualne, z pewnością będą wymagały (w tym momencie) i skorzystają na używaniu 64-bitowego w porównaniu z 32-bitowym ze względu na zdolność procesora do radzenia sobie z samą ilość danych, które są do niego rzucane. Nie tyle jest to kwestia przestrzeni adresowej, ile sposobu przetwarzania danych. 64-bitowy procesor, z 64-bitowym kodem, będzie działał lepiej, szczególnie w przypadku trudnych matematycznie rzeczy, takich jak transkodowanie i dane VoIP - w rzeczywistości wszelkie aplikacje matematyczne powinny korzystać z 64-bitowych procesorów i systemów operacyjnych. Udowodnij, że się mylę.

Dave Vanian
źródło
Nie. Nie będzie. Jeśli zapotrzebowanie na pamięć RAM przekracza 4 GB, tylko będzie szybsze. Możesz łatwo przeszukiwać tablicę liczb całkowitych 1000Millions w mniej niż 4 GB danych w 32-bitowej architekturze. Tak więc użycie 64-bitowej maszyny spowolni
sapy