Интерпретатор и компилятор ФБП



Posted by Рустем Мухаметшин on January 20, 1999 at 03:29:26:

In Reply to: Новые, уже не экспеpиментальные модификации Сеpвеpа 2.9H и ultraH. posted by Аpкадий Водяник, ЗАО Хакеpс Дизайн on January 17, 1999 at 06:48:45:

        Условия теста:
        Одна операция в журнале с проводкой X X DKIF. DKIF содержит цикл с записями приведенными в таблице по номерам тестов. Тест исполнялся на сетевой версии 2.9H с включенными ta. Замеры делались при помощи P MC=1 DC=1 в течении времени "горения" Построение баланса
        Результаты:

1 2 3 4 5
*
S =1
*For I=1 to 300000
* If S<>0
*±X X (S)
* Endif
*EndFor
$ =0
*
S =1
For I=1 to 300000
* If S<>0
*±X X (S)
* Endif
EndFor
$ =0
*
S =1
For I=1 to 300000
If S<>0
*±X X (S)
Endif
EndFor
$ =0
*
S =1
For I=1 to 300000
If S<>0
±X X (S)
Endif
EndFor
$ =0
*
S =1
For I=1 to 300000
* If S<>0
±X X (S)
* Endif
EndFor
$ =0
не замеряемо 0.65 сек 2.35 сек 27.65 сек 25.95 сек

Замеры времени точны до первого знака после запятой и взаимосогласуются (Тест3-Тест2+Тест5 = = Тест4)
        Скорость конструкций языка:
FOR I=1 to 300000             650,000.0 мкс
IF S<>0                                         5.7 мкс
Оператор 177 X X (S)               84.0 мкс

        Выводы:
        Прикладной. Разумно ставить оператор 177 в оператор сравнения суммы проводки в тех случаях когда заранее неизвестна будет ли сумма оной не нулевой
        Теоретический. Скорость интерпретации управляющих конструкций низка. IF S<>0 интерпретируется всего в 15 раз быстрее чем оператор 177. А ведь второму нужно сделать записи в таблице корреспонденций и прописать TA-факты. На его фоне сравнение с нулём должно быть незаметно вообще.

        Интерпретатор и компилятор.
         Как известно ФБП использует оба. На мой взгляд уровень компиляции очень низок К примеру, недавно выяснилось что происходит бинарное связывание позиции метки и оператора GOTO после первого исполнения. Ладно хоть так, а я раньше думал что связывания вообще нет. Почему бы компилятору не сделать это в момент компиляции ????? Тогда и сообщения об отсутствующих метках вышли бы в момент загрузки, а не в момент исполнения кода с оператором перехода. То же касается оператора CALL. По всей видимости операторы IF-ENDIF и FOR-ENDFOR связываются в момент компиляции (хотя бог их знает :). Жаль что при такой модернизации (недвубуквенной) языка переменные остались двубуквенными а метки из 10 символов. А ведь компилятор мог бы запросто компилировать длинные имена в те которые нравятся  интерпретатору получившегося кода.
        В сложившейся тенденции концентрации алгоритмов в ф/к, а сейчас и вместе с проводками роль компилятора возрастает. Я подозреваю что многие другие конструкции не претерпевают должной компиляции до бинарного потока легко усвояемого интепретатором-виртуальной машиной. Список большой: Числа (из строкового представления в бинарный), Предварительные вычисления, Строки, Связывания переходов и управляющих конструкций, ...
        Возможно что-то уже есть. Просто нам приходится ориентироваться в темной комнате на ощупь. Никаких рекомендаций по оптимизации кода ФБП у нас нет.


Пpишедшие ответы: