Виконання циклу коду C [продовження]


83

Це питання продовжується на моє питання тут (за порадою Mystical):

Продуктивність циклу коду C


Продовжуючи своє запитання, коли я використовую упаковані інструкції замість скалярних інструкцій, код, що використовує внутрішні дані, буде виглядати дуже схожим:

for(int i=0; i<size; i+=16) {
    y1 = _mm_load_ps(output[i]);
    …
    y4 = _mm_load_ps(output[i+12]);

    for(k=0; k<ksize; k++){
        for(l=0; l<ksize; l++){
            w  = _mm_set_ps1(weight[i+k+l]);

            x1 = _mm_load_ps(input[i+k+l]);
            y1 = _mm_add_ps(y1,_mm_mul_ps(w,x1));
            …
            x4 = _mm_load_ps(input[i+k+l+12]);
            y4 = _mm_add_ps(y4,_mm_mul_ps(w,x4));
        }
    }
    _mm_store_ps(&output[i],y1);
    …
    _mm_store_ps(&output[i+12],y4);
    }

Виміряна продуктивність цього ядра становить приблизно 5,6 операцій FP за цикл, хоча я би очікував, що це буде рівно в 4 рази ефективність скалярної версії, тобто 4,1,6 = 6,4 операцій FP за цикл.

Беручи до уваги рух вагового коефіцієнта (спасибі, що вказали на це), графік виглядає так:

графік

Схоже, графік не змінюється, хоча після movssоперації існує додаткова інструкція, яка переміщує значення скалярної ваги до регістра XMM, а потім використовує shufpsдля копіювання цього скалярного значення у всьому векторі. Здається, вектор ваги готовий до використання протягом mulpsчасу з урахуванням затримки перемикання з навантаження на домен із плаваючою точкою, тому це не повинно спричиняти додаткової затримки.

movaps(Вирівняні, упакований хід), addpsі mulpsінструкція, які використовуються в цьому ядрі (перевірений з асемблером) має однакову затримку & пропускну здатність, як і їх скалярні версії, тому це не повинно брати на себе якісь - які додаткові затримки або.

Хто-небудь має уявлення, де витрачається цей додатковий цикл за 8 циклів, припускаючи, що максимальна продуктивність, яку може отримати це ядро, становить 6,4 FP операційних циклів за цикл, і він працює при 5,6 операційних операцій FP за цикл?


До речі ось як виглядає фактична збірка:

…
Block x: 
  movapsx  (%rax,%rcx,4), %xmm0
  movapsx  0x10(%rax,%rcx,4), %xmm1
  movapsx  0x20(%rax,%rcx,4), %xmm2
  movapsx  0x30(%rax,%rcx,4), %xmm3
  movssl  (%rdx,%rcx,4), %xmm4
  inc %rcx
  shufps $0x0, %xmm4, %xmm4               {fill weight vector}
  cmp $0x32, %rcx 
  mulps %xmm4, %xmm0 
  mulps %xmm4, %xmm1
  mulps %xmm4, %xmm2 
  mulps %xmm3, %xmm4
  addps %xmm0, %xmm5 
  addps %xmm1, %xmm6 
  addps %xmm2, %xmm7 
  addps %xmm4, %xmm8 
  jl 0x401ad6 <Block x> 
…

Отже, я думаю, питання зараз: "Чому shufpsінструкція додає 1 цикл кожні 1,6 ітерації?" Це важко ...
Містичний

я би очікував, що у нього не буде накладних витрат, оскільки вихідний файл shufpsповинен бути безпосередньо доступним для multpsоператора, оскільки це обидва домени FP
Рікі

Це легко з’ясувати. Переконайтеся, що вектор ваги не містить будь-яких денормалізованих значень. Спробуйте цикл без інструкції перетасовки. Це не дасть корисних результатів, але, можливо, ваша знахідка, інструкція якої коштує вам додаткових циклів (я підозрюю, що відбувається перетасовка, звичайно).
Гюнтер Пієз,

@Mystical: я бачу 0,75 циклів за додану ітерацію циклу. (Хіба це не був мій коментар щодо використання 5 циклів замість 4, які ведуть вас до вашої відповіді там ... :-))
Гюнтер Пієз,

3
По-перше, зараз ви вимагаєте в чотири рази пропускну здатність кешу. Наскільки великі розміри даних? Чи вміщуються вони в кеш-пам'яті L1?
Містичний

Відповіді:


3

Спробуйте скористатися профілем EMON у Vtune або іншим еквівалентним інструментом, таким як oprof

Профілювання EMON (моніторинг подій) => як інструмент, заснований на часі, але він може сказати вам, яка подія продуктивності спричиняє проблему. Хоча спочатку слід почати з часового профілю, щоб перевірити, чи є якась конкретна інструкція, яка вискакує. (І, можливо, пов’язані з цим події, які повідомляють вам, як часто на цьому ІР був пенсійний кіоск.)

