Возврат значения из замыкания

Нет, это функциональный ЯП. В то время никаких таких «элементов ФП» не было. Это сейчас ФП языков куча и речь зашла о «элементах», а классическое ФП - это именно лисп. ГЦ, замыкания, лямбды, динамика.

Пруф. Докажи, что термин «функциональное программирование» к говнолиспу применялся.

а проект писал я один

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

даже осознать потенциал технологии не способен

Ага, ага, потенциал говнолиспа уже более 50 лет вся индустрия осознать не способна. Потенциал, та-акой потенциал!

Проверим. Получается, ты лжешь про «обычные компиляторы»:

Я же тебе сказал - засунь внутренний цикл в функцию, которая не будет заинлайнена.

Если even определена в этом же модуле, и оптимизация просматривает весь модуль - сделает; если even из другого модуля этой же программы, и оптимизатор просматривает всю программу - то же самое.

Фишка трассирующего джита как раз в том, что ему пофиг где что и как определено - он же анализирует чистую последовательность команд ВМ. Ну и пример всегда можно несколько усложнить, после чего уже компилятор справляться не будет.

Опять проблемы препроцессоров, ты заебал. Я не говорил про препроцессоры. я говорю про _макросы_.

Если ты про свой сраный рэкет, то вали из этой темы. Мне не интересно. Мы тут какашки размазываем по вонючему общелиспу.

Я уже ответил - по очереди исполняет формы (a) (b) (c) (d).

Только не в общелиспе. А в рэкете prog нет, там begin.

Ну и макрос может ровно то же самое.

Макрос может изгадить локальные определения.

Если по ссылке передали - тоже не знаем.

Какие тут все невнимательные! a в f никто не передавал. А нагадить оно все равно может.

То есть в случае гигиены не бывает такой ситуации, что у тебя _случайно_ захватило какой-то идентификатор.

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

Фишка трассирующего джита как раз в том, что ему пофиг где что и как определено - он же анализирует чистую последовательность команд ВМ. Ну и пример всегда можно несколько усложнить, после чего уже компилятор справляться не будет.

Ну и на кой твой джыд нужен, когда есть LTO?

Я же тебе сказал - засунь внутренний цикл в функцию, которая не будет заинлайнена.

А зачем писать быдлокод? Да и у нас LTO есть, все равно все будет заинлайнено неизбежно.

Фишка трассирующего джита как раз в том, что ему пофиг где что и как определено - он же анализирует чистую последовательность команд ВМ

Я знаю. Но к динамике это отношения не имеет - VM ровно с тем же успехом может быть предназначена для статического языка. Кстати, Mozilla уходит (или уже ушла) от tracing JIT в пользу статического вывода типов.

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

Мы тут какашки размазываем по вонючему общелиспу.

То есть ты о препроцессорах. Так и надо говорить. А то вы вконец уже заебали: «лисп», «макросы», когда предполагается «общеговно», «препроцессорная хуета». Называй вещи своими именами, блять.

А в рэкете prog нет, там begin.

