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

Zazwyczaj widzę 30% poprawę prędkości dla kodu intensywnie obliczeniowego 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. Tak jest w przypadku kompilatora Intel ICC (11.1) na Linuksie x86-64-wyniki z innymi kompilatorami (np. gcc) lub z innymi systemami operacyjnymi (np. Windows), mogą być oczywiście inne.

Niezależnie od korzyści, sugerowałbym, abyś zawsze kompilował swój program dla domyślnego rozmiaru słowa systemu (32-bit lub 64-bit), ponieważ jeśli skompilujesz bibliotekę jako 32-bitową binarną i dostarczysz ją na 64-bitowym systemie, 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-bitową binarną, gdy Wersja 64-bitowa jest domyślną dostępną. To może być dość uciążliwe dla wszystkich. W razie wątpliwości należy podać zarówno wersje twojej Biblioteki.

Co do praktycznych zalet 64-bitowych... najbardziej oczywiste jest to, że masz większą przestrzeń adresową, więc jeśli mmap plik, można adresować więcej go na raz (i załadować większe pliki do pamięci). Inną korzyścią jest to, że zakładając, że kompilator wykonuje dobrą robotę optymalizacji, wiele operacji arytmetycznych może być równoległych (na przykład umieszczenie dwóch par 32-bitowych liczb w dwóch rejestrach i wykonywanie dwóch dodań w operacji pojedynczego dodawania), a duża liczba obliczenia przebiegną szybciej. To powiedziawszy, całe 64-bitowe vs 32-bitowe coś nie pomoże Ci w asymptotycznej złożoności w ogóle, więc jeśli chcesz zoptymalizować swój kod, powinieneś prawdopodobnie patrzeć na algorytmy, a nie na stałe czynniki takie jak ten.

EDIT :
Proszę pominąć moją wypowiedź o równoległym dodaniu. Nie jest to wykonywane przez zwykłe polecenie add... Pomyliłem to z niektórymi wektoryzowanymi instrukcjami/SSE. A more dokładną korzyścią, poza większą przestrzenią adresową, jest to, że istnieją bardziej uniwersalne rejestry, co oznacza, że więcej zmiennych lokalnych może być utrzymywanych w pliku rejestru CPU, do którego dostęp jest znacznie szybszy niż w przypadku umieszczenia zmiennych w stosie programu (co zwykle oznacza wyjście do pamięci podręcznej L1).

Oprócz większej liczby rejestrów, 64-bit posiada domyślnie SSE2. Oznacza to, że niektóre obliczenia można wykonywać równolegle. Rozszerzenia SSE miały też inne gadżety. Ale myślę, że główną korzyścią jest brak konieczności sprawdzania obecności rozszerzeń. Jeśli jest to x64, ma Dostępny SSE2. ...Jeśli dobrze pamiętam.

W konkretnym przypadku x68 do x68_64, 64-bitowy program będzie mniej więcej tego samego rozmiaru, jeśli nie nieco mniejszy, będzie zużywał nieco więcej pamięci i działał szybciej. Głównie dlatego, że x86_64 nie tylko ma 64-bitowe rejestry, ale także ma dwa razy więcej. x86 nie ma wystarczającej ilości rejestrów, aby skompilowane języki były tak wydajne, jak to tylko możliwe, więc kod x86 spędza dużo instrukcji i przepustowości PAMIĘCI przenosząc dane tam i z powrotem między rejestrami i pamięcią. x86_64 ma tego znacznie mniej, i tak zajmuje trochę mniej miejsca i działa szybciej. Instrukcje zmiennoprzecinkowe i wektorowe są również znacznie wydajniejsze w x86_64.

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

Jedynym uzasadnieniem dla przeniesienia aplikacji do 64-bitowej jest potrzeba większej pamięci w aplikacjach, takich jak duże bazy danych lub aplikacje ERP z co najmniej 100 jednoczesnych użytkowników, gdzie limit 2 GB zostanie dość szybko przekroczony, gdy aplikacje buforują się dla lepszej wydajności. Dzieje się tak szczególnie w przypadku systemu operacyjnego Windows, gdzie integer I long 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 działają aplikacje 32-bitowe z niską karą na 64-bitowym systemie operacyjnym Windows. Moje doświadczenie na Windows x64 to 32-bitowa wersja aplikacji uruchamiana 10-15% szybciej niż 64-bitowa, ponieważ w poprzednim przypadku przynajmniej dla zastrzeżonych baz danych pamięci można użyć pointer arithmatic do utrzymania b-tree (najbardziej intensywnej procesorowo części systemów bazodanowych). Intensywne aplikacje kompuatacyjne, które wymagają dużych dziesiętnych dla najwyższej dokładności, której nie zapewnia podwójne na 32-64-bitowym systemie operacyjnym. Te aplikacje mogą używać _int64 w sposób natywny zamiast emulacja oprogramowania. Oczywiście duże bazy danych oparte na dyskach również wykazują poprawę w stosunku do 32-bitowych po prostu ze względu na możliwość korzystania z dużej pamięci do buforowania planów zapytań i tak dalej.

Więcej danych jest przesyłanych pomiędzy procesorem i pamięcią RAM dla każdego pobierania pamięci (64 bity zamiast 32), więc programy 64-bitowe mogą być szybsze, pod warunkiem, że są napisane tak, aby prawidłowo z tego skorzystały.

Wszelkie aplikacje, które wymagają użycia procesora, takie jak transkodowanie, wydajność wyświetlania i renderowanie multimediów, czy to audio czy wizualne, z pewnością będą wymagać (w tym momencie) i korzystać z używania 64 bitów w porównaniu z 32 bitami ze względu na zdolność procesora do radzenia sobie z ogromną ilością danych wyrzucanych na niego. To nie tyle kwestia przestrzeni adresowej, co sposobu postępowania z danymi. 64-bitowy procesor, biorąc pod uwagę kod 64-bitowy, będzie działał lepiej, zwłaszcza z matematycznie trudne rzeczy, takie jak transkodowanie i dane VoIP - w rzeczywistości wszelkiego rodzaju aplikacje "matematyczne" powinny korzystać z 64-bitowych procesorów i systemów operacyjnych. Udowodnij, że się mylę.