Wychodząc z moich ostatnich testów porównawczych AWS Graviton3 i patrząc na Graviton3 w porównaniu z Intel Xeon i AMD EPYC, wielu czytelników Phoronix wyraziło zainteresowanie obejrzeniem kilku testów porównawczych dostrajania kompilatorów dla Graviton3 wokół rdzeni Arm Neoverse-V1 z obsługą SVE. Oto kilka punktów odniesienia dla osób zainteresowanych wpływem na dostrajanie kompilatora dla tego nowego wysokowydajnego procesora Arm Cloud.
Testy w tym artykule dotyczyły instancji Amazon EC2 c7g.8xlarge wyposażonej w 32 rdzenie z platformy Graviton3. Ubuntu 22.04 LTS działało na tej instancji EC2 z podstawowym jądrem Linux 5.15, podczas gdy zdecydowano się na użycie gcc-snapshot na Ubuntu 22.04 w celu zapewnienia nowszego stosu kompilatora opartego na GCC12.
Z tej samej instancji Graviton3, liczba testów open-source C/C++ przeprowadzono podczas testów z następującymi testowanymi CFLAGS/CXXFLAGS:
-O3-march=armv8.4-a dla ARMv8.4 ponieważ jest oparty na Neoverse-V1.
-O3 0march=armv8.4-a+sve dla określenia wsparcia Arm SVE (Scalable Vector Extension) znalezionego w Neoverse-V1.
-O3-march-armv8.4-a+sve-mcpu=neoverse-v1, aby cieszyć się dostrajaniem procesora specyficznym dla Neoverse-V1.
W GCC 11 dodano obsługę rozszerzenia Arm Scalable Vector Extension (SVE), w tym możliwość automatycznej wektoryzacji wielu funkcji SVE. Rzućmy okiem, aby zobaczyć, jaką różnicę mają te flagi kompilatora na wynikową wydajność wygenerowanych plików binarnych działających na Gravitonie3 w chmurze Amazon.
Testowanie kompilatora na Gravitonie3 ograniczało się tylko do tych trzech konfiguracji, aby oszczędzić koszty operacyjne w chmurze.
Opcje kompilatora SVE zapewniły pewną pomoc w testach kodera obrazu JPEG XL, oferując lepszą wydajność w porównaniu z podstawowym targetowaniem Armv8.4 bez SVE. OpenJPEG również w pewnym stopniu skorzystał na SVE.
W innych obciążeniach przewaga SVE wahała się od niewielkich do umiarkowanych wzrostów.
Obsługa automatycznej wektoryzacji SVE w GCC 12 pomogła w części audio kodowania testów porównawczych.
Oczywiście, w dużym stopniu zależy od testowanego oprogramowania, jak duży wpływ, jeśli w ogóle, może mieć ze strony Arm SVE i innych tuningów Neoverse-V1.
Na przykład z Zstd tylko dostrojenie pomogło w wydajności dekompresji w trybie długim, podczas gdy w innych testowanych konfiguracjach kompresji Zstd nie było mierzalnej różnicy.
W przypadku niektórych testów porównawczych, takich jak Crypto++, dostrojenie-mcpu=neoverse-v1 faktycznie miało negatywny wpływ na wydajność.
Autowektoryzacja GCC i/lub SVE miały negatywny wpływ na wydajność biblioteki cyfrowego przetwarzania sygnału Liquid-DSP o otwartym kodzie źródłowym.
Lub w testach porównawczych kryptowalut Botan strojenie Neoverse-V1 było zauważalną zaletą dla niektórych algorytmów kryptograficznych.
Wydajność biblioteki sieci neuronowej TNN Tencent różniła się w zależności od SVE.
W skrócie, jak to często bywa, w dużej mierze sprowadza się to do konkretnych baz kodu i obciążeń, które aktywnie zaangażuj się w to, czy dodatkowe dostrajanie kompilatora jest warte zachodu. W niektórych obciążeniach testowane GCC 12 wykazywało pewne korzyści dzięki obsłudze automatycznej wektoryzacji SVE, podczas gdy w innych przypadkach nie tak bardzo, aw niektórych przypadkach powodowało regresję wydajności. Interesujące będzie obserwowanie wpływu ręcznie dostrojonych elementów wewnętrznych SVE przez główne oprogramowanie typu open source, ponieważ coraz więcej procesorów Arm zostanie oznaczonych obsługą SVE/SVE2, a także jak ewoluują niekończące się postępy kompilatora open source.
Ci, którzy chcą zobaczyć wszystkie testowane testy porównawcze flag kompilatora dla instancji Graviton3, mogą zobaczyć tę stronę wyników.