Да, там begin, но это не важно. (define-syntax prog (syntax-local-value #'begin)).

Какие тут все невнимательные! a в f никто не передавал. А нагадить оно все равно может.

Ну это значит опять гигиену сломали.

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

не макрос, а препроцессорную хуйню. С макросами все ок.

А зачем писать быдлокод? Да и у нас LTO есть, все равно все будет заинлайнено неизбежно.

Это просто пример. При чем тут написание быдлокода? И если функция большая то нет, она не будет заинлайнена. В любом случае, я вообще не понимаю, чего ты кукарекаешь? Есть факт - luajit на некоторых тяжелых вычислительных задачах обогнал даже фортран. Твое кукареканье уже ничего не изменит.

Ладно, раз ты тут за «макросы» вписываешься. Скажи, что делает вот такое говно?

(yobamakra (begin (print «бдыг») (yoba1)) (begin (print «йопа») (yoba2)))

А потом я тебе определение yobamakra покажу.

И если функция большая то нет, она не будет заинлайнена.

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

Есть факт - luajit на некоторых тяжелых вычислительных задачах обогнал даже фортран.

Пруф или лжешь.

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

Как ты ее поднимешь дебил? Тебе придется вынести условие из одной функции и воткнуть ее в другую функцию:

for (i = 0; i < 1000; i++){
   for (j = 0; j< 1000000; j++) yoba3(i, j);
}

def yoba3(i, j){
   if even(i) then yoba1(i) else yoba2(j);
}

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

Есть факт - luajit на некоторых тяжелых вычислительных задачах обогнал даже фортран.

задачи и код в студию

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

Промышленная серьёзная разработка - это когда два десятка долдоёдов не может написать одну программу? Тогда, да, не годится. На лиспе пишут умные, способные люди, им даже специально завалить проект профессиональная гордость не позволит. Всё делается в лучшем виде.

Ага, ага, потенциал говнолиспа уже более 50 лет вся индустрия осознать не способна. Потенциал, та-акой потенциал!

Ты лучше скажи, на чём и что пишешь, и чего в жизни добился?

Ладно, раз ты тут за «макросы» вписываешься. Скажи, что делает вот такое говно?

Если yobamacra - функция, то что угодно. Если yobamacra - не функция, то тоже что угодно.

Пруф или лжешь.

Я же тебе уже ответил - на шутауте было. Гугли.

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

Там нету никакого цикла. он в другой функции. А в той, где предикат - цикла нет.

Если нет, то ее нельзя выносить, и джыд этого не сделает.

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

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

Я знаю. Но к динамике это отношения не имеет - VM ровно с тем же успехом может быть предназначена для статического языка.

Да, конечно. Вообще tracing JIT был приведен именно потому, что пусть он не обгонит статику, но все динамические проверки на подобных лупах уберет гарантировано. С этим он как раз справляется на отлично.

Кстати, Mozilla уходит (или уже ушла) от tracing JIT в пользу статического вывода типов.

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

Нет, Если yobamakra - функция, то сначала будет выведено в stdout «бздык», будет исполнена (yoba1) со всеми сайд-эффектами, потом будет выведено «йопа» и будет исполнено (yoba2). И потом будет вызвана функция yobamakra со значениями (yoba1) и (yoba2) в качестве аргументов. И плевать мне на то, как определена сама функция, я и без этого достаточно знаю про семантику этого куска кода.

А вот с макросом все совсем не так. Макрос какой-то ублюдок определил так:

(define-syntax yobamakra
  (syntax-rules ()
    [(_ a b) (begin b b b a a)]))

на шутауте было.

не было, там только lua для one core

Промышленная серьёзная разработка - это когда два десятка долдоёдов не может написать одну программу?

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

Тогда, да, не годится. На лиспе пишут умные, способные люди,

Бугагашеньки! Ты сделал мой день, чувак!

им даже специально завалить проект профессиональная гордость не позволит. Всё делается в лучшем виде.

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

Ты лучше скажи, на чём и что пишешь, и чего в жизни добился?

Ну да, конечно же, «спервадобейся». Пишу на Java и C++, добился денег, почета и уважения.

Я же тебе уже ответил - на шутауте было. Гугли.

Пруф или лжешь. Ничего там не было, и уж точно нет сейчас.

Там нету никакого цикла. он в другой функции. А в той, где предикат - цикла нет.

Ну и что? У нас LTO. Inlining не обязателен, можно делать specialization (и как следствие cross-function code motion).

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

Любому современному компилятору наплевать на функции и границы между ними.

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

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

Нет, Если yobamakra - функция, то сначала будет выведено в stdout «бздык», будет исполнена (yoba1) со всеми сайд-эффектами, потом будет выведено «йопа» и будет исполнено (yoba2).

Да вот хуй ты угадал, порядок вычисления аргументов не фиксирован. Именно по-этому в аргументы функции никто сайд-эффекты и не сует, да.

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

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

Нет, это когда пара сотен людей пишут и поддерживают промышленную систему несколько десятилетий.

Т.е., когда пишет одна сотня разрабов и поддерживает всего-то 9,5 лет - то разработка уже не промышленная и не серьезная, а так, погулять вышла :D

Тебе придется вынести условие из одной функции и воткнуть ее в другую функцию:

И что, у тебя от этого понос случится? Ну так это твои личные половые трудности. Компилятору с LTO наплевать на границы функций.

статический компилятор - нет, не может.

У тебя серьезные проблемы с головой. Лечись. Банальная специализация это сделает.

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

И что? Специализация как раз эту ситуацию разрулит. А вот трассирующему джыду тупо времени не хватит.

Как выясняется, фанбои лишпика тут даже проекта из более чем одного человека с более чем одним пользователем предъявить не могут.

Как выясняется, фанбои лишпика тут даже проекта из более чем одного человека с более чем одним пользователем предъявить не могут.

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

Да вот хуй ты угадал, порядок вычисления аргументов не фиксирован.

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

А теперь оберни аргументы в лямбду

А на кой хер я стану это делать? Лямбды, кстати, тоже говно.

Пруф или лжешь. Ничего там не было, и уж точно нет сейчас.

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

У нас LTO.

расшифруй.

Inlining не обязателен

Еще раз, недоумок, куда ты вынесешь цикл, если цикл и предикат _в разных функциях_?

Любому современному компилятору наплевать на функции и границы между ними.

Да ты клоун какойто. Ну возьми и проверь тот же самый пример на том же ллвм. Такая оптимизация которую ты предлагаешь _не может_ быть произведена. Это запрещено.

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

Гм. Я затрудняюсь придумать задачу, где итерация будет _быстрее_ джита.

Специализация (и вообще суперкомпиляция) мощнее любого трассирующего джыда.

Любая статическая оптимизация универсальна. А трассирующий джит делает те же самые оптимизации но в рантайме. Они заведомо быстрее статических, т.к. у джита больше информации об исполняемом коде. Никакой компилятор не уберет dead code, если этот dead code только на некоторых итерациях таковой. И никакая суперкомпиляция или специализация не помогут. А джит - уберет. Именно на тех итерациях, на которых это возможно.

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

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

Лямбды, кстати, тоже говно.

А, ну ясно.

Я предположу, что ленивый семантика тоже говно?

Да вот хуй ты угадал, порядок вычисления аргументов не фиксирован.

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

А зачем ему быть фиксированным? В разных там пуре-фп языках порядок вычисления вообще не фиксированный и это не баг, а фича.

Лямбды, кстати, тоже говно.

Убило.

На помоечке место тем, кто сует сайд-эффекты в аргументы функции.

На помоечке место уродам, не понимающим ценности отладочной печати.

Вставить на место любого выражения (begin (print что-то) выражение) - это офигенно полезно.

Я предположу, что ленивый семантика тоже говно?

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

Блять, естественно что _сейчас_ там только lua. luajit почти сразу убрали.

В разных там пуре-фп языках

А я тут чем третью страницу занимаюсь? Доказываю, что ФП - говно.

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

На помоечке место уродам, не понимающим ценности отладочной печати.

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

Вставить на место любого выражения (begin (print что-то) выражение) - это офигенно полезно.

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

Доказываю, что ФП - говно.

Вау. Могу сказать, что у тебя пока ничего не получилось.

расшифруй.

Link-time optimizations. Означает это то, что все функции компилятору доступны, и с ними можно делать все, что угодно, в том числе менять сигнатуру (потому как доступны и все места, где функция вызывается).

Еще раз, недоумок, куда ты вынесешь цикл, если цикл и предикат _в разных функциях_?

Ты больной. По какому такому уродливому праву ты требуешь, чтобы все оптимизации делались только в пределах одной функции?

Ну возьми и проверь тот же самый пример на том же ллвм. Такая оптимизация которую ты предлагаешь _не может_ быть произведена. Это запрещено.

Это не «запрещено», а не реализовано. Хотя, даже в llvm есть зачаточная форма специализации: http://llvm.org/devmtg/2008-08-23/llvm_partial.pdf

Гм. Я затрудняюсь придумать задачу, где итерация будет _быстрее_ джита.

Любые DSP-задачи. Тупо любые.

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

Идиот. Статически мы можем потратить часы на оптимизацию. А в джыда есть только доли секунды.

Никакой компилятор не уберет dead code, если этот dead code только на некоторых итерациях таковой.

Еще раз: specialization, partial evaluation, суперкомпиляция. Не тупи.

Компилятору с LTO наплевать на границы функций.

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

Банальная специализация это сделает.

Банальная специализация специализирует код _статически_. То есть на тех значениях которые могут _в принципе_ попасть в данное место в соовтетствии с control-flow. А трассирующий джит - это и есть та самая специлазиация но происходящая динамически - то есть специализация на значениях при условии исполнения данной ветки программы.

Чем больше информации о диапазоне значений - тем более эффективна специализация. На этом принципе и основан трассирующий джит. И по-этому он будет работать лучше любого статическог оспециализатора - в рантайме _всегда_ больше информации.

И что? Специализация как раз эту ситуацию разрулит.

Он разрулит только то, что известно статически. А ветка исполнения статически неизвестна.

А вот трассирующему джыду тупо времени не хватит.

Именно поэтому он работает эффективно только на примитивных ЯП вроде луа - джит-компиляция в этом случае неощутима.

luajit почти сразу убрали.

точно, только он таки сливал и Java, и C и С++, а примеры для фортрана тогда были просто недопилены, что сейчас исправлено

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

Да нет никаких функций, тупица! На этапе LTO компилятору доступен ВЕСЬ код. И функции, и все места вызова этих функций. Наплевать на семантику конкретных функций, ее можно менять как угодно, потому как у нас есть гарантия, что никто за пределами доступного нам кода этими функциями не воспользуется.

Банальная специализация специализирует код _статически_. То есть на тех значениях которые могут _в принципе_ попасть в данное место в соовтетствии с control-flow.

И это более общий случай. Более эффективное решение.

А трассирующий джит - это и есть та самая специлазиация но происходящая

Это крайне примитивная форма специализации, потому как у джыда ни хера нет времени на более сложный анализ.

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

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

Он разрулит только то, что известно статически. А ветка исполнения статически неизвестна.

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

Именно поэтому он работает эффективно только на примитивных ЯП вроде луа - джит-компиляция в этом случае неощутима.

От сложности языка тут ничего не зависит. Ну, исключим мы aliasing analysis - остальные то проблемы все останутся.

Link-time optimizations.

Значит я верно понял. То есть это никак не связано с «границами функций» и никакого чудесного выноса за цикл тут не будет, как и ожидалось.

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

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

Ты больной. По какому такому уродливому праву ты требуешь, чтобы все оптимизации делались только в пределах одной функции?

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

Это не «запрещено», а не реализовано. Хотя, даже в llvm есть зачаточная форма специализации:

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

Любые DSP-задачи. Тупо любые.

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

Идиот. Статически мы можем потратить часы на оптимизацию. А в джыда есть только доли секунды.

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

Еще раз: specialization, partial evaluation, суперкомпиляция. Не тупи.

Еще раз - никакой компилятор не уберет dead code если он такой только в одной из веток исполнения. Это _запрещено_. Компилятор не имеет права менять семантику кода. трассирующий джит - это развитие специализации, специализация, которая проводится в рантайме, что резко повышает ее эффективность.

В разных там пуре-фп языках

А я тут чем третью страницу занимаюсь? Доказываю

Зачем?

что ФП - говно.

Что ты подразумеваешь под фп?

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

http://lua-users.org/lists/lua-l/2009-11/msg00039.html

ах, я знаю, это заговор пользователей луа.

То есть это никак не связано с «границами функций» и никакого чудесного выноса за цикл тут не будет, как и ожидалось.

Идиот.

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

Ты тупой. При специализации функция дублируется.

Программа до оптимизации и после должна работать одинаково.

Вся программа. Целиком.

Если у тебя в функции Х не было никаких проверок - а ты вынесешь и проверки будут, то семантику изменится и функция будет давать другой результат.

Какое тебе дело до семантики отдельных функций?!?

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

Там описана самая примитивная форма специализации. Бывает и поумнее - если мы можем вывести, что при таких-то значениях аргумента может быть применена такая-то оптимизация, то проверка на это значение выносится наверх функции (или просто участка кода), код дублируется, и оптимизация применяется.

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

Да да да. Луа-ламер явно никогда DSP не видел. Я еще и посмеялся бы, глядя на то, как ты в picoblaze этот самый жыт засовываешь.

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

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

Еще раз - никакой компилятор не уберет dead code если он такой только в одной из веток исполнения.

Идиот. Любой вменяемый суперкомпилятор сдублирует код для такой ветки.

что резко повышает ее эффективность.

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

Ну а пруфов-то как не было, так и нет. Следовательно, луа-фанбои лгут, а фортран как был в десятки раз быстрее их говняшки, так и остается.

На этапе LTO компилятору доступен ВЕСЬ код.

Да, я вкурсе.

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

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

И это более общий случай. Более эффективное решение.

Ты ебала чтоли? Специализация в том и состоит, что общая функция заменяется частной. И чем более частная функция (чем больше ограничений на домен) тем более эффективна оптимизация.

Это крайне примитивная форма специализации, потому как у джыда ни хера нет времени на более сложный анализ.

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

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

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

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

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

От сложности языка тут ничего не зависит.

Тут все зависит _только_ от сложности языка. Больше ни от чего.

остальные то проблемы все останутся.

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

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

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

Специализация в том и состоит, что общая функция заменяется частной. И чем более частная функция (чем больше ограничений на домен) тем более эффективна оптимизация.

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

Для специализации и не надо сложного анализа, специализация - это одна из простейших оптимизаций

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

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

Идиот. Ты вообще никаких DSP-задач не видел никогда.

Так в том и дело, что специализация не занимается генерацией разных версий ф-й для всевозможных значений аргументов

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

(это невозможно в силу их количества)

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

Тут все зависит _только_ от сложности языка. Больше ни от чего.

Идиот. На этом уровне любой язык будет не сложнее чем LLVM IR.

Не забывай, что все тяжеловесное сделано еще до джит-компиляции.

А как раз эффективнее всего это самое тяжеловесное делать ПОСЛЕ специализации. Всякий агрессивный constant propagation, например, основанный на нем DCE, loop invariant motion, loop fusion, векторизация (само по себе очень тяжелая задача) и тому подобное.

Идиот.

Вам того же.

При специализации функция дублируется.

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

Вся программа. Целиком.

Да, именно так.

Какое тебе дело до семантики отдельных функций?!?

Потому что, ВНЕЗАПНО семантика программы зависит от семантики отдельных ее частей.

Там описана самая примитивная форма специализации. Бывает и поумнее - если мы можем вывести, что при таких-то значениях аргумента может быть применена такая-то оптимизация, то проверка на это значение выносится наверх функции

Замечательно. При каких значениях аргумента в нашем случае может быть применена оптимизация и какая?

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

Нет, не можем, это алгоритмически неразрешимая задача. На практике ничего и нихуя ты не выведшь. По-этому никто еще и не написал таких мифических специализиторов. Это уже не говоря о том, что не факт что такой вынос не _замедлит_ работу программы. В статике мы это не сможем предсказать. Для этого надо статически узнать, какой участок кода какое время будет выполняться, что невозможно (снова лагоритмически неразрешимая задача). Тем более, что это может зависеть от пользовательского ввода, не говоря о том, что в этом случае будет экспоненциальный рост специализированных инстансов. Прекращай уже свое бестолковое кукареканье, да.

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

а при специализации не надо перебирать никакие «эффективные варианты». inlining, loop unrolling, folding, constant propagation, dead code elimination - вот и вся специализация. При этом первые два пункта выполняются «автоматом», то есть их делать не ндао, они уже сделаны благодаря принципам работы джита.

Идиот. Любой вменяемый суперкомпилятор сдублирует код для такой ветки.

Это пушка, блядь. Ты сколько суперкомпиляторов знаешь, ебанько, чтобы из них еще выбирать «вменяемые» и «невменяемые»?