Czy istnieje dobry powód, aby uruchamiać oprogramowanie 32-bitowe zamiast 64-bitowych na komputerach 64-bitowych?

56

Czy jest jakiś dobry powód, aby dostarczyć wersję 32-bitową wraz z 64-bitową wersją jakiegokolwiek oprogramowania skierowanego do nowoczesnych komputerów stacjonarnych, na których działają 64-bitowe systemy operacyjne na 64-bitowym sprzęcie?

Wygląda na to, że 64-bitowe oprogramowanie byłoby bardziej wydajne, w razie potrzeby pozwalałoby na większe wykorzystanie pamięci itp. Apple nawet używa 64-bitowych procesorów do swoich telefonów, mimo że mają tylko 1-2 GB pamięci RAM, znacznie poniżej 4 GB limit 32-bitowych procesorów.

hardware 64-bit 32-bit Filip Haglund
źródło
16
Nie każda nowoczesna maszyna ma 64-bitowy system operacyjny
Bálint
4
Czy masz jakieś przykłady?
Filip Haglund,
8
Zapytaj swoich klientów.
Murphy
22
Pytanie retoryczne: czy istnieje powód, aby dostarczyć 64-bitową wersję dowolnego oprogramowania, ponieważ większość współczesnych 64-bitowych systemów operacyjnych pozwala również na uruchamianie aplikacji 32-bitowych i 64-bitowych?
Dok. Brown
2
Nie duplikat @gnat. To pytanie dotyczy dopasowania znacznika czasu, a identyfikator programisty w kodzie błędu zwracany po wyjściu programu.
Filip Haglund

Odpowiedzi:

80

Korzyści z 32-bitowego oprogramowania w środowiskach 64-bitowych

  • Niższe zużycie pamięci, szczególnie w aplikacjach z dużym wskaźnikiem, 64-bitowy w porównaniu z 32-bitowym może łatwo podwoić wymagania dotyczące pamięci.
  • Pliki obiektowe są również mniejsze.
  • Kompatybilność ze środowiskami 32-bitowymi.
  • Wycieki pamięci są ograniczone do 2 GB, 3 GB lub 4 GB i nie zajmą całego systemu.

Wady 32-bitowego oprogramowania w środowiskach 64-bitowych

  • Limit pamięci 2 GB, 3 GB lub 4 GB na proces. (Tylko na proces, w sumie wiele 32-bitowych procesów może korzystać z pełnej dostępnej pamięci systemowej).
  • Nieużywanie dodatkowych rejestrów i rozszerzeń zestawu instrukcji w zależności od x64. Jest to wysoce specyficzne dla kompilatora i procesora.
  • Może wymagać 32-bitowych wersji wszystkich (większość dystrybucji Linuksa) lub nietypowych (większość wersji Windows) bibliotek i środowisk wykonawczych. Jeśli 32-bitowa wersja biblioteki współużytkowanej jest ładowana wyłącznie dla Twojej aplikacji, a to liczy się dla twojego śladu. Nie ma żadnej różnicy, jeśli łączysz się statycznie.

Inne aspekty

  • Sterowniki zwykle nie stanowią problemu. Tylko biblioteki przestrzeni użytkownika powinny różnić się między wersją 32-bitową a 64-bitową, a nie API modułów jądra.
  • Uwaga na różne domyślne szerokości dla typów danych liczb całkowitych, konieczne są dodatkowe testy.
  • 64-bitowa architektura procesora może nawet nie obsługiwać 32-bitowej.
  • Niektóre techniki, takie jak ASLR i inne, w zależności od znacznie większej przestrzeni adresowej niż pamięć fizyczna, nie będą działać dobrze (lub wcale) w 32-bitowym trybie wykonywania.

O ile nie porównam tutaj bardzo specyficznej architektury procesora, systemu operacyjnego i infrastruktury bibliotecznej, nie będę mógł wdawać się w więcej szczegółów.

Ext3h
źródło
8
„64-bitowa architektura procesora może nawet nie obsługiwać 32-bitowego”. Czy jest to bardziej kwestia teoretyczna, czy istnieje na świecie?
mucaho
10
@mucaho Na pewno były 64-bitowe architektury CPU tylko, takich jak Alpha i IA64. Oba są jednak konające. Nie wiem od samego początku, czy są jakieś obecnie produkowane architektury 64-bitowe - może AArch64? Czy ktoś wie, czy 32-bitowy ARM jest obowiązkowym składnikiem tego?
zwol
10
@zwol Nie, wersja 32-bitowa nie jest obowiązkowa dla ARM, podobnie jak wersja 64-bitowa. Istnieją tylko 64-bitowe procesory ARM, podczas gdy inne obsługują zarówno procesy 32-bitowe, jak i 64-bitowe.
Ext3h
3
Dodatkową zaletą jest wybranie jednej architektury i trzymanie się jej: prostsze tworzenie i testowanie.
jl6
7
@Joshua Zawsze istniał? Czy faraonowie to wiedzieli?
candied_orange 15.04.16
7

