Предыдущая страница Следующая страница [1] > 2 < [3]

Автор Сообщение

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6009   2012-04-21 09:43 GMT+3 часа(ов)      
Цитата
Иными словами, предложи устройство VM, в которой хвостовой вызов будет реализован максимально эффективно.

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

Цитата
Объясни понятнее, что ты хотел этим сказать.

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

Цитата
Т.е. вставляется проверка на рекурсивный вызов, и если он есть, то просто переопределяем параметры (присваиваем новые значения) и совершаем переход на начало.

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

Цитата
Требуется более продвинутый declaim.


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

Цитата
Я использовал короткие целые, поэтому не было никакой распаковки (unboxing).
Даже в этом случае динамика имеет свой оверхед. С боксингом вообще была бы труба.

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

Факт остается фактом - gnu lighnting весьма тормозной jit. остальное уже частности.

Цитата
Разве "старые" технологии запрещают хранить данные на стороне клиента? Вот только все это требует шифрования, поэтому возрастает нагрузка на сервер.

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

Цитата
Применение продолжений всего-лишь несколько упрощает его вид

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

Цитата
А как ты предлагаешь бороться с DDoS-атаками?

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

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6010   2012-04-21 13:01 GMT+3 часа(ов)      
Цитата
Это будет ВМ, в которой хвостовых вызовов нет. И вообще вызовов нет
Можно подробнее? Конечно, если тебе эта тема интересна.
Цитата
Я даже не знаю как это сделать, потому чот не могу пнять, что тут непонятно. Вот есть функция, производится хвосторекурсивная оптимизация и в результате ф-я выглядит ровно как выглядел бы цикл.
Ну, ты не знаешь точно как именно выглядел бы цикл, это я к тому, что существуют различные варианты. Например, самый простой - переопределить аргументы и совершить переход в начало цикла (может не совпадать с адресом функции). При подобном раскладе не потребуется даже производить преобразование промежуточного кода (тут в промежуточном коде вообще нет необходимости), тогда как более продвинутый компилятор (оптимизатор кода) еще "поколдует" с регистрами процессора.
Цитата
Можно подробнее?
Более продвинутый declaim позволит более детально описывать требования к коду. В идеале можно будет указать какие типы оптимизаций обязательно необходимо произвести.
Цитата
Даже в этом случае динамика имеет свой оверхед.
Он незначителен.
Цитата
Не ну всегда все можно, конечно, но это восход солнца вручную...
Можно воспользоваться подходящим фреймворком, конечно, если он есть
Цитата
Не понял вопроса, почему тут должен быть какой-то особый способ борьбы?
А он и не обязан быть особым. Да и справиться с хорошо спланированной атакой практически невозможно.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6014   2012-04-22 06:53 GMT+3 часа(ов)      
Цитата
Можно подробнее? Конечно, если тебе эта тема интересна.

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

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

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

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

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

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

вот фреймворк для континуаций этим и занимается

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6023   2012-04-23 03:59 GMT+3 часа(ов)      
Цитата
Если убрать нерекурсивные вызовы, то все остальysе вызовы можно смело инлайнить, а тьюринг полнота восстанавливается добавлением for
Что значит "убрать нерекурсивные вызовы"?
Цитата
В случае деклаима есть опасность потребовать оптимизаций и нраваться на то, что проведение этой оптимизации будет некорреткным.
Если компилятор "сомневается", то пускай выдаст предупреждение. Или ошибку, если невозможно осуществить в принципе.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6026   2012-04-23 09:33 GMT+3 часа(ов)      
Цитата
Что значит "убрать нерекурсивные вызовы"?

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

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

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6049   2012-04-23 15:06 GMT+3 часа(ов)      
Цитата
да просто запретить.
Ну, я бы не стал вводить такие жесткие ограничения.
Цитата
так он и без деклиймов может попытаться применить максимум оптимизаций и выдать ворнинги...
Тогда есть вероятность, что мы так и не дождемся окончания компиляции Поэтому по умолчанию количество возможных оптимизаций строго ограничено. А декламирование позволит управлять компиляцией вручную, что позволит в некоторых случаях добиться наилучших результатов.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6050   2012-04-23 15:33 GMT+3 часа(ов)      
Цитата
Ну, я бы не стал вводить такие жесткие ограничения.

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

