LINUX.ORG.RU
ФорумTalks

Автор LuaJIT вернулся к разработке и планирует выпуск LuaJIT 3.0

 , , , ,


0

3

https://www.opennet.ru/opennews/art.shtml?num=65795:

Майк Полл (Mike Pall), создатель JIT-компилятора LuaJIT, отошедший от активной разработки проекта в 2015 году и ограничивавшийся с тех пор редким сопровождением ветки 2.1 (github.com), вернулся к активной работе над проектом и опубликовал план синтаксических расширений будущей ветки LuaJIT 3.0.

Среди предлагаемых для LuaJIT 3.0 расширений:

  • Битовые операторы в виде встроенного синтаксиса вместо вызовов функций bit.*: ~a (NOT), a & b (AND), a | b (OR), a ~ b (XOR), a << b, a >> b (логический сдвиг) и a ~>> b (арифметический сдвиг). XOR обозначен как ~, поскольку символ ^ в Lua занят возведением в степень.
  • Альтернативные («привычные») операторы в стиле C/JavaScript: ! (not), && (and), || (or) и != (~=).
  • Оператор целочисленного деления // с округлением в сторону минус бесконечности и метаметодом __idiv (как в Lua 5.3+).
  • Тернарный оператор a ? b : c с поддержкой сокращённого вычисления.
  • Оператор безопасной навигации ?. (a?.field, a?.[key], f?.(...), obj?.:method(...)), возвращающий nil, если левый операнд равен nil.
  • Оператор объединения с nil a ?? b, возвращающий b, только если a равно nil.
  • Составные операторы присваивания: +=, -=, \*=, /=, //=, %=, &=, |=, ~=, <<=, >>=, ~>>=, ..= и ??=. Индексное выражение в левой части вычисляется однократно.
  • Оператор continue для перехода к следующей итерации цикла, оформленный как «мягкое» ключевое слово (можно продолжать использовать как имя переменной).
  • Объявление const — блочная неизменяемая привязка локальной переменной; запрещены переприсваивание и повторное объявление в той же или вложенной области видимости (также «мягкое» ключевое слово).

В обсуждении дополнительно затрагиваются ещё не вошедшие в спецификацию идеи: выражение сопоставления с образцом через ключевое слово in, индексируемый тип для vararg (...varg, varg[i]), краткий синтаксис лямбд (|x| -> expr), оператор отложенного выполнения defer в стиле Go/Zig и присваивание в условии (if local x = ... then).

Появление расширений вызвало и критику: часть участников отметила, что нововведения окончательно превращают LuaJIT в отдельный язык, несовместимый с эталонным Lua 5.1. На это Полл ответил, что «этот корабль уплыл уже очень давно».

Документацию по языку планируется консолидировать в отдельное самостоятельное описание, в котором каждое расширение будет помечено версией, в которой оно появилось.

★★★★★
Ответ на: комментарий от MoldAndLimeHoney

На C++ есть и Luau (тоже с JIT) от Roblox, и Pluto. Но до популярности исходного Lua им ещё гнать и гнать.

dataman ★★★★★
() автор топика

Важным преимуществом LuaJIT является то, что он не ломает обратную совместимость ни в языке, ни в C API. PuC Lua постоянно ломает и то, и другое. Я считаю большой ошибкой использовать PuC Lua для чего-либо, лучше взять легковесные интерпретаторы JavaScript.

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

Не, не лучше. Луа прекрасен минимализмом и продуманностью. Я пишу сейчас и на том и на том. Тот же луажит всего в 2-2,5 раза медленнее ручного кода на ассемблере например. Лишен лютых косяков ява-скрипта в плане синтаксиса. Ничего лишнего, есть все нужное, не жрет, не требует ресурсов.

Простой пример - конкатенацию сравни там и там.

Хотя, конкретно PuC Lua не пробовал.

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

Не, не лучше. Луа прекрасен минимализмом и продуманностью.

Во-первых, 4.2. Во-вторых, даже если бы это было так, это не имеет значения, если обратная совместимость постоянно ломается.

Хотя, конкретно PuC Lua не пробовал.

PuC Lua — это стандартная реализация с lua.org :)

Её так называют, потому что авторы из католического университета Рио-де-Жанейро (PUC-Rio).

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

Ну тогда он прекрасен. Я же говорю - пишу на том и на том. На фоне луа, ява-скрипт кажется нагромодением говна и палок - нужно все время следить, чтобы что то не то или не туда не сделать. Проще вообще писать на ts.

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

Даже если бы это было так, к особенностям скриптовых языков можно привыкнуть. Я не хочу разводить срач на эту тему.