Różnica między oprogramowaniem 32-bitowym a oprogramowaniem 64-bitowym polega na wielkości wskaźników, a być może na wielkości rejestrów liczb całkowitych. Otóż ​​to.

Oznacza to, że wszystkie wskaźniki w twoim programie są dwa razy większe. I (przynajmniej w architekturze ILP32 / LP64) twoje longsą również dwa razy większe. Zwykle osiąga to około 30% wzrost rozmiaru kodu obiektu. To znaczy że …

  • Twój kod obiektu zajmie ~ 30% dłużej, aby załadować z dysku do pamięci RAM
  • twój kod obiektowy zajmie ~ 30% więcej miejsca w pamięci
  • skutecznie zmniejszyłeś przepustowość pamięci (dla kodu obiektowego) o ~ 20%
  • skutecznie zmniejszyłeś rozmiar pamięci podręcznej instrukcji o ~ 20%

Ma to istotny wpływ na wydajność.

Takie postępowanie ma sens tylko wtedy, gdy można „odkupić” te koszty wydajności. Zasadniczo istnieją dwa sposoby, aby to zrobić: wykonujesz wiele 64-bitowych operacji na liczbach całkowitych lub potrzebujesz więcej niż 4 zmapowanej pamięci GiByte. Jeśli jedno lub oba z nich są prawdziwe, warto zastosować oprogramowanie 64-bitowe, w przeciwnym razie nie.

Uwaga: istnieje kilka architektur, w których nie ma odpowiednich wariantów 32- lub 64-bitowych. W takim przypadku pytanie oczywiście nie ma sensu. Najbardziej znane to IA64, który jest tylko 64-bitowy i nie ma wariantu 32-bitowego, oraz x86 / AMD64, które są, choć ściśle powiązane, różne architektury, x86 jest tylko 32-bitowy, a AMD64 jest tylko 64-bitowy.

W rzeczywistości to ostatnie stwierdzenie nie jest już w 100% prawdziwe. Linux ostatnio dodał x32 ABI, który pozwala na uruchamianie kodu AMD64 z 32-bitowymi wskaźnikami, więc nawet jeśli nie jest to „właściwa” architektura procesora, jest to sposób użycia architektury AMD64 w taki sposób, jakby miał natywny Wariant 32-bitowy. Zrobiono to właśnie dlatego napowietrznej wydajność wspomniałem powyżej powodując realne mierzalne, policzalne problemy dla użytkowników pracujących w świecie rzeczywistym świecie rzeczywistym kodu w systemach rzeczywistych.

Jörg W Mittag
źródło
8
Co z dodatkowymi rejestrami i instrukcjami w amd64 w porównaniu do x86? Jak bardzo to poprawia wydajność?
Filip Haglund,
2
Google dla „otagowanych wskaźników” używanych w Objective-C na MacOS X i iOS. Bardzo znaczne ilości obiektów nie mają żadnej przydzielonej pamięci, ale cały obiekt jest sfałszowany wewnątrz wskaźnika w systemach 64-bitowych. (Słyszałem, że Java robi coś podobnego). W języku C ++ std :: string w wersji 64-bitowej często zawiera do 22 znaków w samym obiekcie bez alokacji pamięci. Znaczne oszczędności pamięci i zwiększenie prędkości.
gnasher729 15.04.16
3
Rozmiar wskaźników i liczb całkowitych, prawda? Co z większą przestrzenią adresową i dodatkowymi rejestrami w większości architektur 64-bitowych?
1
„zmniejszyłeś pamięć podręczną instrukcji o ~ 20%” jest dyskusyjny, ponieważ zestaw instrukcji jest zupełnie inny (i często bardziej wydajny)
BlueRaja - Danny Pflughoeft 15.04.2016
3
„Ma to istotny wpływ na wydajność”. Chociaż to stwierdzenie jest prawdziwe w sensie absolutnym, ignoruje fakt, że znaczna większość wąskich gardeł w wydajności aplikacji nie jest obciążona czasem ładowania, wykorzystaniem pamięci / przepustowości lub liczbą instrukcji w pamięci podręcznej.
Ian Kemp,
6

