Ответьте мне пожалуйста о знатоки оптимизаторов. Если мы имеем маленькую функцию с дестятком переменных, насколько оптимизатор будут генерить оптимальные код — например — два последовательных одинаковых фора но по разным массивам, будут ли обьеденены в нечто в виде одного двойного тела и одного цикла. То есть лм смысл оптимизировать ручками (алгоритм не оптимизируем) или смысла нет и лучше для читабельности оставлять более понятный код?

Кстати если кто-знает а насколько интеловый компилятор лучше делает код чем МСовский?

Здравствуйте, Комментатор, Вы писали:

К>Ответьте мне пожалуйста о знатоки оптимизаторов. Если мы имеем маленькую функцию с дестятком переменных, насколько оптимизатор будут генерить оптимальные код — например — два последовательных одинаковых фора но по разным массивам, будут ли обьеденены в нечто в виде одного двойного тела и одного цикла. То есть лм смысл оптимизировать ручками (алгоритм не оптимизируем) или смысла нет и лучше для читабельности оставлять более понятный код?
Кроме как "скомпиль и посмотри в код" вариантов нету. Мало кто тут знает как устроены оптимизаторы в конкретных версиях конкретных компиляторов чтоб дать ответ на такой общий вопрос.

К>Кстати если кто-знает а насколько интеловый компилятор лучше делает код чем МСовский?
Зависит от кода.
По производительности полученного exeшника разница в скорости была до двух раз (AES encryption). А так, на вычислительных задачах в 1.2-1.8 раз быстрее чем МС.

Здравствуйте, CreatorCray, Вы писали:

К>>Кстати если кто-знает а насколько интеловый компилятор лучше делает код чем МСовский?
CC>Зависит от кода.
CC>По производительности полученного exeшника разница в скорости была до двух раз (AES encryption). А так, на вычислительных задачах в 1.2-1.8 раз быстрее чем МС.

Спасибо. А кстати может кто знает — а что интеловый комилятор покупать придется? Или все же там есть что-то триальное. Мне просто только себе лично? И нет уж постоянно таких задач чтобы нужно было супер оптимизацию.

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

Здравствуйте, Комментатор, Вы писали:

К>А кстати может кто знает — а что интеловый комилятор покупать придется? Или все же там есть что-то триальное. Мне просто только себе лично? И нет уж постоянно таких задач чтобы нужно было супер оптимизацию.

Да, у них есть триальные версии.
А воообще на ихнем сайте все расписано
http://www.intel.com/cd/software/products/asmo-na/eng/compilers/284132.htm

Здравствуйте, bkat, Вы писали:

B>Да, у них есть триальные версии.
B>А воообще на ихнем сайте все расписано

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

Здравствуйте, Комментатор, Вы писали:

К>Я не совсем точно выразился, мне бы либо триал на ограниченное число компиляций или что-то вроде ограниченно бесплатное как у МСовской студии.

Ну я же даже ссылку на Intel кинул...

Можно взять триальную версию на 90 дней.
Есть Non-Commercial версии для Linux.
Для винды Non-Commercial версии нету.

Вот еще ссылка:
http://www.intel.com/cd/software/products/asmo-na/eng/340679.htm

Здравствуйте, bkat, Вы писали:

B>Ну я же даже ссылку на Intel кинул...

B>Можно взять триальную версию на 90 дней.
B>Есть Non-Commercial версии для Linux.
B>Для винды Non-Commercial версии нету.

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

Нет — ну очень жаль.

Здравствуйте, Комментатор, Вы писали:
К>Понятно, 90 дней это не интересно, мне все-таки хочется иметь возможность и после 90 дней вносить изменения и перекомпилировать свои программы.
К>Нет — ну очень жаль.

Ну можно посмотреть как он регистрируется. Может в регистре пишет кракозябру. Найти где он фиксирует дату начала триала. Потом удалить ручками. и начать новый триал.
Это если прижимает конечно.

Здравствуйте, Комментатор, Вы писали:

К>Понятно, 90 дней это не интересно, мне все-таки хочется иметь возможность и после 90 дней вносить изменения и перекомпилировать свои программы.
Не, ну триал же...
Хочешь пользовать не на "пробной" основе — покупай. Последний раз был где то в районе $350-400

