Есть ли самосовершенствование компилятора?

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

Пока еще не реализовано, насколько мне известно, но да, существует теория:

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

Ответ 5

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

Ответ 6

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

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

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

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

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

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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