Цитата

---

Это будет ВМ, в которой хвостовых вызовов нет. И вообще вызовов нет

---

Можно подробнее? Конечно, если тебе эта тема интересна.

Цитата

---

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

---

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

Цитата

---

Можно подробнее?

---

Более продвинутый declaim позволит более детально описывать требования к коду. В идеале можно будет указать какие типы оптимизаций обязательно необходимо произвести.

Цитата

---

Даже в этом случае динамика имеет свой оверхед.

---

Он незначителен.

Цитата

---

Не ну всегда все можно, конечно, но это восход солнца вручную...

---

Можно воспользоваться подходящим фреймворком, конечно, если он есть

Цитата

---

Не понял вопроса, почему тут должен быть какой-то особый способ борьбы?

---

А он и не обязан быть особым. Да и справиться с хорошо спланированной атакой практически невозможно.

Цитата

---

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

---

Что значит "убрать нерекурсивные вызовы"?

Цитата

---

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

---

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

Цитата

---

да просто запретить.

---

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

Цитата

---

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

---

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

Цитата

---

Ну речь шла о "самой быстрой вм", а не о самой выразительной

---

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

Цитата

---

дану?

---

Время — деньги, поэтому в некоторых случаях требуется быстрая компиляция.

Цитата

---

Мне не кажется, что компиляция будет такой уж долгой.

---

А ты попробуй собрать рэкет со всеми его модулями и документацией на стареньком ноуте с pentium III. У меня это заняло почти 8 часов Да и сборка libreoffice - то еще удовольствие
Я думаю, принцип понятен: чем больше применяем оптимизаций, тем дольше компиляция.

Цитата

---

Ну в racket 99% компиляции - это экспанд

---

Откуда такая цифра? 99% - это слишком много.

Цитата

---

и с чего вдруг надо считать сборку доккументации вдобавок?

---

Ты ведь хотел пример длительной компиляции А компиляция страниц документации является неотъемлемым этапом сборки.

Цитата

---

Сам байткод весьма шустро генерится. Ну и джитится тоже шустро.

---

Это потому, что отсутствует оптимизатор промежуточного кода, либо он слабо развит. А также слабо развит оптимизатор машкода (платформозависимые оптимизации), но это скорее проблема gnu lightning.

Цитата

---

Откуда такая цифра? 99% - это слишком много.
Цитата

---

Навскидку
Ну да, много, но компиляция в байткод full-expanded кода быстро и делается. Это и в доках указано. Собственно, если в твоем коде есть хотя бы пара широко используемых macro-generated macro, то время компиляции по сравнению с экспандом пренебрежимо мало.

Цитата

---

Ты ведь хотел пример длительной компиляции

---

длительной компиляции а не сборки же. как деклаймы относятся к сборке документации?

Цитата

---

Это потому, что отсутствует оптимизатор промежуточного кода, либо он слабо развит.

---

А там оптимизировать вобщем-то нечего
суровый инлайнинг, constant propagation, dead code elimination...
Байткод - это фактически тот же full-expanded код.
Собственно, чуть менее чем все оптимизации производятся весьма шустро. медленные оптимизации - редкость, а не правило.

Цитата

---

А также слабо развит оптимизатор машкода

---

Ну да, джит фиговый. Но какой-нибудь libjit генерит на порядок более эффективный код практически так же быстро.

Цитата

---

Это возможно, если код состоит из одних макросов

---

а в racket код и состоит из одних макросов всегда
а то что я имел ввиду (про macro-generated macro) это такое:
(define-syntax-rule (f x) (define-syntax-rule (x a) a))
например
само (define-syntax-rule ...) раскрывается в ооогромную простыню, и мы будем эту простыню получать на каждый вызов f.

Цитата

---

А причем тут деклаймы, если речь шла о длительной компиляции?

---

Это у вас надо спросить

Цитата

---

Так уж и нечего? Для адекватного проведения constant propagation, dead code elimination требуются как минимум два прохода по всему коду модуля. Кстати, constant propagation и dead code elimination затрагивают еще и оптимизацию классических конструкций: if, cond, case и др.

