ну конечно, в принципе это был ожидаемый результат по скорости. Просто было интересно на сколько именно медленнее.
Насчет моно — я практически никогда не касался его. Обещаю, что я посмотрю как там все работает, но в ближайшее время я видимо его тестировать не буду…
Вообще результаты gcc тут для справки, просто чтобы сориентироваться. И кроме того, -O2 и -O3 не дают практически никакого прироста производительности на этой задаче.
То есть отличие -O0 от -O1 значительное, а разница -O1 от -O2 уже просто меняет десятые доли секунды в результате. И поскольку я не ставил себе цель сравнивать JIT именно с gcc, для меня цифр с -O0 и -O1 достаточно.
Насчет подгрузки файла, да разумеется, так можно было сделать, но я считаю это шагом назад от обьективного сравнения. Тогда получится, что для libjit время трансляции в исполняемый код полностью включено в результирующее время, а для llvm — только частично.
и libjit и llvm в принципе не предназначены, чтобы писать код на них ручками. Предполагается что должно быть какое-то дерево разбора, по которому генерируется код. поэтому разумеется когда пишешь это используя только API, код будет скриптообразный и тяжелый для восприятия.
логика в том, что: допиливать сообщения об ошибках приходится в любом случае. В случае с LR грамматиками гемороя больше. Эмпирически так сказать установленный факт.
что касается antlr — он может жить везде где живет ява, это же просто jar. но я кстати им не ползуюсь практически.
По поводу замены — В большинстве случаев я использую LL(сколько получится), рисую синтаксические диаграммы вирта, и по ним уже пишу парсер. «Функция на правило», пишется быстро, с такой скоростью, с какой вообще можно писать. И естественно с любой обработкой ошибок там замечательно.
Есть пара мелких старых проектов где использовал продукционные правила флойда для парсера.
Это я к тому что выбор далеко не ограничивается bison, i.e. LALR() против antlr ie LL()
Это вы про «Один раз делаю дифф, и накладываю его на сгенерированный парсер сразу после генерации, той же строчкой в мейкфайле.»? :-)
по поводу error-verbose — это фича исключительно бизона. Скажем byacc не имеет ее. И кстати, насколько я помню — этот error-verbose в старых бизонах тоже отсутствует. ДЛя линукса это не очень важно, а на юниксах можно любую версию yacc встретить
>По поводу удобства: в основном, каждый хвалит тот инструмент, к которому привык, и питает неприязнь к непривычному.
>Например, процитирую один «лучший ответ» со stackoverflow, касательно спора «ANTLR vs. bison»:
> In terms of personal taste, I think that LALR grammars are a lot easier to construct and debug. The downside is you have to deal with somewhat cryptic errors like shift-reduce
>and (the dreaded) reduce-reduce. These are errors that Bison catches when generating the parser, so it doesn't effect the end-user experience, but it can make the development
> process a bit more interesting.
Вот не разделяю вашей иронии тут. Вменяемые сообщения об ошибках — это действительно очень важное качество результирующего продукта. И LR()/LALR тут реально проигрывает.
«Тьфу пропасть! — говорит она,- и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них».
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.
К несчастью, то ж бывает у людей:
Как ни полезна вещь,- цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.
Насчет моно — я практически никогда не касался его. Обещаю, что я посмотрю как там все работает, но в ближайшее время я видимо его тестировать не буду…
// вроде, можно не дублировать, но не помню синтаксис | ( 'if' '(' EXPR ')' OP 'else' OP )=> 'if' '(' EXPR ')' OP 'else' OP | 'if' '(' EXPR ')' OPне.
Вот так:
'if' '(' expr ')' op ( ('else') => 'else' op)?
то есть когда распознали then оператор, глянули на один символ вперед. Если он 'else', то продолжаем разбор. Никакое дублирование тут не нужно.
Для точности:
$gcc -O2 erato1.c -o eratoO2 -lm
$gcc -O3 erato1.c -o eratoO3 -lm
$/usr/bin/time -f "%U" ./eratoO2
13.75
$/usr/bin/time -f "%U" ./eratoO2
13.75
/usr/bin/time -f "%U" ./eratoO3
13.75
/usr/bin/time -f "%U" ./eratoO3
13.74
То есть отличие -O0 от -O1 значительное, а разница -O1 от -O2 уже просто меняет десятые доли секунды в результате. И поскольку я не ставил себе цель сравнивать JIT именно с gcc, для меня цифр с -O0 и -O1 достаточно.
Насчет подгрузки файла, да разумеется, так можно было сделать, но я считаю это шагом назад от обьективного сравнения. Тогда получится, что для libjit время трансляции в исполняемый код полностью включено в результирующее время, а для llvm — только частично.
Сказать простыми словами — вы подставляете своих пользователей. Они могут просто не узнать, что их письмо застряло.
2)
a=b=88;
b=b+1;
echo(«test4=»,a," ",b,"\n");
3)
r=echo(«Test\n»);
echo(«test=»,r);
Из за их природы. Потому что они принимают решение по _правому_ символу в нетерминале. А человеку надо в сообщение левый символ, с которым проблема.
>Что касается бизона — он может жить везде, где есть компилятор Си, это же просто программа на Си :)
Ох не дразнитесь. И сами С везде разные, и клонов yacc целый зоопарк.
it depends. Например для sql выражений скорость разбора — очень важна.
что касается antlr — он может жить везде где живет ява, это же просто jar. но я кстати им не ползуюсь практически.
По поводу замены — В большинстве случаев я использую LL(сколько получится), рисую синтаксические диаграммы вирта, и по ним уже пишу парсер. «Функция на правило», пишется быстро, с такой скоростью, с какой вообще можно писать. И естественно с любой обработкой ошибок там замечательно.
Есть пара мелких старых проектов где использовал продукционные правила флойда для парсера.
Это я к тому что выбор далеко не ограничивается bison, i.e. LALR() против antlr ie LL()
по поводу error-verbose — это фича исключительно бизона. Скажем byacc не имеет ее. И кстати, насколько я помню — этот error-verbose в старых бизонах тоже отсутствует. ДЛя линукса это не очень важно, а на юниксах можно любую версию yacc встретить
>Например, процитирую один «лучший ответ» со stackoverflow, касательно спора «ANTLR vs. bison»:
> In terms of personal taste, I think that LALR grammars are a lot easier to construct and debug. The downside is you have to deal with somewhat cryptic errors like shift-reduce
>and (the dreaded) reduce-reduce. These are errors that Bison catches when generating the parser, so it doesn't effect the end-user experience, but it can make the development
> process a bit more interesting.
Вот не разделяю вашей иронии тут. Вменяемые сообщения об ошибках — это действительно очень важное качество результирующего продукта. И LR()/LALR тут реально проигрывает.
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них».
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.
К несчастью, то ж бывает у людей:
Как ни полезна вещь,- цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.