И привыкнуть проще, чем каждый раз вникать в то, что в очередной раз поломали в новой минорной версии, глазами смотреть на весь код и переписывать. Причём ломают без причины. Вот убрали math.atan2 — он кому-то мешал? Может быть, в новой версии завезли что-то, что позволяло бы более идиоматично выразить эту операцию? Нет, просто так.

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

Полностью согласен - ко всем особенностям можно привыкнуть. Тут прогнал тесты и с удивлением узнал, что js в несколько раз быстрее луа. Что то луа совсем забросили похоже.

У меня луа был по сути первым осознанным языком - я просто предвзят. Для меня он лучший просто подсознательно.

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

Дополню: убирание math.atan2 — не показательное изменение. Вот был у меня код:

for iface, params in pairs(t) do
    -- strip out "label" from the interface name
    iface = iface:gsub(':.*', '')
Его нужно переделывать. Потому что теперь изменять итератор нельзя. Нужно объявлять новую переменную в этой области видимости, которая будет shadow’ить старую:
    local iface = iface:gsub(':.*', '')

Ради чего? У меня нет ответа на этот вопрос.

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

А как ты собрался использовать? У них свой форк - смесь луажит и луа5.4, если я не ошибаюсь. Что они добавят, то и будешь использовать.

Чисто технически - уже используется и да, можно. Но это делать должны разрабы проекта.

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

ха! где-то раньше пару~тройку десятков лет я подобное уже видел :-)

а потом в J# переименовали кажется

user_id_68054 ★★★★★
()

Среди предлагаемых для LuaJIT 3.0 расширений:

Не нужно. Уродуют простой и лаконичный язык. Так им и до JavaScript не далеко.

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

Полностью согласен - ко всем особенностям можно привыкнуть. Тут прогнал тесты и с удивлением узнал, что js в несколько раз быстрее луа. Что то луа совсем забросили похоже.

Язык не может быть быстрей или медленней, тем более когда ты сравниваешь JS и Lua. Ты сравнивал конкретные реализации, а не языки.

Что касается скорости - у Lua фишка в том, что её реализация крохотная. Там по-моему в пару сотен килобайтов умещается всё. А теперь посмотри на V8, с которым ты, скорей всего, сравнивал. Там десятки мегабайтов, разница в сотни раз.

А если хочешь более честное сравнение - ищи крохотные реализации вроде QuickJS и сравнивай с ними. Это будет интересней.

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

Занятно. QuickJS в 2,5раза больше по размеру и в десятки раз иногда медленнее.

Но еще кое что интересное - луа хуже в конкатенации в 8-157!!! раз. Кроме однобайтовых строк.

Вот эта скорость конкатенации меня бесила последние три года. Оптимизировал всеми методами - реально узкое место.

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

А как ты оптимизировал? По идее правильный способ это сначала создать массив строк, а потом их все склеить через table.concat.

В JS скорей всего какие-то оптимизации хитрые для того, чтобы тупой код работал быстро. В Lua видимо такого нет, что написано, то и выполняется.

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

Да! Через тейбл быстрее всего получалось. Это я тоже пробовал. Но проблема в пересборке строк.

Представь, у нас ограниченное место для хранения информации. именно по количеству ключей в таблице. Вместо того чтобы держать каждый кусок информации в своем ключе, мы используем бинарные строки.

	["Ёждк"] = {
		["pets"] = {
			["bbb"] = "",
		},
		["monoObjects"] = {
			"0ka0ka00t00t0ka0ka0ka0ka00t00t00t0ka00t0ka0ka00t0ka0ka00t00t00t00t00t0ka0ka0ka0ka00t0ka0ka00t0ka0ka0ka0ka0ka00t0ka0ob0ka0ka0ka00t00t00t0ka0ka0ka0ka0ka00t00t0ka0ka0ka00t0ka0ka0ka0ka00t0ka00t0ka0ka00t0ka0ka0ka0ka0ka0ka0ka0ka0ka0ka00t00t0ka0ka0ka0ka0ka00t0ka0ka0ka0ka0ka0ka0ka0ka00t0ka0ka0ka0ka0ka00t00t", -- [1]
			"nilnil CJ Ccnilnilnilnil CQ CX CWnil CUnilnil CUnilnil Cc CX CJ CN CSnilnilnilnil CNnilnil CPnilnilnilnilnil CZnilnilnilnilnil CP CJ COnilnilnilnilnil CP C^nilnilnil C`nilnilnilnil COnil CWnilnil CYnilnilnilnilnilnilnilnilnilnil Cb CWnilnilnilnilnil CWnilnilnilnilnilnilnilnil CZnilnilnilnilnil C- CQ", -- [2]
			"nilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnilnil", -- [3]
		},
		["таймер"] = "nilnilnilnilnil2;Q1*5nil2S| $r C|1N@ I| kV GQnilnilnilnilnilnilnilnilnilnilnilnilnilnilnil",
	},