---

ну это всего лишь линейные по длине кода алгоритмы

Цитата

---

Это зависит от реализации

---

Ну речь же о racket. Там структура байткода фактически повторяет full-expanded.

Цитата

---

Смелое заявление

---

Имелось ввиду, что все формы, которые в коде, будут раскрываться. даже если у вас аппликация или константа, то оно будет раскрываться в (#%app ...) и (quote ...).

Цитата

---

Ну и что? Экспанд происходит очень быстро.

---

Нет. Экспанд как раз происходит очень долго

Цитата

---

Тогда как компиляция того же макроса требует предпросмотра

---

Предпросмотра чего?

Цитата

---

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

---

Согласен. я не согласен с тем, что включение оптимизаций повлияет на скорость существенно.

Цитата

---

Или ты думаешь, что все модули скомпилировались мгновенно, а компиляция документации длилась 8 часов?

---

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

Цитата

---

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

---

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

Цитата

---

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

---

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

Цитата

---

А почему она не должна повторять full-expanded код?

---

Да нет, пусть повторяет, я ничего против не имею.

Цитата

---

Так и писал бы код на языке рэкет, а не просто racket код.

---

Непонел, в чем разница?

Цитата

---

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

---

Ну в racket гигиена и синтаксические объекты, так что экспанд как в CL по скорости сделать нельзя.

Цитата

---

Кстати, скорость работы конечного автомата создаваемого, например, syntax-case можно значительно увеличить

---

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

Цитата

---

при использовании локальных переходов, которых нет в рэкет.

---

Как это? Локальные переходы есть в любом ЯП с TCO.

Цитата

---

Так что долгий экспанд - это проблема сугубо рэкета, как языка, так и ВМ.

---

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

Цитата

---

А "существенно" это сколько? Для меня и 5% существенно.

---

5% - это в рамках статистической погрешности. Существенно - раза в два-три.

Цитата

---

А причем тут экспанд, если моя шутка была о времени компиляции? Экспанд является неотъемлемым этапом компиляции. А компиляция документации - один из этапов сборки (компиляции) системы.

---

Напоминаю, о чем шла речь. Речь шла о том, что-де добавление оптимизаций плохо скажется на времени сборки. Я вам указал, что сборка - это большей частью экспанд и сборка документации, а не компиляция. Откуда следует, что ваш тезис не верен.

Цитата

---

А выше упомянутые оптимизации и являются "существенными"

---

О чем и речь. Фактически других эффективных оптимизаций для байткода мы сделать не можем, а эти оптимизации работают очень быстро. нет смысла их включать/отключать, вы даже не заметите включен у вас какой-нибудь dead code elimination или нет, потому что его активация - это единицы процентов (если не доли процентов) от общего времени сборки.

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

Цитата

---

Иногда осуществление которых требует нескольких проходов по данному фрагменту байткода

---

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

Цитата

---

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

---

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

Цитата

---

Это потому, что оптимизатор написан на Си.

---

Насколько я знаю, на си джиттер (gnu lightning), компилятор же написан на racket.

Цитата

---

Непонел, в чем разница?

---

Двусмыслица получается.

Цитата

---

Ну в racket гигиена и синтаксические объекты, так что экспанд как в CL по скорости сделать нельзя.

---

Взгляни на экспанд макроса с syntax-case, и ты увидишь не слишком эффективную реализацию конечного автомата. С tagbody можно использовать и более эффективные алгоритмы.

Цитата

---

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

---

Так в чем проблема? Кстати, а где ты учитываешь время потраченное на компиляцию макросов во время экспанда? А то петрушка получается: ты пишешь, что экспанд длится на много больше компиляции "из-за генерации форм, которые вводят новые макросы", но не учитываешь время затраченное на компиляцию этих новых (промежуточных) макросов. Хорошо бы сложить время затраченное на компиляцию макросов со временем компиляции fully-expanded кода. А затем сравнить время затраченное на раскрытие макросов с общим временем компиляции.

Цитата

---

Как это? Локальные переходы есть в любом ЯП с TCO.

---

Напиши код на рэкете с явным использованием локальных переходов.

Цитата

---

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

---

Так это для тебя её нет

Цитата

---

5% - это в рамках статистической погрешности. Существенно - раза в два-три.

---

А когда я говорил о том, что компиляция в байткод длится в два-три раза дольше экспанда? Я же писал о том, что чем больше оптимизаций, тем медленнее компиляция. Если средняя скорость компиляции упала на 5% - значит, что для данного фрагмента кода компиляция стала происходить дольше. Для разработчиков Си компиляторов 5% - это много.

Цитата

---

Напоминаю, о чем шла речь. Речь шла о том, что-де добавление оптимизаций плохо скажется на времени сборки. Я вам указал, что сборка - это большей частью экспанд и сборка документации, а не компиляция. Откуда следует, что ваш тезис не верен.

---

А о каких именно оптимизациях шла речь. ТСО? Так без правильного распределения регистров процессора её трудно реализовать эффективно. А это уже уровень генератора машкода. Кстати, (declaim (optimize (speed 3))) просит компилятор создать максимально быстрый код в плане производительности.
Еще раз, мне нужен деклайм для того, чтобы заставить производить оптимизацию, когда компилятор её в упор не видит. Например, если ТСО "запрещено" сетом, но я то знаю, что её можно произвести, следовательно, я отмечу её в деклайме. Т.е. я не стану использовать явно цикл, а просто сделаю пометку в деклайме. Конечно, можно написать компилятор учитывающий "сеты", но его уже не назовешь шустрым.

Цитата

---

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

---

Цитата

---

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

---

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

(define a '(begin (+ 1 2 3 4 5)))

(define b `(begin ,@(make-list 10000 '(+ 1 2 3 4 5))))

> (time (compile a))

cpu time: 0 real time: 1 gc time: 0

 

> (time (compile b))

cpu time: 3336 real time: 3444 gc time: 392

Цитата

---

Двусмыслица получается.

---

По-моему эти фразы по смыслу эквивалентны, хз.

Цитата

---

Взгляни на экспанд макроса с syntax-case, и ты увидишь не слишком эффективную реализацию конечного автомата. С tagbody можно использовать и более эффективные алгоритмы.

---

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

Цитата

---

Кстати, а где ты учитываешь время потраченное на компиляцию макросов во время экспанда?

---

Нигде, а почему? Да по той же причине - экспанд макросов в первой фазе намного превышает время их компиляции. Т.к. именно во время этого экспанда и раскрываются те самые syntax-rules-простыни.

Цитата

---

Напиши код на рэкете с явным использованием локальных переходов.

---

Любой конечный автомат через TCO, разве нет?

Цитата

---

Так это для тебя её нет

---

Проблемой могло бы быть долго время экспанда, а не тот факт, что экспанд дольше компиляции

Цитата

---

Хорошо бы сложить время затраченное на компиляцию макросов со временем компиляции fully-expanded кода.

---

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

Цитата

---

Для разработчиков Си компиляторов 5% - это много.

---

Ну это вы придумываете.

Цитата

---

А о каких именно оптимизациях шла речь. ТСО?

---

Конечно, нет, TCO в байткоде не сделаешь. Были упомянуты - constant folding/propagation, инлайнинг, разворачивание циклов, dead code elimination, лямбда-лифтинг. Больше как-то особо и не приходит в голову, что можно сделать с байткодом.

Цитата

---

(declaim (optimize (speed 3))) просит компилятор создать максимально быстрый код в плане производительности.

---

Но это деклайм для машкод-генератора.

Цитата

---

Так это потому, что байткод предельно упрощен.

---

Ну так и должно быть, нет?

Цитата

---

А что если байткод будет приближен к машкоду какого-нибудь RISC процессора?

---

Здесь надо сразу говорить о том, какой имеет смысл подобное представление байткода. Прграму на лиспе удобно компилить в байткод, который напоминает по структуре лисп. Смысл усложнять дело, генерируя код для _какого-то_ RISC-процессора? Тех же микрооптимизаций мы все равно большей частью провести не сможем - они завязаны на конкретную архитектуру.

Цитата

---

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

---

Вы про макросы забыли. Там обычно как раз много чего можно оптимизировать.

 

> (define b `(begin ,@(make-list 10000 '(+ 1 2 3 4 5))))

> (time (expand b) 0)

cpu time: 468 real time: 505 gc time: 156

0

> (time (compile b) 0)

cpu time: 437 real time: 438 gc time: 125

0

> 

 

Цитата

---

Ты про компилятор fasl-ов, то он вроде как ТСО не проводит.

---

Там вообще такого понятия как TCO нет, потому что, например, (#%app + 1 2 3 4 5) компилируется в (#%app + 1 2 3 4 5).

Цитата

---

А это тут причем?

---

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

Цитата

---

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

---

С этим я согласен. Все зависит от конкретного кода.

Цитата

---

Ну это вы придумываете.

---

Тогда зачем придумали разделение optimize levels на 1, 2 и 3? Если разница между 1 и 2 обычно и составляет эти 5%, ну или около того, да и на качестве создаваемого кода это не шибко отражается.

Цитата

---

Конечно, нет, TCO в байткоде не сделаешь.

---

Можно добавить пометку (префикс, деклайм) в байткоде.

Цитата

---

Но это деклайм для машкод-генератора.

---

И не только для машкод-генератора, её может также использовать и компилятор байткода.

Цитата

---

Прграму на лиспе удобно компилить в байткод, который напоминает по структуре лисп.

---

Это удобно только для декомпиляции в Лисп-код. Хотя можно просто поместить fully-expanded код в отдельный файл.

Цитата

---

Смысл усложнять дело, генерируя код для _какого-то_ RISC-процессора?

---

Ну, не какого-то RISC-процессора, а придуманного с учетом архитектуры процессоров на которых будет работать ВМ.

Цитата

---

Вы про макросы забыли. Там обычно как раз много чего можно оптимизировать.

---

А именно?

Цитата

---

Там вообще такого понятия как TCO нет, потому что, например, (#%app + 1 2 3 4 5) компилируется в (#%app + 1 2 3 4 5).

---

Компилируется кем?

Цитата

---

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

---

А мне это не нужно. Мне нужен - деклайм

Цитата

---

Тогда зачем придумали разделение optimize levels на 1, 2 и 3?

---

не ко мне вопрос
Но еще раз - 5% это в рамках стат. погрешности. то есть вы подобного выигрыша в скорости просто не заметите.

Цитата

---

Можно добавить пометку (префикс, деклайм) в байткоде.

---

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

Цитата

---

Это удобно только для декомпиляции в Лисп-код.

---

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

Цитата

---

Ну, не какого-то RISC-процессора, а придуманного с учетом архитектуры процессоров на которых будет работать ВМ.

---

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

Цитата

---

А именно?

---

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

Цитата

---

Компилируется кем?

---

Компилятором байткода

Цитата

---

А мне это не нужно. Мне нужен - деклайм

---

Зачем вам деклайм?

Цитата

---

Но еще раз - 5% это в рамках стат. погрешности. то есть вы подобного выигрыша в скорости просто не заметите.

---

Почему именно 5%, а не 10% - откуда появилась эта цифра? Что мне мешает произвести 50 замеров и вычислить среднее значение?

Цитата

---

зачем? байткод имеет структуру лиспа, так что безо всяких пометок сразу видно, какая форма находится в хвостовой позиции

---

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

Цитата

---

В байткоде ставятся пометки о, например, том, что можно инлайнить.

---

Тогда почему же я их не видел

Цитата

---

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

---

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

Цитата

---

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

---

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

Цитата

---

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

---

Ну, так это не ко мне вопрос.

Цитата

---

Компилятором байткода

---

А почему я не видел #%app в байткоде?