Цитата
Тогда есть вероятность, что мы так и не дождемся окончания компиляции

дану?

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6065   2012-04-26 12:35 GMT+3 часа(ов)      
Цитата
Ну речь шла о "самой быстрой вм", а не о самой выразительной
На подобной идеи базируются экспериментальные компиляторы форта, но им все равно приходится в некоторых случаях эмулировать вызов.
Цитата
дану?
Время — деньги, поэтому в некоторых случаях требуется быстрая компиляция.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6066   2012-04-26 13:15 GMT+3 часа(ов)      
Цитата
Время — деньги, поэтому в некоторых случаях требуется быстрая компиляция.

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

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6067   2012-04-26 13:24 GMT+3 часа(ов)      
Цитата
Мне не кажется, что компиляция будет такой уж долгой.
А ты попробуй собрать рэкет со всеми его модулями и документацией на стареньком ноуте с pentium III. У меня это заняло почти 8 часов Да и сборка libreoffice - то еще удовольствие
Я думаю, принцип понятен: чем больше применяем оптимизаций, тем дольше компиляция.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6069   2012-04-26 19:39 GMT+3 часа(ов)      
Ну в racket 99% компиляции - это экспанд (и с чего вдруг надо считать сборку доккументации вдобавок? ). Сам байткод весьма шустро генерится. Ну и джитится тоже шустро.

Цитата
Я думаю, принцип понятен: чем больше применяем оптимизаций, тем дольше компиляция.

Быстрее, медленнее...
Производительность должна быть _достаточной_. Если она достаточна, то ускорение никаких плюсов не дает. Так что вопрос сводится к: "можно ли получить оптимизации с достаточной производительностью компиляции?"

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6070   2012-04-27 01:03 GMT+3 часа(ов)      
Цитата
Ну в racket 99% компиляции - это экспанд
Откуда такая цифра? 99% - это слишком много.
Цитата
и с чего вдруг надо считать сборку доккументации вдобавок?
Ты ведь хотел пример длительной компиляции А компиляция страниц документации является неотъемлемым этапом сборки.
Цитата
Сам байткод весьма шустро генерится. Ну и джитится тоже шустро.
Это потому, что отсутствует оптимизатор промежуточного кода, либо он слабо развит. А также слабо развит оптимизатор машкода (платформозависимые оптимизации), но это скорее проблема gnu lightning.

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6071   2012-04-27 01:21 GMT+3 часа(ов)      
Цитата
Быстрее, медленнее...
Скорость компиляции является важной характеристикой компилятора, и предметом гордости его разработчиков
Цитата
Производительность должна быть _достаточной_. Если она достаточна, то ускорение никаких плюсов не дает. Так что вопрос сводится к: "можно ли получить оптимизации с достаточной производительностью компиляции?"
"Продвинутый" declaim позволит более детально описать проблемные участки кода. Это, в свою очередь, позволит получить достаточно производительный код без существенного увеличения времени компиляции.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6074   2012-04-28 11:27 GMT+3 часа(ов)      
Цитата
Откуда такая цифра? 99% - это слишком много.
Цитата

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

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

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

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

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

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

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

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6075   2012-04-28 14:31 GMT+3 часа(ов)      
Цитата
Собственно, если в твоем коде есть хотя бы пара широко используемых macro-generated macro, то время компиляции по сравнению с экспандом пренебрежимо мало.
Это возможно, если код состоит из одних макросов и не учитывается время затрачиваемое на компиляцию самих макросов.
Цитата
длительной компиляции а не сборки же. как деклаймы относятся к сборке документации?
А причем тут деклаймы, если речь шла о длительной компиляции? Рэкет там был в качестве примера.
Цитата
А там оптимизировать вобщем-то нечего
суровый инлайнинг, constant propagation, dead code elimination...
Так уж и нечего? Для адекватного проведения constant propagation, dead code elimination требуются как минимум два прохода по всему коду модуля. Кстати, constant propagation и dead code elimination затрагивают еще и оптимизацию классических конструкций: if, cond, case и др.
Цитата
Байткод - это фактически тот же full-expanded код.
Это зависит от реализации, хотя для Лиспа это так и есть.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6076   2012-04-29 05:25 GMT+3 часа(ов)      
Цитата
Это возможно, если код состоит из одних макросов

