Здравствуйте, Аноним, Вы писали:
А>Кто что может сказать по поводу А>1) Chilon А>2) pegtl
А>в плане удобности использования/простоты/надежности/скорости etc. А>а также по сравнению с boost::spirit
А>масштаб — начиная от сложных конфигурационных файлов до фронтендов
Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д). В Испльзовании, на любителя, но не так сложно как кажется. Надежность — ну не очень понятно, что имеется ввиду. Первый аналог, отмел бы сразу — так как C++0x Library. Будет еще очень сырая. Вторая — тоже самое. все ИМХО.
Не знаю что такое "фронтенд" но если имеется в виду DSL, то писать на спирите можно(про "сложных конфигурационных файлов" без вопрсов). Если правила DSL очень сложны, то я бы посмотрел в сторону flex/bison
Здравствуйте, pzhy, Вы писали:
P>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д). В Испльзовании, на любителя, но не так сложно как кажется. Надежность — ну не очень понятно, что имеется ввиду. Первый аналог, отмел бы сразу — так как C++0x Library. Будет еще очень сырая. Вторая — тоже самое. все ИМХО. P>Не знаю что такое "фронтенд" но если имеется в виду DSL, то писать на спирите можно(про "сложных конфигурационных файлов" без вопрсов). Если правила DSL очень сложны, то я бы посмотрел в сторону flex/bison
+1
только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.
Здравствуйте, pzhy, Вы писали:
P>Здравствуйте, Аноним, Вы писали:
А>>Кто что может сказать по поводу А>>1) Chilon А>>2) pegtl
А>>в плане удобности использования/простоты/надежности/скорости etc. А>>а также по сравнению с boost::spirit
А>>масштаб — начиная от сложных конфигурационных файлов до фронтендов
P>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д).
Существует мнение, что Spirit и atoi/ftoi не одинакововы по функциональности. Точнее, Spirit не охватывает всей функциональности atoi/ftoi. А именно, вторые функции преобразуют строки в числа в зависимости от настроек языка в системе.
Ну и вообще, сами подумаете, было бы глупо, если бы вручную написанны функции на голом Си (в Spirit функции чтения числа, впрочем, тоже написаны вручную) работали бы на порядок медленнее чем шаблонные нагромождения Boost.
Здравствуйте, Aleх, Вы писали:
A>Здравствуйте, pzhy, Вы писали:
P>>Здравствуйте, Аноним, Вы писали:
А>>>Кто что может сказать по поводу А>>>1) Chilon А>>>2) pegtl
А>>>в плане удобности использования/простоты/надежности/скорости etc. А>>>а также по сравнению с boost::spirit
А>>>масштаб — начиная от сложных конфигурационных файлов до фронтендов
P>>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д)
A>Ну и вообще, сами подумаете, было бы глупо, если бы вручную написанны функции на голом Си (в Spirit функции чтения числа, впрочем, тоже написаны вручную) работали бы на порядок медленнее чем шаблонные нагромождения Boost.
Я что-то не пойму каким образом производительность в рантайме связана с шаблонами, которые инстанцируются в compile-time?
Здравствуйте, blackhearted, Вы писали:
B>Здравствуйте, Aleх, Вы писали:
A>>Здравствуйте, pzhy, Вы писали:
P>>>Здравствуйте, Аноним, Вы писали:
А>>>>Кто что может сказать по поводу А>>>>1) Chilon А>>>>2) pegtl
А>>>>в плане удобности использования/простоты/надежности/скорости etc. А>>>>а также по сравнению с boost::spirit
А>>>>масштаб — начиная от сложных конфигурационных файлов до фронтендов
P>>>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д)
A>>Ну и вообще, сами подумаете, было бы глупо, если бы вручную написанны функции на голом Си (в Spirit функции чтения числа, впрочем, тоже написаны вручную) работали бы на порядок медленнее чем шаблонные нагромождения Boost.
B>Я что-то не пойму каким образом производительность в рантайме связана с шаблонами, которые инстанцируются в compile-time?
А очень простым. Понимаете ли, мы живем не в идеальном мире, в котором всё на практике точно так же, как и в теории. Компиляторы часто написаны так, что плохо переваривают шаблонный код. Особенно плохо (я бы сказал отвратительно) это делает компилятор Intel. То есть на одном проекте (с большим количеством шаблонного кода) я встретился с тем, что msvc и gcc компилировали код на ура (и всё хорошо работало), а компилятор Intel (какие бы я настройки на пробовал) компилировал проект в значительно худший (медленный) код (причем кода получалось раз в 10 больше). И не надо мне говорить по поводу размера кода то, что возможно туда добавились библиотеки.
P>>>>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д)
A>>>Ну и вообще, сами подумаете, было бы глупо, если бы вручную написанны функции на голом Си (в Spirit функции чтения числа, впрочем, тоже написаны вручную) работали бы на порядок медленнее чем шаблонные нагромождения Boost.
B>>Я что-то не пойму каким образом производительность в рантайме связана с шаблонами, которые инстанцируются в compile-time?
A>А очень простым. Понимаете ли, мы живем не в идеальном мире, в котором всё на практике точно так же, как и в теории. Компиляторы часто написаны так, что плохо переваривают шаблонный код. Особенно плохо (я бы сказал отвратительно) это делает компилятор Intel. То есть на одном проекте (с большим количеством шаблонного кода) я встретился с тем, что msvc и gcc компилировали код на ура (и всё хорошо работало), а компилятор Intel (какие бы я настройки на пробовал) компилировал проект в значительно худший (медленный) код (причем кода получалось раз в 10 больше). И не надо мне говорить по поводу размера кода то, что возможно туда добавились библиотеки.
Никто не спорит, что если под вашу платформу и компилятор boost давал значительно худший (кстати — это в каких единицах?) код — то флаг вам в руки, пишите всё сами и не используёте boost.
Здравствуйте, blackhearted, Вы писали:
B>Здравствуйте, Aleх, Вы писали:
P>>>>>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д)
A>>>>Ну и вообще, сами подумаете, было бы глупо, если бы вручную написанны функции на голом Си (в Spirit функции чтения числа, впрочем, тоже написаны вручную) работали бы на порядок медленнее чем шаблонные нагромождения Boost.
B>>>Я что-то не пойму каким образом производительность в рантайме связана с шаблонами, которые инстанцируются в compile-time?
A>>А очень простым. Понимаете ли, мы живем не в идеальном мире, в котором всё на практике точно так же, как и в теории. Компиляторы часто написаны так, что плохо переваривают шаблонный код. Особенно плохо (я бы сказал отвратительно) это делает компилятор Intel. То есть на одном проекте (с большим количеством шаблонного кода) я встретился с тем, что msvc и gcc компилировали код на ура (и всё хорошо работало), а компилятор Intel (какие бы я настройки на пробовал) компилировал проект в значительно худший (медленный) код (причем кода получалось раз в 10 больше). И не надо мне говорить по поводу размера кода то, что возможно туда добавились библиотеки.
B>Никто не спорит, что если под вашу платформу и компилятор boost давал значительно худший (кстати — это в каких единицах?) код — то флаг вам в руки, пишите всё сами и не используёте boost.
Я бы сказал во всех: скорость выполнения, размер кода, время компиляции.
Boost и не использовался, хотя код всё равно был похож на внутренности буста.
Проблема была только в компиляторе Intel. Кстати, интересно, как он компилирует Boost?
А вообще своим постом я хотел сказать, что к примеру код переписанный с использованием лямбд в большинстве случаев будет работать медленнее, и уж точно не будет обгонять такой же по функциональности и алгоритмической сложности код, написанный без них.
Здравствуйте, jazzer, Вы писали:
J>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.
По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.
Здравствуйте, Aleх, Вы писали:
P>>Использовал, только boost::spirit. Скорость в рантайме впечатляет(например парсинг числа быстрее чем atoi,ftoi и т.д). A>Существует мнение, что Spirit и atoi/ftoi не одинакововы по функциональности. Точнее, Spirit не охватывает всей функциональности atoi/ftoi. А именно, вторые функции преобразуют строки в числа в зависимости от настроек языка в системе.
A>Ну и вообще, сами подумаете, было бы глупо, если бы вручную написанны функции на голом Си (в Spirit функции чтения числа, впрочем, тоже написаны вручную) работали бы на порядок медленнее чем шаблонные нагромождения Boost.
Функцональность спирита в этом плане несоизмерима выше. Вы можете понять воспринял он это как число или нет. А в atoi и т.д. нет. В плане перфоманса, думаю заинлайненный код спирита имеет больше шансов быть более сильно оптимизирован по месту. А atoi это всегда вызов уже созданного бинарного кода.
Здравствуйте, pzhy, Вы писали:
J>>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.
P>По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.
В спирите раньше был глобальный мьютекс (сейчас не знаю), который иногда здорово просаживал производительность.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Здравствуйте, pzhy, Вы писали:
J>>>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.
P>>По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.
ТКС>В спирите раньше был глобальный мьютекс (сейчас не знаю), который иногда здорово просаживал производительность.
Интересно, с чем же он конкурировал? Он что парсит в несколько потоков? Когда вешал его, то почему-то видел 100% занятие только одного ядра. Но если все же в несколько потоков, то респект разрабам. Да только по всей логике, так быть не может. Вы с чем то путаете
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Здравствуйте, pzhy, Вы писали:
J>>>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.
P>>По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.
ТКС>В спирите раньше был глобальный мьютекс (сейчас не знаю), который иногда здорово просаживал производительность.
Или для защиты запуска нескольких парсеров одновременно. Ну может быть... Хотя тоже не очень понятно зачем. По крайней мере дизасамблируя его в свое время я ничего подобного не видел. Но вообще он очень быстр, по крайней мере на простых парсерах. Я на первых порах просто офигел.
Здравствуйте, pzhy, Вы писали:
J>>>>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.
P>>>По скорости в рантайме, думаю спирит будет быстрее. Спирит2, я так и не нашел как к обработчику прикрутить позиционный итератор. Хотя не так долго искал.
ТКС>>В спирите раньше был глобальный мьютекс (сейчас не знаю), который иногда здорово просаживал производительность.
P>Интересно, с чем же он конкурировал? Он что парсит в несколько потоков?
У меня в программе сериализация в xml в несколько потоков, соответственно и парсить надо было в несколько потоков.
P>Когда вешал его, то почему-то видел 100% занятие только одного ядра. Но если все же в несколько потоков, то респект разрабам. Да только по всей логике, так быть не может. Вы с чем то путаете
Сейчас проверил — в версии 1.42 данный мьютекс по-прежнему в наличии, ищется по макросу BOOST_SPIRIT_THREADSAFE. Хотя раньше вроде как-то слегка по другому там все было. На кой черт он понадобился в object_with_id_base — понятия не имею. Я при возникновении проблемы просто переписал xml-парсер без спирита, благо были и другие показания (рекурсивное правило, которое я не знал как переписать со спиритом без рекурсии и которое иногда роняло программу). Стало быстрее.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, pzhy, Вы писали:
P>Или для защиты запуска нескольких парсеров одновременно. Ну может быть... Хотя тоже не очень понятно зачем. По крайней мере дизасамблируя его в свое время я ничего подобного не видел. Но вообще он очень быстр, по крайней мере на простых парсерах. Я на первых порах просто офигел.
Да на простых парсерах там реально полезны только примитивы, которые вместо atoi и т.п. Все остальное получается без спирита в 2, ну пусть в 3 раза многословней, зато отлаживается и компилируется в лет.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, jazzer, Вы писали:
J>только одно замечание: имхо, смотреть в сторону flex/bison имеет смысл только если гонишься за скоростью либо генерацией парсеров на нескольких языках, в остальном спирит в плане интеграции с твоим кодом удобнее будет. Особенно Спирит2.
Да еще один минус спирита, на нем покрайней мере года 2 назад, невозможно было описать граматику плюсов. Т.е. теритически возоможно, но ни один компилятор не справлялся со всеми 180 правилами. Ну скорость компиляции, это нечто. Простой ДСЛ описаный на спирите прибавлял у меня 10 минут. Хотя в рантайме он очень крут
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Здравствуйте, pzhy, Вы писали:
P>>Или для защиты запуска нескольких парсеров одновременно. Ну может быть... Хотя тоже не очень понятно зачем. По крайней мере дизасамблируя его в свое время я ничего подобного не видел. Но вообще он очень быстр, по крайней мере на простых парсерах. Я на первых порах просто офигел.
ТКС>Да на простых парсерах там реально полезны только примитивы, которые вместо atoi и т.п. Все остальное получается без спирита в 2, ну пусть в 3 раза многословней, зато отлаживается и компилируется в лет.
А вы пишите свой парсер с нуля, или что то используете? Просто писать что то свое для ДСЛ, ну очень для меня сложно. flex/bison очень маштабно и обьемно. Но для своих целей самое то. Но и спирит во многих вещах рулит. Я как то переписал один парсер (был на стртоках) на нем получил 70% профита. Но ведь самое главное этот код потом менять можно, а тот только переписать
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Сейчас проверил — в версии 1.42 данный мьютекс по-прежнему в наличии, ищется по макросу BOOST_SPIRIT_THREADSAFE.
У меня походу собрана без этого дефайна. Прикольно. Linux Fedora 13.
Здравствуйте, pzhy, Вы писали:
ТКС>>Сейчас проверил — в версии 1.42 данный мьютекс по-прежнему в наличии, ищется по макросу BOOST_SPIRIT_THREADSAFE. P>У меня походу собрана без этого дефайна. Прикольно. Linux Fedora 13.
Собирать буст (конкретно, serialization) с этим дефайном под виндой — отдельное развлечение
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Тот кто сидит в пруду, Вы писали:
ТКС>Собирать буст (конкретно, serialization) с этим дефайном под виндой — отдельное развлечение
А он так сильно нужен для вас? При крахе, не помню уже точно как на винде, все равно можно не успеть. А так не легче, ли свою синхронизацию сделать? Ведь все равно придется, но более наглядно
