Co ' jest takiego specjalnego w x64 i x86? [zamknięte]

Zamknięte . To pytanie wymaga szczegółów lub jasności . Obecnie nie przyjmuje odpowiedzi.

Komentarze

Duplikat stackoverflow.com/questions/607322/… , którego niestety mogę ' t oflagować, ponieważ ' jest na SO, a nie na programistach.
@Matthew Read: Itanium zawiódł spektakularnie na rynku, ponieważ ISA był bardzo trudny do napisania kompilatorów. Rynek HPC zrezygnował z tego na długo przed wprowadzeniem przez AMD swoich rozszerzeń.
@Mathew, można tak powiedzieć o Intelu! Gdyby nie ' t dla wstecznej kompatybilności, pracowalibyśmy na procesorach z rozsądnymi zestawami instrukcji i kolejnością bajtów w sieci.
@Matthew: Czy kiedykolwiek spojrzałeś na Itanium zestaw instrukcji? Co za koszmar! Przeniesienie planowania instrukcji do kompilatora było złym pomysłem. Jeśli potrzebujesz dobrego modelu 64-bitowego, spójrz na DEC ' s Alpha.
@Mathew, nie lekceważ znaczenia platformy, która jest wstecznie kompatybilna.

Odpowiedź

Jedyną prawdziwą różnicą, jaką zauważysz podczas korzystania z HLL, będzie rozmiar kodu, i odkrycie, że niektóre funkcje / biblioteki nie są jeszcze dostępne dla x64. Aha, i kod x64 wydaje się być mniej wydajny, przynajmniej w .NET. Aplikacja, nad którą pracuję, działa około 20% szybciej, kiedy kompiluję na x86. Nie wiem, czy to dlatego, że używam większej przepustowości magistrali, przesuwając 8-bajtowe ilości, czy też jest jakiś „fragment” aby dostosować 32-bitowe interfejsy API do 64-bitowych.

Komentarze

Nie tyle przepustowość magistrali ruchów, ile fakt, że jeśli radzisz sobie z 64-bitowymi ilościami w porównaniu z 32-bitowymi, ' skutecznie zmniejszyłeś rozmiar pamięci podręcznej o połowę.
@Brian: Doskonała uwaga, nie ' nie pomyślałem o tym.
Szczególnie w przypadku .NET z dużą liczbą referencji, gdzie wszystko jest wskaźnikiem (odniesieniem).

Odpowiedź

Na tym poziomie, o którym mówisz (.NET), różnica jest bardzo mała. Jeśli używasz całkowicie zarządzanego kodu, JIT automatycznie skompiluje Twój kod i będzie działał prawie tak samo, z różnymi charakterystykami wydajności. W przypadku niektórych rzeczy będzie to szybsze (przetwarzanie dużej ilości danych, dane mogą być przetwarzane w fragmentach 64-bitowych, więcej dostępnych rejestrów itp.), A dla innych wolniej (dane 64-bitowe (tj. Wskaźniki) ładują się wolniej do pamięci podręcznej na początek , co oznacza więcej danych i wolniejsze transfery z pamięci głównej).

Tak naprawdę musisz się martwić tylko o różnicę, gdy używasz niezarządzanego kodu. Ten blog zawiera dobry przegląd problemów.

Komentarze

Nie ' nie masz 64-bitowych danych, chyba że je określisz. Wskaźniki są promowane do 64-bitów, ale wartości int i float pozostają takie same. Prawie wszystkie systemy 32-bitowe obsługują 64-bitowy float (double), a wiele obsługiwanych 64-bitowych int (long long). 64-bitowy otwiera również nowe funkcje, w tym więcej rejestrów widocznych dla użytkownika.
@Omega, Wskaźniki to dane. Aby ich użyć, należy je przenieść do pamięci podręcznej. Uruchomienie na 64 bitach oznacza, że każde odwołanie lub dereferencja może potencjalnie przenieść jedno lub więcej z nich do pamięci podręcznej, a także rozszerza każdy obiekt, który zawiera odniesienia. Ale masz rację, twierdząc, że połówki stwierdzenia są nieprawidłowe. Zmienię to. Dzięki.
Z mojego doświadczenia wynika, że wskaźniki ' nie są zbyt częste. Ale nie ' nie robię OOP i miałem naprawdę bolesne wczesne doświadczenie ze złymi wskazówkami, więc używam ich tylko wtedy, gdy jest to absolutnie konieczne. Dlatego wskaźniki IMO nie ' nie zajmują bardzo dużo miejsca na adres. Nowoczesne kompilatory OTOH generują wiele rozwijania pętli, usuwania pętli i specjalnego kodu przypadku, więc rozmiar kodu może stać się dość duży.
@Omega, za każdym razem, gdy odwołujesz się do złożonej instancji obiektu w zarządzanym języku, którego używasz wskaźnik pod maską.

Odpowiedź

Programy .Net, które zostaną napisane dla systemów 64-bitowych, będą miały większa przestrzeń adresowa, a więc będzie znacznie szybsza niż programy oparte na architekturze x86-32 bit. Również najnowsze kompilatory języka .NET tworzą znacznie zoptymalizowany kod. JIT został również ulepszony w ostatnich latach i teraz możesz wykonać optymalizację wielordzeniową JIT. Ulepszono również debuggery. W międzyczasie tworzony jest lepszy i zoptymalizowany kod dla systemów 64-bitowych.

Komentarze

Niezupełnie.Jako główny komentarz, do którego odwoływano się ponad rok temu, x86-64 ma znacznie lepszy zestaw rejestrów i nie można go uznać za " rozszerzenie ". Następnie przestrzeń adresowa nie ' nie przyspiesza programów. Następnie ich udział w rynku. Obecnie prowadzi się 64 bity, 32 bity mniejszość (inwentarz Steam, sierpień 2012).
To ( en.wikipedia.org/wiki/X86-64 ) mówi, że X86-64 jest rozszerzeniem x86. Być może przestrzeń adresowa nie wpływa bezpośrednio na programy działające wolno, ale może wpływać na pamięć, co spowoduje spowolnienie działania programu. Podczas tworzenia systemów 64-bitowych możesz mieć kilka dodatkowych miejsc pracy, ale nie jest to duża liczba. Jeśli chodzi o rynek pracy, nie ' nie patrz tylko na kraje rozwinięte, ale także z krajami trzeciego świata. Aby uzyskać dobre informacje, zobacz: arstechnica.com/features/2008/09/x86-64 .
Ty ' cytując artykuł sprzed 4 lat. Obecnie, w 2012 r., Praktycznie nie wyprodukowano 32-bitowych procesorów x86, w tym niskobudżetowych procesorów ' przeznaczonych dla krajów trzeciego świata.
W Kraje trzeciego świata, które stanowią znaczną część światowej populacji, regularnie korzystają z tego systemu. Mimo że pojawiają się nowe systemy, ale wskaźnik zakupów nie jest dobry w porównaniu z systemami mobilnymi.
@Badar Wątpliwe. Widzę 64-bitowe procesory do komputerów niskiego i średniego zasięgu w Ameryce Łacińskiej. Zgadzam się, że nie ma już 32-bitowych procesorów, przynajmniej w przypadku komputerów stacjonarnych i laptopów średniej klasy.

Dodaj komentarz Anuluj pisanie odpowiedzi