Компиляция и преждевременная оптимизация

А с какой точки зрения походили вы? Даже без байткода нельзя просто взять и выполнить программу, сначала нужно её разобрать и перевести в понятные машине машкоды.

Когда вы пишете текст, он вне зависимомти от трансляции уже представлен в машкоде. То, что транслятор его пропарсит, выделит переменные, строки функции, не отменяет того факта, что Вы можете просто открыть этот текст проги текстовым редактором и прочитать. Для этого не нужно ничего никуда преобразовывать, все уже есть.

Я могу прочитать исходный, а код машина машинный. От этого взаимонепонимания и появились интерпретаторы. Но парсить текст интерпретатору всё равно придется. И выделение переменных, строк, подгрузка необходимого и т.п. это время потраченное на перевод программы во внутренне представление. В результате интерпретатор будет выполнять уже не исходный текст. И если подобные преобразования всё равно придется проводить, то почему бы не соптимизировать несколько структур? Это потребует второго (в зависимости от интерпретатора, возможно n-ого) прохода, но будет ли здесь трата, сопоставимая с изначальным разбором?

Изначально то разговор шел о необходимости оптимизации.

А текущяя версия какая?

8.6

Скоько с той 15-летней изменилось?

очень много

а код машина машинный

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

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

Имеет смысл, потому что компилятор парсит текст, анализирует его, строит деревья и пр. Если это не нужно, это время (и ресурсы) тратится впустую.

Интерпретатор занимается тем же самым. Просто в вашей модели расширение «машину» поглотило интерпретатор.

Интерпретатор занимается тем же самым

Да нет же, интерпретатор (чистый) выполняет код построчно или пословно, если быть точней — «поеденично», где единица — expression, терм языка.

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

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

Стало быть, снова приходим к тому, что для одноразового скрипта лучше использовать «чистый» интерпретатор. Но если там встретится, например, затратный (по времени) цикл, то все компиляторские замашки интерпретатора окупятся с лихвой. К тому же, если программа «одноразовая» то, почти наверняка, время её исполнения не так критично, как в случае с повторно используемыми. Итого, нет эта оптимизация не преждевременная. ИМХО, конечно же.

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

В сущности я с вами согласен. Нужно ещё вспомнить о стоимости разработки программы. Оптимизатор, встроенный в компилятор (интерпретатор), сглаживает разницу в уровне программистов, позволяя снизить затраты на рабочую силу. С другой стороны он уменьшает время доведения программы до приемлемого уровня, также уменьшая затраты на её разработку ещё до стадии тиражирования.

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

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

Какая же она преждевременная если окончательный вариант исходника готов?

Я написал:

Конечно, время компиляции часто неважно, но если вспомнить языки высокого уровня, такие как JS, LISP, Python, Perl, это же определенно не так.Там ведь вполне может быть цикл компиляция, интерпретация, снова компиляция и тд. А тут уже пользователь ЯП терпеливо ждет.

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