Большое спасибо!

Это, всё-таки, скорее наброс в известном стиле "крутой пожилой профессор пересматривает основы", поэтому название совершенно не отражает содержание, которое, если "в двух словах":

1. Код разделился на hot & cold, что связано с большими объёмами данных, которые пропускаются через системы. А объёмы данных связаны с тем, что они реально лимитированы терпением конечных пользователей к тормозам (есть диалектическая пара - "производительность компа" и "объём данных, которые через него будут пропускать). Очень важно знать, какой кусок программы cold, какой hot.

2. Ручные оптимизации работают значительно лучше компиляторных, поскольку человек понимает, какие данные с какой вероятностью могут проходить через систему. А передать компилятору эти знания не может.

3. Автор подмечает, что разработчик алгоритма и компилятор работают в связке, пытаясь создать как можно более ... код на целевой машине. Как правило, разработчик алгоритма правильно оценивает сложность алгоритма, но! Если программа мигрирует в сторону более параллельных машин, то изначальные оценки даже сложности алгоритма могут быть неверны (это, кстати, ещё проявляется на кешах).

В данном случае, компилятор знает многое о машине, но рассказать разработчику не может.

4. Резюме - компилятору и разработчику нужен диалог. И этот диалог надо вести на одном языке.

Регер же "слайды не читал, но осуждает" - отвечает на название, которое - откровенный наброс. И, соответственно, практически весь его ответ пролетает мимо.

А ещё есть всякие приложения типа Slack. Казалось бы, в чем сложность написать чат чтобы он не тормозил и не отжирал кучу памяти...

такой вопрос:

в какой момент мы совмещаем синтаксический анализатор и интерпретатор?

с учетом того, что при рекурсивном списке синтаксическое дерево - это стек вызовов (просто вызов методов) - то в какой момент мы вызываем методы визитора интерпретатора?

В защиту Регера, слайды-то он прочитал, просто стриггерился на то, что написано, а не на то, что имелось в виду (как я подозреваю).

В частности, под "смертью оптимизирующих компиляторов" Бернштейн скорее всего подразумевает, что мы дошли до зоны deminishing returns, и существенного увеличения производительности сверх того, что есть уже не будет. Более того, можно даже слегка "откатиться назад" в количестве оптимизаций, слегка ухудшив результат при этом сильно ускорив компиляцию. Это и будет "холодный код". Впрочем, JIT-компиляторы реально холодный код не оптимизируют вообще, да и PGO может двигаться в ту же сторону.

Кроме того Регер возражал против тезиса про фактическое разделение на очень горячий и крайне холодный код. Правда в качестве примера "плоского профиля" приводил замеры из Гугла, а там, я подозреваю, весь код, который замерялся, написан руками на C++ и весьма тщательно вылизан и оптимизирован. Скорее всего, на протяжении десятков итераций профилирования и оптимизации и нагрузочного тестирования. Далеко не "средний" код. 😊

Оптимизиций не бывает много. Да они бывают медленные иногда конфликтуют между собой (это можно решить тем же E-Graphs и здесь есть куда развиваться). Но нужно так же учитывать, что языки сейчас довольно высокоуровневые и стараются быть детерминированными и безопасными, поэтому появился новый класс оптимизаций и анализов например Shape Analysis, Escape Analysis, Bounds Check Elimination and Range Analysis. Ну и постоянно добавляются новые =)

Насчет более низкоуровневых оптимизаций. Например до сих пор я так и не увидел достаточно интерестных оптимизаций с плавающей точкой с более точной регуляций потери точности (fast-math честно говоря такое себе решение). Кое какие наработки есть в совокупности с Affine Arithmetics (AA) но вся эта тема до сих пор не раскрыта как мне кажется

Потом автовекторизация. LLVM и GCC худо-бедно автовекторизируют циклы и gather/scater операции, но относительно слабо справляются с редукциями

> на основе обратной связи от компилятора и на уровне абстракции (близком к) исходного языка была бы просто ох*енной.

Это как раз то, что предоставляет сейчас MLIR

Дело не в том, что он НЕ векторизует, а в том, что без подсказок делает это очень ограниченно. Более того, ICC уже тогда давал обратную связь относительно чего он не смог векторизовать, и, возможно, даже почему не смог (уже не помню деталей).

Начастую это просто напросто невыровненные данные (или отсутсвие таких гарантий), но есть конечно и более специфичные причины

я бы смотрел на наличие в комплекте библиотеки или средств языка реализации для перезаписи графов.
если есть — правильнее в парсере построить чистое дерево разбора, а потом его трансформировать: правила трансформации будут в общей куче.
если нет — часть преобразований делаю непосредственно при разборе