Jaki jest związek między tłumaczami meta-cyklicznymi, maszynami wirtualnymi i zwiększoną wydajnością?

12

Czytałem o interpreterach okrągłych w Internecie (w tym SICP) i sprawdziłem kod niektórych implementacji (takich jak PyPy i Narcyz).

Czytałem całkiem sporo o dwóch językach, które świetnie wykorzystywały ewaluację wewnątrzkolistną, Lisp i Smalltalk. O ile rozumiałem, Lisp był pierwszym kompilatorem samo hostującym, a Smalltalk miał pierwszą „prawdziwą” implementację JIT.

Nie do końca rozumiem, w jaki sposób tłumacze / kompilatory mogą osiągnąć tak dobrą wydajność lub, innymi słowy, dlaczego PyPy jest szybszy od CPython? Czy to z powodu refleksji?

Ponadto moje badania Smalltalk doprowadziły mnie do przekonania, że ​​istnieje związek między JIT, maszynami wirtualnymi i refleksją. Maszyny wirtualne, takie jak JVM i CLR, pozwalają na wiele introspekcji typu i uważam, że świetnie wykorzystują je w kompilacji Just-in-Time (i chyba AOT?). Ale o ile mi wiadomo, maszyny wirtualne przypominają procesory, ponieważ mają podstawowy zestaw instrukcji. Czy maszyny wirtualne są wydajne, ponieważ zawierają informacje o typie i referencjach, które umożliwiłyby refleksję niezależną od języka?

Pytam o to, ponieważ wiele języków interpretowanych i skompilowanych używa teraz kodu bajtowego jako celu (LLVM, Parrot, YARV, CPython), a tradycyjne maszyny wirtualne, takie jak JVM i CLR, uzyskały niesamowity wzrost wydajności. Powiedziano mi, że chodzi o JIT, ale o ile wiem, JIT nie jest niczym nowym, odkąd Smalltalk i własna Jaźń Sun robili to przed Javą. Nie pamiętam, aby maszyny wirtualne osiągały szczególnie dobre wyniki w przeszłości, nie było wielu nieakademickich poza JVM i .NET, a ich wydajność zdecydowanie nie była tak dobra, jak teraz (chciałbym móc pozyskać to twierdzenie, ale ja mówić z własnego doświadczenia).

Nagle pod koniec 2000 roku coś się zmieniło i wiele maszyn wirtualnych zaczęło pojawiać się nawet w ustalonych językach i przy bardzo dobrej wydajności. Czy odkryto coś w implementacji JIT, która pozwoliła niemal każdej nowoczesnej maszynie wirtualnej na wzrost wydajności? Może papier czy książka?

virtual-machine reflection jit smalltalk Gomi
źródło
3
Pieniądze. Pieniądze, które kiedyś były przelewane do C ++ i Fortran, teraz są przelewane do HotSpot, CLR, Mono, V8, Nitro, SpiderMonkey itp.
Jörg W Mittag
Mogę tylko zgadywać, ale myślę, że to po prostu poprawa w czasie, jak opisano tutaj joelonsoftware.com/articles/fog0000000017.html
Doc Brown
1
RE, jak PyPy może być szybszy niż CPython: nie jest napisany w Pythonie, jest napisany w zupełnie innym języku, który można skutecznie zoptymalizować AOT .
1
@Gomi Nie chodzi o to, jak podobny jest język implementacji do języka implementacji. Istnieją interpretery JavaScript, Lisp, Prolog, SmallTalk i Ruby napisane w RPython i otrzymują dokładnie takie same korzyści, jakie oferuje PyPy. Jedynym powodem, dla którego RPython jest oparty na Pythonie, jest to, że został stworzony przez grupę entuzjastów Pythona. Funkcje RPython, które sprawiają, że PyPy jest szybki, nie mają nic wspólnego z Pythonem: automatyczne generowanie kompilatora JIT, śmieciarze itp. - i tak, większość z nich można w zasadzie zrobić w innych językach. Trzeba by jednak stworzyć zupełnie nowy kompilator.
4
-1, ponieważ wydaje się, że masz co najmniej 3 różne pytania: (a) Dlaczego implementacje meta-okólne są tak dobre? (b) Czy maszyny wirtualne są wydajne z powodu informacji o typie i czy introspekcja jest korzystna dla wydajności? (c) Jak popularność maszyn wirtualnych wzrosła pod koniec 2000 roku i dlaczego nagle nagle osiągają dobre wyniki? Myślę, że lepiej zadawać te pytania osobno.
Oak

Odpowiedzi:

1

2 z 3: Nie ma związku między środowiskami uruchomieniowymi „meta-circular” i „high-performance”. Meta-cykliczne środowiska wykonawcze, które osiągają wysoką wydajność, robią to poprzez kompilację JIT do kodu natywnego i uruchomienie kodu natywnego. Nie ma powodu, dla którego Twój wysokiej jakości środowisko wykonawcze w Pythonie musi być napisane w Pythonie lub Lisp w Lisp itp. Ale jeśli uważasz, że Twój język jest silniejszy, bardziej ekspresyjny itp. Niż inne, to dlaczego nie użyć go do pisania własny czas działania? Lub jeśli nie uważasz, że Twój język jest w jakiś sposób „lepszy” od innych, dlaczego w ogóle masz problem z jego wdrożeniem?

Alex D.
źródło