Для використання профілювання EMON потрібно пройти список подій, починаючи від "звичайних підозрюваних" і закінчуючи ...

Тут я б почав з помилок кешу, вирівнювання. Я не знаю, чи має процесор, яким ви користуєтесь, лічильник обмежень радіочастотних портів - він повинен - ​​але я давно додав профілювання EMON, і я не знаю, наскільки вони вдаються, додаючи події, відповідні мікроархітектурі.

Також може бути можливо, що це інтерфейс, вибір інструкцій, стійло. Скільки байтів у цих інструкціях, у будь-якому випадку? Для цього теж є події EMON.


Відповідаючи на коментар, що Nehalem VTune не може бачити події L3: неправда. Ось речі, які я додав до коментаря, але не підходив:

Насправді є лічильники продуктивності для LL3 / L3 $ / так званий Uncore. Я був би надзвичайно здивований, якщо VTune їх не підтримує. Див. Http://software.intel.com/sites/products/collateral/hpc/vtune/performance_analysis_guide.pdfвказує на VTune та інші інструменти, такі як PTU. Насправді, навіть без подій LL3, як говорить Девід Левінталь: "Процесор Intel® Core ™ i7 має" затримку ", яка дуже схожа на подію EAR Itanium® Processor Family Data. Ця подія відбирає завантаження, реєструючи кількість цикли між виконанням інструкції та фактичною доставкою даних. Якщо виміряна затримка більша за мінімальну затримку, запрограмовану в MSR 0x3f6, біти 15: 0, тоді лічильник збільшується. Лічильник переповнює озброєння механізмом PEBS і на наступному подія, що задовольняє поріг затримки, виміряна затримка, віртуальна або лінійна адреса та джерело даних копіюються в 3 додаткові регістри в буфері PEBS, оскільки віртуальна адреса фіксується у відомому місці, драйвер вибірки також може виконувати віртуальний у фізичний переклад та фіксувати фізичну адресу. Фізична адреса ідентифікує домашнє місцезнаходження NUMA і, в принципі, дозволяє аналізувати деталі зайнятості кешу. "Він також вказує на сторінці 35 на події VTune, такі як L3 CACHE_HIT_UNCORE_HIT і L3 CACHE_MISS_REMOTE_DRAM. Іноді потрібно шукати числовий коди та запрограмуйте їх на інтерфейс нижчого рівня VTune, але я думаю, що в цьому випадку це видно в симпатичному інтерфейсі користувача.


Добре, в http://software.intel.com/en-us/forums/showthread.php?t=77700&o=d&s=lr програміст VTune в Росії (я думаю) "пояснює", що ви не можете взяти зразки на Uncore події.

Він помиляється - ви можете, наприклад, увімкнути лише один центральний процесор і зробити значущий зразок. Я також вважаю, що є можливість позначити відсутні дані L3, коли вони повертаються до центрального процесора. Насправді загалом L3 знає, до якого процесора він повертає дані, тож ви точно можете взяти вибірку. Можливо, ви не знаєте, який гіперпотік, але знову ж ви можете відключити, перейти в режим одного потоку.

Але схоже, що, як це досить часто, для цього вам доведеться працювати навколо VTune, а не з ним.

Спробуйте спершу профілювати затримки. Це всередині центрального процесора, і люди з VTune навряд чи занадто переплутали його.

І я ще раз кажу, що ймовірність полягає в тому, що ваша проблема полягає в основному, а не в L3. Отже, VTune повинен мати змогу це впоратись.


Спробуйте "Цикловий облік" для Levinthal.


Дякую за вашу реакцію. Я використовую VTune для аналізу мого додатка, але проблема архітектури nehalem полягає в тому, що кеш L3 належить до off-coreчастини ядра, тому для цієї частини немає лічильників подій продуктивності. Тому важко оцінити відсутність кеш-пам’яті тощо.
Рікі

Власне, є лічильники продуктивності для LL3 / L3 $ / так званий Uncore. Я був би надзвичайно здивований, якщо VTune їх не підтримує. Див. Software.intel.com/sites/products/collateral/hpc/vtune/…
Krazy Glew

Я написав більше, ніж міститься в коментарі, намагався перемістити його до відповіді та очистити оригінальний коментар, але коментарі можуть редагуватися лише протягом 5 хвилин. Коротка версія: VTune дозволяє побачити пропуски кешу L3. Навіть без підтримки Uncore, використовуючи профілювання затримок - і вона має підтримку Uncore.
Krazy Glew

І загалом я підозрюю, що ваша проблема полягає не в помилках кешу L3. Швидше за все, подія фронту.
Krazy Glew

@KrazyGlew: Ви гадаєте, це правильно, він російський хлопець з Російської Федерації. Ось його профіль у LinkedIn - linkedin.com/in/vtsymbal
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.