а в 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.

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6077   2012-04-29 13:25 GMT+3 часа(ов)      
Цитата
а в racket код и состоит из одних макросов всегда
Смелое заявление
Цитата
а то что я имел ввиду (про macro-generated macro) это такое
Я в курсе
Цитата
само (define-syntax-rule ...) раскрывается в ооогромную простыню, и мы будем эту простыню получать на каждый вызов f.
Ну и что? Экспанд происходит очень быстро. Тогда как компиляция того же макроса требует предпросмотра (он может происходить и во время экспанда), а иначе как мы осуществим инлайнинг или определим необходимость constant propagation и dead code elimination?
Цитата
Это у вас надо спросить
Ты не согласен с фразой: "чем больше включено оптимизаций, тем дольше компиляция"? Или ты думаешь, что все модули скомпилировались мгновенно, а компиляция документации длилась 8 часов?
Цитата
ну это всего лишь линейные по длине кода алгоритмы
Все зависит от оптимизатора кода, если он примитивен, то, конечно, компиляция будет мгновенной. Если не хочешь, чтобы экспанд происходил очень долго, то как можно меньше используй сложных макросов.
Цитата
Ну речь же о racket. Там структура байткода фактически повторяет full-expanded.
А почему она не должна повторять full-expanded код? Тем более, что благодаря этому фаслы (fasl files) не будут зависеть он версии ВМ. Да и размер файлов будет меньше, чем при использовании машкодов.

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6078   2012-04-29 14:31 GMT+3 часа(ов)      
Цитата
Смелое заявление

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6079   2012-04-29 17:44 GMT+3 часа(ов)      
Цитата
... будет раскрываться в (#%app ...) и (quote ...).
Так и писал бы код на языке рэкет, а не просто racket код.
Цитата
Нет. Экспанд как раз происходит очень долго
Что ему мешает быть быстрым? Экспанд по сути довольно примитивный процесс, скорость которого можно значительно повысить. Например, путем ручного парсинга, как в CL. Кстати, скорость работы конечного автомата создаваемого, например, syntax-case, можно значительно увеличить при использовании локальных переходов, которых нет в рэкет. Так что долгий экспанд - это проблема сугубо рэкета, как языка, так и ВМ.
Цитата
Предпросмотра чего?
Кода, макрос по сути - функция.
Цитата
я не согласен с тем, что включение оптимизаций повлияет на скорость существенно.
А "существенно" это сколько? Для меня и 5% существенно.
Цитата
Конечно не мгновенно. но из всего времени сборки бОльшая часть - экспанд и генерация документации. Причем _значительно_ бОльшая.
А причем тут экспанд, если моя шутка была о времени компиляции? Экспанд является неотъемлемым этапом компиляции. А компиляция документации - один из этапов сборки (компиляции) системы.
Цитата
При компиляции байткода по-просту невозможно применить какие-то существенные оптимизации кроме вышеупомянутых, потому что структура байткода повторяет структура кода программы.
А выше упомянутые оптимизации и являются "существенными", т.к. их реализация (оптимизаций) является довольно сложной и неоднозначной. Иногда осуществление которых требует нескольких проходов по данному фрагменту байткода, т.е. оптимизация происходит в несколько стадий, и после каждой стадии происходит изменение байткода. Это описано в большинстве учебников. Так что хороший компилятор на это тратит немало времени (речь идет о миллисекундах).
Если были произведены какие-либо оптимизации, то структура байткода будет несколько отличаться от структуры кода программы. Например, будет удален мертвый код, произведен инлайнинг функций.
Цитата
А вышеупомянутые оптимизации проводятся быстро (не мгновенно, конечно, но быстро).

Это потому, что оптимизатор написан на Си. А в экспанде участвуют макросы откомпилированные (надеюсь на это) gnu lightning, компиляция которых также является частью экспанда, да и много их в языке racket
Цитата
Да меня все устраивает
С этого и нужно было начинать

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6080   2012-04-29 19:05 GMT+3 часа(ов)      
Цитата
Так и писал бы код на языке рэкет, а не просто racket код.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6081   2012-04-29 19:10 GMT+3 часа(ов)      
кстати codebase racket - около 5000 kloc, можете привести мне в пример проект такого же размера, который собирается существенно быстрее?

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6083   2012-04-29 21:48 GMT+3 часа(ов)      
Цитата
Непонел, в чем разница?
Двусмыслица получается.
Цитата
Ну в 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

отредактировал(а) misha: 2012-04-30 00:24 GMT+3 часа(ов)

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6084   2012-04-29 22:00 GMT+3 часа(ов)      
Цитата
Насколько я знаю, на си джиттер (gnu lightning), компилятор же написан на racket.
Ты про компилятор fasl-ов, то он вроде как ТСО не проводит.
Цитата
кстати codebase racket - около 5000 kloc, можете привести мне в пример проект такого же размера, который собирается существенно быстрее?
А это тут причем?

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6085   2012-04-30 12:55 GMT+3 часа(ов)      
Цитата
Двусмыслица получается.

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

Цитата
Взгляни на экспанд макроса с 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).

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

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

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6087   2012-05-02 17:44 GMT+3 часа(ов)      
Цитата
Собственно, там практически никакого проигрыша и нет по сравнению с ручным парсингом.
Я же писал, что отсутствие локальных переходов в самом языке не позволяет написать что-то более эффективное.
Цитата
Собственно есть только одна функция из-за которой бывает просадка, но я, если честно, не понял, почему вместо нее не написали какую-то быструю замену, на мой взгляд это вполне можно было сделать.

