Czy są jakieś przykłady kompilatorów JIT wielowątkowych?

Zarówno JVM, jak i .NET CLR zawierają kompilatory Just-In-Time, które obsługują wiele wątków użytkownika. Sądzę jednak, że są to JIT z podziałem na metody.Czy są jakieś przykłady kompilatorów JIT wielowątkowych?

Wszystkie tracing JITs Jestem świadomy, na przykład LuaJIT i PyPy, są tylko jednowątkowe.

Czy są jakieś przykłady śledzenia zespołów JIT, które obsługują wątki wielu użytkowników? Jeśli nie, czy istnieją jakieś techniczne powody, dla których takie nie istnieją?

Źródło

2016-09-06 user200783

. NET obsługuje jit wielordzeniowy. Ale generalnie nie jest to rozwiązanie uniwersalne, może mieć tylko zauważalny wpływ, gdy rdzenie są zajęte jitowaniem. Wymaga to maszyny czasu, która wie, jaka metoda może być później wykorzystana. Rozwiązany w .NET przez rejestrowanie danych profilu, kolejność, w jakiej wykonywane są metody. Tak więc * następny * czas działania programu może zostać przerwany z wyprzedzeniem. Maszyny czasowe są trudne, mówią, że ludzie mają hoverboards i latające samochody w 2015 roku. Cóż, hoverboards okazały się prawdziwe. –

@HansPassant - Używanie wątków tła do kodu kompilacji JIT jest interesujące, nie wiedziałem, że .NET ma tę funkcję. Jednak nawet przed dodaniem tej funkcji użytkownicy mogli tworzyć wiele wątków - tak więc JSI .NET był już wymagany do kompilowania kodu na wielu wątkach. AFAIK jednak .NET nadal JIT-kompiluje jedną metodę na raz.Moje pytanie dotyczy właśnie [Tracing JITs] (https://en.wikipedia.org/wiki/Tracing_just-in-time_compilation): czy istnieją przeszkody techniczne dla JT śledzącego, który kompiluje wiele wątków (w tle lub do obsługuje wątki wielu użytkowników)? – user200783

Profilowanie (śledzenie) uruchomionego programu wielowątkowego jest o wiele trudniejsze, ale również niemożliwe. Celem całego śledzenia jest sprawienie, aby środowisko uruchomieniowe było lepsze niż kompilator optymalizujący. Jeśli wątki są ze sobą powiązane, wówczas JIT, który zamierza zmodyfikować kod, musi zrozumieć nie tylko sposób wykonania kodu, ale także efekty uboczne na innych wątkach.

Gdy wątek ma mieć dostęp do dużego pliku w pamięci, tworzy drugi poziom pamięci podręcznej, który powoduje, że wątek drugi jest zwalniany z przyczyny, która jest zewnętrzna dla kodu, który jest uruchomiony. JIT musi zrozumieć te interakcje. W przeciwnym razie może spędzić dużo czasu próbując zoptymalizować wątek drugi, gdy ulepszenia w wątku drugim będą wynikać z faktu, że wątek jeden kod negatywnie wpływa na wątek drugi i próbuje wyeliminować efekt bufora podręcznego.

Czy rozważasz próbę napisania własnego, wielowątkowego JIT? Można to zrobić, ale jest w to zaangażowany.

Źródło

2016-09-13 17:34:48

AFAIK LuaJIT, na przykład, decyduje, który kod JIT opiera się tylko na tym, ile razy jest uruchamiany, nie korzystając z informacji o taktowaniu. Dlatego uważam, że jego algorytmy powinny być odporne na problemy z buforowaniem między wątkami, o których wspomniałeś. Wydaje mi się, że nie ma teoretycznego powodu, dla którego śledzenie JIT nie może obsługiwać wielu wątków - ale być może taki JIT nigdy nie został wdrożony? _Czy rozważasz próbę napisania własnego wielowątkowego JIT-a? _ Rozważam napisanie JIT śledzącego, tak. Próbuję sprawdzić, czy wsparcie dla wielowątkowości jest wiarygodnym celem projektu. – user200783

Nie ma wątpliwości, że można zoptymalizować tylko to, ile razy dany kod jest uruchamiany, ale byłoby to nieoptymalne z perspektywy globalnej w aplikacjach wielowątkowych. W poprzedniej pracy wykonalibyśmy ręczną optymalizację wyłączania niektórych rdzeni w procesorze, aby więcej pamięci podręcznej L2 i L3 było dostępnych bez płukania i moglibyśmy wyeliminować muteksy i zweryfikować, że dane wejściowe nie zostały zaktualizowane po obliczeniu kompletne, ponieważ "szpiegowanie" jest znacznie tańsze niż blokowanie muteksu, w którym profilowanie pokazało, że aktualizacje i odczyty rzadko się kolidują. –

Obsługa wielowątkowość w JIT śledzenia jest wiarygodne. Jedynym pytaniem jest, jak dobrze można dokonać optymalizacji. –

Twoje pytanie jest dyskusyjne z powodu niewłaściwego założenia. Optymalizator HotSpot JVM/OpenJDK firmy Oracle to , a nie "JIT typu" w czasie rzeczywistym ". Jedną z jej podstawowych technologii jest zdolność do inlineingu, często nazywana "agresywnym inliningiem", ponieważ spekulacyjnie inline metody, które są prawdopodobnie celem ekspedycji metod dynamicznych, oparte są na profilowaniu bieżącej realizacji (i innych wskazówek). Obejmuje to nawet możliwość de-optymalizacji, jeśli zachowanie środowiska wykonawczego programu ulegnie zmianie i nie wykona już zoptymalizowanej ścieżki kodu.

Wpisywanie jest fundamentalne, ponieważ większość innych optymalizacji kodu rozwija swój prawdziwy potencjał tylko wtedy, gdy kod metod jest wbudowany w dzwoniącego, zapewniając niezbędny kontekst.

Tak więc w przypadku maszyny wirtualnej HotSpot JVM istnieje już wielowątkowe środowisko optymalizacyjne wykorzystujące znane ścieżki wykonania. Informacje te nie muszą być gromadzone w sposób opisany jako "śledzenie". Ponieważ ta maszyna JVM może w dowolnym momencie utworzyć migawkę wątku stosu wątku, może również przeglądać ślad w określonych odstępach czasu, mając większą kontrolę nad narzutem profilowania, niż dodając funkcję nagrywania do każdego wywołania metody. Tak więc JVM może ograniczyć pozyskiwanie śladów do wątków rzeczywiście zużywających znaczny czas procesora i samoistnie uzyska rzeczywisty łańcuch wywołania, nawet jeśli zaangażowane metody są zawarte w wielu łańcuchach wywołań różnych wątków.

Źródło

2016-09-14 09:51:14 Holger

Jako dodatek można skorzystać z opcji '-XX: + UnlockDiagnosticVMOptions -XX: + PrintInlining', aby umożliwić JVM wydrukować * drzewa wywołań *, które zostaną wstawione. – Holger

Czy są jakieś przykłady kompilatorów JIT wielowątkowych?

Odpowiedz

Powiązane problemy