По поводу оптимизации кода

mOleg

Mihail писал(а):

mOleg писал(а):оптимизатор сильно запутывает код Где и чего он запутывает?

я уже говорил свои пожелания, код оптимизатора должен быть оформлен в виде библиотеки, а не находиться внутри ядра (мало того, что он весит как все остальное в СПФ, так еще и вот это:

Код:

: UNTIL \ 94
  ?COMP 3 <> IF -2004 THROW THEN \ ABORT" UNTIL без BEGIN !"
  ?BRANCH,
  0xFFFFFF80  DP @ 4 - @  U<
  IF  DP @ 5 - W@ 0x3F0 + DP @ 6 - W!   -4 ALLOT
  THEN  DP @ TO :-SET
; IMMEDIATE

вместо: (под рукой нет кода СПФ3, поэтом малость правленый из форка пример)

Код:

: UNTIL ( flag --> ) 
            ?COMP ?PAIRS" тут ошибка!"
            COMPILE ?BRANCH <RESOLVE
            ; IMMEDIATE

И таких место не так уж и мало, тем более, что нужны они только в ix86 архитектуре, т.е. портировать куда-то еще достаточно неприятно, собственно, просто выдрать оптимизатор оказалось не так уж и просто(еще и по той причине, что он подключается по сути трижды: уже есть в сборке, подключается перед сборкой образа, подключается в собираемый образ системы).

Еще раз, я не против оптимизатора, я против того, как он прикручен.

mOleg

Mihail писал(а):

Простого способа не нашел.

первое, что приходит на ум, тот же код перенести в библиотеку,
при сборке либо не подключать оптимизатор, либо подключать один раз (а не три).
(иными словами, все IFы и прочее подключаются поверх имеющихся в ядре (на фоне размера оптимизатора это заметно не будет).

Mihail писал(а):

По нынешнем объемам ОЗУ, СПФ достаточно компактен.

проблема не в занимаемом ОЗУ, а в том, что текст ядра получается путанный, т.к. кроме кода ядра надо еще и в оптимизаторе разбираться. И именно нетребовательность к ОЗУ и дисковому пространству является аргументом в пользу вынесения оптимизатора из ядра в библиотеку.

Mihail писал(а):

можно фрагментКод: 0xFFFFFF80 DP @ 4 - @ U< IF DP @ 5 - W@ 0x3F0 + DP @ 6 - W! -4 ALLOT THEN DP @ TO :-SET сунуть в ?BRANCH,

не нужно, лучше все в библиотеку поместить.

Mihail писал(а):

Если твой Форк простой и компактной, будь до конца последователен.Убери слова типа IFNOT *IF -IF

он не простой (сложнее СПФа) и не компактный(хотя и меньше СПФа), хотя в ядре я оставляю лишь те определения, которые используются в описании самого ядра, либо если уж совсем нет смысла убирать (если в ядре не используется AND то нет смысла его убирать). А -IF как и *IF как и IFNOT в ядре используются неоднократно.

Mihail

Хищник писал(а):

Сначала твое утверждение "низкая эффективность кода не является недостатками Форта". Теперь оказывается, из твоих же слов, что низкая эффективность - объективный недостаток.

Под недостатком Форта я понимаю причину его неиспользования.
Данный недостаток перестал быть присущим для Форта, поскольку устранен (еще не совсем).
У Форта только 2 неустранимых недостатка. Это отсутствие защиты от плагиата
и от дурака. Дело в том, что при введении этих зашит в Форт, Форт перестает быть Фортом.

Хищник писал(а):

Форт обуславливает определенный уровень производительности скомпилированного кода в силу специфики разбора исходных текстов.

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

Хищник писал(а):

Возвращаясь к оптимизатору: если за него никак не хотят стабильно платить, так ли он нужен?

Я никогда не пытался его продавать. И вообще, я не столько хочу продавать форт-исходняки ,
сколько хочу сам приобретать нужные мне наработки. Чтобы не делать лишнюю работу и повысить эффективность
своего труда.

Хищник писал(а):

программирование на Форте способно дать человеку уверенную позицию

Думаю это не только мне может быть интересно.

Hishnik

Mihail писал(а):

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

Мда, а Черезов называл тебя скромным

А тут, оказывается, недостаток в виде низкой эффективности не совсем, но уже устранен :))