Jeśli oprogramowanie musi łączyć się bezpośrednio ze starszymi systemami, sterownikami lub bibliotekami, może być konieczne dostarczenie wersji 32-bitowej, ponieważ AFAIK ogólnie system operacyjny (zdecydowanie Windows i Linux AFAIK) nie pozwala na mieszanie 64-bitowych i 32-bitowych -bitowy kod w procesie.

Na przykład, jeśli twoje oprogramowanie potrzebuje dostępu do specjalistycznego sprzętu, klienci często korzystają ze starszych modeli, dla których dostępne są tylko sterowniki 32-bitowe.

W pobliżu

Michael Borgwardt
źródło
2
Ty może mieszać 32 bit i 64 bit w tym samym procesie w systemach Windows i Linux: stackoverflow.com/q/12716419/703382
Navin
1
@Navin: Ale czy to praktyczne? Czy można użyć komponentu COM w 64-bitowej aplikacji Windows (np. Aplikacji .NET oznaczonej jako Dowolny procesor działający na 64-bitowej wersji systemu Windows)?
Peter Mortensen
3

Jeśli twoje oprogramowanie jest biblioteką DLL, MUSISZ podać wersje 32-bitową i 64-bitową. Nie masz pojęcia, czy klient będzie używał oprogramowania 32-bitowego, czy 64-bitowego do komunikowania się z biblioteką DLL, a biblioteka DLL musi używać tej samej długości bitów co aplikacja. To nie podlega negocjacji.

Jeśli twoje oprogramowanie jest samodzielnym plikiem wykonywalnym, jest mniej jasne. Jeśli nie potrzebujesz, aby twoje oprogramowanie działało na starszych systemach operacyjnych, może nie być konieczne zapewnienie wersji 32-bitowej. Po prostu trzymaj się wersji 64-bitowej, określ, że wymaga 64-bitowego systemu operacyjnego i wykonanej pracy.

Jeśli jednak potrzebujesz oprogramowania do działania na starszych systemach operacyjnych, być może NIE będziesz chciał udostępniać wersji 64-bitowej. Jeśli masz dwie wersje, to dwukrotnie testujesz, a prawidłowe testowanie oprogramowania w różnych wersjach systemu operacyjnego i językach nie jest szybkim procesem. Ponieważ oprogramowanie 32-bitowe działa idealnie na platformie 64-bitowej, nadal dość powszechne jest, że oprogramowanie jest wydawane tylko w wersji 32-bitowej, szczególnie przez mniejszych programistów.

Należy również pamiętać, że większość telefonów komórkowych jest 32-bitowa. Być może niektóre high-endowe są teraz 64-bitowe, ale nie ma istotnego powodu, aby zrobić ten krok. Jeśli więc pracujesz na różnych platformach i chcesz, aby Twój kod działał również na Androidzie, pozostanie w wersji 32-bitowej jest bezpieczną opcją.

Graham
źródło
Argumentowałbym przeciwko twojemu stanowisku w sprawie ograniczonych testów. Zamiast tego argumentowałbym na testowanie na wielu platformach, zwłaszcza z nie tylko różnymi rozmiarami rejestrów, ale z różnymi kolejnością bajtów, jako prosty sposób na zwiększenie testowania i wyłapanie subtelnych błędów. Ponadto wykonałbym również testy na komputerach, które nie spełniają zalecanych minimalnych wymagań sprzętowych, ponieważ ujawni to również dodatkowe problemy, które mogą się nie pojawić, z wyjątkiem bardzo dużych zestawów danych.
hildred
@hildred Zgadzam się z nieograniczonymi zasobami testowymi. W praktyce jednak, jeśli masz większą kontrolę nad swoim celem, może nie być konieczne natychmiastowe wykonanie tego testu. To wcale nie jest „łatwy sposób” - na pewno możesz symulować niektóre z tych platform na maszynie wirtualnej, ale jeśli potrzebujesz fizycznej konfiguracji sprzętu, wiąże się to z dużą ilością ręcznej (nieautomatycznej) pracy. Może cię to uratować przed napisaniem testowej uprzęży, aby to dokładnie przetestować, ale w żadnym wypadku nie jest darmowe.
Graham
1
Nie za darmo, ale wręcz tanio. Jeśli ograniczysz testowanie poza platformą do testów automatycznych, okazjonalny test idioty, używany sprzęt Poza konfiguracją koszty udanych testów po wstępnej konfiguracji będą ograniczone do mocy i około 7 osobodni na test. Koszt nieudanych testów byłby oczywiście wyższy, ale zwykle byłyby one warte więcej (zawsze występuje awaria sprzętu). Ten typ konfiguracji jest szczególnie użyteczny dla programistów c, ponieważ łatwo ujawnia pewną klasę problemów ze wskaźnikami, które w innym przypadku byłyby trudne do wyśledzenia.
Hildred