Czy architektury procesorów są tendencyjne w stosunku do proceduralnych środowisk wykonawczych?

Czy są jakieś zmiany, które można wprowadzić w procesorach, aby działały lepiej w przypadku równoczesnych środowisk uruchomieniowych, takich jak Rust? Na przykład, czy są jakieś zmiany w implementacjach przewidywania gałęzi lub rozmiarach pamięci podręcznej, które pomogłyby w jednoczesnych uruchomieniach?

Mam wrażenie, że obecne konstrukcje procesorów mogą być bardziej zoptymalizowane pod kątem proceduralnych środowisk wykonawczych, takich jak C. Jeśli zamiast tego zamierzalibyśmy zoptymalizować pod kątem równoczesnych uruchomień, w jaki sposób procesory wyglądałyby inaczej?

W przypadku prognozy zaimplementowano przewidywanie gałęzi na podstawie uogólnień przedstawionych w pracach naukowych analizujących kody proceduralne. Zastanawiam się, czy abstrakcja współbieżności doda znaczący zestaw roboczy do środowiska wykonawczego, który negatywnie wpłynie na istniejące algorytmy przewidywania gałęzi. Na przykład przewidywanie w pętli for to jedno, ale gdy celem gałęzi jest zawsze jakaś nowa część pamięci (grafika, tekst itp.), Zawsze będzie brakowało pamięci podręcznej i nigdy nie będzie gałęzi historia za to - bo żadne jeszcze jej nie dotknęło.

Jest to prawdopodobnie głupie pytanie, ponieważ zawartość, choć zawsze może być w pamięci RAM, zostanie rozgałęziona do rzędu wielkości mniejszej niż będzie używana (po załadowaniu do pamięci podręcznej) ... ale nadal tam powinna stanowić możliwą do zaobserwowania granicę czasową kontekstów przechowywanych w pamięci podręcznej i predyktorach rozgałęzień w proceduralnym środowisku wykonawczym, który przejawiałby się jako granica abstrakcji w bardziej zrównoleglonym środowisku. Zastanawiam się więc ... Czy przestrzegano tych granic? Czy jakieś prace badawcze to przeanalizowały?

Czy architektury procesorów są stronnicze w stosunku do kodu proceduralnego w stosunku do kodu współbieżnego; lub czy współczesne procesory są wystarczająco ogólnego przeznaczenia, aby nie ucierpiał wysoce współbieżny język?

computer-architecture concurrency functional-programming

— paZwiększenie
źródło

Czy przeglądałeś literaturę dotyczącą architektury Itanium (IA-64)? Został zaprojektowany z wielkimi marzeniami o ultrarównoległości, ale potem ludzie nie stworzyli kompilatorów, które wykorzystywałyby funkcje procesora, a oprogramowanie wcale nie działało tak dobrze.

— Gilles „SO- przestań być zły”

@Gilles tak. Chociaż jest to inne pytanie, to w rzeczywistości interesujące spostrzeżenie - być może paralelizm zapieczętowany w Itanium byłby bardziej odpowiedni dla współczesnych współczesnych języków?

— paIncrease

@Gilles: Podobnie, wydaje się, że nowa architektura Mill została zbudowana z myślą o równoległości i tanich przełącznikach. Na przykład, używając jednej wirtualnej przestrzeni adresowej dla wszystkich „procesów”, przesuwa TLB między ostatnim poziomem pamięci podręcznej a kontrolerami urządzeń (patrz slajd 49 millcomputing.com/docs/memory ).

— Matthieu M.

@pedAntic Rust wymagający środowiska wykonawczego jest łatwym do zrozumienia nieporozumieniem : chat.stackoverflow.com/transcript/message/24171983#24171983 . Twoje pytanie wydaje się potwierdzać to błędne przekonanie, które nie jest dobre dla Rust.

— ArtemGr,

@pedAntic Widzisz, Rust miał jednocześnie środowisko uruchomieniowe (dla zielonego wątkowania), ale już nie. W tej chwili Rust jest w dużej mierze tej samej ligi co C pod względem profilu wydajności współbieżności. Jedyna różnica w stosunku do C polega na tym, że analiza statyczna w Rust sprawia, że współbieżność jest w większości bezpieczna.

— ArtemGr,

Odpowiedzi:

Prawdopodobnie bardziej jest tak, że współczesne architektury komputerowe są projektowane w celu poprawy jakości kodu generowanego przez kompilatory w stosunku do budżetu kosztów w obszarze matrycy i zużytej mocy. Biblioteki wykonawcze to tylko określone wystąpienie skompilowanego kodu, które należy wykonać w wydajny sposób.

Przez bardzo długi czas językiem docelowym dla większości architektur był język „C”. Odzwierciedla to skromne wymagania, jakie ten język stawia na swoim sprzęcie oraz fakt, że stał się on prawie uniwersalnym językiem programowania systemów (przepraszam, Rust i Go, musisz pokonać C).

Konsekwencją tego wydaje się być to, że nowe języki są często definiowane pod względem ich semantyki równoważnej C tylko po to, aby uniknąć konieczności korzystania z funkcji procesora, których prawdopodobnie nie będzie na obecnych komputerach.

Korzyścią dla procesora, który dobrze pasuje do nowoczesnych kompilatorów, jest to, że kod z tych kompilatorów działa dobrze, a procesor ma co najmniej szansę na konkurencyjność. Koszt awarii tutaj skazuje procesor przed jego uruchomieniem. Tylko dwa przykłady negatywne to iAPX-432 i Itanium, oba firmy Intel. Oba miały bardzo słabe relacje ze swoimi kompilatorami (odpowiednio Ada i C), a porażka produktów przerodziła się w winę między krzemem a oprogramowaniem.

— Peter Camilleri
źródło

Bez wątpienia tak.

W szczególności model komunikacji implikowany przez C99 to pamięć współdzielona. Bardziej zaawansowane języki współbieżne mają bogatsze modele komunikacji, takie jak kanały przekazywania wiadomości (jak w Rust).

Nowoczesne architektury procesorów mają wyraźne wsparcie sprzętowe dla pamięci współużytkowanej. W szczególności protokoły koherencji pamięci podręcznej, takie jak MESI, są implementowane w rzeczywistych bramkach i przewodach. Nie ma rzeczywistej obsługi przekazywania komunikatów między procesami, nawet jeśli idea przekazywania komunikatów nie jest obca procesorom. Nowoczesne magistrale PCI-e emulują nawet pamięć współdzieloną za pomocą przekazywania wiadomości, podczas gdy procesy CPU muszą emulować przekazywanie wiadomości za pomocą pamięci współdzielonej!

— MSalters
źródło