Raspbian przechodzi do trybu 64-bitowego

Na tej stronie oficjalne ogłoszenie RPi3 stwierdza:

Będziesz potrzebować najnowszego obrazu NOOBS lub Raspbian z naszej strony pobierania. Podczas uruchamiania korzystamy z tej samej 32-bitowej przestrzeni użytkownika Raspbian, której używamy na innych urządzeniach Raspberry Pi; w ciągu najbliższych kilku miesięcy sprawdzimy, czy przejście na tryb 64-bitowy ma wartość.

Moje pytanie brzmi: biorąc pod uwagę, że procesor ma 64 bity, czy nie jest oczywiste, że działanie systemu operacyjnego na 64 bity będzie lepsze pod każdym względem? czego mi brakuje?

biorąc pod uwagę, że procesor ma 64 bity, czy nie jest oczywiste, że uruchomienie systemu operacyjnego na 64 bity będzie lepsze pod każdym względem?

Nie, właściwie to nie jest. Pod pewnymi względami uruchomienie 64-bitowego systemu operacyjnego może pogorszyć wydajność Raspberry Pi.

Korzyści z wersji 64-bitowej :

Dwie podstawowe zalety korzystania z 64-bitowego procesora / systemu operacyjnego polegają na tym, że urządzenie może obsłużyć ponad 4 GB pamięci RAM i natywnie obsługiwać liczby całkowite większe niż 2^32bez potrzeby korzystania z biblioteki bignum.

Raspberry Pi nie ma więcej niż 4 GB pamięci RAM. Przy 1 GB pamięci RAM całkowicie straciłeś pierwszą z dwóch głównych korzyści. Jeśli chodzi o drugą korzyść, jaki procent ludzi faktycznie używa wystarczającej liczby gigantów, aby fundacja obsługiwała cały drugi system operacyjny? Jak na razie RPi może wykorzystywać ogromne liczby za pomocą metod programowych, ale wydaje się, że jeśli zamierzasz być konsekwentnie w tej sferze, musisz i tak używać lepszego sprzętu.

Problemy z 64-bitową wersją :

Magia nie zapewnia zdolności do przechowywania większej liczby. Zamiast tego należy zwiększyć rozmiar obiektów pamięci. W C (i C ++) oznacza to zmianę intna int64_t. Nie dzieje się to automatycznie, stąd komentarze na temat fundacji, która nie chce utrzymywać dwóch gałęzi.

Ponadto wiele aplikacji po prostu nie zapewnia korzyści (dla większości użytkowników) w trybie 64-bitowym. Zauważ, że większość przeglądarek internetowych, MS Office i całe mnóstwo innych popularnych programów jest nadal wysyłana i obsługiwana w 32-bitowy sposób. Pewnie, że możesz dostać 64-bitową wersję MS Office, ale jest ona rzadko używana.

Jeśli aplikacja / system operacyjny został napisany w celu wykorzystania architektury 64-bitowej, aplikacja będzie zużywać więcej pamięci, po prostu dlatego, że zmienne i wskaźniki zajmują więcej miejsca. Zwykle jest to stosunkowo niewielki kompromis dla maszyn, które skorzystają z profitów. W naszym przypadku mamy bardzo niewiele korzyści i bardzo mało pamięci RAM.

Uwaga :

To, że działasz na komputerze 64-bitowym, nie oznacza, że ​​aplikacja nie działa w wersji 32-bitowej. System Windows wyraźnie to wyjaśnia, mając dwie różne ścieżki instalacji C:\Program Filesoraz C:\Program Files (x86).

Czy więc podstawa prawdopodobnie zapewni wsparcie 64-bitowe? :

Wracamy w tym samym momencie: „Niektórzy ludzie mogą widzieć korzyści, ale większość nie.”. Na pewno zobaczysz inne projekty oferujące wersje 64-bitowe, ale jeśli fundacja nie otrzyma dużo niezasłużonego (imo) flacka, prawdopodobnie nie zrobi tego i nie powinna (imo). Tworzenie i utrzymywanie oddzielnego 64-bitowego oddziału nie jest małym przedsięwzięciem i szczerze mówiąc, po prostu nie wydaje się tego warte.

Warto zauważyć, że sytuacja jest inna w przypadku ARM i Intel / AMD. To dlatego, że przejście na x86_64 zostało również wykorzystane jako okazja do zaktualizowania źle starzejącej się architektury, zasadniczo sparaliżowanej jedynie przez 8 rejestrów ogólnego przeznaczenia - i podwojonej w trybie 64-bitowym. Tak więc przełączenie systemu Intel / AMD na tryb 64-bitowy oznacza również włączenie rzeczywistych funkcji, które znacząco wpływają na wydajność.

