Czy LuaJIT działa szybciej niż inne dynamiczne języki JIT?

Zgodnie z testową wersją języka komputerowego, implementacja LuaJIT seems to beat every other JIT-ed dynamic language (V8, Tracemonkey, PLT Scheme, Erlang HIPE) przez o rząd wielkości.Czy LuaJIT działa szybciej niż inne dynamiczne języki JIT?

Wiem, że te testy porównawcze nie są reprezentatywne (jak mówią: "Które implementacje języków programowania mają najszybsze programy testów porównawczych?"), Ale wciąż jest to imponujące.

W praktyce, czy tak naprawdę jest? Ktoś przetestował tę implementację Lua?

Źródło

2010-04-06 Gabriel Cuvillier

>> Wiem, że te wartości referencyjne nie są reprezentatywne << Czy Ty? Przypominamy, że nie twierdzą, że są reprezentatywni dla wszystkiego, co chcielibyście robić. Od Ciebie zależy zrozumienie, jak te małe programy przypominają (lub nie) programy, które piszesz. – igouy

@igouy: Gdyby sądził, że wskaźniki były reprezentatywne, nie zadałby tego pytania. Pytanie wymaga potwierdzenia tych wyników. – Mud

Istnieje dobra dyskusja pod adresem Lambda the Ultimate. LuaJIT jest bardzo dobry.

Wiele osób zgłosiło imponujące przyspieszenia na lua-l (lista dyskusyjna Lua). Przyspieszenia są najbardziej imponujące dla czystego kodu Lua; kompilator śledzenia nie jest tak skuteczny, gdy istnieje wiele wywołań funkcji C w ładowalnych modułach bibliotecznych.

Źródło

2010-04-06 21:30:34

Zrobiłem eksperyment z lekcji nauczyłem się tutaj: http://www.sampalib.org/luajit2.0_tunning.html Niektóre dane nie są już tak ważny (maxmcode = 1024 jest na tyle), ale luajit przynosi solidną poprawę na 600 liniach kodu czystego skryptu Lua (brak połączenia C uderzać w perfy ...), która nie jest aplikacją na dużą skalę ani wbudowanym przypadkiem użycia, ale znacznie bardziej niż testy porównawcze.

Źródło

2010-05-03 21:29:54

W moim przypadku (rozwój prototypu gry) nie zaobserwowałem żadnej poprawy wydajności. Używam lua do osadzania, więc istnieje wiele wywołań funkcji biblioteki C++. Mimo że główna pętla znajduje się w skrypcie lua, a cała istotna logika jest zaimplementowana w lua, ogólna wydajność została określona przez renderowanie silników i silników fizycznych zaimplementowanych w C++. Oryginalna lua jest już wystarczająco szybka dla takich aplikacji.

Źródło

2011-01-26 16:21:27 tbear

Zrobiłem podobne doświadczenie. Tak, luajit jest znacznie szybszy dla czystej lua, ale nie przyspieszy twoich połączeń do C. Użyłem luabind do zawijania (prawdopodobnie zły pomysł), a skończyło się na tym, że spędzałem więcej czasu na wywoływaniu obiektów niż w moich funkcjach lua. . – cib

+16

Jeśli użyjesz interfejsu LuaJIT ffi do wywoływania funkcji C, zostaną one natywnie wbudowane przez kompilator jit, a to będzie znacznie szybsze. Wywołałem wywołania systemowe systemu Linux z taką samą szybkością, jak C. –

Dla tbear i cib problem nie jest narzutem wywoływania C, ale raczej, że cały czas był spędzany wewnątrz funkcji C. Oczywiście w takim przypadku Lua nie jest częścią wąskiego gardła i przyspieszenie go nie przyniesie poprawy. – Eloff

-1

Wydajność JIT zależy od dwóch rzeczy: wydajności oryginalnego języka skryptowego i wydajności kompilatora.

Kompilator to dość dojrzała technika, a większość kompilatorów JIT ma porównywalną wydajność. Jednak sama lua, tj. Lua-without-JIT, jest prawdopodobnie jednym z najszybszych języków skryptowych.

Lua jest szybsza niż Java-bez-JIT. Lua jest szybsza niż JavaScript-bez-JIT. Lua jest szybsza niż większość języków skryptowych bez JIT.

tak,

lua-JIT jest szybszy niż Java-z-JIT (Sun Java), lua-JIT jest szybsze niż V8 (JavaScript-z-JIT), etc ...

Źródło

2012-02-22 01:09:38 pansz

Większość kompilatorów JIT nie ma porównywalnej wydajności. Lua w przeważającej części nadaje się dobrze do interpretacji i wydajności JIT, ale nie jest to decydujący czynnik, który został stworzony. LuaJIT nie jest "szybszy" niż Sun JVM, chociaż jest porównywalny. Również interpretator LuaJIT jest zupełnie inny niż PUC Lua. – jsimmons

Czy LuaJIT działa szybciej niż inne dynamiczne języki JIT?

Odpowiedz

Powiązane problemy