Разница в производительности между MSVC и GCC для высоко оптимизированного матричного кода

Ответ 1

Поскольку мы рассмотрели проблему выравнивания, я бы предположил, что это: http://en.wikipedia.org/wiki/Out-of-order_execution

Так как g++ выдает отдельную инструкцию загрузки, ваш процессор может изменить порядок инструкций, чтобы предварительно получить следующие данные, которые понадобятся, а также добавление и умножение. MSVC, бросающий указатель в mul, делает нагрузку и mul привязан к одной и той же инструкции, поэтому изменение порядка выполнения команд ничего не помогает.

РЕДАКТИРОВАТЬ: сервер Intel со всеми документами сегодня менее сердитый, поэтому здесь больше исследований о том, почему выполнение вне порядка (часть) ответа.

Прежде всего, похоже, что ваш комментарий совершенно прав о том, что версия MSVC команды умножения может декодироваться для разделения μ-ops, которые могут быть оптимизированы процессором бездействия. Интересная часть здесь заключается в том, что современные микрокодовые секвенсоры программируются, поэтому фактическое поведение зависит как от аппаратного, так и от прошивки. Различия в сгенерированной сборке, по-видимому, от GCC и MSVC, каждая из которых пытается бороться с различными потенциальными узкими местами. Версия GCC пытается дать возможность выйти из строя (как мы уже рассмотрели). Тем не менее, версия MSVC заканчивается тем, что использует функцию "micro-op fusion". Это связано с ограничениями на выбывание μ-op. Окончание конвейера может только уйти в отставку по 3 μ-ops за галочку. Слияние микроопераций в отдельных случаях принимает два μ-ops, которые должны выполняться на двух разных исполнительных устройствах (например, чтение и арифметика памяти) и связывает их с одним μ-op для большей части конвейера. Сплавленный μ-op разделяется только на два реальных μ-op непосредственно перед назначением исполнительного блока. После выполнения операции ops снова сливаются, позволяя им удаляться как один.

В двигателе без порядка отображается только сплавленный μ-op, поэтому он не может вытащить нагрузку из памяти. Это приводит к зависанию трубопровода, ожидая, когда следующий операнд завершит свою поездку на автобусе.

ВСЕ ССЫЛКИ!!!: http://download-software.intel.com/sites/default/files/managed/71/2e/319433-017.pdf

http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-optimization-manual.pdf

http://www.agner.org/optimize/microarchitecture.pdf

http://www.agner.org/optimize/optimizing_assembly.pdf

http://www.agner.org/optimize/instruction_tables.ods (ПРИМЕЧАНИЕ: Excel жалуется на то, что эта таблица частично повреждена или в противном случае отрывочна, поэтому открыта на свой страх и риск. Однако она не выглядит злонамеренной, и, согласно остальным моим исследованиям, Agner Fog является удивительным. - На этапе восстановления Excel я нашел множество полных данных)

http://cs.nyu.edu/courses/fall13/CSCI-GA.3033-008/Microprocessor-Report-Sandy-Bridge-Spans-Generations-243901.pdf

http://www.syncfusion.com/Content/downloads/ebook/Assembly_Language_Succinctly.pdf

ПОСЛЕДНЕЕ ПОСЛЕДНЕЕ ИЗМЕНЕНИЕ: Вау, здесь было интересное обновление. Наверное, я ошибался в том, какая часть трубопровода на самом деле влияет на микрооперацию. Может быть, есть больше первичного усиления, чем я ожидал от различий в проверке состояния цикла, когда незадействованные команды позволяют GCC чередовать сравнение и прыгать с последней векторной нагрузкой и арифметическими шагами?

vmovups ymm9, YMMWORD PTR [rax-32]
cmp esi, edx
vmulps  ymm0, ymm0, ymm9
vaddps  ymm1, ymm1, ymm0
jg  .L4

Ответ 2

Я могу подтвердить, что использование кода GCC в Visual Studio действительно улучшает производительность. Я сделал это с помощью преобразования объектного файла GCC в Linux для работы в Visual Studio. Эффективность составляла от 50% до 60%, используя все четыре ядра (и от 60% до 70% для одного ядра).

Microsoft удалила встроенную сборку из 64-битного кода, а также сломала свой 64-разрядный дизассемблер, чтобы код не мог быть похож без изменений (но 32-разрядная версия все еще работает). Очевидно, они считали, что внутренности будут достаточными, но поскольку этот случай показывает, что они ошибаются.

