LINUX.ORG.RU

Lua Jit 2.0


1

5

Вышел компилятор для Lua — LuaJit 2.0.

Основные изменения для релиза были в исправлении багов.

Изменения и улучшения по сравнению с первой версией:

  • Возможность использования конверсии исключений C++ для всех платформ с помощью функций-обёрток.
  • Обёртки для libm функций.
  • Сборка static и shared библиотек на POSIX.
  • Компилирование рекурсивного кода.
  • Портирование интепретатора и JIT компилятора на x86-64.
  • Разметка текущего трейса, даже если компилятор не доступен.
  • Оптимизация для and/or операторов.

И много других здесь.

Также доступны бенчмарки.

>>> Подробности

anonymous

Проверено: catap ()
Последнее исправление: Binary (всего исправлений: 1)

Огромное спасибо разработчикам за этот новый релиз. Я влюбился в этого маленького быстрого демона Lua Jit. В Lua отлично сочитаются преимущества встраиваемого языка и скорость кскомпилрованного кода!

anonymous
()
Ответ на: комментарий от anonymous

и скорость кскомпилрованного кода!

это мягко говоря не так, lua раз в 20-30 медленнее С, если ориентироваться на бенчмарк shootout

wota ★★
()
Ответ на: комментарий от wota

хм, но там же не используется jit. Нужно посмотреть бенчмарки в ТС посте.

anonymous
()
Ответ на: комментарий от frozenix

luajit около 30 раз быстрей lua :D

достаточно быстро

RedPossum ★★★★★
()
Ответ на: комментарий от wota

А если не ориентироваться на всякие левые бенчмарки, а сравнивать производительность на реальных задачах, то моя интерпретация генерации $6$ (с использованием sha512) shadow-паролей (aka sha512_crypt), написанная на Lua (даже без JIT) по руквоводству Ульриха Дреппера работает в несколько раз быстрее той, что написана им самим на Сях и приведена в конце того руковоства.

От така фигня, малята.

mva
()
Ответ на: комментарий от frozenix

Кстати, и в некоторых особенных ситуациях потребление памяти до 55+ раз меньше :)

mva
()

lua раз в 20-30 медленнее С
luajit около 30 раз быстрей lua

luajit в 1-10 раз быстрее С !!!

wxw ★★★★★
()
Ответ на: комментарий от wxw

а что не так? это же jit чем больше работает тем быстрее.

anonymous
()
Ответ на: комментарий от wota

С lua-jit не сравнивают на shootout, только с lua. Lua-jit очень быстр... Во многих случаях код lua-jit работает почти так-же быстро, как и код на C.

lucentcode ★★★★★
()
Ответ на: комментарий от D_Lans

Интересно, можно ли теоретически запилить PythonJit, который бы «работал почти также быстро, как и код на C».

Уже сделано: man pypy. Для некоторых тестов обработки строк даже превосходит C.

Vudod ★★★★★
()
Ответ на: комментарий от dizza

В свое время интересовался этим lua, но потом увидел Golang...

У них совсем разные области. Lua для скриптования внутри приложений, Go полноценный компилируемый язык, пригодный для разработки в первую очередь сетевых приложений. То, что оба позволяют написать HelloWorld, вовсе не значит, что они могут заменить один другой в типичных задачах.

Vudod ★★★★★
()
Ответ на: комментарий от D_Lans

нет, гвидонщики очень ленивые им делали, но они отказались и теперь у них ничего нет, в отличие от луа у которой есть jit.

anonymous
()
Ответ на: комментарий от D_Lans

Боюсь, что нет. Python слишком привязан к некоторым очень высокоуровневым вещам, да и его траблы с GIL всем известны. JavaScript, и сравнительно низкоуровневый, Lua можно очень сильно оптимизировать введя JIT. Чем выше уровень ЯП, тем больше в нём вещей, трудно поддающихся оптимизации. Теоретически, возможно использовать схему, известную по некоторым Lisp. Когда часть кода компилируется в сравнительно быстрый байткод, или даже нативный код. А часть кода, требующая интепритации на ходу, и высокоуровневые вещи, специфичные для интерпретируемого кода - будет запускаться в прилинкованной к бинарю приложения виртуальной машине.

lucentcode ★★★★★
()

Годный проект, плюсую

pftBest ★★★★
()
Ответ на: комментарий от Vudod

Мне встравиваемость не нужна, так что я их в этом разрезе смотрел. А так да, для кого-то годнота.

dizza ★★★★★
()

А есть смысл запускать на нём, например, awesome?

anonymous
()
Ответ на: комментарий от st4l1k

В си нету обработки строк если че.

Если что, её можно написать. Там сравнивались стандартные функции типа find, split, strip, join, одни написаны на C, другие на RPython с JIT компиляцией.

Vudod ★★★★★
()
Последнее исправление: Vudod (всего исправлений: 1)
Ответ на: комментарий от AVL2

смишно.

Действительно, 2 ошибки в предложении из 1 слова. Иначе и не скажешь.

