СПФ и оптимизатор

Kopa

Попробовал такой тест для оптимизатора
В сравнении с Си проигрыш ~3 раза на обоих вариантах ( 2.9 и 3.7 )

Код:

 REQUIRE LOCALS|   ~af\lib\locals.f
 lib/ext/disasm.f
 DECIMAL

\ : tst ( a -- n ) 100000001 2 DO I + LOOP ; \ 1-й вариант

: tst { a -- n }                                            \ 2-й вариант
       100000001 2 DO I a + TO a LOOP a ;

: test  1 tst  . ;

\ SEE tst

  ' test TO <MAIN> 
  S" tst.exe" SAVE 

Что оптимизатору не нравится?

P.S. Форт ОС с такой оптимизацией не будет нормально работать.
или переходить на asm ?:)

Mihail

Kopa писал(а):

REQUIRE LOCALS| ~af\lib\locals.f

Лучше REQUIRE { ~MAK\locals1.f

Цитата:

Код:

: tst { a -- n }                                            \ 2-й вариант
       100000001 2 DO I a + TO a LOOP a ;

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

Цитата:

P.S. Форт ОС с такой оптимизацией не будет нормально работать.
или переходить на asm ?:)

В крайнем случае, можно применить и ассемблерные вставки.

Гость

Бывает, что case может быть следующим:

Код:

lib/ext/disasm.f


\ : ts  \ 1-й вариант
\     CASE
\        0 OF 3 ENDOF
\        1 OF 4 ENDOF
\        2 OF 5 ENDOF
\     ENDCASE
\ ;
: ts   \ 2-й вариант более оптимальный при генерации тоже не совсем не оптимален
        \ комаду LEA можно заменить на DEC EAX ( если она быстрее )
     CASE
            0 OF 3 ENDOF
        1- 0 OF 4 ENDOF
        1- 0 OF 5 ENDOF
     ENDCASE
;    
SEE ts

Доработка оптимизатора позволит оптимально генерить код для приведенного варианта.

Mihail

Гость писал(а):

комаду LEA можно заменить на DEC EAX ( если она быстрее )

http://spf.cvs.sourceforge.net/spf/src/ ... f?view=log

Гость

Cпасибо за доработку оптимизатора.
[quote=""]

Код:

lib/ext/disasm.f


\ : ts  \ 1-й вариант
\     CASE
\        0 OF 3 ENDOF
\        1 OF 4 ENDOF
\        2 OF 5 ENDOF
\     ENDCASE
\ ;
: ts   \ 2-й вариант более оптимальный при генерации тоже не совсем не оптимален
        \ комаду LEA можно заменить на DEC EAX ( если она быстрее )
     CASE
            0 OF 3 ENDOF
        1- 0 OF 4 ENDOF
        1- 0 OF 5 ENDOF
     ENDCASE
;    
SEE ts

Хотелось бы еще, чтобы 1-й вариант оптимизировался, как 2-й и
по возможности непрерывные числа выбора по CASE автодетектировались, т.к.
они могут быть определены как константы.

Mihail

Гость писал(а):

Хотелось бы еще, чтобы 1-й вариант оптимизировался, как 2-й и

Отличие только: там где в первом используется CMP
во 2-ом используется DEC

Код:

58B4A0 3D00000000   CMP     EAX , # 0 
58B4A5 0F8507000000   JNE     58B4B2  ( ts1+12  ) 
58B4AB B803000000   MOV     EAX , # 3 
58B4B0 EB2A      JMP     58B4DC 
58B4B2 3D01000000   CMP     EAX , # 1 
58B4B7 0F8507000000   JNE     58B4C4  ( ts1+24  ) 
58B4BD B804000000   MOV     EAX , # 4 
58B4C2 EB18      JMP     58B4DC 
58B4C4 3D02000000   CMP     EAX , # 2 
58B4C9 0F8507000000   JNE     58B4D6  ( ts1+36  ) 
58B4CF B805000000   MOV     EAX , # 5 
58B4D4 EB06      JMP     58B4DC 
58B4D6 8B4500      MOV     EAX , 0 [EBP] 
58B4D9 8D6D04      LEA     EBP , 4 [EBP] 
58B4DC C3      RET     NEAR 
END-CODE   Ok

58B3E0 3D00000000   CMP     EAX , # 0 
58B3E5 0F8507000000   JNE     58B3F2  ( ts+12  ) 
58B3EB B803000000   MOV     EAX , # 3 
58B3F0 EB22      JMP     58B414 
58B3F2 48      DEC     EAX 
58B3F3 0F8507000000   JNE     58B400  ( ts+20  ) 
58B3F9 B804000000   MOV     EAX , # 4 
58B3FE EB14      JMP     58B414 
58B400 48      DEC     EAX 
58B401 0F8507000000   JNE     58B40E  ( ts+2E  ) 
58B407 B805000000   MOV     EAX , # 5 
58B40C EB06      JMP     58B414 
58B40E 8B4500      MOV     EAX , 0 [EBP] 
58B411 8D6D04      LEA     EBP , 4 [EBP] 
58B414 C3      RET     NEAR 
END-CODE   Ok