Здравствуйте, CreatorCray, Вы писали:

CC>По производительности полученного exeшника разница в скорости была до двух раз (AES encryption).

Ого, а что за имплементация?

CC> А так, на вычислительных задачах в 1.2-1.8 раз быстрее чем МС.

+1

Здравствуйте, Комментатор, Вы писали:

К>Ответьте мне пожалуйста о знатоки оптимизаторов. Если мы имеем маленькую функцию с дестятком переменных, насколько оптимизатор будут генерить оптимальные код — например —

На таком количестве переменных у MSVC обычно проблемы с распределением по регистрам, начинает активно использовать стек . Здесь C++ может легко порвать "С", учитывая const и объявления переменных по месту.

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

Ни разу не видел. Хотя это скорее оптимизация по размеру, и на скорости может сказаться отрицательно.

К> То есть лм смысл оптимизировать ручками (алгоритм не оптимизируем) или смысла нет и лучше для читабельности оставлять более понятный код?

А что думает по этому поводу профайлер? Если это самое узкое место, возможно, надо.

К>Кстати если кто-знает а насколько интеловый компилятор лучше делает код чем МСовский?

10-20%, но зависит от версий (последние MS могут обгнать на те же 10% старые)

Здравствуйте, Комментатор, Вы писали:

B>>Есть Non-Commercial версии для Linux.

К>Нет — ну очень жаль.

[оффтоп]
А линукс для образовательных целей чем не подходит?
[/оффтоп]

Здравствуйте, gear nuke, Вы писали:

CC>>По производительности полученного exeшника разница в скорости была до двух раз (AES encryption).
GN>Ого, а что за имплементация?
Да самая что ни на есть обычная.
Я тогда от разницы сам офигел и полез смотреть сгенеренный код: все оказалось банально: МС компилер почти ничего в регистрах не закешировал и за каждым чихом лез в память. ICC же попереставлял местами операции чтения, кэшил данные по регистрам и в результате на одно и то же действие тратил гораздо меньше операций чтения.

Здравствуйте, CreatorCray, Вы писали:

CC>Да самая что ни на есть обычная.

То есть своя? (а обычно почему-то гора макросов )

CC>Я тогда от разницы сам офигел и полез смотреть сгенеренный код: все оказалось банально: МС компилер почти ничего в регистрах не закешировал и за каждым чихом лез в память.

Я тоже помню такое, когда сделал в лоб. Посмотрел внимательнее — алгоритм на big-endian расчитан. Изменил генерацию раундовых ключей, что бы не было необходимости в лишних вычислениях для смены порядка байт. Ниже листинг после 2008, но и на 2003й должно похоже быть — тогда вполне устроило, проиграло те самые 10-20% Intel'у и реализации на ассемблере от Brian Gladman (выиграв у почти всех из бенчмарка Christophe Devine). Главное, что получился компактный исходник

Кстати, развёрнутые руками циклы (GNU Crypto?) давали очень заметный провал, а MSVC норовил это сделать сам

_rk$ = -8                       ; size = 4
_i$3831 = -4                        ; size = 4
_a1$ = 8                        ; size = 4
_in$ = 8                        ; size = 4
_out$ = 12                      ; size = 4
?encrypt@aes@@QAEXQBEQAE@Z PROC             ; aes::encrypt, COMDAT
; _this$ = ecx

; 152  : {

    sub esp, 8

; 153  :     //  Указатель на раундовые константы
; 154  :     u32   * rk = encryption_round_key;
; 155  : 
; 156  :     //  Считываем блок и добавляем раундовый ключ.
; 157  :     u32     a0 = get( &in[ 0] ) ^ rk[0];
; 158  :     u32     a1 = get( &in[ 4] ) ^ rk[1];

    mov eax, DWORD PTR [ecx+8]
    push    ebx

; 159  :     u32     a2 = get( &in[ 8] ) ^ rk[2];

    mov ebx, DWORD PTR [ecx+12]
    lea edx, DWORD PTR [ecx+4]

; 160  :     u32     a3 = get( &in[12] ) ^ rk[3];
; 161  :     u32     b0, b1, b2, b3;
; 162  : 
; 163  :     //  Раунды криптования (цикл развёрнут 2x)
; 164  :     for( int i = rounds; ; rk += 8 )   

    mov ecx, DWORD PTR [ecx]
    push    ebp
    mov ebp, DWORD PTR [edx+12]
    push    esi
    mov esi, DWORD PTR _in$[esp+16]
    xor eax, DWORD PTR [esi+4]
    xor ebx, DWORD PTR [esi+8]
    push    edi
    mov edi, DWORD PTR [edx]
    xor edi, DWORD PTR [esi]
    xor ebp, DWORD PTR [esi+12]
    mov DWORD PTR _rk$[esp+24], edx
    mov DWORD PTR _a1$[esp+20], eax
    mov DWORD PTR _i$3831[esp+24], ecx
$LL4@encrypt:

; 165  :     {
; 166  :         b0 = fb(a0, 0) ^ fb(a1, 1) ^ fb(a2, 2) ^ fb(a3, 3) ^ rk[4];

    mov esi, eax
    shr esi, 8
    and esi, 255                ; 000000ffH
    mov ecx, ebx
    shr ecx, 16                 ; 00000010H
    and ecx, 255                ; 000000ffH
    mov eax, DWORD PTR ?ft@aes@@1PAY0BAA@KA[ecx*4+2048]
    xor eax, DWORD PTR ?ft@aes@@1PAY0BAA@KA[esi*4+1024]
    mov ecx, ebp
    shr ecx, 24                 ; 00000018H
    xor eax, DWORD PTR ?ft@aes@@1PAY0BAA@KA[ecx*4+3072]
    mov ecx, edi
    and ecx, 255                ; 000000ffH
    xor eax, DWORD PTR ?ft@aes@@1PAY0BAA@KA[ecx*4]

; 167  :         b1 = fb(a1, 0) ^ fb(a2, 1) ^ fb(a3, 2) ^ fb(a0, 3) ^ rk[5];

    mov ecx, ebp
    xor eax, DWORD PTR [edx+16]
    shr ecx, 16                 ; 00000010H
    and ecx, 255                ; 000000ffH
    mov ecx, DWORD PTR ?ft@aes@@1PAY0BAA@KA[ecx*4+2048]
    mov esi, ebx
    shr esi, 8
    and esi, 255                ; 000000ffH
    xor ecx, DWORD PTR ?ft@aes@@1PAY0BAA@KA[esi*4+1024]
    mov esi, edi
    shr esi, 24                 ; 00000018H
    xor ecx, DWORD PTR ?ft@aes@@1PAY0BAA@KA[esi*4+3072]
    mov esi, DWORD PTR _a1$[esp+20]
    and esi, 255                ; 000000ffH
    xor ecx, DWORD PTR ?ft@aes@@1PAY0BAA@KA[esi*4]

; 168  :         b2 = fb(a2, 0) ^ fb(a3, 1) ^ fb(a0, 2) ^ fb(a1, 3) ^ rk[6];

    mov esi, edi
    xor ecx, DWORD PTR [edx+20]
    shr esi, 16                 ; 00000010H
    and esi, 255                ; 000000ffH
    mov edx, ebp
    shr edx, 8
    and edx, 255                ; 000000ffH
    mov edx, DWORD PTR ?ft@aes@@1PAY0BAA@KA[edx*4+1024]
    xor edx, DWORD PTR ?ft@aes@@1PAY0BAA@KA[esi*4+2048]
    mov esi, DWORD PTR _a1$[esp+20]
    shr esi, 24                 ; 00000018H
    xor edx, DWORD PTR ?ft@aes@@1PAY0BAA@KA[esi*4+3072]
    mov esi, ebx
    and esi, 255                ; 000000ffH
    xor edx, DWORD PTR ?ft@aes@@1PAY0BAA@KA[esi*4]
    mov esi, DWORD PTR _rk$[esp+24]
    xor edx, DWORD PTR [esi+24]

; 169  :         b3 = fb(a3, 0) ^ fb(a0, 1) ^ fb(a1, 2) ^ fb(a2, 3) ^ rk[7];

    mov esi, DWORD PTR _a1$[esp+20]
    shr esi, 16                 ; 00000010H
    and esi, 255                ; 000000ffH
    mov esi, DWORD PTR ?ft@aes@@1PAY0BAA@KA[esi*4+2048]
    shr edi, 8
    and edi, 255                ; 000000ffH
    xor esi, DWORD PTR ?ft@aes@@1PAY0BAA@KA[edi*4+1024]
    shr ebx, 24                 ; 00000018H
    xor esi, DWORD PTR ?ft@aes@@1PAY0BAA@KA[ebx*4+3072]
    mov ebx, DWORD PTR _rk$[esp+24]
    and ebp, 255                ; 000000ffH
    xor esi, DWORD PTR ?ft@aes@@1PAY0BAA@KA[ebp*4]
    xor esi, DWORD PTR [ebx+28]

Здравствуйте, gear nuke, Вы писали:

CC>>Да самая что ни на есть обычная.
GN>То есть своя? (а обычно почему-то гора макросов )
Макросами там обычно статические таблицы генерят — очень удобно.
+ раунды разворачивать тоже самое оно.

GN>Изменил генерацию раундовых ключей, что бы не было необходимости в лишних вычислениях для смены порядка байт.
Этож простым bswap делается. Мне в свое время было сильно лень переделывать — вставил bswap-ы.

CC>>Я тогда от разницы сам офигел и полез смотреть сгенеренный код: все оказалось банально: МС компилер почти ничего в регистрах не закешировал и за каждым чихом лез в память.
GN>Я тоже помню такое, когда сделал в лоб. Посмотрел внимательнее — алгоритм на big-endian расчитан.
Не, ну компилер то endian то сам не сменил при компиляции. На скорость не влияет для какого endian алгоритм. Влиять может только преобразование входных/выходных данных в нужную форму, но на фоне общих вычислений дополнительные 2*4 bswap-а погоды не делают.

GN>Кстати, развёрнутые руками циклы (GNU Crypto?) давали очень заметный провал, а MSVC норовил это сделать сам
Я сразу развернутый делал.

GN> Ниже листинг после 2008, но и на 2003й должно похоже быть — тогда вполне устроило, проиграло те самые 10-20% Intel'у и реализации на ассемблере от Brian Gladman (выиграв у почти всех из бенчмарка Christophe Devine). Главное, что получился компактный исходник

1 раунд скопиленного 2003й

; 183  :     AES_FROUND(X0, X1, X2, X3, Y0, Y1, Y2, Y3);       // round 2

    movzx    ebx, BYTE PTR _Y1$[esp+38]
    xor    edx, DWORD PTR [eax+12]
    movzx    esi, ch
    mov    esi, DWORD PTR ?m_FT2@AES@@0QBKB[esi*4]
    xor    esi, DWORD PTR ?m_FT1@AES@@0QBKB[ebx*4]
    mov    ebx, DWORD PTR _Y0$[esp+32]
    shr    ebx, 24                    ; 00000018H
    xor    esi, DWORD PTR ?m_FT0@AES@@0QBKB[ebx*4]
    mov    ebx, edx
    and    ebx, 255                ; 000000ffH
    xor    esi, DWORD PTR ?m_FT3@AES@@0QBKB[ebx*4]
    movzx    ebx, BYTE PTR _Y2$[esp+38]
    xor    esi, DWORD PTR [eax+16]
    add    eax, 16                    ; 00000010H
    mov    DWORD PTR _X0$[esp+36], esi
    movzx    esi, dh
    mov    esi, DWORD PTR ?m_FT2@AES@@0QBKB[esi*4]
    xor    esi, DWORD PTR ?m_FT1@AES@@0QBKB[ebx*4]
    mov    ebx, DWORD PTR _Y1$[esp+36]
    shr    ebx, 24                    ; 00000018H
    xor    esi, DWORD PTR ?m_FT0@AES@@0QBKB[ebx*4]
    mov    ebx, DWORD PTR _Y0$[esp+32]
    and    ebx, 255                ; 000000ffH
    xor    esi, DWORD PTR ?m_FT3@AES@@0QBKB[ebx*4]
    movzx    ebx, BYTE PTR _Y0$[esp+33]
    xor    esi, DWORD PTR [eax+4]
    movzx    ebp, BYTE PTR _Y0$[esp+34]
    mov    DWORD PTR _X1$[esp+36], esi
    mov    DWORD PTR _Y3$[esp+36], edx
    movzx    esi, BYTE PTR _Y3$[esp+38]
    mov    esi, DWORD PTR ?m_FT1@AES@@0QBKB[esi*4]
    xor    esi, DWORD PTR ?m_FT2@AES@@0QBKB[ebx*4]
    mov    ebx, ecx
    shr    ebx, 24                    ; 00000018H
    xor    esi, DWORD PTR ?m_FT0@AES@@0QBKB[ebx*4]
    mov    ebx, DWORD PTR _Y1$[esp+36]
    and    ebx, 255                ; 000000ffH
    xor    esi, DWORD PTR ?m_FT3@AES@@0QBKB[ebx*4]
    shr    edx, 24                    ; 00000018H
    xor    esi, DWORD PTR [eax+8]
    and    ecx, 255                ; 000000ffH
    mov    DWORD PTR _X2$[esp+36], esi
    movzx    esi, BYTE PTR _Y1$[esp+37]
    mov    ebx, DWORD PTR ?m_FT2@AES@@0QBKB[esi*4]
    xor    ebx, DWORD PTR ?m_FT1@AES@@0QBKB[ebp*4]

он же, но ICC 10.1

;;;     AES_FROUND(X0, X1, X2, X3, Y0, Y1, Y2, Y3);       // round 2

  mov       edi, DWORD PTR [esp]
  movzx     eax, al
  xor       ebp, DWORD PTR ?m_FT1@AES@@0QBKB[0+eax*4] 
  mov       eax, DWORD PTR [ecx+32]
  movzx     ebx, bl
  xor       ebp, DWORD PTR ?m_FT2@AES@@0QBKB[0+ebx*4] 
  and       esi, 255
  xor       ebp, DWORD PTR ?m_FT3@AES@@0QBKB[0+esi*4] 
  mov       esi, DWORD PTR [esp+8]
  mov       ebx, esi
  shr       ebx, 24
  xor       eax, DWORD PTR ?m_FT0@AES@@0QBKB[0+ebx*4] 
  mov       ebx, edi
  shr       ebx, 16
  movzx     ebx, bl
  xor       eax, DWORD PTR ?m_FT1@AES@@0QBKB[0+ebx*4] 
  mov       ebx, edx
  shr       ebx, 8
  movzx     ebx, bl
  xor       eax, DWORD PTR ?m_FT2@AES@@0QBKB[0+ebx*4] 
  mov       ebx, ebp
  and       ebx, 255
  xor       eax, DWORD PTR ?m_FT3@AES@@0QBKB[0+ebx*4] 
  mov       ebx, edi
  shr       ebx, 24
  mov       DWORD PTR [esp+12], eax
  mov       eax, DWORD PTR [ecx+36]
  xor       eax, DWORD PTR ?m_FT0@AES@@0QBKB[0+ebx*4] 
  mov       ebx, edx
  shr       ebx, 16
  movzx     ebx, bl
  xor       eax, DWORD PTR ?m_FT1@AES@@0QBKB[0+ebx*4] 
  mov       ebx, ebp
  shr       ebx, 8
  movzx     ebx, bl
  xor       eax, DWORD PTR ?m_FT2@AES@@0QBKB[0+ebx*4] 
  mov       ebx, esi
  and       ebx, 255
  xor       eax, DWORD PTR ?m_FT3@AES@@0QBKB[0+ebx*4] 
  mov       ebx, DWORD PTR [ecx+40]
  mov       DWORD PTR [esp+16], eax
  mov       eax, edx
  shr       eax, 24
  xor       ebx, DWORD PTR ?m_FT0@AES@@0QBKB[0+eax*4] 
  mov       eax, ebp
  shr       eax, 16
  movzx     eax, al
  xor       ebx, DWORD PTR ?m_FT1@AES@@0QBKB[0+eax*4] 
  mov       eax, esi
  shr       eax, 8
  shr       ebp, 24
  movzx     eax, al
  xor       ebx, DWORD PTR ?m_FT2@AES@@0QBKB[0+eax*4] 
  shr       esi, 16
  mov       eax, edi
  and       eax, 255
  xor       ebx, DWORD PTR ?m_FT3@AES@@0QBKB[0+eax*4] 
  shr       edi, 8
  mov       eax, DWORD PTR [ecx+44]
  xor       eax, DWORD PTR ?m_FT0@AES@@0QBKB[0+ebp*4]

Здравствуйте, Комментатор, Вы писали:

К>Кстати если кто-знает а насколько интеловый компилятор лучше делает код чем МСовский?
От задачи зависит. Есть мнение что на многих реальных проектах MSовский может и побыстрее оказаться за счет генерации более компактного кода. Впрочем их же ж смешивать можно смотря по задаче )

Здравствуйте, CreatorCray, Вы писали:

CC>Этож простым bswap делается. Мне в свое время было сильно лень переделывать — вставил bswap-ы.

Делается, но в то время он жутко тормозил на 4м Пне. А с << | >> MSVC 2003 как раз и начинало активно использовать память. ICC, если правильно помню, догадывался вместо этого читать отдельные байты movzx.

CC>Не, ну компилер то endian то сам не сменил при компиляции.

Кстати, слабо представляю, как бы он смог сделать трансфармацию алгоритма подобного рода...

CC> На скорость не влияет для какого endian алгоритм. Влиять может только преобразование входных/выходных данных в нужную форму, но на фоне общих вычислений дополнительные 2*4 bswap-а погоды не делают.

Дело не столько в "оверхеде" от этих (по сути, лишних) команд. Я как раз на этом изучал необходимость ручных оптимизаций, смотрел асм листинги после компиляции нескольких известных реализаций . Замена endian'ства и выполнение раундов в естественном порядке (цикле) сильно помогло оптимизатору MSVC (вроде на ~50%, поэтому и удивило "в 2 раза"). bswap, возможно, отключает какие-то оптимизации, а вот в случае ручного разворачивания (макросами) получается сверхбольшая функция, у оптимизатора похоже заканчиваются какие-то лимиты и он начинает тупить. Результаты здесь

Автор: gear nuke
Дата: 07.05.07

Цифры вроде для MSVC 2005, на CoreDuo (разумеется, тест только одного ядра) процентов на 20 быстрее. ICC обгонит, но не на много.

Ах, да, как всегда, забыл суть... вывод сделал такой же, что и Кнут

Здравствуйте, gear nuke, Вы писали:

CC>>Этож простым bswap делается. Мне в свое время было сильно лень переделывать — вставил bswap-ы.
GN>Делается, но в то время он жутко тормозил на 4м Пне.
дык на 4-м как раз и проверялось. Впрочем 8 bswapов на блок совершенно незаметны на фоне остальных преобразований.

CC>>Не, ну компилер то endian то сам не сменил при компиляции.
GN>Кстати, слабо представляю, как бы он смог сделать трансфармацию алгоритма подобного рода...
Аналогично. Не могут пока компилеры делать подобное.

GN>Результаты здесь

Автор: gear nuke
Дата: 07.05.07

на P4 + ICC. Мерялку только переделал на затрачиваемые тики а не на байт/сек. Т.е сейчас чем меньше тем лучше.
В принципе скорость такая же, кроме разворачивания ключа — у меня таблицы built-in а ты их строишь в реалтайме.

Speed test:

key | ticks | ticks | ticks
128 bit | 1'156'118'790 | 393'997'570 | 392'477'940 |
192 bit | 1'451'474'370 | 461'571'200 | 461'309'350 |
256 bit | 1'721'478'160 | 532'790'750 | 534'686'330 |

Speed test CrayLib AES:

key | ticks | ticks | ticks
128 bit | 595'427'690 | 367'691'340 | 439'560'560 |
192 bit | 929'636'750 | 432'452'780 | 450'385'640 |
256 bit | 935'224'110 | 494'964'760 | 520'458'230 |