Подробнее можно.
Цитата
Нигде, а почему? Да по той же причине - экспанд макросов в первой фазе намного превышает время их компиляции. Т.к. именно во время этого экспанда и раскрываются те самые syntax-rules-простыни.
Пиши конкретнее. Т.к. само раскрытие происходит очень быстро. Возможно проблема в том, что для полного экспанда необходимо совершать дополнительные проходы по всему коду (синтаксическому объекту), да и после каждого прохода необходимо создавать новый код (синтаксический объект). И все-таки я настаиваю на необходимости учета времени затраченного на компиляцию генерируемых макросов. Т.к. в некоторых случаях она может составлять до 1/5 времени экспанда, и даже более.
Цитата
Любой конечный автомат через TCO, разве нет?
А зачем? Все равно это будет медленно, а мне ведь нужна скорость.
Цитата
Проблемой могло бы быть долго время экспанда, а не тот факт, что экспанд дольше компиляции
А я и писал о времени экспанда. Можешь прочесть еще раз: "Так что долгий экспанд - это проблема сугубо рэкета, как языка, так и ВМ."

отредактировал(а) misha: 2012-05-02 18:50 GMT+3 часа(ов)

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6088   2012-05-02 18:47 GMT+3 часа(ов)      
Цитата
На моей практике экспанд обычно в ~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).
Компилируется кем?
Цитата
Ну вы просто упомянули что-де так вот долго шла сборка и все такое. Вот я и предлагаю сравнить с временем сборки других аналогичных по размеру проектов, например на каких-нибудь плюсцах прежде чем делать выводы о длительности.
А мне это не нужно. Мне нужен - деклайм

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6092   2012-05-03 17:24 GMT+3 часа(ов)      
Цитата
Я же писал, что отсутствие локальных переходов в самом языке

опять двадцать пять. мы же уже выяснили что в любом ЯП с TCO есть локальные переходы.

Цитата
Подробнее можно.

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

Цитата
Пиши конкретнее. Т.к. само раскрытие происходит очень быстро.

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

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

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

Цитата
Т.к. в некоторых случаях она может составлять до 1/5 времени экспанда, и даже более.

Ну да, до 1-5. То есть экспанд в 4-5 раз больше времени компиляции. Другими словами если вы сделаете экспанд быстрее на 20%, то эффекта будет больше, чем если вы ускорите компиляцию в 10 раз

Цитата
А зачем? Все равно это будет медленно

Почему же медленно? Чем хвостовой вызов (fun) отличается от локального перехода? Его же впоkyе спокойно можно компилировать в обычный джамп. То есть натурально на место (fun) ставим JMP fun; - и все прекрасно работает

