Выравнивание данных и кода

[azekeprofit]

1. Выравнивание данных в CREATED/CREATE :


: CREATED ( addr u -- )
  SHEADER
  ALIGN-BYTES @ DUP 4 >
  IF 5 - ALLOT
  ELSE 1 - ALLOT
  THEN

  HERE DUP LAST-CFA @ !
  DOES>A ! ( для DOES )
  ['] _CREATE-CODE COMPILE,
;

Если целью было обеспечить выровненность на ALIGN-BYTES байтов адреса получаемого при вызове новосозданного слова, то этого сейчас нет.

Должно быть:

: CREATED ( addr u -- )
  SHEADER
  ALIGN
  ALIGN-BYTES @ DUP 4 >
  IF CFL - ALLOT
  ELSE 1 - ALLOT
  THEN

  HERE DUP LAST-CFA @ !
  DOES>A ! ( для DOES )
  ['] _CREATE-CODE COMPILE,
;

Или положить ALIGN в SHEADER (в строчку перед HERE SWAP ! ).

2. Выравнивание кода -- ALIGN-NOP. Agner Fog ( http://www.agner.org/optimize/ ) в том числе советует использовать более длинные маш. инструкции аналогичные "обычному" NOP'у (0x90). Есть двухбайтовые NOP'ы -- XCHG EAX, EAX (0x87C0) и LEA EBX , [EBX] (0x8D1B) и есть даже шестибайтовые NOP'ы -- LEA EBX, DWORD 0 [EBX] (0x8D9B00000000) и т.д.

Имеет ли смысл:

: ALIGN-NOP ( n -- )
\ выровнять HERE на n и заполнить NOP
  HERE DUP ROT ALIGN-TO
\ OVER - DUP ALLOT 0x90 FILL \ <-- оригинальная строчка
  SWAP - ( u )
  BEGIN
    DUP 5 > IF 0x9B8D W, 0 ,  6 - ELSE \ LEA EBX, DWORD 0 [EBX]
    DUP 1 > IF 0x1B8D W,      2 - ELSE \ LEA EBX, [EBX]
    DUP 1 = IF 0x90 C,        1 - THEN \ NOP
    THEN THEN
  DUP 0= UNTIL DROP
;

Проверка:


0 C, 0 C, 0 C, 0 C, 0 C, \ 0 C, 0 C, 0 C, 0 C,
: r [ 16 ALIGN-NOP ] ;
lib/ext/disasm.f
SEE r

3. Проблема существенного оставания SPF в бенчмарке от MPE (последняя версия от сентября 2007-го: http://www.mpeforth.com/arena/benchmrk.fth ) -- непонятная чувствительность к выравниванию данных по 4кб (размер страницы?..). Сравните оригинальный тест с изменённым (я включил выравнивание по 4кб для SPF): http://forth.org.ru/~profit/benchmark.f .

[Dmitry Groshev-2]

Приветствую!

azekeProfit пишет:
> 3. Проблема существенного оставания SPF в бенчмарке от MPE (последняя версия
> от сентября 2007-го: http://www.mpeforth.com/arena/benchmrk.fth ) --
> непонятная чувствительность к выравниванию данных по 4кб (размер
> страницы?..). Сравните оригинальный тест с изменённым (я включил
> выравнивание по 4кб для SPF): http://forth.org.ru/~profit/benchmark.f .

Ничего непонятного. На P4, смешивать записываемые данные и исполнимый код чревато боком - запись в память вызывает инвалидацию кэша трассы (trace cache) для всех адресов в радиусе 1 Кб от записанного.
Кстати: если кому не лениво, проверьте как на это реагируют Intel Core 2 и Athlon 64 - если примерно так же, то тем Форт-системам, у которых данные и код лежат кучей в одном сегменте, уготована судьба мамонтов.


-= With best regards, Dmitry Groshev =-


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Some javascript/style in this post has been disabled (why?)

Добрый день, Dmitry Groshev!

Ваше сообщение от 15.11.2007 14:01:

страницы?..). Сравните оригинальный тест с изменённым (я включил
выравнивание по 4кб для SPF): http://forth.org.ru/~profit/benchmark.f .
    

Ничего непонятного. На P4, смешивать записываемые данные и исполнимый код чревато боком - запись в память вызывает инвалидацию кэша трассы (trace cache) для всех адресов в радиусе 1 Кб от записанного.
Кстати: если кому не лениво, проверьте как на это реагируют Intel Core 2 и Athlon 64 - если примерно так же, то тем Форт-системам, у которых данные и код лежат кучей в одном сегменте, уготована судьба мамонтов.

Да, азаматова оптимизация на Athlon64 X2 дает прирост в разы на тех провальных тестах (блочных), по которым SPF проиграл лидерам (см. ниже). В результате лидеров догоняем или перегоняем. Но если бы в мамонты записывали по производительности, то очень немногие языки сейчас бы использовались :) Вот SPF/2.5 использовал отдельные данные и код, однако вымер аки обры :)

Сравнение файлов amd64_0.txt (0 [IF]) и AMD64.TXT

Benchmark code size                                       126376 bytes.
***** AMD64.TXT
Benchmark code size                                       141038 bytes.
*****

***** amd64_0.txt
                                              0
+                                           16                                                  1000000                       
                                       16
M+                                            0                                                  1000000                      
***** AMD64.TXT
                                              0
+                                            0                                                  1000000                       
                                        0
M+                                            0                                                  1000000                      
*****

***** amd64_0.txt
                                                15
Total:                                          156                                                  1

***** AMD64.TXT
                                                15
Total:                                          140                                                  1

*****

***** amd64_0.txt
   2000000                                                                86
Generate random numbers (1024 kb array)                                         2140                                          
      262144                                                              8163
LZ77 Comp. (400 kb Random Data Mem>Mem)                                          953                                          
      1
Dhrystone (integer)                                          125                                                  500000      
                                                       250                                                                    
4000000 Dhrystones/sec
Total:                                         3610                                                  1

***** AMD64.TXT
   2000000                                                                86
Generate random numbers (1024 kb array)                                           93                                          
      262144                                                               354
LZ77 Comp. (400 kb Random Data Mem>Mem)                                          266                                          
      1
Dhrystone (integer)                                          141                                                  500000      
                                                       282                                                                    
3546099 Dhrystones/sec
Total:                                          892                                                  1

*****



-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev

[ygrek-3]

On Thu, 15 Nov 2007 19:06:54 +0200
Andrey Cherezov <andrey@...> wrote:

> Добрый день, Dmitry Groshev!
>
> Ваше сообщение от 15.11.2007 14:01:
> >> страницы?..). Сравните оригинальный тест с изменённым (я включил
> >> выравнивание по 4кб для SPF): http://forth.org.ru/~profit/benchmark.f .
> >>    
> >
> > Ничего непонятного. На P4, смешивать записываемые данные и исполнимый код чревато боком - запись в память вызывает инвалидацию кэша трассы (trace cache) для всех адресов в радиусе 1 Кб от записанного.
> > Кстати: если кому не лениво, проверьте как на это реагируют Intel Core 2 и Athlon 64 - если примерно так же, то тем Форт-системам, у которых данные и код лежат кучей в одном сегменте, уготована судьба мамонтов.
> Да, азаматова оптимизация на Athlon64 X2 дает прирост в разы на тех
> провальных тестах (блочных), по которым SPF проиграл лидерам (см. ниже).
> В результате лидеров догоняем или перегоняем. Но если бы в мамонты
> записывали по производительности, то очень немногие языки сейчас бы
> использовались :) Вот SPF/2.5 использовал отдельные данные и код, однако
> вымер аки обры :)

10000000 VALUE total

400
( N ) VALUE offset
VARIABLE data
offset ALLOT

: test total 0 DO data @ data ! LOOP ;

WINAPI: GetTickCount KERNEL32.DLL
: ms@ GetTickCount ;

ms@ test ms@ - ABS .

вариация offset даёт следуещее :
на Celeron 2.6 (D331) - offset до 830 - около 3000мс, после - 30 мс
на Cel 3.2 - 1200 на 20 мс, порог offset около 450

я бы сказал существенная разница.

( Сначала пытался обьяснить это тем что кэш-линии в L1i и L1d
постоянно инвалидируются поочерёдно, но расстояние слишком большое -
кэш-линия L2 - 128 байт, для L1  и того меньше, тем более что в него
всё должно было поместиться )
А наткнулся на письмо выше и вроде тогда всё обьясняется...

размер trace-cache на втором процессоре - 12K uops - что бы это ни
значило.

--


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
Spf-dev@...
https://lists.sourceforge.net/lists/listinfo/spf-dev