Problemy z dwurdzeniowym kodem ARM NEON Qualcomm Scorpion?

Question

Zajmuję się tworzeniem rodzimej biblioteki dla systemu Android, w której korzystam z optymalizacji montażu ARM i wielowątkowości, aby uzyskać maksymalną wydajność w dwurdzeniowym mikroukładzie ARM MSM8660. Robiąc pewne pomiary zauważyłem następujące:

1. jednowątkowy biblioteka z NEON optymalizacje jest szybciej niż jednowątkowy bibliotece ARMv6 optymalizacje (zgodnie z oczekiwaniami).
2. wielowątkowy biblioteka z ARMv6 optymalizacji jest szybciej niż jednowątkowy bibliotece ARMv6 optymalizacje (prawidłowo).
3. W wielowątkowych biblioteka z NEON optymalizacje jest wolniej niż jednowątkowych biblioteka z NEON optymalizacje (na pewno nie spodziewałem!).

Próbowałem przeszukiwać całą sieć, aby uzyskać wyjaśnienie, dlaczego tak jest, ale do tej pory nie znaleziono żadnych. Wygląda na to, że wszystkie rdzenie mają wspólny rurociąg NEON lub coś podobnego, ale wszystkie schematy zdają się wskazywać, że każdy rdzeń powinien mieć własną jednostkę NEON. Czy ktoś wie, dlaczego tak się dzieje?

Answer 1

Jest to prawdopodobnie spowodowane brakami w pamięci podręcznej. Trudno powiedzieć bez większej ilości informacji.

Answer 2

Zgaduję, że to z powodu dodatkowej opłaty za cykl związany z płukaniem rurociągu NEON. Gazociąg NEON znajduje się za resztą rdzenia, a więc widzisz dodatkową karę cyklu za nieodebrane gałęzie i tak dalej.

Jeśli wątki muszą być synchronizowane dość często, lub jeśli masz dużo zamków, myślę, że zobaczysz duże kary z NEON.

Jedynym sposobem wykorzystania NEON do ogólnego zwiększenia wydajności za pomocą wielowątkowego kodu jest sytuacja, w której kod jest zawstydzająco równoległy, a między wątkami występuje bardzo słaba i nieczęsta komunikacja.

Answer 3

Po pierwsze, jakiej biblioteki używasz?

Masz rację, każdy rdzeń ma swoją własną jednostkę NEON, ale jest to własna własna jednostka "VeNum" i niewiele informacji o niej jest, Została zaprojektowana dla Skorpiona opartego na Cortex-A8 w 8x50 i została znacznie lepsze niż własna implementacja NEON SIMD firmy ARM, Jednak dobrą ulgą jest to, że oni (qcom) projektują swój sprzęt w taki sposób, aby był zgodny z bazowym wzorcem refencji, więc większość kodu dla cortex-A8 będzie działała dobrze z Scorpionem, chociaż niektóre trafienia wydajnościowe ze względu na możliwe różne terminy rozkazów.

Jeśli używasz "softfp" do kompilacji programu, będziesz mieć narzut około 20 cykli dla każdej wywoływanej funkcji, która używa argumentów zmiennoprzecinkowych i lub używa jednostki NEON jako transferu danych rejestru z rdzenia ARM do jednostki Neon i na odwrót jest dość powolny i czasami może zablokować rdzeń przez wiele cykli, czekając, aż potok przepłynie.

Również dla programu z gwintem przy użyciu jednostki zmiennoprzecinkowej, jądro musi zapisać rejestry FP podczas przełączania kontekstu, co powoduje dodatkową karę za wątki, ponieważ wiemy już, że przenoszenie rejestrów z neonu do ramienia jest powolne i znane jest z przeciągnięcia rurociągu.

Dodatkowo wiele innych czynników może prowadzić do takich sytuacji, jak zła optymalizacja kompilatora, brak pamięci podręcznej, niewykorzystywanie podwójnej funkcji skorpiona, złe planowanie rozkazów i wielokrotne przełączanie wątku z jednego rdzenia na drugi.