На уровне понимания автор описал out-of-order && register renaming && score-boarding без употребления умных терминов, но по-сути. А дальше удивляется: они не дают наблюдаемого результата из-за DU-зависимости. На этом фоне ваш комментарий похож на нагромождение умных слов без понимания сути под ними.
1. Автора удивляет разрыв DU-зависимости (единственной "истинной" зависимости в терминах компиляторов, которую разорвать действительно сложно, особенно в аппаратуре). Причём разрыв DU-зависимости в аппаратуре.
2. Автор описал разрыв зависимости (и возможные решения) довольно качественно (что прямо супер для человека от железа\компиляторов далёкого).
3. Как указано выше - за такую технику отвечает Immediate Folding. Что весьма интересно.
1. У всего мира мониторы на Realteck-овских чипах работают (без доп-чипов), а у Лайткома не работают. 2. Что значит "не работают" - если выпаять Миландровский чип наблюдаются минорные проблемы при загрузке со стабилизацией сигнала.
Мой субьективный вывод: чип Realteck работает с неполной функциоальностью (подпорчен, неправильно впаян, ещё что-то - не принципиально) чтобы Миландровскому чипу формально было чем заняться.
Мы росли в сотрудниках, в ассортименте, в обороте, в квадратных метрах, единственное, что росло плохо – эффективность.
Спасибо за честность (и к стати сразу видно, что "Я ушел с хорошей работы в корпорации" - подход явно с пониманием "что и зачем делать" и с ретро "что не получилось".
А про маркетплейсы - к сожалению у меня, как покупателя противоположный взгляд:
А допродажа прекрасна тем, что деньги на привлечение вы уже потратили ... Но на маркетплейсах невозможно делать апсейл (допродажи) или звонить клиенту.
Не можете слать полезные почтовые рассылки, рассказывать о новых продуктах, догонять ретаргетингом, работать с брошенными корзинами, выстраивать собственный бренд — показывать свои фирменные цвета на сайте и призывать купить в собственной тональности.
Спасибо маркетплейсы, что избавили меня, покупателя, от всего этого!
Конкуренция на маркетплейсах растет, а с ней и потребность в рекламе.
Также спасибо, что увеличили конкуренцию - т.е. в канале продаж нет заградительной наценки за высокий порог входа.
какие проблемы решает текущая грамматика - я понимаю:
Это например упрощение обработки, включая избегание ошибок: a - b + x / y * z (а не аргументы про скорость (*)) Ценой заставление пользователя делать мешанину из скобок. Моё утверждение, что плюсы от такого парсера вовсе не перевешивают минусов.
*) Ваши аргументы про скорость - вероятно неактуальны. За исключением corner-case (шаблоны \ хиндли-милнер \ ...) фронтэнд, а тем более парсинг, не является сколь бы то ни было прожорливой частью.
======= спор по маловажной perf-части ========
Совершенно верно. Однако в практических случаях, когда он вас всё-таки настигает, он именно что «бесконечный». Поэтому я позволил себе такую художественную вольность описания явления.
А где посмотреть примеры с экспоненциальным парсингом, скажем C (кратно более сложная вещь, чем парсинг подинтегрального выражения) зависал? Чтобы оценить насколько актуальна проблема для кардинально более сложного случая?
Непонятно, почему оно должно быть быстрее, если с лексером получается всё то же самое, только ещё и с лексером.
Тут был не прав, причём неправ в том месте, где "можно вынести лексер из-под капота парсера". Токенизировать всё-таки надо по ходу парсинга выплёвывая в парсинг только правильные токены.
> максимально простых фаз, каждая из которых делает свою законченную часть работы;
Поздравляю, это суть всех парсер-комбинаторов ... Его кирпичики (и наши кирпичики тоже!) — именно что максимально простые фазы
Как у вас сочетается "совместить парсер с лексером" и "делать максимально простые фазы". Ну это не говоря уже о том, что компилятор делит на фазы компиляции, а парсер-комбинатор - делает работу внутри фазы компиляции.
А по бэкэнду - выглядит так, что минимально необходимый функционал: - нелокальный peephole: a + b + c + c -a ( у вас "+a" и "-а" будут отстоять довольно далеко друг от друга). - замена переменных.
Ну это если бэк входит в область рассмотрения статьи.
Судя по задаче у вас графовых оптимизаций не будет - тольк над деревьями.
Исходя из этого - в чистой теории: имеет ли смысл в этой схеме вообще упоминать IR? (я в целом писал это ниже - но я тогда предполагал, что вы студент).
В LL-парсерах бэктрэкинг не бесконечный, а экспоненциальной.
Но на практике вы в эту экспоненту вообще вряд ли когда-нибудь упираетесь при парсинге чего-то похожего на ЯП (corner case - разумеется возможны) - т.е. бэктрегинг в каких-то разумных случаях в профиле вообще не виден.
С заменой как у вас L_PAREN = skip(r'\(')- куда лучше; На мой взгляд там нарушение PEP 8: Function and Variable Names (но я не спец по Python - возможно для 0-арных ф-ий там хитрое исключение) .
Наличие regexp внутри бизнес-логики - делают код куда менее поддерживаемым. Странно, что это следует объяснять.
С лексером:
куда более "compiler way" - когда сложная системаа строится из набора максимально простых фаз, каждая из которых делает свою законченную часть работы;
лексер имеет законченную функциональность;
Не сложно - здесь достаточно линейного прохода лексера, потом прохода парсера;
скорее всего быстрее;
Что можно перефразирвовать, как "с лексером лучше".
употребление терминов так, как у вас в предисловии.
Вы действительно сомниваетесь в том, что сегодня compiler (по поводу DSL-компилятор к стати у меня изначально вопросов не было - такое употребление встречал, хотя с DSL особо не работаю - чем объяснить разную выдачу гугла пока не понимаю) в большинстве случаев употребляется как частный стучай транслятора, когда целевой язык - биранрый \ объектный \ ассемблер (или другой язык платформы)?
Но это говорит только о распространенности обсуждаемых определений, правильно?
Ничего себе "только" - значения слов это узус, то как они употребляются. Тем более вы преподаватель (а не студент, как изначально думал). Сделать хорошую работу, и снабдить её разъяснительным текстом лет на 20 устаревшим? А потом студенты тут на хабре пишут - нас учили всякой устаревшей фигне.
Что вообще может человека мотивировать поступать так? Нежелание признавать свои ошибки "якобы под давлением"? Ну ок мне не сложно: - вы сделали хорошую полезную для студентов работу; - сопровождение хорошо написано и отлично выглядит; - если поменяете терминологию на более современную - это сделает и без того хорошую работу ещё лучше;
Чтобы сэкономить 20-30 строк на PEG-парсере превратим входное выражение в нечитаемую мешанину из скобок.
Это выглядит как плохое архитектурное решение, анлесс ваша целевая метрика - минимальное число строк кода (ценой удобства пользователя).
П.С. > Вообще-то именно так и принято писать PEG-парсеры, не знаю, что вас здесь удивило. А где и зачем так принято, - что ради довольно небольшого кол-ва строк и исходная грамматика менее удобна и код regex начитает содержать?
К стати вам тут IR в общепринятом понимании не нужен (это довольно сложная структура).
Если пишите диплом (или что вы пишите?) - то можете черкнуть, что поскольку AST структурно совпадает разработанным вами IR, то IR = map(transform_node, AST), но (*). *) А в случае эквивалентных преобразований структурно одинаковых выражений воспользуемся α-эквивалентностью поддеревьев (комиссии понравится).
Углы срезаны, as-is, смысл имеет (сложность-то обычно не в лексере, а в заворачивании лексера под капот парсера бесшовно лениво и с нормальными сообщениями об ошибках). В минимально поддежриваемом проекте лучше бы в этих местах не срезать.
В целом "пара месяцев поддержки и зумеры переизобретут лексер" - если тут есть сарказм (а он есть), то абсолютно беззлобный. @worldbeater
Несколько неточностей в предисловии лучше поправить:
1. Переводом кода с одного ЯП на другой занимается транслятор (иногда применяют термин "транспилятор"). Компилятор - частный случай транслятора: компилятор переводит код с высокоуровневого языка (обычно ЯП) в машинный \ объектный код. 2. "передним/задним планом" фронтэнд и бэкэнд азывать не принято. 3. Сегодня (начиная с llvm) компилятор делят на frontend / middleend / backend 4. Лексер + парсер - малая часть фронтэнда. Основная часть фронтэнда - построение AST и специфические (обычно глобальные) оптимизации над AST.
Также добавлю вопрос от себя: Лексер (в лексере-парсере) нужен для того, чтобы ваш парсинг был устойчив к разделителям и форматированию пользователя. 5. С peco (и вообще парсерами в python) не работал - а что у вас обеспечивает эту фунциональность?
Так да - нормальная проверка на наличие мозга у кандидата-джуна.
Я думаю что теория графов - самый востребованный раздел математики для чистых прогеров (для DS - теорвер + статистика, для ML - линейная алгебра + методы оптимизации).
то написать правильное окончание у слова с числительным (2 ракетки, но 5 ракеток, и вам нужно в автоматическом режиме подставить окончание);
Вы осетра-то урежьте. В склонениях \ спряжениях список исключений такой, что делается или сторонними средствами или с таким количеством ошибок, что лучше не начинать.
Статья норм (за исключением всяких нюансов - например в leetcode заранее пишут, что дана ASCII строка).
Найм действительно сломан - т.к. выпускники курсов обмануты дезинформированы рекламой платных курсов. После выпуска программистами они не являются и подают по 100 заявок на любую приличную вакансию, обманывая дописывая опыт в резюме.
Проблема почему к вам не идут приличные кандидаты - ну у вас максимально безотрадный стек (с одной стороны он не модный и бесперспективный, с другой IMHO скучный и унылый). Но тут уже ничего не сделать.
Это не от clang зависит а от опций оптимизации.
На -O0 цикл есть, начиная с -O1 цикл сворачивается.
На уровне понимания автор описал out-of-order && register renaming && score-boarding без употребления умных терминов, но по-сути. А дальше удивляется: они не дают наблюдаемого результата из-за DU-зависимости.
На этом фоне ваш комментарий похож на нагромождение умных слов без понимания сути под ними.
1. Автора удивляет разрыв DU-зависимости (единственной "истинной" зависимости в терминах компиляторов, которую разорвать действительно сложно, особенно в аппаратуре).
Причём разрыв DU-зависимости в аппаратуре.
2. Автор описал разрыв зависимости (и возможные решения) довольно качественно (что прямо супер для человека от железа\компиляторов далёкого).
3. Как указано выше - за такую технику отвечает Immediate Folding. Что весьма интересно.
Краткое резюме расследования:
1. У всего мира мониторы на Realteck-овских чипах работают (без доп-чипов), а у Лайткома не работают.
2. Что значит "не работают" - если выпаять Миландровский чип наблюдаются минорные проблемы при загрузке со стабилизацией сигнала.
Мой субьективный вывод:
чип Realteck работает с неполной функциоальностью (подпорчен, неправильно впаян, ещё что-то - не принципиально) чтобы Миландровскому чипу формально было чем заняться.
Постоянные издержки не масштабируются вообще - во всяком случае в учебнике.
Это как "ноутбук руководителя" или "подписка 1С предприятие 1шт".
Спасибо за честность (и к стати сразу видно, что "Я ушел с хорошей работы в корпорации" - подход явно с пониманием "что и зачем делать" и с ретро "что не получилось".
А про маркетплейсы - к сожалению у меня, как покупателя противоположный взгляд:
Спасибо маркетплейсы, что избавили меня, покупателя, от всего этого!
Также спасибо, что увеличили конкуренцию - т.е. в канале продаж нет заградительной наценки за высокий порог входа.
Update:
какие проблемы решает текущая грамматика - я понимаю:
Это например упрощение обработки, включая избегание ошибок:
a - b + x / y * z(а не аргументы про скорость (*))Ценой заставление пользователя делать мешанину из скобок.
Моё утверждение, что плюсы от такого парсера вовсе не перевешивают минусов.
*) Ваши аргументы про скорость - вероятно неактуальны. За исключением corner-case (шаблоны \ хиндли-милнер \ ...) фронтэнд, а тем более парсинг, не является сколь бы то ни было прожорливой частью.
======= спор по маловажной perf-части ========
А где посмотреть примеры с экспоненциальным парсингом, скажем C (кратно более сложная вещь, чем парсинг подинтегрального выражения) зависал? Чтобы оценить насколько актуальна проблема для кардинально более сложного случая?
Тут был не прав, причём неправ в том месте, где "можно вынести лексер из-под капота парсера". Токенизировать всё-таки надо по ходу парсинга выплёвывая в парсинг только правильные токены.
Как у вас сочетается "совместить парсер с лексером" и "делать максимально простые фазы".
Ну это не говоря уже о том, что компилятор делит на фазы компиляции, а парсер-комбинатор - делает работу внутри фазы компиляции.
А по бэкэнду - выглядит так, что минимально необходимый функционал:
- нелокальный peephole: a + b + c + c -a ( у вас "+a" и "-а" будут отстоять довольно далеко друг от друга).
- замена переменных.
Ну это если бэк входит в область рассмотрения статьи.
👍
Судя по задаче у вас графовых оптимизаций не будет - тольк над деревьями.
Исходя из этого - в чистой теории: имеет ли смысл в этой схеме вообще упоминать IR?
(я в целом писал это ниже - но я тогда предполагал, что вы студент).
В LL-парсерах бэктрэкинг не бесконечный, а экспоненциальной.
Но на практике вы в эту экспоненту вообще вряд ли когда-нибудь упираетесь при парсинге чего-то похожего на ЯП (corner case - разумеется возможны) - т.е. бэктрегинг в каких-то разумных случаях в профиле вообще не виден.
С заменой как у вас
L_PAREN = skip(r'\(')- куда лучше;На мой взгляд там нарушение PEP 8: Function and Variable Names (но я не спец по Python - возможно для 0-арных ф-ий там хитрое исключение) .
Наличие regexp внутри бизнес-логики - делают код куда менее поддерживаемым. Странно, что это следует объяснять.
С лексером:
куда более "compiler way" - когда сложная системаа строится из набора максимально простых фаз, каждая из которых делает свою законченную часть работы;
лексер имеет законченную функциональность;
Не сложно - здесь достаточно линейного прохода лексера, потом прохода парсера;
скорее всего быстрее;
Что можно перефразирвовать, как "с лексером лучше".
употребление терминов так, как у вас в предисловии.
Вы действительно сомниваетесь в том, что сегодня compiler (по поводу DSL-компилятор к стати у меня изначально вопросов не было - такое употребление встречал, хотя с DSL особо не работаю - чем объяснить разную выдачу гугла пока не понимаю) в большинстве случаев употребляется как частный стучай транслятора, когда целевой язык - биранрый \ объектный \ ассемблер (или другой язык платформы)?
Ничего себе "только" - значения слов это узус, то как они употребляются.
Тем более вы преподаватель (а не студент, как изначально думал).
Сделать хорошую работу, и снабдить её разъяснительным текстом лет на 20 устаревшим? А потом студенты тут на хабре пишут - нас учили всякой устаревшей фигне.
Что вообще может человека мотивировать поступать так? Нежелание признавать свои ошибки "якобы под давлением"? Ну ок мне не сложно:
- вы сделали хорошую полезную для студентов работу;
- сопровождение хорошо написано и отлично выглядит;
- если поменяете терминологию на более современную - это сделает и без того хорошую работу ещё лучше;
Чтобы сэкономить 20-30 строк на PEG-парсере превратим входное выражение в нечитаемую мешанину из скобок.
Это выглядит как плохое архитектурное решение, анлесс ваша целевая метрика - минимальное число строк кода (ценой удобства пользователя).
П.С.
> Вообще-то именно так и принято писать PEG-парсеры, не знаю, что вас здесь удивило.
А где и зачем так принято, - что ради довольно небольшого кол-ва строк и исходная грамматика менее удобна и код regex начитает содержать?
К стати вам тут IR в общепринятом понимании не нужен (это довольно сложная структура).
Если пишите диплом (или что вы пишите?) - то можете черкнуть, что поскольку AST структурно совпадает разработанным вами IR, то IR = map(transform_node, AST), но (*).
*) А в случае эквивалентных преобразований структурно одинаковых выражений воспользуемся α-эквивалентностью поддеревьев (комиссии понравится).
https://ru.wikipedia.org/wiki/Лямбда-исчисление#α-эквивалентность
Учился я как раз по Ахо-Ульман, где компилятором называется программа переводящая с одного языка на другой.
Но в реальной жизни семантика translator && compiler разделилась - оставив компилятору узкое значение, конкретного вида трансляторов.
> Rosetta is a dynamic binary translator developed by Apple Inc. for macOS, an application compatibility
> Online Rust to Csharp Converter
Проверил для DSL - их это тоже касается (см число найденных ответов)
Ок, спасибо (грепнул skip).
Ручной скип delimiters без лексера.
expr = alt(
seq(skip(r'\('), expr, bop, expr, skip(r'\)'), mkbop),
seq(var, skip(r'\('), args, skip(r'\)'), mkfun),
var,
num,)
Углы срезаны, as-is, смысл имеет (сложность-то обычно не в лексере, а в заворачивании лексера под капот парсера бесшовно лениво и с нормальными сообщениями об ошибках). В минимально поддежриваемом проекте лучше бы в этих местах не срезать.
В целом "пара месяцев поддержки и зумеры переизобретут лексер" - если тут есть сарказм (а он есть), то абсолютно беззлобный.
@worldbeater
Несколько неточностей в предисловии лучше поправить:
1. Переводом кода с одного ЯП на другой занимается транслятор (иногда применяют термин "транспилятор"). Компилятор - частный случай транслятора: компилятор переводит код с высокоуровневого языка (обычно ЯП) в машинный \ объектный код.
2. "передним/задним планом" фронтэнд и бэкэнд азывать не принято.
3. Сегодня (начиная с llvm) компилятор делят на frontend / middleend / backend
4. Лексер + парсер - малая часть фронтэнда. Основная часть фронтэнда - построение AST и специфические (обычно глобальные) оптимизации над AST.
Также добавлю вопрос от себя:
Лексер (в лексере-парсере) нужен для того, чтобы ваш парсинг был устойчив к разделителям и форматированию пользователя.
5. С peco (и вообще парсерами в python) не работал - а что у вас обеспечивает эту фунциональность?
Так да - нормальная проверка на наличие мозга у кандидата-джуна.
Я думаю что теория графов - самый востребованный раздел математики для чистых прогеров (для DS - теорвер + статистика, для ML - линейная алгебра + методы оптимизации).
Вы осетра-то урежьте.
В склонениях \ спряжениях список исключений такой, что делается или сторонними средствами или с таким количеством ошибок, что лучше не начинать.
Статья норм (за исключением всяких нюансов - например в leetcode заранее пишут, что дана ASCII строка).
Найм действительно сломан - т.к. выпускники курсов
обманутыдезинформированы рекламой платных курсов. После выпуска программистами они не являются и подают по 100 заявок на любую приличную вакансию,обманываядописывая опыт в резюме.Проблема почему к вам не идут приличные кандидаты - ну у вас максимально безотрадный стек (с одной стороны он не модный и бесперспективный, с другой IMHO скучный и унылый). Но тут уже ничего не сделать.