ARM nie ma na początku tego problemu (chociaż AArch64 dodaje rejestry, 32-bitowe architektury nie były dla nich głodne), więc korzyściami są w zasadzie bardziej adresowalna pamięć i natywna obsługa dużych liczb całkowitych - o wiele mniej umowa, a być może przeciwdziałać jej wadą (więcej pamięci wykorzystuje się na wszystko).

(Nawiasem mówiąc, z tego powodu było trochę pracy nad stworzeniem abi „x32” dla Intel / AMD Linux , utrzymując ulepszenia procesora, ale używając 32-bitowych wskaźników.)

Jestem pewien, że są już ludzie z Debian Aarch64 (ARMv8) na Pi 3; dla wielu osób z pewnością nie byłoby to takie trudne ( zobacz tutaj kilka wskazówek na ten temat, które mogą zadziałać) ^1, chociaż dla większości użytkowników jest to prawdopodobnie trochę skomplikowane.

Jeśli jednak Raspbian i / lub Fundacja nie wyjdą z wersją 64-bitową, coraz częściej będziesz widzieć ludzi z blogami itp., Którzy wyjaśniają, jak je uruchomić i nadal otrzymywać potrzebne produkty.

Jest teraz wydanie Fedory aarch64 dla Pi 3.

^{1. Będą pewne komplikacje związane z 32-bitowymi /opt/vcrzeczami, nie jestem pewien, jak to jest do pokonania; kiedyś istniały 32-bitowe biblioteki kompatybilności dla x86-64, ale Aarch64 ... może nie.}

W ramach reklamy związanej z uruchomieniem zauważyłem, że jedną z obaw jest wysiłek związany z utrzymaniem dwóch oddzielnych baz kodu (32- i 64-bitowego). Film z Adafruit PI3 Launch wspomniał również, że przejście na procesor 64-bitowy dotyczyło raczej zwiększenia szybkości zegara nowego dostarczonego układu, niż używania trybu 64-bitowego.

Adresowanie 64-bitowe może być przydatne, nawet jeśli nie masz więcej niż 1 GB pamięci.

Pozwala na mapowanie pamięci dużych plików, dzięki czemu masz wskaźnik i pozwala systemowi operacyjnemu we / wy transparentnie wykonywać operacje we / wy. Po prostu inny sposób wykonywania operacji we / wy. Aby to zrobić w przypadku dużych plików, potrzebujesz adresowania 64-bitowego.

Innym przykładem, w którym moim zdaniem może być przydatne, jest zezwolenie, aby procesy miały więcej niż 2 GB przestrzeni adresowej, używając przestrzeni wymiany. Ostatnio miałem problem z 32-bitowym NAS z dużą ilością miejsca i uszkodzonym systemem plików. Procesowi fsck zabrakło pamięci, nawet po włączeniu opcji buforowania. Dodanie przestrzeni wymiany nie mogło rozwiązać problemu, 32-bitowa przestrzeń adresowa była tam twardym ograniczeniem. Tak więc nie było sposobu, aby uruchomić fsck na tym dużym, uszkodzonym systemie plików z 32-bitowym plikiem binarnym. Przy 64-bitowym pliku binarnym i pewnej przestrzeni wymiany, działałoby.

Odnosząc się do twierdzenia, że ​​64-bitowe programy macierzyste są większe (więcej pamięci na dane i wskaźniki) oraz że nie ma zauważalnych korzyści dla 64-bitowego systemu operacyjnego na ARMv8 z mniej niż 4 GB pamięci RAM, chciałbym podnieść kilka zwrotnica.

Istnieją pewne znaczące różnice w sposobie działania w architekturze ARMv7 (i wcześniejszych) i ARMv8, które zwiększają wydajność wykonywania ARMv8. Niektóre z nich pochodzą z szerszych wewnętrznych ścieżek danych, inne to eliminacja szczególnych przypadków i znacznie głębszy potok). Te same zmiany sprawiają, że ARMv8 lepiej działa z kodem ARMv7 (32 bity).

Natywne 64-bitowe aplikacje używają 64-bitowych wskaźników, a 'size_t' ma 64 bity, więc elementy, które je wykorzystują, stają się większe. Pozostała część danych będzie miała ten sam rozmiar. Znaczenie tego jest jednak niewielkie w stosunku do wielkości plików wykonywalnych.

Tam, gdzie naprawdę świeci 64-bitowy natywny (jeśli nie obchodzi Cię duża liczba całkowita i liczba zmiennoprzecinkowa), ma większą wirtualną przestrzeń adresową:

• System operacyjny jest w stanie podzielić wirtualną przestrzeń adresową na coraz większe sekcje, umożliwiając łatwiejsze zarządzanie zasobami współdzielonymi, usprawnione przełączanie kontekstu między różnymi poziomami uprawnień i tak dalej.
• Jeśli włączyłeś zamianę, możesz uruchamiać coraz więcej procesów, przekraczając limity pamięci fizycznej (jest to prawdą również w 32 bitach, ale masz mniej ograniczeń w 64 bitach)

