Lua Jit 2.0

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

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

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

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

Тут сравнение lua разных версий и разных архитектур с luajit

http://luajit.org/performance.html

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

http://luajit.org/performance_x86.html

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

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

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

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

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

Годнота-то какая.

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

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

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

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

Ничего себе математика

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

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

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

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

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

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

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

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

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

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

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

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

смишно.

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

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

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

смишно.

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

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

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

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

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

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

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

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

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

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

Use Numba, nigga.

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

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

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

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

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

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

Не мешайте людям гордится скоростью pypy )))

И если можно ссылку на статью.

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

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

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

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

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

Конкретных задач по перемещению NPC в играх. Хотя хаскель и этой задачи не решает.

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

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

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

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

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

Смотрим 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.

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

А как обстоят дела у LUA с большими целыми числами?

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

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