Простите за скептицизм, но уверены, что речь не о планетах (Венера, Юпитер)? Они в разы ярче любой звезды, но найти на дневном небе даже их почти нереально, хотя потом уже хорошо видно. У меня получалось найти биноклем и только потом глазами по очень точному направлению. Может быть в горах с этим получше, яркость неба, теоретически, чуть меньше, контрастность выше, но всё равно с трудом верится.
Наверное уже сто раз писали, но почему каждый год конкурс в настолько неудобное время? То в разгар новогодних праздников, то как сейчас финал под ёлочкой. Что для студентов, что для работающих, конец года — самое напряжное время — зачёты, дедлайны и тд. Почему не весной? Чтобы и середина семестра, и не отпускной сезон, и не праздники.
Уже который год очень хочу нормально поучаствовать, но катастрофически не хватает времени и сил.
И всё равно спасибо организаторам. Хоть как-нибудь но постараюсь поучаствовать.
Спасибо за статью. Тоже использую 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), паралакс должен смазать все высокие здания. Да и на уровне земли из-за поворота кадра будет смаз сильно выше дифракционного.
Как они это делают?
Выглядит как панацея и серебряная пуля вместе взятые. Я правильно понимаю, что вы при каждой потере ссылки проходите до рута чтобы понять, не была ли она последней? Если да, то это медленно. Если нет, то не понятно, как это защищает от циклических ссылок.
Есть ли замеры скорости работы? Потребления памяти?
Хотя бы раз попробую оправдать свой ник и поучаствую в челендже ++++++++++[>++++++++++<-]>[->+>[-]>[-]++++++++++<<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<]>[<+>-]>[-]>[<+<+>>-]+<[>-<[-]]>[>-<<<++++++++++>>-]<<[>+>+<<-]>>>+<[>[>+>+<<-]>[<+>-]<<-]>[-]>>[>>+>+<<<-]>>>[<<<+>>>-]<<+>[<->[>++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<]>[-]++++++++[<++++++>-]>[<<+>>-]>[<<+>>-]<<]>]<[->>++++++++[<++++++>-]]<[.[-]<]<[-]<<<<---------->+<[>-<[-]+++++++++.[-]]>[[-]++++++++++.[-]]<<<<]
P.S. Ужимать код не пытался, главное, что вообще работает.
Как только речь заходит об эмодзи и их сочетаниях, в памяти должны всплывать такие слова, как code point, сурогатная пара, графема. Тысячи статей про отличия букв, байт, нормализацию юникода и прочее. Кстати, при простом гуглении разделения по графемам в js находится, например: github.com/orling/grapheme-splitter
Это всё к тому, что надо знать разные тонкости, а так же иметь банальный IT кругозор чтобы знать, что спросить у гугла. В этом смысле задачка отличная.
Более того, с учётом реализации any_of, предложенной выше, она ещё и медленнее. Она перебирает все элементы, а не останавливается на первом удовлетворяющем, как цикл. Так что зависит от реальных данных, а на общий случай нужны как минимум бенчмарки.
Спасибо за статью, тема ranges не частый гость на хабре.
Не могли бы вы уточнить, что вам не нравится в коде, который упомянут в заключении? Да, ваш вариант короче, но при чём здесь эффективность? Алгоритмическая сложность одинаковая, особого оверхеда я тоже не вижу. В чём проблема?
Почему-то представил себе антиутопию, в которой люди борются за право оставаться людьми, введя специальные курсы в школах для прохождения капчи. Что-то основанное на задачах, которые мозг решает лучше процессора, но уже настолько сложное, что нетренированный человек не в состоянии это сделать. И постоянная гонка со слабым ИИ за эффективность. Учись или сольёшься с безликой массой людей и роботов.
Есть неплохое выступление Мейерса, в котором он разбирает странности C++ www.youtube.com/watch?v=KAWA1DuvCnQ
Так вот он акцентирует внимание на том, что всё это не плохо, это не идиоты в комитете, у всего есть нормальное объяснение, почему именно так, а не иначе. Да, C++ сложен, но и задача, которую он перед собой ставит не тривиальна. Сложная задача не решается просто. Совсем отдельный вопрос, актуальна ли задача и нельзя ли было взять нишу поуже.
Это должно быть здесь. Доклад Андрея Александреску про алгоритмическую сложность и реальность на CppCon 2019.
Уже который год очень хочу нормально поучаствовать, но катастрофически не хватает времени и сил.
И всё равно спасибо организаторам. Хоть как-нибудь но постараюсь поучаствовать.
У вас не самая простая для рагелевской грамматики задача — парные кавычки. Обычно всё проще и не требует ручных fcall и fret — больше описаний грамматики, меньше внутренностей.
Про понятнее или нет — спорный вопрос. Безусловно, порог входа в него высокий. Понять написанное в общих чертах можно и без доки, но чтобы менять придётся освоить весь pdf документации. Зато потом начинаешь понимать, что это самый нормальный способ парсинга любого текстового формата. Поддерживаемость и возможность добавления фич по сравнению с ручным разбором кодом даже с регекспами и рядом не стояла. Есть опыт поддержки парсера, написанного полностью руками и другого на рагеле, написанных другими людьми — небо и земля. В первом поправить логику ничего не сломав практически невозможно, со вторым делай, что хочешь.
И ещё хотел бы отметить безумную производительность. Есть разные режимы генерации, но тот, что через goto, создаёт нечто, что обогнать в бенчмарках руками написанным кодом не получается. Так что, если нужно распарсить текстовый протокол, Ragel — одновременно удобное и очень высокопроизводительное решение.
Если компенсировать, вращая телескоп в обратную движению сторону, то будет лучше, но на реально возможных выдержках порядка 1мс (1/1000), паралакс должен смазать все высокие здания. Да и на уровне земли из-за поворота кадра будет смаз сильно выше дифракционного.
Как они это делают?
Есть ли замеры скорости работы? Потребления памяти?
++++++++++[>++++++++++<-]>[->+>[-]>[-]++++++++++<<[->+>-[>+>>]>[+[-<+>]>+>>]<<<<<<]>[<+>-]>[-]>[<+<+>>-]+<[>-<[-]]>[>-<<<++++++++++>>-]<<[>+>+<<-]>>>+<[>[>+>+<<-]>[<+>-]<<-]>[-]>>[>>+>+<<<-]>>>[<<<+>>>-]<<+>[<->[>++++++++++<[->-[>+>>]>[+[-<+>]>+>>]<<<<<]>[-]++++++++[<++++++>-]>[<<+>>-]>[<<+>>-]<<]>]<[->>++++++++[<++++++>-]]<[.[-]<]<[-]<<<<---------->+<[>-<[-]+++++++++.[-]]>[[-]++++++++++.[-]]<<<<]P.S. Ужимать код не пытался, главное, что вообще работает.
Это всё к тому, что надо знать разные тонкости, а так же иметь банальный IT кругозор чтобы знать, что спросить у гугла. В этом смысле задачка отличная.
Не могли бы вы уточнить, что вам не нравится в коде, который упомянут в заключении? Да, ваш вариант короче, но при чём здесь эффективность? Алгоритмическая сложность одинаковая, особого оверхеда я тоже не вижу. В чём проблема?
Так вот он акцентирует внимание на том, что всё это не плохо, это не идиоты в комитете, у всего есть нормальное объяснение, почему именно так, а не иначе. Да, C++ сложен, но и задача, которую он перед собой ставит не тривиальна. Сложная задача не решается просто. Совсем отдельный вопрос, актуальна ли задача и нельзя ли было взять нишу поуже.