Vudod ★★★★★
()
Ответ на: комментарий от lucentcode

Python слишком привязан к некоторым очень высокоуровневым вещам, да и его траблы с GIL всем известны.

Не понял смысла ваших слов. RPython прекрасно справляется с этою функцией, предлагая полный набор функций стандартного Питона, включая Tkinter. Кстати, GIL и JIT совсем не связаны. В C до стандарта C11 не было собственных средств для организации многопоточности (pthread не в счёт), при том, что это и вовсе компилируемый язык.

Vudod ★★★★★
()
Последнее исправление: Vudod (всего исправлений: 1)
Ответ на: комментарий от Vudod

Ну выже понимаете что это не одно и тоже, и говорить что pypy со строками работает быстрее чем си как сравнивать сладкое и мокрое.

st4l1k ★★
()
Ответ на: комментарий от st4l1k

Ну выже понимаете что это не одно и тоже

И в чем же разница?

tailgunner ★★★★★
()
Ответ на: комментарий от wxw

О, а вот и дибил, который «разы» друг из друга вычитает.

anonymous
()
Ответ на: комментарий от st4l1k

Ну выже понимаете что это не одно и тоже

Честно говоря, не понимаю. В коде на RPython все операторы содержат только код на RPython, никаких сишных вставок и вызовов сишных функций там нет. Это всё равно, что сравнивать C и fortran или Pascal, например. Если я напишу на Паскале find и join, вы же не станете отрицать, что его можно сравнивать с сишным?

Vudod ★★★★★
()
Ответ на: комментарий от mva

Очевидно, что на С он прогать не умеет-же, не?

anonymous
()
Ответ на: комментарий от Vudod

Если я напишу на Паскале find и join, вы же не станете отрицать, что его можно сравнивать с сишным?

Стану отрицать. а вот если будете сравнивать с gcc 4.x то не стану.

st4l1k ★★
()
Ответ на: комментарий от Vudod

Не связаны. Но GIL не позволит Python работать с той-же скоростью, что и компилируемые ЯП, и даже близко к ним приблизится...

lucentcode ★★★★★
()
Ответ на: комментарий от Vudod

Уже сделано: man pypy. Для некоторых тестов обработки строк даже превосходит C.

Это там, где pypy зная входные данные производить оптимизацию для конкретных данных?

Вещь, конечно забавная, и возможно где-нибудь, кому-нибудь и нужная. Вот только в реальных задачах неизменяемые текстовые данные редко встречаются.

x86_64 ★★★
()
Ответ на: комментарий от st4l1k

Стану отрицать. а вот если будете сравнивать с gcc 4.x то не стану.

Пора заканчивать с веществами. Вы против сравнения компилируемых языков, зато вы предлагаете сравнить C и gcc 4.x. Т.е. язык и компилятор. Мои таблетки, увы, бессильны...

Vudod ★★★★★
()

Отличный, современный язык, теперь ещё и с JIT-компилятором. Предназначенный для решения конкретных задач, а не для жонглирования анафорическими катаморфизмами, как во всяких лиспохаскелях, чьи фанбои смачно SOSNOOLEY с выходом этой новости.

anonymous
()
Ответ на: комментарий от lucentcode

Не связаны. Но GIL не позволит Python работать с той-же скоростью, что и компилируемые ЯП, и даже близко к ним приблизится...

GIL не имеет отношения к однопоточным операциям, поэтому в них никак не помешает. Если же вы про многопоточные, то сдесь работа ведётся, хотя пока выход в использовании multiprocessing.

Vudod ★★★★★
()
Ответ на: комментарий от PolarFox

Конкретных задач по перемещению NPC в играх.

Вообще-то, Lua — язык общего назначения. Что не так?

anonymous
()
Ответ на: комментарий от Vudod

бяда. Не сравнивайте pypy (конкретную реализацию) с языком си. У си него много реализаций под разные платформы, с разным быстродействием. И в си нема строк, и как вы напишите на си реализацию так и будет работать. Напишите криво будет медленно напишите хорошо быстро будет.

st4l1k ★★
()
Ответ на: комментарий от Vudod

а есть тесты, где pypy для некоторых тестов обработки строк даже нэйтивный код превосходит?

iddqd
()

Новость вообще русским человеком писалась? Это тихий ужас.

vovans ★★★★★
()
Ответ на: комментарий от Vudod

Смотрим http://morepypy.blogspot.ru/2011/08/pypy-is-faster-than-c-again-string.html
читаем :

Overall PyPy is almost 2x faster. This is clearly win for dynamic compilation over static - the sprintf function lives in libc and so cannot be specializing over the constant string, which has to be parsed every time it's executed. In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant.

А потом осмысливаем.

anonymous
()
Ответ на: комментарий от mva

Одно из двух. Либо ты написал что-то не то, либо Дреппер не умеет программировать, а glibc — кусок говна.

Reset ★★★★★
()
Ответ на: комментарий от D_Lans

Представь себе, можно! И называется от PyPy, работает на некоторых бенчмарках быстрее С. Твой К.О.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.