Автор | Сообщение |
Kergan
300 сообщений |
#6009 2012-04-21 09:43 GMT+3 часа(ов) |
Цитата Это будет ВМ, в которой хвостовых вызовов нет. И вообще вызовов нет ![]() Цитата Я даже не знаю как это сделать, потому чот не могу пнять, что тут непонятно. Вот есть функция, производится хвосторекурсивная оптимизация и в результате ф-я выглядит ровно как выглядел бы цикл. Цитата Ну это оно и есть. В общем если вызов рекурсивный то можно гарантировать, что не потребуется создавать новый фрейм. Если просто хвостовой - не факт. Цитата Можно подробнее? ЦитатаДаже в этом случае динамика имеет свой оверхед. С боксингом вообще была бы труба. Цитата Факт остается фактом - gnu lighnting весьма тормозной jit. остальное уже частности. Цитата Не ну всегда все можно, конечно, но это восход солнца вручную... Цитата Весьма значительно упрощает, вообще говоря. CPS-программа выглядит совершенно иначе ![]() Цитата Не понял вопроса, почему тут должен быть какой-то особый способ борьбы? |
|
misha![]()
1275 сообщений |
#6010 2012-04-21 13:01 GMT+3 часа(ов) |
ЦитатаМожно подробнее? Конечно, если тебе эта тема интересна. ЦитатаНу, ты не знаешь точно как именно выглядел бы цикл, это я к тому, что существуют различные варианты. Например, самый простой - переопределить аргументы и совершить переход в начало цикла (может не совпадать с адресом функции). При подобном раскладе не потребуется даже производить преобразование промежуточного кода (тут в промежуточном коде вообще нет необходимости), тогда как более продвинутый компилятор (оптимизатор кода) еще "поколдует" с регистрами процессора. ЦитатаБолее продвинутый declaim позволит более детально описывать требования к коду. В идеале можно будет указать какие типы оптимизаций обязательно необходимо произвести. ЦитатаОн незначителен. ЦитатаМожно воспользоваться подходящим фреймворком, конечно, если он есть ![]() ЦитатаА он и не обязан быть особым. Да и справиться с хорошо спланированной атакой практически невозможно. |
|
Kergan
300 сообщений |
#6014 2012-04-22 06:53 GMT+3 часа(ов) |
Цитата Если убрать нерекурсивные вызовы, то все остальysе вызовы можно смело инлайнить, а тьюринг полнота восстанавливается добавлением for, при чем полученный код можно просто и очень эффективно оптимизировать всякими RA и т.п. Цитата ну обычно компилятор знает какие оптимизации _можно_ произвести. В случае деклаима есть опасность потребовать оптимизаций и нраваться на то, что проведение этой оптимизации будет некорреткным. Цитата зависит от реализации, опять же. Конкретно здесь можно сказать только проанализировав сгенеренный машкод. Цитата вот фреймворк для континуаций этим и занимается ![]() |
|
misha![]()
1275 сообщений |
#6023 2012-04-23 03:59 GMT+3 часа(ов) |
ЦитатаЧто значит "убрать нерекурсивные вызовы"? ЦитатаЕсли компилятор "сомневается", то пускай выдаст предупреждение. Или ошибку, если невозможно осуществить в принципе. |
|
Kergan
300 сообщений |
#6026 2012-04-23 09:33 GMT+3 часа(ов) |
Цитата да просто запретить. Цитататак он и без деклиймов может попытаться применить максимум оптимизаций и выдать ворнинги... |
|
misha![]()
1275 сообщений |
#6049 2012-04-23 15:06 GMT+3 часа(ов) |
ЦитатаНу, я бы не стал вводить такие жесткие ограничения. ЦитатаТогда есть вероятность, что мы так и не дождемся окончания компиляции ![]() |
|
Kergan
300 сообщений |
#6050 2012-04-23 15:33 GMT+3 часа(ов) |
Цитата Ну речь шла о "самой быстрой вм", а не о самой выразительной ![]() Есть, кстати, еще один плюс - размер "стека" (по сути это даже не стек будет, а один единственный фрейм, и вся программа представляет монолитную функцию) в этом случае строго детерменирован и легко расчитывается на основе кода. Цитата дану? |
|
misha![]()
1275 сообщений |
#6065 2012-04-26 12:35 GMT+3 часа(ов) |
ЦитатаНа подобной идеи базируются экспериментальные компиляторы форта, но им все равно приходится в некоторых случаях эмулировать вызов. ЦитатаВремя — деньги, поэтому в некоторых случаях требуется быстрая компиляция. |
|
Kergan
300 сообщений |
#6066 2012-04-26 13:15 GMT+3 часа(ов) |
Цитата Мне не кажется, что компиляция будет такой уж долгой. |
|
misha![]()
1275 сообщений |
#6067 2012-04-26 13:24 GMT+3 часа(ов) |
ЦитатаА ты попробуй собрать рэкет со всеми его модулями и документацией на стареньком ноуте с pentium III. У меня это заняло почти 8 часов ![]() ![]() Я думаю, принцип понятен: чем больше применяем оптимизаций, тем дольше компиляция. |
|
Kergan
300 сообщений |
#6069 2012-04-26 19:39 GMT+3 часа(ов) |
Ну в racket 99% компиляции - это экспанд (и с чего вдруг надо считать сборку доккументации вдобавок?
![]() Цитата Быстрее, медленнее... Производительность должна быть _достаточной_. Если она достаточна, то ускорение никаких плюсов не дает. Так что вопрос сводится к: "можно ли получить оптимизации с достаточной производительностью компиляции?" |
|
misha![]()
1275 сообщений |
#6070 2012-04-27 01:03 GMT+3 часа(ов) |
ЦитатаОткуда такая цифра? 99% - это слишком много. ЦитатаТы ведь хотел пример длительной компиляции ![]() ЦитатаЭто потому, что отсутствует оптимизатор промежуточного кода, либо он слабо развит. А также слабо развит оптимизатор машкода (платформозависимые оптимизации), но это скорее проблема gnu lightning. |
|
misha![]()
1275 сообщений |
#6071 2012-04-27 01:21 GMT+3 часа(ов) |
ЦитатаСкорость компиляции является важной характеристикой компилятора, и предметом гордости его разработчиков ![]() Цитата"Продвинутый" declaim позволит более детально описать проблемные участки кода. Это, в свою очередь, позволит получить достаточно производительный код без существенного увеличения времени компиляции. |
|
Kergan
300 сообщений |
#6074 2012-04-28 11:27 GMT+3 часа(ов) |
Цитата Навскидку ![]() Ну да, много, но компиляция в байткод full-expanded кода быстро и делается. Это и в доках указано. Собственно, если в твоем коде есть хотя бы пара широко используемых macro-generated macro, то время компиляции по сравнению с экспандом пренебрежимо мало. Цитата длительной компиляции а не сборки же. как деклаймы относятся к сборке документации? ![]() Цитата А там оптимизировать вобщем-то нечего ![]() суровый инлайнинг, constant propagation, dead code elimination... Байткод - это фактически тот же full-expanded код. Собственно, чуть менее чем все оптимизации производятся весьма шустро. медленные оптимизации - редкость, а не правило. Цитата Ну да, джит фиговый. Но какой-нибудь libjit генерит на порядок более эффективный код практически так же быстро. |
|
misha![]()
1275 сообщений |
#6075 2012-04-28 14:31 GMT+3 часа(ов) |
ЦитатаЭто возможно, если код состоит из одних макросов и не учитывается время затрачиваемое на компиляцию самих макросов. ЦитатаА причем тут деклаймы, если речь шла о длительной компиляции? Рэкет там был в качестве примера. ЦитатаТак уж и нечего? Для адекватного проведения constant propagation, dead code elimination требуются как минимум два прохода по всему коду модуля. Кстати, constant propagation и dead code elimination затрагивают еще и оптимизацию классических конструкций: if, cond, case и др. ЦитатаЭто зависит от реализации, хотя для Лиспа это так и есть. |
|
Kergan
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. Цитата Это у вас надо спросить ![]() Цитата ну это всего лишь линейные по длине кода алгоритмы ![]() Цитата Ну речь же о racket. Там структура байткода фактически повторяет full-expanded. |
|
misha![]()
1275 сообщений |
#6077 2012-04-29 13:25 GMT+3 часа(ов) |
ЦитатаСмелое заявление ![]() ЦитатаЯ в курсе ![]() ЦитатаНу и что? Экспанд происходит очень быстро. Тогда как компиляция того же макроса требует предпросмотра (он может происходить и во время экспанда), а иначе как мы осуществим инлайнинг или определим необходимость constant propagation и dead code elimination? ЦитатаТы не согласен с фразой: "чем больше включено оптимизаций, тем дольше компиляция"? Или ты думаешь, что все модули скомпилировались мгновенно, а компиляция документации длилась 8 часов? ЦитатаВсе зависит от оптимизатора кода, если он примитивен, то, конечно, компиляция будет мгновенной. Если не хочешь, чтобы экспанд происходил очень долго, то как можно меньше используй сложных макросов. ЦитатаА почему она не должна повторять full-expanded код? Тем более, что благодаря этому фаслы (fasl files) не будут зависеть он версии ВМ. Да и размер файлов будет меньше, чем при использовании машкодов. |
|
Kergan
300 сообщений |
#6078 2012-04-29 14:31 GMT+3 часа(ов) |
Цитата Имелось ввиду, что все формы, которые в коде, будут раскрываться. даже если у вас аппликация или константа, то оно будет раскрываться в (#%app ...) и (quote ...). Цитата Нет. Экспанд как раз происходит очень долго ![]() Цитата Предпросмотра чего? Цитата Согласен. я не согласен с тем, что включение оптимизаций повлияет на скорость существенно. Цитата Конечно не мгновенно. но из всего времени сборки бОльшая часть - экспанд и генерация документации. Причем _значительно_ бОльшая. Цитата При компиляции байткода по-просту невозможно применить какие-то существенные оптимизации кроме вышеупомянутых, потому что структура байткода повторяет структура кода программы. А вышеупомянутые оптимизации проводятся быстро (не мгновенно, конечно, но быстро). Цитата Да меня все устраивает ![]() В крайнем случае почти всегда можно вынести логику внутреннего макроса в функцию старшей фазы и все начинает летать. Но иногда, конечно, ничего не поделаешь - как в typed racket, например. Цитата Да нет, пусть повторяет, я ничего против не имею. |
|
misha![]()
1275 сообщений |
#6079 2012-04-29 17:44 GMT+3 часа(ов) |
ЦитатаТак и писал бы код на языке рэкет, а не просто racket код. ЦитатаЧто ему мешает быть быстрым? Экспанд по сути довольно примитивный процесс, скорость которого можно значительно повысить. Например, путем ручного парсинга, как в CL. Кстати, скорость работы конечного автомата создаваемого, например, syntax-case, можно значительно увеличить при использовании локальных переходов, которых нет в рэкет. Так что долгий экспанд - это проблема сугубо рэкета, как языка, так и ВМ. ЦитатаКода, макрос по сути - функция. ЦитатаА "существенно" это сколько? Для меня и 5% существенно. ЦитатаА причем тут экспанд, если моя шутка была о времени компиляции? Экспанд является неотъемлемым этапом компиляции. А компиляция документации - один из этапов сборки (компиляции) системы. ЦитатаА выше упомянутые оптимизации и являются "существенными", т.к. их реализация (оптимизаций) является довольно сложной и неоднозначной. Иногда осуществление которых требует нескольких проходов по данному фрагменту байткода, т.е. оптимизация происходит в несколько стадий, и после каждой стадии происходит изменение байткода. Это описано в большинстве учебников. Так что хороший компилятор на это тратит немало времени (речь идет о миллисекундах ![]() Если были произведены какие-либо оптимизации, то структура байткода будет несколько отличаться от структуры кода программы. Например, будет удален мертвый код, произведен инлайнинг функций. ЦитатаЭто потому, что оптимизатор написан на Си. А в экспанде участвуют макросы откомпилированные (надеюсь на это ![]() ![]() ЦитатаС этого и нужно было начинать ![]() |
|
Kergan
300 сообщений |
#6080 2012-04-29 19:05 GMT+3 часа(ов) |
Цитата Непонел, в чем разница? ![]() Цитата Ну в racket гигиена и синтаксические объекты, так что экспанд как в CL по скорости сделать нельзя. Цитата Зачем? Я же уже упоминал, что длительность экспанда не из-за раскрытия макросов происходит, а из-за генерации форм, которые вводят новые макросы. Цитата Как это? Локальные переходы есть в любом ЯП с TCO. Цитата Это вообще никакая не проблема. С чего вдруг тот факт, что экспанд выполняется намного дольше, чем копиляция, стал проблемой? ![]() Цитата 5% - это в рамках статистической погрешности. Существенно - раза в два-три. Цитата Напоминаю, о чем шла речь. Речь шла о том, что-де добавление оптимизаций плохо скажется на времени сборки. Я вам указал, что сборка - это большей частью экспанд и сборка документации, а не компиляция. Откуда следует, что ваш тезис не верен. Цитата О чем и речь. Фактически других эффективных оптимизаций для байткода мы сделать не можем, а эти оптимизации работают очень быстро. нет смысла их включать/отключать, вы даже не заметите включен у вас какой-нибудь dead code elimination или нет, потому что его активация - это единицы процентов (если не доли процентов) от общего времени сборки. Вот когда мы начинаем делать микрооптимизации при генерации машкода - уже появляются проблемы, тут куда ни плюнь эффективные алгоритмы NP (которые могут вам часами генерить код для 1к строк исходников, какие там микросекунды ![]() Цитата Да ради бога. Факт-то остается фактом - эти алгоритмы работают чрезвычайно быстро и их наличие весьма трудно заметить, если вообще можно заметить. Цитата Это и делается. Еще лямбда-лифтинг делается, разворачивание циклов (учитывая, что циклы реализуются в виде рекурсивных ф-й - тот же инлайнинг до некоторой глубины), кое-где проставляются аннотации для jit - вот и все. Цитата Насколько я знаю, на си джиттер (gnu lightning), компилятор же написан на racket. |
|
Kergan
300 сообщений |
#6081 2012-04-29 19:10 GMT+3 часа(ов) |
кстати codebase racket - около 5000 kloc, можете привести мне в пример проект такого же размера, который собирается существенно быстрее?
|
|
misha![]()
1275 сообщений |
#6083 2012-04-29 21:48 GMT+3 часа(ов) |
ЦитатаДвусмыслица получается. ЦитатаВзгляни на экспанд макроса с syntax-case, и ты увидишь не слишком эффективную реализацию конечного автомата. С tagbody можно использовать и более эффективные алгоритмы. ЦитатаТак в чем проблема? Кстати, а где ты учитываешь время потраченное на компиляцию макросов во время экспанда? А то петрушка получается: ты пишешь, что экспанд длится на много больше компиляции "из-за генерации форм, которые вводят новые макросы", но не учитываешь время затраченное на компиляцию этих новых (промежуточных) макросов. Хорошо бы сложить время затраченное на компиляцию макросов со временем компиляции fully-expanded кода. А затем сравнить время затраченное на раскрытие макросов с общим временем компиляции. ЦитатаНапиши код на рэкете с явным использованием локальных переходов. ЦитатаТак это для тебя её нет ![]() ЦитатаА когда я говорил о том, что компиляция в байткод длится в два-три раза дольше экспанда? Я же писал о том, что чем больше оптимизаций, тем медленнее компиляция. Если средняя скорость компиляции упала на 5% - значит, что для данного фрагмента кода компиляция стала происходить дольше. Для разработчиков Си компиляторов 5% - это много. ЦитатаА о каких именно оптимизациях шла речь. ТСО? Так без правильного распределения регистров процессора её трудно реализовать эффективно. А это уже уровень генератора машкода. Кстати, (declaim (optimize (speed 3))) просит компилятор создать максимально быстрый код в плане производительности. Еще раз, мне нужен деклайм для того, чтобы заставить производить оптимизацию, когда компилятор её в упор не видит. Например, если ТСО "запрещено" сетом, но я то знаю, что её можно произвести, следовательно, я отмечу её в деклайме. Т.е. я не стану использовать явно цикл, а просто сделаю пометку в деклайме. Конечно, можно написать компилятор учитывающий "сеты", но его уже не назовешь шустрым. Цитата Цитата Так это потому, что байткод предельно упрощен. А что если байткод будет приближен к машкоду какого-нибудь RISC процессора? Кстати, когда ты пишешь код, то стараешься сделать его наиболее эффективным, поэтому и оптимизировать там практически нечего. Разве что проинлайнить несколько функций, да вывести пару констант. Мертвого кода ведь нет. (define a '(begin (+ 1 2 3 4 5))) отредактировал(а) misha: 2012-04-30 00:24 GMT+3 часа(ов) |
|
misha![]()
1275 сообщений |
#6084 2012-04-29 22:00 GMT+3 часа(ов) |
ЦитатаТы про компилятор fasl-ов, то он вроде как ТСО не проводит. ЦитатаА это тут причем? |
|
Kergan
300 сообщений |
#6085 2012-04-30 12:55 GMT+3 часа(ов) |
Цитата По-моему эти фразы по смыслу эквивалентны, хз. Цитата Там вполне нормальный конечный автомат. Собственно, там практически никакого проигрыша и нет по сравнению с ручным парсингом. Собственно есть только одна функция из-за которой бывает просадка, но я, если честно, не понял, почему вместо нее не написали какую-то быструю замену, на мой взгляд это вполне можно было сделать. Цитата Нигде, а почему? Да по той же причине - экспанд макросов в первой фазе намного превышает время их компиляции. Т.к. именно во время этого экспанда и раскрываются те самые syntax-rules-простыни. Цитата Любой конечный автомат через TCO, разве нет? Цитата Проблемой могло бы быть долго время экспанда, а не тот факт, что экспанд дольше компиляции ![]() Цитата На моей практике экспанд обычно в ~4 раза дольше (на простых макросах) ну и до бесконечности (если макрос сложный и внутри зашита какая-то логика - тут понятно он может работать сколь угодно долго, но это и бывает чрезвычайно редко). Цитата Ну это вы придумываете. Цитата Конечно, нет, TCO в байткоде не сделаешь. Были упомянуты - constant folding/propagation, инлайнинг, разворачивание циклов, dead code elimination, лямбда-лифтинг. Больше как-то особо и не приходит в голову, что можно сделать с байткодом. Цитата Но это деклайм для машкод-генератора. Цитата Ну так и должно быть, нет? Цитата Здесь надо сразу говорить о том, какой имеет смысл подобное представление байткода. Прграму на лиспе удобно компилить в байткод, который напоминает по структуре лисп. Смысл усложнять дело, генерируя код для _какого-то_ RISC-процессора? Тех же микрооптимизаций мы все равно большей частью провести не сможем - они завязаны на конкретную архитектуру. Цитата Вы про макросы забыли. Там обычно как раз много чего можно оптимизировать.
![]() Цитата Там вообще такого понятия как TCO нет, потому что, например, (#%app + 1 2 3 4 5) компилируется в (#%app + 1 2 3 4 5). Цитата Ну вы просто упомянули что-де так вот долго шла сборка и все такое. Вот я и предлагаю сравнить с временем сборки других аналогичных по размеру проектов, например на каких-нибудь плюсцах ![]() |
|
misha![]()
1275 сообщений |
#6087 2012-05-02 17:44 GMT+3 часа(ов) |
ЦитатаЯ же писал, что отсутствие локальных переходов в самом языке не позволяет написать что-то более эффективное. ЦитатаПодробнее можно. ЦитатаПиши конкретнее. Т.к. само раскрытие происходит очень быстро. Возможно проблема в том, что для полного экспанда необходимо совершать дополнительные проходы по всему коду (синтаксическому объекту), да и после каждого прохода необходимо создавать новый код (синтаксический объект). И все-таки я настаиваю на необходимости учета времени затраченного на компиляцию генерируемых макросов. Т.к. в некоторых случаях она может составлять до 1/5 времени экспанда, и даже более. ЦитатаА зачем? Все равно это будет медленно, а мне ведь нужна скорость. ЦитатаА я и писал о времени экспанда. Можешь прочесть еще раз: "Так что долгий экспанд - это проблема сугубо рэкета, как языка, так и ВМ." отредактировал(а) misha: 2012-05-02 18:50 GMT+3 часа(ов) |
|
misha![]()
1275 сообщений |
#6088 2012-05-02 18:47 GMT+3 часа(ов) |
ЦитатаС этим я согласен. Все зависит от конкретного кода. ЦитатаТогда зачем придумали разделение optimize levels на 1, 2 и 3? Если разница между 1 и 2 обычно и составляет эти 5%, ну или около того, да и на качестве создаваемого кода это не шибко отражается. ЦитатаМожно добавить пометку (префикс, деклайм) в байткоде. ЦитатаИ не только для машкод-генератора, её может также использовать и компилятор байткода. ЦитатаЭто удобно только для декомпиляции в Лисп-код. Хотя можно просто поместить fully-expanded код в отдельный файл. ЦитатаНу, не какого-то RISC-процессора, а придуманного с учетом архитектуры процессоров на которых будет работать ВМ. ЦитатаА именно? ЦитатаКомпилируется кем? ЦитатаА мне это не нужно. Мне нужен - деклайм ![]() |
|
Kergan
300 сообщений |
#6092 2012-05-03 17:24 GMT+3 часа(ов) |
Цитата опять двадцать пять. мы же уже выяснили что в любом ЯП с TCO есть локальные переходы. Цитата Там при при биндинге аргументов паттерна что-то делалось в рантайме, что можно было раскрыть в компайлтайме, в результате это выглядело неэффективно. Подробностей не помню - смотрел я это дело давно, надо заново реализацию раскуривать. Цитата Очень быстро происходит компиляция, раскрытие - намного дольше. Это факт. просто возьмите и проверьте, в чем проблема? Цитата Да нет, просто во время экспанда может выполняться любая сколь угодно сложная логика. Цитата Ну да, до 1-5. То есть экспанд в 4-5 раз больше времени компиляции. Другими словами если вы сделаете экспанд быстрее на 20%, то эффекта будет больше, чем если вы ускорите компиляцию в 10 раз ![]() Цитата Почему же медленно? Чем хвостовой вызов (fun) отличается от локального перехода? Его же впоkyе спокойно можно компилировать в обычный джамп. То есть натурально на место (fun) ставим JMP fun; - и все прекрасно работает ![]() |
|
Kergan
300 сообщений |
#6093 2012-05-03 17:33 GMT+3 часа(ов) |
Цитатане ко мне вопрос ![]() Но еще раз - 5% это в рамках стат. погрешности. то есть вы подобного выигрыша в скорости просто не заметите. Цитата зачем? байткод имеет структуру лиспа, так что безо всяких пометок сразу видно, какая форма находится в хвостовой позиции ![]() В байткоде ставятся пометки о, например, том, что можно инлайнить. Цитата для компиляции в байткод - тоже удобно. как раз компиляция будет быстрее ![]() Цитата микрооптимизации для каждого процессора все равно свои. Цитата Гм. Что "именно"? Просто во время экспанда макроса часто куча ненужной лапши возникает. Была даже презентация одна на эту тему - что, мол, нормальная макросистема обязательна должна предполагать наличие упомянутых оптимизаций. Цитата Компилятором байткода ![]() Цитата Зачем вам деклайм? ![]() |
|
misha![]()
1275 сообщений |
#6101 2012-05-06 14:24 GMT+3 часа(ов) |
ЦитатаВ любом схеме есть локальные переходы, даже если ТСО не проводится. Приведи мне аналог tagbody(prog)-go для racket, который был бы таким же быстрым, лаконичным и удобным. Кстати, мы уже выяснили, что наличие TCO (у racket) не гарантирует производительность, т.е. мы не можем получить быстрые циклы. ЦитатаРаскури ![]() ЦитатаА зачем мне проверять? Если у любой схемы раскрытие происходит очень быстро - это факт. Короче, тебе нужно - сам и проверяй. А мне представь только сам тест и твои результаты. ЦитатаВо время компиляции, кстати, тоже. ЦитатаТогда нужны деклаймы и для экспанда ![]() ЦитатаЯ же уже писал ранее, что одна только замена call на jmp не дает желаемого (мной) увеличения производительности. А зачем мне медленные циклы? отредактировал(а) misha: 2012-05-06 14:59 GMT+3 часа(ов) |
|
misha![]()
1275 сообщений |
#6102 2012-05-06 14:58 GMT+3 часа(ов) |
ЦитатаПочему именно 5%, а не 10% - откуда появилась эта цифра? Что мне мешает произвести 50 замеров и вычислить среднее значение? ЦитатаЗачем? Да, затем, чтобы не тратить время на проведение оптимизации кода, когда это уже можно было произвести заранее. ЦитатаТогда почему же я их не видел ![]() ЦитатаТогда лучше просто сохранять синтаксический объект. И не называть его компилятором, а просто - оптимизатор кода. ЦитатаТак лучше сосредоточиться на микрооптимизациях, чем тратить время на оптимизацию кода, когда это уже можно было сделать заранее. ЦитатаНу, так это не ко мне вопрос. ЦитатаА почему я не видел #%app в байткоде? |
|