Allegro CL 9.0 Free Express Edition стал доступен для загрузки

Или Lua игрушечный? Думаю, IonMonkey, V8 и PyPy делают не меньше.

90% перечисленных оптимизаций спокойно делаются на байткоде, на долю джита остаются только совсем низкоуровневые оптимизации типа RA. Но тут уже дело в том, что перечисленные языки очень низкоуровневые, по сравнению с Racket - практически ассемблеры, рантайм сверхпримитивный, по-этому с оптимизациями никаких проблем нет. Если же язык действительно высокоуровневый со сложным рантаймом, то из-за любого неосторожного чиха джита семантика пойдет по пизде.

Ну и в любом случае все перечисленные оптимизации даже вместе взятые не дают какого-то реально ощутимого прироста - практически вся оптимизация ЯВУ заключается в эвристиках для рантайма и кодогенератора, когда скоростью исполнения неидиоматического кода жертвуют ради скорости исполнения идиоматического. Естественно для каждого антайма и для каждого языка эти оптимизации свои, ничего общего с другими не имеющие.

Нормальные люди так делают:

(define-syntax-rule (car-n name n)
  (define (name lst) (helper n lst)))

(define-syntax (helper stx)
  (syntax-case stx ()
    [(_ 1 lst) #`(car lst)]
    [(_ n lst) #`(helper #,(sub1 (syntax->datum #'n)) (cdr lst))]))

Оптимизации? В байткоде?

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

тот же llvm умеет быть jit-ом.

И делает большинство оптимизаций на IR (что и есть байткод).

Красиво.

это лучшее описание москвы, которое я встречал. зачот ))

у них есть неплохие сервисы. например «Яндекс пробки», «Яндекс карты». очень удобные.

у меня открытие главной тормозит.

У меня --- мгновенно открылось.

90% перечисленных оптимизаций спокойно делаются на байткоде, на долю джита

У тебя какие-то свои, глубоко личные термины. Все перечисленные оптимизации делаются LuaJIT.

Ну и в любом случае все перечисленные оптимизации даже вместе взятые не дают какого-то реально ощутимого прироста

Не дают прироста по сравнению с чем?

Естественно для каждого антайма и для каждого языка эти оптимизации свои, ничего общего с другими не имеющие.
ничего общего с другими не имеющие.

Понятно.

У тебя какие-то свои, глубоко личные термины. Все перечисленные оптимизации делаются LuaJIT.

Да ради бога, пусть они делаются LuaJIT. Как это опровергает тот факт, что на байткоде их делать проще и эффективнее?

Не дают прироста по сравнению с чем?

С эвристиками. RA, констант фолдинги и прочая чушь в совокупности ускорят работу вдвое-втрое максимум. Если же речь об оптимизации рантайма и кодогенерации, то тут мы говорим о росте производительности на десятичные порядки. Например, если у тебя в рантайме есть green threads, то производительность массивно использующей их программы на 99% зависит исключительно от того, как реализована работа этих green threads в рантайме. Ну а оставшийся 1% остается на всякие констант фолдинги (это не говоря уже о том что от устройства рантайма результативность и применимость таких оптимизаций существенно зависит).

Понятно.

Что понятно? Возвращаясь к green threads - что общего в оптимизации этих самых green threads в том рантайме где они есть и в том где их тупо нет? Ничего, очевидно. Или, например, в оптимизации продолжений. Или в работе TCO. Или в реализации ленивости. Или в оптимизации аллокатора гц, который для императивных и для ФП языков должен работать принципиально по-разному. Про какие-то более узкоспециализированные фишки рантайма я уже молчу. Это какой-нибудь низкоуровневый луа или там петон можно компилировать в машкод джитом, и ебашить там же оптимизации, потому что эти языки и есть по сути ассемблер, компилится все напрямую, рантайм ущербен и там нихуя нет, соответственно и оптимизировать нечего - только перекладывание байтиков.

Вон, толксы, настолько оторванное от реального мира место, что там свой Лисп народ изобретает:

Идея для языка программирования

Универсальный компилятор для самых разных парадигм - конец холивара какой язык лучше (начало холивара «какой пак макросов лучше»).

Лет через десять может даже s-выражения изобретут.

У тебя какие-то свои, глубоко личные термины. Все перечисленные оптимизации делаются LuaJIT.

Да ради бога, пусть они делаются LuaJIT. Как это опровергает тот факт, что на байткоде их делать проще и эффективнее?

Это опровергает утверждение:

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

даже теоретически невозможны.

Я полагаю, что ты именно тот анонимус, который это сказал.

Понятно.

Что понятно?

Что ты принадлежишь к какой-то эзотерической компиляторной школе (не удивлюсь, если эта школа состоит из одного тебя), но излагаешь свои взгляды так, будто они являются общепринятыми.

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

А мы уже говорим об оптимизации рантайма? Тогда можно поговорить и об оптимизации алгоритмов исходных программ.

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

Забавно. Примеры высокоуровневых рантаймов будут? И да, есть минимум один рантайм Python с green threads.

И делает большинство оптимизаций на IR (что и есть байткод).

Але, дятел, где LLVM IR, и где Racket VM? Они разного уровня. На уровне стековой машины такие оптимизации никто не делает, ибо нелепо. Для этого есть регистровые VM, со всякими там SSA, блэкджеком и лаборантками.

Замкадышная проктомука такая замкадышная!

Это опровергает утверждение:

В этом утверждении речь о том как работает _конкретный_ jit, а невозможность была указана для сложных рантаймов. Ты в пример привел питон с луа, в питоне и луа вообще tracing jit. Ты, наверное, в курсе, что основной аспект производительности tracing jit - быстрый _интерпретатор_, по-этому такой джит применяется только для очень простых языков (а питон или луа проще даже чистой r5rs scheme), чтобы обеспечить скорость интерпретации, в которую будет упирается работа джита. Тот же джаваскрипт для чистого tracing оказался чересчур сложен.

Что ты принадлежишь к какой-то эзотерической компиляторной школе (не удивлюсь, если эта школа состоит из одного тебя), но излагаешь свои взгляды так, будто они являются общепринятыми.

Ну я даже не знаю. Тот же Mike Pall, видимо, тоже относится к эзотерической компиляторной школе? Ведь если почитать некоторые обсуждения с его участием, то выяснится, что он также считает наиболее важными эвристики в работе оптимизатора, которые заточены под конкретный рантайм/ЯП и весьма ограничено применимы в какой-либо другой ситуации. Он правда обычно это высказывает в контексте работы tracing jita - а именно способа построения trace-графа, его вида и кодогенерации.

А мы уже говорим об оптимизации рантайма?

А разве мы говорили о чем-то другом? В PyPy джит, например, вообще не оптимизирует программу, он оптимизирует именно _рантайм_ (тайт-лупы самого интерпретатора). Если программа выполняется под некоторым рантаймом то по сути такого понятия как «скорость исполнения программы» не существует - есть скорость исполнения виртуальной машины/интерпретатора, в которую входит и работа сборщика, и оптимизация тех или иных фич рантайма и качество сгенерированного кода в том числе, конечно.

Забавно. Примеры высокоуровневых рантаймов будут?

Лиспы, например, или там джаваскрипт (с натяжечкой).

И да, есть минимум один рантайм Python с green threads.

И?

На уровне стековой машины такие оптимизации никто не делает, ибо нелепо. Для этого есть регистровые VM, со всякими там SSA, блэкджеком и лаборантками.

Единственная оптимизация, которая существенно выигрывает от SSA - это RA, это во-первых. Во-вторых, твое знание о байткоде Racket заканчивается на первых двух строчках соответствюущей статьи, иначе ты бы знал, что этот байткод хоть и является высокоуровневым, а по сути есть то же самое SSA (в байткоде нету операции присваивания значения переменной, просто нету). Ну и это представление совершенно не мешает делать constant folding/propagation, cross-module-inlining, lambda-lifting, loop unrolling и некоторые другие преобразования, которые на более низком уровне было как минимум затруднительно сделать (потому что в схеме нету циклов, вместо них хвостовая рекурсия, то есть любой алгоритм (тот же RA) имеет смысл применять только whole-program, иначе результата просто не будет).

Единственная оптимизация, которая существенно выигрывает от SSA - это RA, это во-первых.

Уйди отсюда, ламер.

Без SSA намного труднее делать: constant propagation, agressive DCE, invariant motion (да и вообще любой анализ на инварианты).

что этот байткод хоть и является высокоуровневым, а по сути есть то же самое SSA (в байткоде нету операции присваивания значения переменной, просто нету)

Идиот! Там есть стек - а это констрейны SSA ломает сразу и начисто. Не рассуждай о том, в чем ни черта не смыслишь, лошара.

lambda-lifting

Придурь. Lambda lifting делается задолго до генерации байткода.

которые на более низком уровне было как минимум затруднительно сделать (потому что в схеме нету циклов, вместо них хвостовая рекурсия,

Обратно же придурок. Про эквивалентность CPS и SSA не слышал?

И тот один анонимус.

Идиот! Там есть стек - а это констрейны SSA ломает сразу и начисто. Не рассуждай о том, в чем ни черта не смыслишь, лошара.

Нда, уебок. Если не знаешь нихуя, то молчи в тряпочку. В байткоде Racket нету никакого стека. Если бы ты, долбоеб, хотя бы раз этот байткод видел, то знал бы это. Для особо одаренных дебилов я повторю - байткод Racket имеет SSA-форму.

Придурь. Lambda lifting делается задолго до генерации байткода.

Он делается именно во время компиляции в байткод.

Обратно же придурок. Про эквивалентность CPS и SSA не слышал?

Во-первых, дебилушка, при чем тут эквивалентность CPS и SSA? Во-вторых, дебилушка, если бы ты знал не только баззворды, то был бы вкурсе, что никто на практике CPS-трансформацию при компиляции не производит. Потому что она ТОРМОЗИТ.

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

никто на практике CPS-трансформацию при компиляции не производит.

А можно подробнее? Такую трансформацию делает F# в Async, который на вычислительных выражениях. Еще я делаю на хаскеле, но это так экcперименты... Там просто такая трансформация естественным образом получается, если создать соответсвующую монаду (Cont и производные). Может быть, я вырвал фразу из контекста и неправильно понял?

Ты, наверное, в курсе, что основной аспект производительности tracing jit - быстрый _интерпретатор_

Вполне очевидно, что производительность интерпретатора важна. Про то, что она основная - впервые слышу.

Тот же Mike Pall, видимо, тоже относится к эзотерической компиляторной школе? Ведь если почитать некоторые обсуждения с его участием, то выяснится, что он также считает наиболее важными эвристики в работе оптимизатора, которые заточены под конкретный рантайм/ЯП

Не видел, чтобы он бросался фразами «даже теоретически невозможно».

Тот же джаваскрипт для чистого tracing оказался чересчур сложен.

Причины, по которым Мозилла отказалась от TraceMonkey для JS, применимы ко всем динамически типизированным языкам.

А мы уже говорим об оптимизации рантайма?

А разве мы говорили о чем-то другом?

Да. О возможностях JIT.

Примеры высокоуровневых рантаймов будут?

Лиспы, например, или там джаваскрипт (с натяжечкой).

О как. И в чем же проявляется высокоуровневость Лиспов и JS по сравнению с Питоном?

1ce. Это ты?

В байткоде Racket нету никакого стека.

У-тю-тю. Байткод racket - это expression trees. То есть, неявный стек. Эти expression trees еще надо в плоскую форму привести и регистры каждому подвыражению назначить, чтобы хоть что-то полезное с ними можно было бы делать.

Для особо одаренных дебилов я повторю - байткод Racket имеет SSA-форму.

Ты так жидко уделался, что тебя даже жалко.

Он делается именно во время компиляции в байткод.

Нет, лошара. До компиляции в байткод. Это совершенно отдельный и никак с компиляцией не связанный проход.

Во-первых, дебилушка, при чем тут эквивалентность CPS и SSA?

При том, ничтожество, что loop analysis на CPS делается точно теми же методами.

Во-вторых, дебилушка, если бы ты знал не только баззворды, то был бы вкурсе, что никто на практике CPS-трансформацию при компиляции не производит. Потому что она ТОРМОЗИТ.

Редкостной невменяемости ничтожество! Сначала CPS (смотри снова на тот же «байткод» в Racket, убожество), потом - обратно из CPS, ровно теми же методами, какими перед кодогенерацией делается переход из SSA.

1ce. Это ты?

Да, это я. Чё хотел?

Уважаемый, на ваши-с труды ссылочку можно-с в уважаемых зарубежных интеллектуальных круга-с? Благодарствую-с.

Вот здесь мои главные научные достижения: www.linux.org.ru/show-comments.jsp?nick=Kuka

... по шкале развития лисп-болезни... Шкала, напомню, такая:

1) пишет на лиспе, 2) пишет свой лисп, 3) пишет свой язык, 4) пишет лисп-ОС, 5) конструирует лисп-машину.

Проиграл в голос.

1) пишет на лиспе,

Ну да пишу, как и на Си, Erlang и Tcl, которые покрывают 99.999% моих задач. А что?

2) пишет свой лисп,

Не нужно. Есть уже мощный лисп — СL.

3) пишет свой язык,

Не нужно. Уже все есть и написано.

4) пишет лисп-ОС,

А вот этого бы не помешало. Хотеть. Но эта задача только посильна коммьюнити.

5) конструирует лисп-машину.

Тоже не помешало бы. Для встраивания было бы неплохо. Хотеть.

Вот здесь мои главные научные достижения: www.linux.org.ru/show-comments.jsp?nick=Kuka

Если бы это был кука, то писал бы из под куки. И да, кука ничем не интересен.

А вот этого бы не помешало. Хотеть. Но эта задача только посильна коммьюнити.

Какая ерунда. Зачем нужно коммьюнити? Коммьюнити ненужно. Ведь известно же, что один лиспер за месяц может сделать то, над чем 10 жабщиков будут безуспешно пыхтеть целый год. Про сишников я и не говорю — лиспер их уделает одним мизинцем.

Так что, может, ты просто плохо знаешь лисп? Если бы знал хорошо, давно бы уже сделал свою ОС за пару месяцев. Ведь этот язык мощнее и продуктивнее всех остальных языков, вместе взятых!!!111

Troll harder!

В чём «троллинг»? Разве ты не согласен с тем, что лисп повышает производительность труда программиста на порядки (10-100 раз)?

Разве ты не согласен с тем, что лисп повышает производительность труда программиста на порядки (10-100 раз)?

Только, если в розовых снах зеленых.

Не на порядки, но да, повышает.

Только, если в розовых снах зеленых.

Но ведь mv утверждает, что его коллега за месяц сделал работу, которую за год не смогли сделать несколько Java-программистов! Пусть их было 5, это уже 60 раз. Стало быть, mv лжёт?

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

+1 качество мышления обеспечивает уровень решения

Ну вот и я про то же! А gensym не верит.

Почему не верит.

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

Но если лисп настолько существенно повышает продуктивность разработки, код получается гораздо более качественным, а лисперы — профессионалы с высочайшей квалификацией, то почему никто до сих пор не написал современную LISP OS для x86 и ARM?

История говорит, lisp os вполне были. На lisp hardware (а не C, которым x86/arm является). История же говорит, что просто море сишечных осей для x86 умерло на стадиях от эмбриона до мужчины в расцвете сил.

Т.е. LISP OS в принципе невозможна на x86 и ARM? Почему?

Т.е. LISP OS в принципе невозможна на x86 и ARM?

Возможна. Кто-то даже делает, я название забыл.

Почему?

Потому что «не нужно».

Потому что «не нужно».

Но ведь современные ОС полны архитектурных недостатков, их код огромный и раздутый, развитие заторможено из-за того, что императивный код давно превратился в лапшу. А при помощи новой современной LISP OS можно было бы избавиться разом ото всех этих недостатков!

Но ведь современные ОС полны архитектурных недостатков, их код огромный и раздутый, развитие заторможено из-за того, что императивный код давно превратился в лапшу. А при помощи новой современной LISP OS можно было бы избавиться разом ото всех этих недостатков!

В п...у эти операционные системы, давай лучше бухать!

сруукы!

Перестань писать на лоре.

У-тю-тю. Байткод racket - это expression trees.

Именно так. А expression trees без присваиваний - это SSA.

Эти expression trees еще надо в плоскую форму привести

Не надо. Они и так SSA. Зачем что-то приводить, если оно и так приведено?

Подумай, дебилушка, чем отличается (let ([x 'huy]) (let ([x x]) (pizda x))) от (x1 = 'huy, x2 = x1, pizda x)? Правильно - ничем.

Нет, лошара. До компиляции в байткод. Это совершенно отдельный и никак с компиляцией не связанный проход.

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

При том, ничтожество, что loop analysis на CPS делается точно теми же методами.

И что дальше? Еще раз для особо одаренных - никто не использует CPS-трансформацию.

Редкостной невменяемости ничтожество! Сначала CPS (смотри снова на тот же «байткод» в Racket, убожество)

Байткод Racket никакого отношения к CPS не имеет, дятел.

потом - обратно из CPS

Преобразование «обратно из CPS» не делается, дебилушка. Оно неопределено. Максимум ты сможешь оптимизировать отдельные куски, но, конечно, все равно это говно будет ТОРМОЗИТЬ.

ровно теми же методами, какими перед кодогенерацией делается переход из SSA.

Во-первых, никакого такого «перехода из SSA» не делается - просто после проведенных оптимизаций (то же RA) код уже не будет иметь SSA-формы. Во-вторых - CPS это НЕ SSA. По-этому все твои мокрые мечты к нему весьма слабо применимы. Ты начитался базвордов на википедии (про «эквивалентность», лол), но даже не знаешь, что они означают, и почему CPS считается эквивалентным SSA.

А можно подробнее? Такую трансформацию делает F# в Async

Речь шла о whole-program преобразовании, которое иногда используется в, например, игрушечных схемах для реализации продолжений. Но оно тормозит, как я уже сказал (т.к. код в CPS создает и передает лишнюю санку на каждый вызов), по-этому в серьезных реализациях продолжения поддерживаются на уровне рантайма. Но когда другого способа нет (типа Async в #F) - то на безрыбье и рак рыба, конечно же. Однако тут речь не идет о превращении всей программы в тормоз - преобразуются только некоторые куски (что, с другой стороны, портит совместимость этих кусков с непреобразованным кодом, но это уже совсем другой разговор).

Не видел, чтобы он бросался фразами «даже теоретически невозможно».

Естественно. Он ведь обычно говорит про простые языки без рантайма типа Lua. Там все возможно.

Причины, по которым Мозилла отказалась от TraceMonkey для JS, применимы ко всем динамически типизированным языкам.

Коненчо же нет. все дело было исключительно в сравнительной сложности JS.

Да. О возможностях JIT.

А что с возможностями jit?

О как. И в чем же проявляется высокоуровневость Лиспов и JS по сравнению с Питоном?

В том, что семантика лисп-машины от компьютерного железа на порядок дальше семантики питона, которая почти прямо переводится на машкод. Как я уже говорил - питон язычок простой, проще даже r5rs, если же сравнивать с CL или со схемой с расширениями - это просто смешно. Технологическая разница примерно как между довоенным самолетом и истребителем пятого поколения.

Про то, что она основная - впервые слышу.

Это очевидно, по-моему. tracing jit так работает, что какой бы компилированный джитом код не работал, перед этим он всегда должен быть исполнен интерпретатором (и не раз). При чем большая часть кода и скомпилирована-то никогда не будет - то есть, вообще говоря, в реальности (а не в бенчмарках) бОльшую часть рантайм проводит в режиме интерпретации. Скорострельность того же луаджита объясняется, собственно, не какими-то сверхоптимизациями джита, а тем, что там интерпретатор работает иногда быстрее чем компилированный v8 в машкод джаваскрипт.

А, понятно, спасибо. В F# и Haskell все ограничивается соответствующей монадой, которую еще надо запустить из «обычного» кода.