Каким образом теряется RAII или раскрутка стека? Если раскрутка как-то и страдает из-за использования map и then, то деструкторы не перестают вызываться. Гарантии те же и даже больше, потому что больше никто не может вклиниться в неудобные места вроде вычисления аргументов функций. Писать expected safe код проще, чем exception safe.
Что же вы все так набросились на статью! Да, не идеал, ради рекламы Expected много написано, но озвучить эту сторону тоже надо было.
Не надо забывать, что исключения совсем не zero cost даже, когда не бросаются, иначе бы noexcept в стандарт не тащили. Кроме затрат непосредственно на секцию try, которая в реализации SJLJ может быть очень недешёвой, есть ещё и косвенные на сломанные оптимизации. Сейчас с ходу не найду доклад, но точно был про внутренности llvm, где демонстрировалось, какие именно оптимизации ломаются.
Кроме того есть ещё разбухание бинаря (привет dwarf), -fno-exceptions и прочие интересные случаи.
Возможно, я чего-то о нём не знаю, но как без возможности воспроизвести проблему тестом, воспользоватся valgrind'ом? Когда есть, что запустить, чтобы воспроизвести утечку, valgrind гораздо лучше, но что делать, когда она никак не воспроизводится? Что он может сделать с одним лишь дампом?
Понятно, что посыл не в том, но всё же никто бы не стал в первый же год добавлять новый день. В реальности остались бы на старом календаре, а потом бы уже постепенно перешли, когда подготовили и софт и людей. Церковь вон живёт с юлианским календарём и никаких проблем не имеет.
Да, невнимательно посмотрел на флаги. Дописал в P.S.
Протестировал у себя, получил похожие цифры, а потом уже удвоился за счёт проверок границ. Даже не задумывался, что можно бенчмаркать DMD, на автомате взял ldc. Результаты у меня:
C gcc 8.3: Finished in 0.696s
D ldc2 1.10.0: Finished in 0.638s
Есть разброс, но в целом D версия чуть быстрее.
Уже прокомментировали про C++, добавлю то же самое про D. Достаточно добавить флажок boundscheck=off и получить удвоение скорости. Размен безопасности на скорость, которую вы сделали в хаскеле.
P.S. Забыл про главное, компилятор ldc2, а не референсный DMD.
Простите за скептицизм, но уверены, что речь не о планетах (Венера, Юпитер)? Они в разы ярче любой звезды, но найти на дневном небе даже их почти нереально, хотя потом уже хорошо видно. У меня получалось найти биноклем и только потом глазами по очень точному направлению. Может быть в горах с этим получше, яркость неба, теоретически, чуть меньше, контрастность выше, но всё равно с трудом верится.
Наверное уже сто раз писали, но почему каждый год конкурс в настолько неудобное время? То в разгар новогодних праздников, то как сейчас финал под ёлочкой. Что для студентов, что для работающих, конец года — самое напряжное время — зачёты, дедлайны и тд. Почему не весной? Чтобы и середина семестра, и не отпускной сезон, и не праздники.
Уже который год очень хочу нормально поучаствовать, но катастрофически не хватает времени и сил.
И всё равно спасибо организаторам. Хоть как-нибудь но постараюсь поучаствовать.
Спасибо за статью. Тоже использую Ragel, очень неожиданно и приятно видеть, что ещё кто-то его тоже использует.
У вас не самая простая для рагелевской грамматики задача — парные кавычки. Обычно всё проще и не требует ручных fcall и fret — больше описаний грамматики, меньше внутренностей.
Про понятнее или нет — спорный вопрос. Безусловно, порог входа в него высокий. Понять написанное в общих чертах можно и без доки, но чтобы менять придётся освоить весь pdf документации. Зато потом начинаешь понимать, что это самый нормальный способ парсинга любого текстового формата. Поддерживаемость и возможность добавления фич по сравнению с ручным разбором кодом даже с регекспами и рядом не стояла. Есть опыт поддержки парсера, написанного полностью руками и другого на рагеле, написанных другими людьми — небо и земля. В первом поправить логику ничего не сломав практически невозможно, со вторым делай, что хочешь.
И ещё хотел бы отметить безумную производительность. Есть разные режимы генерации, но тот, что через goto, создаёт нечто, что обогнать в бенчмарках руками написанным кодом не получается. Так что, если нужно распарсить текстовый протокол, Ragel — одновременно удобное и очень высокопроизводительное решение.
Потому что про i++ компилятор имеет и прав, и возможность убрать лишние операции, превратив в ++i, а v.size() выносить за пределы цикла нет. Если я, конечно, правильно понял вашу претензию к i++
Так вектор и не теряет. Немного маскирует. На чистом uint8_t* вы получите ту же самую беду с алиасингом, если не как автор в примере с указателем передадите по значению, а создадите свой struct с указателем и длинной и передадите указтель на этот самый struct. Это очень часто используется в C для всевозможных массивов и буферов и точно так же стреляет.
При чём тут C++? Заметьте, код корректно работает во всех версиях, дело только в производительности. Ну а то, что для написания производительного кода приходится закапываться в асм и архитектуру процессора, никогда никого не удивляло.
Спасибо за перевод. У меня появился ещё один аргумент в войне за возвращение strict aliasing в проект. К сожалению сейчас по причинам зависимостей и глубокой истории включен -fno-strict-aliasing. Он вообще абсурдно популярен. С одной стороны люди не хотят разбираться с правилами и багами оптимизированного билда, но с другой иногда существенно теряют в производительности, что и показано в статье.
Ошибся на 3 порядка. Всё-таки получается выдержка в микросекундах. Разница относительно реальных около 100 раз, но это уже выглядит решаемым при помощи ведения за объектом и TDI, про который написали выше.
С дифракционным пределом всё просто, но на какой выдержке сделан кадр, чтобы не было смаза? Если не компенсировать орбитальную скорость, то получится, что нужна выдержка 10см / 7км/с, что даёт наносекунды. Никакой светосилы не хватит.
Если компенсировать, вращая телескоп в обратную движению сторону, то будет лучше, но на реально возможных выдержках порядка 1мс (1/1000), паралакс должен смазать все высокие здания. Да и на уровне земли из-за поворота кадра будет смаз сильно выше дифракционного.
Как они это делают?
Выглядит как панацея и серебряная пуля вместе взятые. Я правильно понимаю, что вы при каждой потере ссылки проходите до рута чтобы понять, не была ли она последней? Если да, то это медленно. Если нет, то не понятно, как это защищает от циклических ссылок.
Есть ли замеры скорости работы? Потребления памяти?
Не надо забывать, что исключения совсем не zero cost даже, когда не бросаются, иначе бы noexcept в стандарт не тащили. Кроме затрат непосредственно на секцию try, которая в реализации SJLJ может быть очень недешёвой, есть ещё и косвенные на сломанные оптимизации. Сейчас с ходу не найду доклад, но точно был про внутренности llvm, где демонстрировалось, какие именно оптимизации ломаются.
Кроме того есть ещё разбухание бинаря (привет dwarf), -fno-exceptions и прочие интересные случаи.
Протестировал у себя, получил похожие цифры, а потом уже удвоился за счёт проверок границ. Даже не задумывался, что можно бенчмаркать DMD, на автомате взял ldc. Результаты у меня:
C gcc 8.3: Finished in 0.696s
D ldc2 1.10.0: Finished in 0.638s
Есть разброс, но в целом D версия чуть быстрее.
P.S. Забыл про главное, компилятор ldc2, а не референсный DMD.
Это должно быть здесь. Доклад Андрея Александреску про алгоритмическую сложность и реальность на CppCon 2019.
Уже который год очень хочу нормально поучаствовать, но катастрофически не хватает времени и сил.
И всё равно спасибо организаторам. Хоть как-нибудь но постараюсь поучаствовать.
У вас не самая простая для рагелевской грамматики задача — парные кавычки. Обычно всё проще и не требует ручных fcall и fret — больше описаний грамматики, меньше внутренностей.
Про понятнее или нет — спорный вопрос. Безусловно, порог входа в него высокий. Понять написанное в общих чертах можно и без доки, но чтобы менять придётся освоить весь pdf документации. Зато потом начинаешь понимать, что это самый нормальный способ парсинга любого текстового формата. Поддерживаемость и возможность добавления фич по сравнению с ручным разбором кодом даже с регекспами и рядом не стояла. Есть опыт поддержки парсера, написанного полностью руками и другого на рагеле, написанных другими людьми — небо и земля. В первом поправить логику ничего не сломав практически невозможно, со вторым делай, что хочешь.
И ещё хотел бы отметить безумную производительность. Есть разные режимы генерации, но тот, что через goto, создаёт нечто, что обогнать в бенчмарках руками написанным кодом не получается. Так что, если нужно распарсить текстовый протокол, Ragel — одновременно удобное и очень высокопроизводительное решение.
Если компенсировать, вращая телескоп в обратную движению сторону, то будет лучше, но на реально возможных выдержках порядка 1мс (1/1000), паралакс должен смазать все высокие здания. Да и на уровне земли из-за поворота кадра будет смаз сильно выше дифракционного.
Как они это делают?
Есть ли замеры скорости работы? Потребления памяти?