Причем не просто неважный недостаток, а уже устранен! Ну почитай уже хотя бы обзорные материалы, чтобы не оставаться в иллюзиях.

Mihail писал(а):

У Форта только 2 неустранимых недостатка. Это отсутствие защиты от плагиата
и от дурака. Дело в том, что при введении этих зашит в Форт, Форт перестает быть Фортом.

Ох... "мои мысли - мои скакуны". А это-то откуда вдруг появилось?

Mihail писал(а):

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

Код:

A ! 
B ! 
C !
D !

Компилятор Си, не будучи связан стековой моделью, имеет возможность положить часть переменных в регистры. Компилятор Форта по умолчанию сделает последовательность push и call, каждый раз пропуская числа через стек. Я уже предвкушаю, как ты предлагаешь "продвинуть оптимизатор", но этот пример не единственный, а всего-навсего наглядный. Все случаи не отловишь. А я вот еще и такое добавлю:

Код:

A @ B @ + D !

Для Си, с учетом отсутствия чтения из D между двумя записями, появляется возможность убрать код, записывающий 4 в D. А если еще A и B нужны только для того, чтобы посчитать их сумму, то и их не будет. А в Форте я даже не имею права тронуть верхнюю часть кода, если она оформлена в отдельное слово - а вдруг я вызову такое слово из консоли?

Mihail писал(а):

Я никогда не пытался его продавать. И вообще, я не столько хочу продавать форт-исходняки ,
сколько хочу сам приобретать нужные мне наработки. Чтобы не делать лишнюю работу и повысить эффективность
своего труда.

1. Что ты будешь продавать, чтобы находить деньги на покупку наработок?
2. Если ты не продавал, и не собираешься продавать оптимизатор, почему регулярно появляется волна флейма, в основе которой то, что у тебя есть оптимизатор, а им мало пользуются?

Mihail писал(а):

Хищник писал(а):
программирование на Форте способно дать человеку уверенную позицию

Думаю это не только мне может быть интересно.

Я уже не раз такие вопросы поднимал. Но складывается впечатление, что многие ждут просто разновидность красивого кода или неожиданной кодерско-интерфейсной идеи. "А дальше оно как-нибудь само...". Нет, не само.

вопрос

Цитата:

Ну почитай уже хотя бы обзорные материалы, чтобы не оставаться в иллюзиях.

Что имеется ввиду?

Mihail

mOleg писал(а):

не подключать оптимизатор, либо подключать один раз (а не три).

Где там 3 раза? Один раз в фале src\spf.f

mOleg писал(а):

IFы и прочее подключаются поверх имеющихся в ядре (на фоне размера оптимизатора это заметно не будет).

А кто соптимизирует сам оптимизатор?

mOleg

Mihail писал(а):

Где там 3 раза? Один раз в фале src\spf.f

1) уже имеется в ядре - это раз
2) подключается перед сборкой ядра (по крайней мере так было в версии 4.17)
3) компилируется в образ
мне эта особенность в свое время сильно мешала понять возникающие проблемы с ним.

Mihail писал(а):

А кто соптимизирует сам оптимизатор?

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

А вообще, тему про оптимизатор, имхо, стоит в отдельную треду вынести.

Mihail

Хищник писал(а):

Компилятор Си, не будучи связан стековой моделью

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

Хищник писал(а):

Я уже предвкушаю, как ты предлагаешь "продвинуть оптимизатор",

Использую данную версию оптимизатора как есть
Листинг Файла:

Код:

VARIABLE A

57B13C  4B B1 57 00  00 01 41 1B  B1 57 00 55  55 00 00 E8 K±W...A.±W.UU..и
57B14C  CC 6E FD FF  00 00 00 00 Мnэя....

VARIABLE B

57B154  63 B1 57 00  00 01 42 41  B1 57 00 00  00 00 00 E8 c±W...BA±W.....и
57B164  B4 6E FD FF  00 00 00 00 ґnэя....

VARIABLE C

