Jakie są zalety ogólnych typów (int/uint) nad określonymi typami (int64/uint64) w Go lang?

Question

Rozumiem, że int i uint są 64-bitowymi liczbami całkowitymi podpisanymi/bez znaku - podobnie jak int64/uint64. Rozumiem również, że int nie jest po prostu aliasem dla int64 (jak byte ->uint8), więc int64 musiałby zostać przekonwertowany na int i na odwrót, jeśli dotyczy. Jednak jakie są zalety korzystania z jednego na drugim? Czy jest jakaś kara za wydajność podczas korzystania z ogólnych typów?

Przepraszam, jeśli jest to częste pytanie - szukałem w Google odpowiedzi (również tutaj wyszukałem), ponieważ uważałem, że inni mogli się pojawić wcześniej, ale nie znaleźli odpowiedzi na pytanie, jak wpływają na wydajność (jeśli w ogóle), użycie pamięci (nie zgaduję, czy są to zarówno 64-bitowe liczby całkowite?), jak i sposób, w jaki kompilator je traktuje.

edytuj: Jestem świadomy, że int/unit są 32-bitowymi architekturami 32-bitowymi. Ze względu na zwięzłość i porównywanie, jak na przykład, zakładałem, że jest to 64-bitowe środowisko Golang.

Answer 1

int i uint są tylko 64-bitowe na architekturach 64-bitowych. W architekturach 32-bitowych mają one 32 bity.

Ogólna odpowiedź brzmi, że jeśli nie potrzebujesz pewnej precyzji, trzymanie się typów danych, które mają ten sam rozmiar co słowo na aktualnej architekturze (na przykład 32 bity w architekturze 32-bitowej), jest zazwyczaj nieco bardziej efektywne.

Answer 2

Poza int będącym "natywnym" rozmiarem i indeksami tablicowymi są int, a nie int64 lub int32.

Answer 3

int i uint odpowiadają maksymalnej możliwej długości podstawowych struktur danych Go w implementacji Go i środowisku wykonawczym. Długość string, map[K]T, []T i chan T zawsze pasuje do int, a pojemność []T i chan T zawsze pasuje do int.

Przydział za pośrednictwem make jest zobowiązany zwrócić obiekt o długości i pojemności, która zawsze pasuje do int. Wbudowana funkcja append zwraca wycinek o długości i pojemności nieprzekraczającej wartości int. Długość (liczba zdefiniowanych klawiszy) mapy po wstawieniu nowej pary klucz-wartość zawsze pasuje do int.

Główną zaletą jest to, że int i uint jesteś najmniejszą (w sensie bitsize) typów danych, które są bezpieczne do użycia w programie Go w połączeniu z popularnych typów danych wychodzą takie jak plastry i mapami.

Rozmiar int jest niezależny od rozmiaru wskaźnika *T. Typ całkowity odpowiadający *T to uintptr. Teoretycznie, implementacja Go może wybrać mapowanie int na int16 - wiele programów Go pozostanie działać poprawnie, ale ograniczenie rozmiaru alokacji do 15 bitów może być zbyt restrykcyjne i spowodować panikę w czasie wykonywania.

Na architekturach 64-bitowych Przejdź 1.0 ma int i uint 32-bitowe, Go 1.1 długości 64 bitów (patrz Go 1.1 Release Notes). Ta zmiana zwiększy użycie pamięci niektórych programów Go na 64-bitowych architekturach..

wyraźny przy użyciu int64 zamiast int w programie Go może spowolnić pod idź 1,0 i 32-bitowych, ponieważ:

• konwersji między int i int64

• Osiągi niektóre instrukcje procesora, takie jak podział, zależą od wielkości operandów:

jawnie przy użyciu int64 zamiast int w programie Go można zrobić to szybciej pod Go 1.0 na 64-bitowych architektur, ponieważ:

• Kompilator może generować bardziej wydajnego kodu dla adresu i obliczenia przesunięcia, jeżeli wszystkie argumenty są 64- kawałek. Mieszanie 32-bitowych i 64-bitowych operandów podczas obliczania adresów i przesunięć jest wolniejsze.

Używanie uint16 jako indeksu podczas uzyskiwania dostępu do [1<<16]T umożliwia kompilatorowi usunięcie instrukcji sprawdzania ograniczeń.