Kergan

Members


Статус

300 сообщений

Где: ---
Род занятий:
Возраст:

#6093   2012-05-03 17:33 GMT+3 часа(ов)      
Цитата
Тогда зачем придумали разделение optimize levels на 1, 2 и 3?
не ко мне вопрос
Но еще раз - 5% это в рамках стат. погрешности. то есть вы подобного выигрыша в скорости просто не заметите.

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

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

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

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

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

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

Цитата
А именно?

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

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

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

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

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

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6101   2012-05-06 14:24 GMT+3 часа(ов)      
Цитата
опять двадцать пять. мы же уже выяснили что в любом ЯП с TCO есть локальные переходы.
В любом схеме есть локальные переходы, даже если ТСО не проводится. Приведи мне аналог tagbody(prog)-go для racket, который был бы таким же быстрым, лаконичным и удобным. Кстати, мы уже выяснили, что наличие TCO (у racket) не гарантирует производительность, т.е. мы не можем получить быстрые циклы.
Цитата
Там при при биндинге аргументов паттерна что-то делалось в рантайме, что можно было раскрыть в компайлтайме, в результате это выглядело неэффективно. Подробностей не помню - смотрел я это дело давно, надо заново реализацию раскуривать.

Раскури
Цитата
Очень быстро происходит компиляция, раскрытие - намного дольше. Это факт. просто возьмите и проверьте, в чем проблема?
А зачем мне проверять? Если у любой схемы раскрытие происходит очень быстро - это факт. Короче, тебе нужно - сам и проверяй. А мне представь только сам тест и твои результаты.
Цитата
Да нет, просто во время экспанда может выполняться любая сколь угодно сложная логика.
Во время компиляции, кстати, тоже.
Цитата
Другими словами если вы сделаете экспанд быстрее на 20%, то эффекта будет больше, чем если вы ускорите компиляцию в 10 раз
Тогда нужны деклаймы и для экспанда Кстати, а почему у racket очень долго создается синтаксический объект? Может лучше оптимизировать этот процесс?
Цитата
Почему же медленно? Чем хвостовой вызов (fun) отличается от локального перехода? Его же впоkyе спокойно можно компилировать в обычный джамп. То есть натурально на место (fun) ставим JMP fun; - и все прекрасно работает
Я же уже писал ранее, что одна только замена call на jmp не дает желаемого (мной) увеличения производительности. А зачем мне медленные циклы?

отредактировал(а) misha: 2012-05-06 14:59 GMT+3 часа(ов)

misha

Moderators


Статус

1273 сообщений
http://racket-lang.org/
Где: Yemen
Род занятий:
Возраст:

#6102   2012-05-06 14:58 GMT+3 часа(ов)      
Цитата
Но еще раз - 5% это в рамках стат. погрешности. то есть вы подобного выигрыша в скорости просто не заметите.
Почему именно 5%, а не 10% - откуда появилась эта цифра? Что мне мешает произвести 50 замеров и вычислить среднее значение?
Цитата
зачем? байткод имеет структуру лиспа, так что безо всяких пометок сразу видно, какая форма находится в хвостовой позиции
Зачем? Да, затем, чтобы не тратить время на проведение оптимизации кода, когда это уже можно было произвести заранее.
Цитата
В байткоде ставятся пометки о, например, том, что можно инлайнить.
Тогда почему же я их не видел
Цитата
для компиляции в байткод - тоже удобно. как раз компиляция будет быстрее
Тогда лучше просто сохранять синтаксический объект. И не называть его компилятором, а просто - оптимизатор кода.
Цитата
микрооптимизации для каждого процессора все равно свои.
Так лучше сосредоточиться на микрооптимизациях, чем тратить время на оптимизацию кода, когда это уже можно было сделать заранее.
Цитата
Просто во время экспанда макроса часто куча ненужной лапши возникает. Была даже презентация одна на эту тему - что, мол, нормальная макросистема обязательна должна предполагать наличие упомянутых оптимизаций.
Ну, так это не ко мне вопрос.
Цитата
Компилятором байткода
А почему я не видел #%app в байткоде?


Онлайн :

0 пользователь(ей), 15 гость(ей) :




Реклама на сайте: