Хищник
Но здесь мы (т.е. эти самые криворукие программисты) даем друг другу советы "космического масштаба и космической же глупости". Ни договоренности о терминах, ни общей теории. Каждый считает просто обязанным шокировать остальных известными ему огрызками сведений о великом таинстве написания "эффективного кода".
Спросить, например, наших "оптимизаторов": "Сколько реально полезных программ Вы лично ускорили?" Какого рода программ? И на сколько? И какими методами? Вот тогда и можно будет говорить о тенденциях оптимизации.

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

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

Я не буду вступать в спор, что есть синтаксис, а что не есть, только замечыу, что в суждениях "синтаксис отсутствует" или подобных нужно быть осторожным

За неимением доступных "продвинутых" оптимизаторов для spf4
обсуждение идёт именно этого варианта убыстрения Форт
кода (для PC это не так актуально в сравнении, например с МК)

Есть некоторая статистика http://www.complang.tuwien.ac.at/forth/peep/ встречаемости отдельных примитивов и цепочек
Форт слов в программах. Это может быть полезно при развитии макрооптимизатора.

Как я уже писал выше, с тем же успехом можно бороться с кариесом и перхотью Forth. Кто из присутствующих видел тормозную Forth-программу? Кому мешала ее тормознутость? Насколько лучше работали аналогичные программы (на других языках) с "эффективной оптимизацией"? За счет чего?
P.S. Профессионально занимаясь анализом ПО я видел много статистик и ни одной полезной...

Их ещё необходимо найти аналоги для сравнения:)
или "странслировать" (перепроектировать? и.др.) и тогда можно будет сравнивать,
но нет уверенности что Форт программа по эффективности будет быстрее без использования "танцев с бубном"



Замеченная тенденция для торможения (например отображение сложного PDF файла) чем лечится непонятно.

Одна из эффективных оптимизаций, что бы ни говорили, написание софта на ассемблере (воможно сецифика мышления отличается? и "рабочий материал" не высокоуровневый)
А в Си оптимизаторы уже ой-как много человеко-часов вложено.

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

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

P.S. PostScript, конечно же не Форт и почти невероятно, что в PS принтерах может быть программа обработки PS на Форт языке:)

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

насчет оптимизации вопрос, имхо непростой. Для начала хочу сказать, чего мне бы хотелось:
оптимизация должна:
1) производиться по необходимости (в случае SPF DIS-OPT)
2) подключаться отдельно (а не идти с ядром вместе) т.е. либа быть должна
3) происходить после завершения компиляции кода
4) перехватывать процесс сборки только в одном месте
собственно, это мои комментарии к оптимизатору Михаила.

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

Да, видимо, нужно именно так, потому что, если, скажем, кто-то вручную заменил несколько строк для быстродействия, то это будет названо оптимизацией, не вполне понятно, почему Хищник так упорно отрицает, что "макроподстановка" Михаила - оптимизация.

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

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

Присоединяюсь к этим комментариям. По 3) пункту это будет возможно лишнее усложнение.


Генетический алгоритм это интересно. Только вот работает он медленно и применяют его в основном где другие решения на данный момент не известны.
Другой вариант нейросеть. Она тоже тренируется долго, но зато потом можно вытащить из нее математическое выражение и вставить в свой алгоритм.
Проблема в другом. Оба эти варианта выдают приближенное решение, а нам в случае с оптимизатором нужно точное решение (постановка).

Оптимизация кода производится после получения промежуточного представления.

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