Цитата:

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

Константы компилируются как литералы.

Гость

Mihail писал(а):

Гость писал(а):

Хотелось бы еще, чтобы 1-й вариант оптимизировался, как 2-й и

Отличие только: там где в первом используется CMP
во 2-ом используется DEC

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

Константы компилируются как литералы.[/quote]

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

P.S. Надеюсь - это более понятное объяснение:)
константы необходимо, при этом отсортировать.

WingLion

А самый быстрый CASE - это, разве, не JMP по таблице?

Kopa

Код:

lib/ext/disasm.f

123 456 
\ : tst [ HEX HERE . BL EMIT ]
\                LITERAL [ HERE . BL EMIT ] LITERAL [ HERE . ] ; 
: tst LITERAL LITERAL ;

SEE tst

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

profiT

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

Внимательнее надо, об этом уже говорилось (в этой же теме).

Mihail

Kopa писал(а):

Код:

lib/ext/disasm.f

123 456 
\ : tst [ HEX HERE . BL EMIT ]
\                LITERAL [ HERE . BL EMIT ] LITERAL [ HERE . ] ; 
: tst LITERAL LITERAL ;

SEE tst

Приведенные варианты создают разный код.

Слово HERE устанавливает ограничение оптимизатору.
Может ты собираешся туда передавать управление.

Код:

VECT TSTV
: TST LITERAL [ HERE TO TSTV ] LITERAL ;

Если вместо HERE использовать DP @ , то код будет такой-же.

Kopa

Может это и обсуждалось, но хочется услышать мнение
по следующему вопросу:

Имеет ли смысл вводить макрооптимизацю ( например свертку транслируемого
текста в эквивалентный текст или поиск по входному тексту шаблонов и на
основе этого трансформации входного потока текста программы )
перед выдачей слову INTERPRET

P.S. Текстовая макрооптимизация может быть ограничена в рамках одного слова.
При этом входной буфер должен будет принять текст всего слова.
Для уменьшения требуемого входного буфера входные слова можно сжимать.

in4

Kopa писал(а):

Имеет ли смысл вводить макрооптимизацю

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

chess

Kopa писал(а):

Имеет ли смысл вводить макрооптимизацю ( например свертку транслируемого
текста в эквивалентный текст или поиск по входному тексту шаблонов и на
основе этого трансформации входного потока текста программы )
перед выдачей слову INTERPRET

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

Гость

Тест сравнения производительности
SPF-4.18 и WIN32STC(клон WIN32FORTH c оптимизатором)
Система P4 2.4GHz 1Гб WinXP

Код:

Test time including overhead    SPF/ STC ms     times     SPF/STC ns (each)
DO LOOP                                 16   16         5000000    3   3
+                                            15   15         5000000    3   3
M+                                          32   47         5000000    6   9
*                                             15   16         5000000    3   3
/                                             78   94         5000000   15  18
M*                                          16   31         5000000    3   6
M/                                           40  125         5000000   28  25
/MOD                                       94   94         5000000   18  18
*/                                            25  109         5000000   25  21
ARRAY fill                                 16    0         1000000    16   0
Total:                                    563  578         1


This system's O/S interface using no extensions

Test time including overhead    SPF/ STC ms     times     SPF/ STC ns (each)
Win32 API: SendMessage          328  281        500000    656  562
Win32 API: GetTickCount          203   32        2000000   101   16
System I/O: KEY?                    734   15         80000    9175  187
Total:                                   1265  328        1 


This system's application performance using no extensions

Test time including overhead                          SPF/ STC ms  times    SPF/ STC ns (each)

Eratosthenes sieve 1899 Primes                       125  219     8190000   15   26
Fibonacci recursion ( 35 -> 9227465 )               203  281     9227430   21   30
Hoare's quick sort (reverse order)                    156   297     2000000   78  148
Generate random numbers (1024 kb array)       172   250     262144    656 953
LZ77 Comp. (400 kb Random Data Mem>Mem) 250    406     1
Dhrystone (integer)                                        188    281     500000        
                                                                     376   562          2659574 1779359 Dhrystones/sec
Total:                                                           1110  1734     1

P.S. Тест из дистрибутива SPF-4.18.
в Win32STC есть еще тесты на плавающую арифметику и матрицы, если
их сделать для SPF то можно и по ним провести сравнение:)

СПФ и оптимизатор

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