57B16C  7B B1 57 00  00 01 43 59  B1 57 00 00  00 00 00 E8 {±W...CY±W.....и
57B17C  9C 6E FD FF  00 00 00 00 њnэя....

VARIABLE D

57B184  93 B1 57 00  00 01 44 71  B1 57 00 00  00 00 00 E8 “±W...Dq±W.....и
57B194  84 6E FD FF  00 00 00 00 „nэя....


: XXX

57B19C  AF B1 57 00  00 03 58 58  58 89 B1 57  00 00 00 00 Ї±W...XXX‰±W....
57B1AC  00 00 00 ...

1 A !
57B1AF C70550B1570001000000    MOV     57B150  ( A+5  ) , # 1 
2 B !
57B1B9 C70568B1570002000000    MOV     57B168  ( B+5  ) , # 2 
3 C !
57B1C3 C70580B1570003000000    MOV     57B180  ( C+5  ) , # 3 
4 D ! ;
57B1CD C70598B1570004000000    MOV     57B198  ( D+5  ) , # 4 
57B1D7 C3        RET     NEAR 

Хищник писал(а):

Для Си, с учетом отсутствия чтения из D между двумя записями, появляется возможность убрать код, записывающий 4 в D.

Код:

1 A !
57B1AF C70550B1570001000000    MOV     57B150  ( A+5  ) , # 1 
2 B !
57B1B9 C70568B1570002000000    MOV     57B168  ( B+5  ) , # 2 
3 C !
57B1C3 C70580B1570003000000    MOV     57B180  ( C+5  ) , # 3 
4 D !
57B1CD C70598B1570004000000    MOV     57B198  ( D+5  ) , # 4 
A @ B @ + D !
57B1D7 8945FC        MOV     FC [EBP] , EAX 
57B1DA A150B15700    MOV     EAX , 57B150  ( A+5  ) 
57B1DF 030568B15700    ADD     EAX , 57B168  ( B+5  ) 
57B1E5 890598B15700    MOV     57B198  ( D+5  ) , EAX 
57B1EB 8B45FC        MOV     EAX , FC [EBP] 

Здесь лишнее сохранение EAX . В
MOV EAX , 57B150 ( A+5 )
ADD EAX , 57B168 ( B+5 )
MOV 57B198 ( D+5 ) , EAX
следует заменить EAX на другой регистр, а MOV FC [EBP] , EAX и
MOV EAX , FC [EBP] удалить. Данная процедура в оптимизаторе есть,
только пара кода не прописана в соответствующей таблице.
И что мешает оптимизатору определить, что между
MOV 57B198 ( D+5 ) , # 4 и
...
MOV 57B198 ( D+5 ) , EAX 57B198 не используется.

Хищник писал(а):

Все случаи не отловишь.

Для охвата наибольшего количества случаев применяются
абстрактные правила. Абстрактные правило получается из
жесткого, проложив оптимизируемые фрагмент не относящемся
к правилу кодом. Си в этом смысле никакого преимуществом не обладает.

Хищник писал(а):

А в Форте я даже не имею права тронуть верхнюю часть кода, если она оформлена в отдельное слово - а вдруг я вызову такое слово из консоли?

Если ты о передачи управления не в начало программы, точка отмеченная
HERE защищена от оптимизации

Код:

VARIABLE A

57B13C  4B B1 57 00  00 01 41 1B  B1 57 00 55  55 00 00 E8 K±W...A.±W.UU..и
57B14C  CC 6E FD FF  77 55 33 00 МnэяwU3.

VARIABLE B

57B154  63 B1 57 00  00 01 42 41  B1 57 00 00  00 00 00 E8 c±W...BA±W.....и
57B164  B4 6E FD FF  A6 B1 57 00 ґnэя¦±W.

: XXX

57B16C  7F B1 57 00  00 03 58 58  58 59 B1 57  00 00 00 00 ±W...XXXY±W....
57B17C  00 00 00 ...

1
57B17F C70550B1570001000000    MOV     57B150  ( A+5  ) , # 1 
 A ! ;
57B189 C3        RET     NEAR 

: YYY

57B18A  9B B1 57 00  00 03 59 59  59 71 B1 57  00 00 00 00 ›±W...YYYq±W....
57B19A  00 .

1
57B19B 8945FC        MOV     FC [EBP] , EAX 
57B19E B801000000    MOV     EAX , # 1 
57B1A3 8D6DFC        LEA     EBP , FC [EBP] 
 [ HERE B ! ]

 A !  ;
57B1A6 890550B15700    MOV     57B150  ( A+5  ) , EAX 
57B1AC 8B4500        MOV     EAX , 0 [EBP] 
57B1AF 8D6D04        LEA     EBP , 4 [EBP] 
57B1B2 C3        RET     NEAR 

0x335577 B @ EXECUTE

исходный код

Код:

VARIABLE A
VARIABLE B

: XXX
1
 A ! ;

: YYY
1
 [ HERE B ! ]

 A ! ;

0x335577 B @ EXECUTE

Хищник писал(а):

1. Что ты будешь продавать, чтобы находить деньги на покупку наработок?

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

Hishnik

вопрос писал(а):

Цитата:
Ну почитай уже хотя бы обзорные материалы, чтобы не оставаться в иллюзиях.

Что имеется ввиду?

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

Hishnik

Mihail писал(а):

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

Неверно. Смотри виды промежуточного представления кода, стековое - только одна из разновидностей.

Mihail писал(а):

Данная процедура в оптимизаторе есть, только пара кода не прописана в соответствующей таблице.

Вот-вот. А потом еще в одной таблице прописать, а потом еще, еще и еще.

Mihail писал(а):

И что мешает оптимизатору определить, что между
MOV 57B198 ( D+5 ) , # 4 и
...
MOV 57B198 ( D+5 ) , EAX 57B198 не используется.

Откуда ж я знаю, что ему мешает?

Mihail писал(а):

Си в этом смысле никакого преимуществом не обладает.

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

Mihail писал(а):

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

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

Mihail

Хищник писал(а):

Смотри виды промежуточного представления кода, стековое - только одна из разновидностей.

Дополнительных может быть сколько угодно, но без
стекового (в самом начале) не обойтись.

Хищник писал(а):

А потом еще в одной таблице прописать, а потом еще, еще и еще.

Это для определения типа кода, т.ч. весьма ограничена. Наверняка ее можно ужать
только руки не доходят.

Хищник писал(а):

Преимуществом обладает не Си, а подход, основанный на многопроходной компиляции.

Совсем не обязательно. Второй проход только для определения ссылок вперед.
В основном, он удобен для ассемблера. В LCC и в PASP один проход.

Хищник писал(а):

производительности кода, созданного из исходного текста языка "как есть".

Форма представления алгоритма особого значения не имеет.
Оптимизировать легче бинарное представление.

Хищник писал(а):

задача повышения производительности решается ассемблерными

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

Хищник писал(а):

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

Что-за "структура кода на Форте"? Каким образом облегчает?

Хищник писал(а):

когда много людей что-то друг другу перепродают, накручивая цену

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

Хищник писал(а):

Заказчик (в идеале) уже заинтересован в результате, и может дать четкие ориентиры для определения эффективности проводимых работ.

Заказчик может объявить о свои пожеланиях в конференции, вот и будет ориентир для
участников эволюционных разработок. Это приведет к появлению ряда вариантов на
выбор за мизерную плату.

Mihail писал(а):

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

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

Hishnik

Mihail писал(а):

Дополнительных может быть сколько угодно, но без
стекового (в самом начале) не обойтись.

Ориентированные графы, тройки? Это, навскидку, прямая альтернатива стековому представлению.

Mihail писал(а):

Хищник писал(а):
А потом еще в одной таблице прописать, а потом еще, еще и еще.

Это для определения типа кода, т.ч. весьма ограничена. Наверняка ее можно ужать
только руки не доходят.

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

Mihail писал(а):

Совсем не обязательно. Второй проход только для определения ссылок вперед.
В основном, он удобен для ассемблера. В LCC и в PASP один проход.

Fasm постоянно рапортует о пяти проходах, в какой-то версии gcc их 35.

Mihail писал(а):

Форма представления алгоритма особого значения не имеет.
Оптимизировать легче бинарное представление.

Это твое частное мнение, идущее в прямое противоречие с литературой. Например, существует оптимизация общих подвыражений, которая не зависит от языка. Например, при наличии в коде f1(x+y) и f2(x+y) компилятор сможет выделить общее выражение x+y и вычислять его отдельно. А в Форте такое сделать нельзя, потому что допустимы побочные эффекты, и во второй раз X Y + может сработать совсем не так, как в первый. Для оптимизации на уровне текста должны быть специфицированы элементы языка, а в Форте все есть слово, да еще с возможностью смены контекста и модификации кода в рантайме. Однако упор на оптимизацию бинарного представления не означает, что и другие языки должны только так и оптимизировать. Что ты про это не знаешь - в основном твоя проблема (хотя отчасти и тех, кто некритически ориентируется на информацию об оптимизаторе для СПФ).

Mihail писал(а):

Бывает проще добавить правило к оптимизатору, чем писать на ассемблере.

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

Вот уж золотое дно! :))

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

