Comments 12
Подбор ключей и эвристик, это полезно, но душа хочет интеллектуальной трансляции.
Современный компилятор слишком алгоритмическая вещь, трансляция строится в основном на правилах переписывания. Конечно, есть более сложные техники, при распределении регистров применяется раскраска графов… Но между собой оптимизации взаимодействуют плохо, (по крайней мере, так было, когда я этим серьёзно занимался), при всём при этом качество кода того же gcc приятно удивляет.
ИИ тут и приткнуться особо негде, нужен принципиально новый компилятор, возможно даже новый язык, где исходный код рассматривался бы не как инструкция, а как спецификация, которую транслятор может реализовывать как хочет. Думаю, прогресс придёт со стороны авто-доказателей теорем — agda, coq и прочих SAT.
Современный компилятор слишком алгоритмическая вещь, трансляция строится в основном на правилах переписывания. Конечно, есть более сложные техники, при распределении регистров применяется раскраска графов… Но между собой оптимизации взаимодействуют плохо, (по крайней мере, так было, когда я этим серьёзно занимался), при всём при этом качество кода того же gcc приятно удивляет.
ИИ тут и приткнуться особо негде, нужен принципиально новый компилятор, возможно даже новый язык, где исходный код рассматривался бы не как инструкция, а как спецификация, которую транслятор может реализовывать как хочет. Думаю, прогресс придёт со стороны авто-доказателей теорем — agda, coq и прочих SAT.
> возможно даже новый язык, где исходный код рассматривался бы не как инструкция, а как спецификация, которую транслятор может реализовывать как хочет
При этом целевой процессор, «данный нам в ощущения», уже служит ограничивающим фактором с заложенной в него архитектурой.
При этом целевой процессор, «данный нам в ощущения», уже служит ограничивающим фактором с заложенной в него архитектурой.
Э-э ну да, естественно? Не очень понял, что вы хотели сказать. Ограничения должны учитываться; если надо, представлять целое число машинным словом (общепринятый компромисс между точностью и производительностью).
То, что при неизменности бинарного кода, например х86 процессора, следующие поколения ядер ускоряют данный код не требуя его, зачастую, перекомпиляции.
Сколько при этом внутри этих ядер транзисторов без предоставления внутренней спецификации к RISC ядру х86 процессора.
P.S. Как, например, ещё и Java байт код в рантайме ускоряют. :)
Умный компилятор для ограниченного процессорного ядра, не в этом ли один из принципиальных баръеров для умного компилятора. Отсюда и возникает конкуренция Софт-процессоров в FPGA с классикой.
Сколько при этом внутри этих ядер транзисторов без предоставления внутренней спецификации к RISC ядру х86 процессора.
P.S. Как, например, ещё и Java байт код в рантайме ускоряют. :)
Умный компилятор для ограниченного процессорного ядра, не в этом ли один из принципиальных баръеров для умного компилятора. Отсюда и возникает конкуренция Софт-процессоров в FPGA с классикой.
при всём при этом качество кода того же gcc приятно удивляет
Замечу только, что качество кода достаточно хорошее за счет того, что разработчики компиляторов сами на данный момент и занимаются настройками эвристик на большом количестве бенчмарков. Настраиваются различные числовые значения, от релиза к релизу может меняться порядок проходов. Поэтому для популярных платформ, естественно, компиляторы хорошо настроены. И этот процесс настройки во время разработки компилятора по большей части пока делается перебором значений хоть и в ограниченном диапазоне с анализом человеком (хотя возможно у некоторых компаний есть какие-то закрытые решения), от этого как раз и хотелось бы избавиться и переложить эту задачу на некоторую систему.
При этом если начинать рассматривать конфигурируемые процессоры, то там уже так однозначно настроить оптимизации куда сложнее, и пользователи компилятора периодически могли бы получать лучший код.
К тому же, если, например, говорить о LLVM, который используют для написания компиляторов для множества языков, то в самой документации LLVM написано, что оптимизации настроены для clang, и если вы пишете свой фронтенд для другого языка, стоит поднастроить оптимизации по-другому, потому что иначе компилятор будет не очень эффективен.
Любая автоматизация это приятно, но у меня сомнения. Построение эффективной цепочки оптимизаций процесс творческий, включает как перебор, так и понимание происходящего, а система подбора параметров вторым не обладает, а рассматривает фазы оптимизации как чёрные ящики с рукоятками-параметрами. Нейросети наше всё, но чтобы работала регрессия, система должна быть более или менее линейной, не наш случай.
Я не спорю, что это сложная и отчасти творческая задача, но есть проблема, что и человеку сложно удержать в голове много мелких деталей, которые часто тоже влияют на общую картину. Иногда даже опытным инженерам нужно потратить много времени на понимание некоторых эффектов. Возможно, это должна быть в начале рекомендательная система, которая должна натолкнуть инженера при анализе или помочь собрать и визуализировать некоторые данные. Вариантов много. Начинать же с чего-то надо.
Кстати, в мире FPGA тоже есть некоторый движ в этом направлении, например: www.plunify.com/en/intime. Здесь пытаются использовать ИИ для подбора лучших опций синтеза и place & route под конкретные проекты.
UFO just landed and posted this here
Sign up to leave a comment.
На пути к светлому будущему «умных» компиляторов