Есть ли здесь какой-нибудь самоулучшающийся компилятор?

Хотя это правда, что компиляторы могут улучшать код без вмешательства человека, однако утверждение о том, что «компиляторы являются самоулучшающимися», довольно сомнительно. Эти «улучшения», которые делают компиляторы, просто основаны на наборе правил, написанных людьми (кто-нибудь киборгами?). Итак, ответ на ваш вопрос: нет.

Кстати, если бы существовал что-то вроде самоулучшающегося компилятора, мы бы знали ... сначала он улучшил бы язык, затем его собственный код и, наконец, он бы изменил свой код, чтобы он стал вирусом и заставил всех разработчиков использовать его ... и тогда, наконец, у нас будет одна из тех классических вещей типа компьютер против людей-последней надежды для человечества ... так что ... Нет.

MilepostGCC - это компилятор MachineLearning, который со временем улучшается в том смысле, что способна измениться, чтобы со временем стать «лучше». Более простой подход итеративной компиляции может улучшить практически любой компилятор.

25 лет программирования, и я никогда не слышал о таком (если вы не говорите о компиляторах, которые автоматически загружают обновления программного обеспечения!).

Насколько мне известно, еще не реализовано практически, но да, теория есть:

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

Самоулучшающийся компилятор по определению должен иметь самомодифицирующийся код. Если вы посмотрите вокруг, вы можете найти примеры людей, делающих это (самомодифицирующийся код). Однако это очень редко можно увидеть, особенно в таких больших и сложных проектах, как компилятор. И это необычно по очень веской причине - до смешного сложно (то есть почти невозможно) гарантировать правильную работу. Многие программисты, которые думают, что они умны (особенно кодировщики на ассемблере), в тот или иной момент экспериментируют с этим. Те, кто на самом деле умны, в большинстве своем выходят из этой фазы. ;)

В некоторых ситуациях компилятор C запускается несколько раз без участия человека, каждый раз получая «лучший» компилятор. К счастью (или, к сожалению, с другой точки зрения) этот процесс выходит на плато после нескольких шагов - дальнейшие итерации генерируют точно такой же исполняемый файл компилятора, что и предыдущий.

1. У нас есть весь исходный код GCC, но единственный доступный компилятор C на этой машине - это не GCC. Увы, некоторые части GCC используют «расширения», которые могут быть созданы только с помощью GCC. К счастью, на этой машине есть функциональный исполняемый файл make и некоторый произвольный частный компилятор C. Человек идет в каталог с исходным кодом GCC и вручную набирает "make".

2. Утилита make находит MAKEFILE, который дает указание запустить (проприетарный) компилятор C для компиляции GCC, и использует параметр «-D», чтобы все части GCC, использующие «расширения», # ifdef'ed out. (Эти фрагменты кода могут быть необходимы для компиляции некоторых программ, но не на следующем этапе GCC.). Это создает очень ограниченный урезанный двоичный исполняемый файл, у которого едва хватает функциональности для компиляции GCC (и люди, которые пишут код GCC, тщательно избегают использования функций, которые этот урезанный двоичный файл не поддерживает).

3. Утилита make запускает этот урезанный двоичный исполняемый файл с соответствующей опцией, так что все части GCC скомпилированы, в результате чего получается полнофункциональный (но относительно медленный) двоичный исполняемый файл.

4. Утилита make запускает полнофункциональный двоичный исполняемый файл в исходном коде GCC со всеми включенными параметрами оптимизации, в результате чего создается фактический исполняемый файл GCC, который люди будут использовать с этого момента, и устанавливает его в соответствующем месте.

5. Утилита make проверяет, все ли работает нормально: она запускает исполняемый файл GCC из стандартного места в исходном коде GCC со всеми включенными параметрами оптимизации. Затем он сравнивает полученный двоичный исполняемый файл с исполняемым файлом GCC в стандартном расположении и подтверждает, что они идентичны (за возможным исключением нерелевантных временных меток).

После того, как человек напечатал "make", весь процесс запускается автоматически, каждый этап генерирует улучшенный компилятор (пока он не достигнет плато и не сгенерирует идентичный компилятор). http://gcc.gnu.org/wiki/Top-Level_Bootstrap и http://gcc.gnu.org/install/build.html и "Скомпилировать GCC с исходным кодом" можно подробнее.

Я видел другие компиляторы, у которых в этом процессе было бы намного больше этапов, но все они требуют некоторого человеческого участия после каждого этапа или двух. Пример: «Начальная загрузка простого компилятора с нуля» Эдмунд Гримли Эванс, 2001 г. http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.html И есть вся историческая работа, проделанная программистами, которые работали над GCC, которые используют предыдущие версии GCC. скомпилировать и проверить свои умозрительные идеи о возможно улучшенных версиях GCC. Хотя я бы не сказал, что это происходит без какого-либо человеческого участия, тенденция, похоже, такова, что компиляторы выполняют все больше и больше «работы» за одно нажатие клавиши человеком.

Я не уверен, подходит ли он, но компилятор Java HotSpot улучшает код во время выполнения, используя статистику.

Но во время компиляции? Как этот компилятор узнает, что несовершенно, а что нет? Какая мера добра?

Есть много примеры людей, использующих генетические методы, чтобы противопоставить алгоритмы друг другу, чтобы найти «лучшие» решения. Но обычно это хорошо изученные проблемы, у которых есть метрика.

Итак, какие показатели мы можем применить во время компиляции? Минимальный размер скомпилированного кода, циклометрическая сложность или что-то еще? Что из этого имеет значение во время выполнения?

Что ж, есть методы JIT (как раз вовремя). Кто-то может возразить, что компилятор с некоторыми оптимизациями JIT может перенастроить себя, чтобы быть более эффективным с программой, которую он компилирует ???