Mihail писал(а):

Хищник писал(а):
прослеживаемая структура кода на Форте облегчает интеграцию такого стороннего кода.

Что-за "структура кода на Форте"? Каким образом облегчает?

Что за структура, посмотри... в исходниках Форта

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

Mihail писал(а):

Хищник писал(а):
когда много людей что-то друг другу перепродают, накручивая цену

Никакого накручивания продается за копейки и на апгрейд тратятся минуты.
Выигрыш за счет тиража.

Ты сейчас процитировал аргументы "впаривателей" из многоуровневого маркетинга

"Наш товар стоит копейки, а даже если он вам не нужен, вы можете его перепродать, а прибыль получите от тиража".

Mihail писал(а):

Заказчик может объявить о свои пожеланиях в конференции, вот и будет ориентир для
участников эволюционных разработок. Это приведет к появлению ряда вариантов на
выбор за мизерную плату.

Да ну?

И о каких именно вещах заказчик может объявить? ОС реального времени? АСУТП? Движок для трехмерной графики? Интернет-магазин? И все это программисты бросятся писать на выбор за мизерную плату? Ой, а напиши мне чего-нибудь за мизерную плату...

Mihail писал(а):

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

Мда, я как-то думал, что рано или поздно ты от этого избавишься. Видимо, нет, но я не особо и удивлен. По крайней мере, это объясняет твое топтание на месте, в сочетании с иллюзией продвижения чего-то куда-то. Я уже молчу об игнорировании тобой матчасти в области, которую ты рассматриваешь как приоритетную для себя.

dynamic-wind

Mihail писал(а):

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

оно и видно :))

С другой стороны, я с трудом представляю "серьезный" Н-проходный компилятор для форта и на форте.
Идеология форта--простота, да и в теорию он плохо укладывается.
Так что остается выбор между peephole-оптимизатором и компиляцией в C, как у Ёртла.
Плюс временно-постоянное решение писать вставки на ассемблере :dmad;

chess

dynamic-wind писал(а):

оно и видно

Принцип peephole-оптимизатора лежит на поверхности, знать нужно лишь платформу.
Что мы и видим.
А так, практичнее иметь набор базовых знаний в предметной области, остальное выводить.

dynamic-wind писал(а):

С другой стороны, я с трудом представляю "серьезный" Н-проходный компилятор для форта и на форте

У Ларионова в SMALL32 делалось 5 проходов.

dynamic-wind писал(а):

Идеология форта--простота, да и в теорию он плохо укладывается.

Тут надо уточнять про простоту, что это лишь простота(в смысле краткость, лаконичность) реализации транслятора.
Этот момент становится менее привлекательным из-за повышения математических возможностей харда.
Теория хоть и небольшая у Форта есть-даже на форуме об этом где-то было.
По сути Форт дрейфует в сторону аккумулирования различных парадигм программирования за счет
открытости своего транслятора.
Уже в названиях форт-систем перестают употреблять слово форт(quest, vfx, quark и т.д.).
Где-то видел форт даже без стека параметров. Остается в основе пожалуй только виртуальная машина(не обязательно стековая).
Но это и в других языках есть.

dynamic-wind писал(а):

Так что остается выбор между peephole-оптимизатором и компиляцией в C, как у Ёртла.
Плюс временно-постоянное решение писать вставки на ассемблере

И оптимизаторы в разных форт-системах тоже разные.
В swift и spf peephole-оптимизация, в vfx алгоритмическая (ресурсная) оптимизация.
Оптимизация как правило не исключает использования ассемблера для особо тяжелых случаев.
Peephole-оптимизация - разумный компромис между навороченным многоуровненвым алгоритмическим оптимизатором
и ассемблером(оптимизирует типовые кодовые связки, которые и составляют 90% форт-кода).

dynamic-wind

Меня интересуют открытые системы, vfx и smal закрыты.

chess писал(а):

У Ларионова в SMALL32 делалось 5 проходов.

Ух ты! Не знал. Можно ссылку?

По поводу оптимизации кода

Кто сейчас на конференции