Строки неизменны, значит чтобы записать параметр, надо пересборать строку. Представь, что таких операций много.

Когда это единичные запросы - тут проблем нет, пусть оно будет даже не шибко шустрое. А теперь представь, что нам нужно сформирвать статистику по всей таблице. И тут наступает кирдык.

Оно мало того, что тормозит, так еще и память выжирает.

А теперь представь работу со строкой на 30 тысяч символов. Тут у quickjs преимущество перед луа в 127 раз!!! На нем вполне можно было бы работать, а на луа уже невозможно.

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

Честно говоря мало что понял. Но посоветую посмотреть на структуру данных Ropes. Она очень редко нужна. Но когда нужна - альтернатив ей просто нет. Думаю, что на базе Lua будет не так уж сложно реализовать эту структуру данных. Там можно делать очень быстрые манипуляции со строками: соединять их; брать подстроку и тд. Понятно, что это уже будет не строка в понимании Lua, а эдакое дерево из строк, и код работы с символами нужно будет писать в терминах API для работы с этими Ropes и тд. Но может и поможет. Я за всю жизнь один раз наткнулся на подобную ситуацию, в которой наивный подход к работе со строками просто не работал, скорость была неудовлетворительная, а переход на Ropes сразу решил все проблемы.

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

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

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

Я пробовал даже префиксное дерево. Чем больше ты усложняешь код и пишешь своих структур, тем медлененнее все это работает. Ладно бы был доступ к низкоуровневым языкам, я мог бы сделать модули на раст или сишке. А когда ты только в рамках луа песочницы, тут жопа.

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

Тут важна алгоритмическая сложность и всё будет работать мгновенно. Если медленно работает, значит алгоритмы подобраны неправильно. Нет никаких чудес, которые позволяют жаваскрипту работать в 127 раз быстрей. Только то, что в интерпретаторе жаваскрипта под капотом какие-то другие алгоритмы и структуры данных, которые под твой код подошли лучше. И ничего не мешает в Lua их реализовать своими силами.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от vbr
================================================================================
                    ИТОГИ ТРЁХ ТЕСТОВ (WoW 3.3.5 Lua 5.1)
================================================================================

ТЕСТ 1: 500 ПРАВОК В СЕРЕДИНЕ СТРОКИ
─────────────────────────────────────────────────────────────
Длина строки  | Обычный .. | table.concat | Rope
──────────────+────────────+──────────────+──────────
100 б         |   0.7 мс   |    2.0 мс    |   6.4 мс
300 б         |   0.6 мс   |    2.1 мс    |   6.0 мс
500 б         |   1.1 мс   |    2.0 мс    |  10.6 мс
1000 б        |   2.8 мс   |    2.9 мс    |  11.0 мс
2000 б        |   3.6 мс   |    3.4 мс    |   4.7 мс
3000 б        |   2.5 мс   |    3.9 мс    |   5.0 мс
──────────────+────────────+──────────────+──────────
СРЕДНЕЕ       |   1.9 мс   |    2.7 мс    |   7.3 мс
─────────────────────────────────────────────────────────────

ТЕСТ 2: 10 ПРАВОК В РАЗНЫХ МЕСТАХ (3000 б)
───────────────────────────────────────────
Обычный ..    |  0.1 мс
table.concat  |  0.1 мс
Rope          |  0.2 мс
───────────────────────────────────────────

ТЕСТ 3: НАРАЩИВАНИЕ СТРОКИ (1000 × 50 б = 50К)
───────────────────────────────────────────
Обычный ..    |  16.6 мс   уже заметно
table.concat  |   0.3 мс   бог
Rope          |   3.8 мс   в 13× медленнее table.concat
================================================================================

Понимаешь в чем проблема своих реализаций - они пишутся на луа. И тут все, на этом все заканчивается. Потому что инструменты луа написаны на си. И ты никогда не сможешь на луа написать инструмент быстрее того, который был написан на си.

Причем тут зависимость нелинейная от длины строки. Нужно тестировать где что использовать и использовать нужный инстремент ровно по своим длинам.

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

Думаю, что прикрутить к проекту на c++. Назначение – задавать правила для импорта из JSON-файла приложения проверки чеков ФНС в базу домашних расходов. То ли интерпретатор с lua.org, то ли вообще наколхозить список правил самому (сложной логики там, скорее всего, не будет, навскидку просто условия и их комбинации и указания, какую категорию/подкатегорию выбирать при какой комбинации условий – но если этого окажется недостаточно, будет обидно).

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

Ты про какие инструменты? Я про то, чтобы дать возможность пользователю (не программисту) прикручивать к программе свою несложную логику импорта.

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

А, тогда, да тот же луа - неплохой вариант. Главное - универсальный.

LightDiver ★★★★★
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)