Возможно, скомпонованные инструкции должны быть отдельными функциями?

Но Microsoft не единственный, который производит менее оптимальный внутренний код. Если вы поместите код ниже в http://gcc.godbolt.org/, вы увидите, что делают Clang, ICC и GCC. ICC дал еще худшую производительность, чем MSVC. Использует vinsertf128, но я не знаю почему. Я не уверен, что делает Clang, но похоже, что он ближе к GCC в другом порядке (и больше кода).

Это объясняет, почему Агнер Фог написал в своем руководстве " Оптимизация подпрограмм в сборке язык "в отношении" недостатков использования внутренних функций ":

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

Это разочаровывает случай использования встроенных функций. Это означает, что нужно либо все-таки писать 64-битный ассемблерный код, либо найти компилятор, который реализует внутренности так, как планировал программист. В этом случае только GCC, похоже, делает это (и, возможно, Clang).

#include <immintrin.h>
extern "C" void AddDot4x4_vec_block_8wide(const int n, const float *a, const float *b, float *c, const int stridea, const int strideb, const int stridec) {     
    const int vec_size = 8;
    __m256 tmp0, tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7;
    tmp0 = _mm256_loadu_ps(&c[0*vec_size]);
    tmp1 = _mm256_loadu_ps(&c[1*vec_size]);
    tmp2 = _mm256_loadu_ps(&c[2*vec_size]);
    tmp3 = _mm256_loadu_ps(&c[3*vec_size]);
    tmp4 = _mm256_loadu_ps(&c[4*vec_size]);
    tmp5 = _mm256_loadu_ps(&c[5*vec_size]);
    tmp6 = _mm256_loadu_ps(&c[6*vec_size]);
    tmp7 = _mm256_loadu_ps(&c[7*vec_size]);

    for(int i=0; i<n; i++) {
        __m256 areg0 = _mm256_set1_ps(a[i]);

        __m256 breg0 = _mm256_loadu_ps(&b[vec_size*(8*i + 0)]);
        tmp0 = _mm256_add_ps(_mm256_mul_ps(areg0,breg0), tmp0);    
        __m256 breg1 = _mm256_loadu_ps(&b[vec_size*(8*i + 1)]);
        tmp1 = _mm256_add_ps(_mm256_mul_ps(areg0,breg1), tmp1);
        __m256 breg2 = _mm256_loadu_ps(&b[vec_size*(8*i + 2)]);
        tmp2 = _mm256_add_ps(_mm256_mul_ps(areg0,breg2), tmp2);    
        __m256 breg3 = _mm256_loadu_ps(&b[vec_size*(8*i + 3)]);
        tmp3 = _mm256_add_ps(_mm256_mul_ps(areg0,breg3), tmp3);   
        __m256 breg4 = _mm256_loadu_ps(&b[vec_size*(8*i + 4)]);
        tmp4 = _mm256_add_ps(_mm256_mul_ps(areg0,breg4), tmp4);    
        __m256 breg5 = _mm256_loadu_ps(&b[vec_size*(8*i + 5)]);
        tmp5 = _mm256_add_ps(_mm256_mul_ps(areg0,breg5), tmp5);    
        __m256 breg6 = _mm256_loadu_ps(&b[vec_size*(8*i + 6)]);
        tmp6 = _mm256_add_ps(_mm256_mul_ps(areg0,breg6), tmp6);    
        __m256 breg7 = _mm256_loadu_ps(&b[vec_size*(8*i + 7)]);
        tmp7 = _mm256_add_ps(_mm256_mul_ps(areg0,breg7), tmp7);    
    }
    _mm256_storeu_ps(&c[0*vec_size], tmp0);
    _mm256_storeu_ps(&c[1*vec_size], tmp1);
    _mm256_storeu_ps(&c[2*vec_size], tmp2);
    _mm256_storeu_ps(&c[3*vec_size], tmp3);
    _mm256_storeu_ps(&c[4*vec_size], tmp4);
    _mm256_storeu_ps(&c[5*vec_size], tmp5);
    _mm256_storeu_ps(&c[6*vec_size], tmp6);
    _mm256_storeu_ps(&c[7*vec_size], tmp7);
}

Ответ 3

MSVC сделал именно то, что вы просили. Если вы хотите, чтобы команда vmovups испускалась, используйте встроенный _mm256_loadu_ps.