Niezależnie od tego, czy system operacyjny korzysta z tego, czy nie, robi to różnicę, ponieważ główny nurt odchodzi od wersji 32-bitowej.

Myślę, że najlepszym argumentem przemawiającym za przejściem do natywnego 64-bitowego jądra AArch64 jest przenośność: główny pulpit został przeniesiony głównie do 64-bitowych procesorów, i widzę więcej pakietów, które zakładają 64 bity, a przeniesienie takiego kodu z powrotem do 32 bitów jest trudniejsze niż portowanie od 32 do 64 bitów. W przestrzeni użytkownika możesz uruchamiać 32-bitowe aplikacje i aplikacje 64-bitowe obok siebie, zakładając, że zainstalowałeś biblioteki wieloskalowe, więc nie jest wymagane portowanie od 32 do 64 bitów tam, gdzie nie materia. 64-bitowy system operacyjny zapewni po prostu większy wybór oprogramowania.

Nie twierdzę, że tworzenie 64-bitowego jądra dla Raspberry PI 3 jest łatwe - istnieją znaczne różnice, które wymagają zmian na niskim poziomie, nie wszystkie sterowniki urządzeń są 64-bitowe czyste (szczególnie sterowniki dla GPU specyficznych dla ARM). Możliwe, że Raspberian pozostanie 32-bitowym systemem operacyjnym, ale wierzę, że (w długim zasięgu) jest krótkowzroczny.

Jeden nośnik rozruchowy (na przykład karta SD) może zawierać zarówno 64-bitową, jak i 32-bitową wersję systemu operacyjnego, a dodatkowe oprogramowanie rozruchowe (u-boot, arm-boot i inne) może określić, który z nich załadować. Najtrudniejszą częścią jest obszar użytkownika - system plików musiałby być wieloskalowy, nawet w systemach 32-bitowych, w których 64-bitowe pliki będą bezużyteczne. Rozwiązałbym to za pomocą skryptu lub narzędzia, które można uruchomić po pierwszym uruchomieniu, aby usunąć niepotrzebne biblioteki i pliki wykonywalne programów w systemach tylko 32-bitowych.

Istniejące odpowiedzi bardzo dobrze opisują problemy z 64-bitowym łukiem, ale nie widzę wielu deklarowanych zalet aktualizacji. Oto dwa, które niedawno odkryłem:

• Gdy PHP obsługuje uniksowe znaczniki czasu, rozmiar liczby całkowitej w 32-bitowym łuku ustawia górny limit dat, tak że nie mogą one przekroczyć określonego dnia w 2038 r . Oczekuję, że jest to problem dotyczący wszystkich języków, które obsługują znaczniki czasu. (Na szczęście większość podsystemów obsługujących datę, które nie używają uniksowych znaczników czasu, takich jak PHP DateTime, zostały zaprojektowane specjalnie, aby nie były ograniczone tym problemem nawet na starszych procesorach).

• Mongo jest ograniczone do baz danych o rozmiarze poniżej 2G na tym łuku, a wersje 32-bitowe wkrótce będą przestarzałe. Z instrukcji :

  Począwszy od wersji MongoDB 3.2, 32-bitowe pliki binarne są przestarzałe i będą niedostępne w przyszłych wersjach.

  Chociaż wersje 32-bitowe istnieją dla systemów Linux i Windows, nie nadają się do wdrożeń produkcyjnych. Wersje 32-bitowe również nie obsługują silnika pamięci WiredTiger.

Moje przemyślenia na ten temat: chociaż nie wiem dokładnie, w jaki sposób procesor ARM adresuje pamięć, mogę powiedzieć o tym z poprzednich wielu architektur procesora, które zaprogramowałem (SPARC / Alpha / i386 / AMD64 / X86_64): podczas korzystania z pamięci współdzielonej i adresowania dzięki „rzeczywistemu” wirtualnemu wskaźnikowi adresu przejście do wersji 64-bitowej nie jest trywialne. Chociaż memcpy robi to, co powinien, należy wziąć pod uwagę, że w 64 bitach dane są przechowywane w ten sposób (bit do tyłu):

HGFEDCBA
HGFEDCBA
HGFEDCBA

ale w 32 bitach wygląda to tak:

ABCD
ABCD
ABCD

Tak więc, w 32 bitach, kiedy przechowujesz powiedzmy jpeg w pamięci RAM, możesz odczytać jego bajty nagłówka lub wykonać wykrywanie krawędzi bez żadnego problemu w sposób liniowy * powiedz, przechodząc bajt po bajcie do przodu. Ale w architekturze 64-bitowej zmienia się to:

32bit:

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64bit:

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}