Оптимизация кода для платформы Эльбрус на простых примерах

    "Обычно хакер пишет программы не ради выгоды,
    а ради собственного удовольствия. Такая программа
    может оказаться полезной, а может остаться
    всего лишь игрой интеллекта."
    Генри С. Уоррен. Алгоритмические трюки для программистов [1]


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


    image


    Однажды мы с коллегами заинтересовались, как самые простые методы оптимизации работают на Эльбрусе.


    Процессор Эльбрус имеет VLIW (Very Long Instruction Word) архитектуру — то есть оперирует “широкими” командными словами. Это означает, что компилятор lcc анализирует исходный код программы при компиляции, определяет зависимости между командами и формирует широкие командные слова. В одном таком слове можно уместить до 23 действий, которые будут исполняться одновременно. Если использовать SIMD (Single Instruction Multiple Data), то это число может возрасти до 33 и более операций. Команды в широком слове исполняются параллельно, обеспечивая загрузку всех 6 арифметико-логических устройств на каждом процессоре. Распараллеливание и загрузка всех вычислителей целиком ложится на плечи оптимизирующего компилятора, что позволяет значительно упростить аппаратуру для анализа и исполнения команд и снизить энергопотребление до 45 Вт для Эльбрус-4С [2, 3].


    Мы в Smart Engines задались вопросом, как будут работать все привычные оптимизации, такие как, например, развертывание циклов, на столь непривычной платформе с “умным” компилятором.


    Мы рассмотрели простые примеры на С++ и сравнили результаты работы на Эльбрус-4С и Intel Core i7-6700K. На Эльбрусе использовался компилятор lcc версии 1.20.17, для Core i7 — Microsoft Visual Studio Community 2015. Для lcc мы использовали флаги компиляции -O3 и -ffast-math.


    Для начала, приведем характеристики Эльбрус-4С и Intel Core i7-6700K:


    Эльбрус-4С Intel Core i7-6700K
    Архитектура Эльбрус Skylake-S
    Частота, GHz 0.8 4
    Число ядер 4 4 (8 c Hyper-Threading)
    Технологический процесс 65 nm 14 nm
    Cache L1 size, data 64 Kb 32 Kb
    Cache L1 size, instructions 128 Kb 32 Kb
    Cache L2 size 8 Mb 1 Mb
    Cache L3 size - 8 Mb
    Тип оперативной памяти DDR3-1600 DDR4-2133
    Потребляемая мощность, Вт 45 91

    Тактовая частота этих процессоров значительно отличается: 800 МГц у Эльбрус-4С и 4 ГГц у Intel Core i7. Также заметим, что Эльбрус имеет другую структуру кэш-памяти: отсутствует L3 кэш, однако размер L2 кэша составляет 8 Mb (по 2 Mb на ядро), в то время как у рассмотренного Core­ i7 1 Mb (по 0.25 Mb на ядро). L1 кэш на Эльбрусе также больше, особенно кэш инструкций (128 Kb против 32 Kb).


    Пример 1. Развертывание циклов


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


    Теперь рассмотрим пример:


    #define N 64000
    unsigned int x = 0;
    unsigned int a[N];
    for (int i = 0; i < N; ++i)
      a[i] = i;
    //Оптимизируемый цикл
    for (int k = 0; k < N;)
    {
      x += a[k];
      a[k++] = k;
    }

    Последний цикл мы и попробовали развернуть. Результаты замеров времени (для 10000 итераций цикла) приведены в таблице 1. Стоит отметить, что на Эльбрусе использовался 32-битный режим адресации (флаг компилятора -mptr32). Мы также рассчитали время работы на 1 ГГц путем умножения измеренного времени на тактовую частоту процессора в ГГц. Полученная таким образом безразмерная величина позволяет сравнить производительность Эльбрус и Core i7 с учетом различия в тактовой частоте.


    Таблица 1. Время работы в зависимости от N — числа развернутых итераций.


    Эльбрус-4С Эльбрус-4С Intel Core i7 Intel Core i7
    N Время, мс Время в пересчете на 1 ГГц Время, мс Время в пересчете на 1 ГГц
    1 401 320 255 1020
    2 400 320 275 1100
    4 401 320 261 1044
    8 401 320 247 988
    16 401 320 361 1444
    32 452 362 262 1048
    64 451 362 262 1048

    Можно видеть, что развертывание цикла в данном примере не дает выигрыша во времени работы как на современном Core i7, так и на Эльбрус-4С. В случае совсем простого цикла, который мы рассмотрели, Эльбрус-4С работает эффективнее Core i7 с учетом отношения частот.


    Пример 2. Обработка данных различной длины


    В этом примере мы обрабатываем массив по 1, 4 или 8 байтам. Исходный массив а был выровнен на 8 байт.


    #define MASK1  0xF1
    #define MASK4 0xF1F2F3F4
    #define MASK8 0xF1F2F3F4F5F6F7F8
    
    for (k = 0; k < n; ++k)
    {
      а[k] &= MASK1;
    }

    Результаты замеров времени приведены в таблице 2.


    Таблица 2. Время работы в зависимости от N — числа обрабатываемых байт.


    Эльбрус-4С Эльбрус-4С Intel Core i7 Intel Core i7
    N Время, мс Время в пересчете на 1 ГГц Время, мс Время в пересчете на 1 ГГц
    1 2400 1920 811 3244
    4 600 480 201 804
    8 300 240 102 408

    Можно видеть, что обработка по 4 и 8 байт работает быстрее как на современном Core i7, так и на Эльбрус-4С, причем времена уменьшаются кратно числу обрабатываемых байт. Кроме того, Эльбрус работает эффективнее Core i7 с учетом отношения частот.


    Пример 3. Использование SIMD


    В этом примере мы решили протестировать интринсики и рассмотрели вычисление скалярного произведения чисел типа float при n = 12800.
    Неоптимизированный цикл:


    float result = 0.0;
    for (int i = 0; i < n; ++i)
    {
      result += x[i] * y[i];
    }

    С использованием SSE:


    float *pX = x;
    float *pY = y;
    __m128 Sum = _mm_setzero_ps();
    int num = n / 4;
    for (int i = 0; i < num; ++i, pX += 4, pY += 4)
    {
      Sum = _mm_add_ps(Sum, _mm_mul_ps(_mm_load_ps(pX), _mm_load_ps(pY)));
    }
    float result = _mm_extract_ps(Sum, 0) + _mm_extract_ps(Sum, 1) + _mm_extract_ps(Sum, 2) + _mm_extract_ps(Sum, 3);

    С использованием EML [4] (оптимизированная библиотека под Эльбрус):


    double result;
    eml_Vector_DotProd_32F(x, y, n, &result);

    Результаты замеров времени приведены в таблице 3. Размер SIMD-регистра на Эльбрус-4С составляет 64 бита (instruction set версии 3), что в общем-то соответствует наблюдаемому ускорению в 2 раза между версией без оптимизаций и версией с SIMD. На Core i7 все тоже довольно правдоподобно, мы оперировали 128-битными регистрами, в которые помещается 4 числа типа float. Кроме того, заметно, что Эльбрус без интринсиков работает эффективнее Core i7 с учетом частоты, а вот с интринсиками времена работы практически совпадают.


    Таблица 3. Время работы подсчета скалярного произведения.


    Эльбрус-4С Эльбрус-4С Intel Core i7 Intel Core i7
    Время, мс Время в пересчете на 1 ГГц Время, мс Время в пересчете на 1 ГГц
    Без оптимизации 263 210 99 396
    С SIMD 110 88 24 96

    Пример 4. Подсчет расстояния Хэмминга между двумя массивами


    Здесь мы вычисляли расстояние Хэмминга между двоичным представлением двух массивов, т.е. взяли расстояния Хэмминга между двоичными представлениями соответствующих чисел в массивах и нашли их сумму. Для массивов с 8-битными данными мы использовали побитовое ИСКЛЮЧАЮЩЕЕ ИЛИ и предподсчитанную таблицу расстояний:


    int result = 0;
    for (int i = 0; i < n; ++i)
    {
      result += popcnt_table[x[i] ^ y[i]];
    }

    Для 32- и 64-битных данных мы использовали побитовое логическое ИСКЛЮЧАЮЩЕЕ ИЛИ и интринсики _mm_popcnt_u32, _mm_popcnt_u64 на Intel и интринсики __builtin_e2k_popcnts, __builtin_e2k_popcntd на Эльбрусе. Общая длина массивов x и y в байтах оставалась неизменной и равной n = 512. Результаты замеров времени приведены в таблице 4.


    Таблица 4. Время подсчета расстояния Хэмминга в зависимости от числа обрабатываемых байт N.


    Эльбрус-4С Эльбрус-4С Intel Core i7 Intel Core i7
    N Время, мс Время в пересчете на 1 ГГц Время, мс Время в пересчете на 1 ГГц
    1 630 504 155 620
    4 110 88 47 188
    8 76 61 15 60

    В этом примере мы видим, что интринсики для подсчета числа единиц в 64-битном и 32-битном регистрах и на Эльбрусе, и на Core i7 дают значительное ускорение относительно версии с предподсчитанной таблицей. Кроме того, 32-битная команда popcnt на Эльбрусе работает быстрее, чем на Core i7 с учетом отношения частот. А вот в 64-битной случае времена работы на Core i7 и Эльбрусе сравнялись.


    Пример 5. Устранение зависимости по данным


    Данный пример позаимствован из книги Криса Касперски “Техника оптимизации программ. Эффективное использование памяти” [5]. Он демонстрирует, как устранение зависимости по данным помогает повысить производительность. Массив a заполнен нулями, n = 2097152.
    Пример с зависимостью по данным:


    int x = 0;
    for (size_t a = 0; a < BLOCK_SIZE; a += 8 * sizeof(int))
    {
            x = *(int *)((char *)p1 + a + 0 * sizeof(int));
            a += x;
            x = *(int *)((char *)p1 + a + 1 * sizeof(int));
            a += x;
            x = *(int *)((char *)p1 + a + 2 * sizeof(int));
            a += x;
            x = *(int *)((char *)p1 + a + 3 * sizeof(int));
            a += x;
            x = *(int *)((char *)p1 + a + 4 * sizeof(int));
            a += x;
            x = *(int *)((char *)p1 + a + 5 * sizeof(int));
            a += x;
            x = *(int *)((char *)p1 + a + 6 * sizeof(int));
            a += x;
            x = *(int *)((char *)p1 + a + 7 * sizeof(int));
            a += x;
    }

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


    int x = 0;
    for (size_t a = 0; a < BLOCK_SIZE; a += 8 * sizeof(int))
    {
            x += *(int *)((char *)p2 + a + 0 * sizeof(int));
            x += *(int *)((char *)p2 + a + 1 * sizeof(int));
            x += *(int *)((char *)p2 + a + 2 * sizeof(int));
            x += *(int *)((char *)p2 + a + 3 * sizeof(int));
            x += *(int *)((char *)p2 + a + 4 * sizeof(int));
            x += *(int *)((char *)p2 + a + 5 * sizeof(int));
            x += *(int *)((char *)p2 + a + 6 * sizeof(int));
            x += *(int *)((char *)p2 + a + 7 * sizeof(int));
    }

    Результаты замеров времени приведены в таблице 5. Устранение зависимости по данным работает как на Эльбрусе, так и на Core i7, причем на Core i7 время работы различается примерно в 11 раз, а на Эльбрусе — практически в 20! Код с зависимостью по данным отработал на Эльбрусе медленнее, чем на Core i7 в пересчете на 1 ГГц, а вот без зависимости Эльбрус всего в 4 раза медленнее Core i7 (при различии частот в 5 раз). Такие результаты на Эльбрусе можно объяснить наличием механизма асинхронной подкачки массивов (array prefetch buffer), которая работает эффективно, если подкачиваемые элементы располагаются последовательно.


    Таблица 5. Время чтения зависимых и независимых данных.


    Эльбрус-4С Эльбрус-4С Intel Core i7 Intel Core i7
    Время, мс Время в пересчете на 1 ГГц Время, мс Время в пересчете на 1 ГГц
    Зависимые данные 605 484 87 348
    Независимые данные 32 26 8 32

    Пример 6. Многопоточные вычисления


    Разумеется, мы не могли не рассмотреть такой метод оптимизации, как распараллеливание. Для чистоты эксперимента мы взяли полностью независимые задачи (вычисление скалярного произведения двух массивов типа double). В таблице 6 приведено время последовательной работы N задач (Tпосл), время работы N задач в N потоков (Tпар) и ускорение E:


    Таблица 6. Время последовательного и параллельного вычисления скалярного произведения в зависимости от числа задач и потоков N.


    Эльбрус-4С Эльбрус-4С Эльбрус-4С Intel Core i7 Intel Core i7 Intel Core i7
    N Tпосл, мс Tпар, мс E=Tпосл/Tпар Tпосл, мс Tпар, мс E=Tпосл/Tпар
    2 2628 1316 2.00 1033 500 2.07
    4 5259 1318 3.99 1994 500 3.99
    8 10513 2634 3.99 3987 503 7.93
    16 21045 5268 4.00 7980 1009 7.91
    20 26321 6583 4.00 9967 1263 7.89
    32 42053 10535 3.99 15948 2014 7.92
    40 52566 13170 3.99 19936 2528 7.89

    Видно, что на Core i7 ускорение практически в 8 раз достигается на 8 потоках и дальше варьируется незначительно. На Эльбрусе ускорение в 4 раза достигается на 4 потоках и также с увеличением числа потоков не меняется. Соотношение по скорости между Эльбрус и Core i7 оказалось равным примерно 2.6, в то время как отношение частот равно 5.


    Выводы


    Привычные методы ускорения вычислений вполне работают на Эльбрусе и в этом плане программирование для него не требует специфических знаний и умений. В рассмотренных элементарных примерах для оптимизации кода Эльбрус показал себя просто замечательно с учетом тактовой частоты в 800 МГц и в два раза меньшей потребляемой мощности по сравнению с Core i7.


    P.S. А еще мы запустили нашу систему распознавания паспорта на SPARC! Это означает, что теперь мы сможем писать статьи о распознавании на еще одной вычислительной архитектуре.


    Update. В результаты примера 1 вкралась ошибка, благодаря комментариям VLev мы ее обнаружили и исправили. Результаты обновлены.


    Использованные источники


    [1] Генри С. Уоррен, мл. Алгоритмические трюки для программистов. М.: Издательский дом "Вильямс", 2014. ISBN 978-5-8459-1838-3 – 512 С.
    [2] http://www.elbrus.ru/arhitektura_elbrus.
    [3] http://www.mcst.ru/mikroprocessor-elbrus4s.
    [4] http://www.mcst.ru/vysokoproizvoditelnye_biblioteki.
    [5] Крис Касперски. “Технологии оптимизации программ. Эффективное использование памяти”. Спб.: БХВ-Петербург, 2003. ISBN 5-94157-232-8 – 464 С.

    Smart Engines
    89,00
    Обработка изображений, распознавание в видеопотоке
    Поделиться публикацией

    Комментарии 86

      +9
      А почему вы прересчитываете на ГГц процессора? У компьютеров и память разная. Тот же 2й тест — я думаю он упирается не в частоту а в память.
        0
        Мы не учитывали различия по памяти, поскольку у Эльбрус-4С и Core i7 не только разная скорость ОЗУ, но и разная структура кэш-памяти, алгоритмы кэширования, есть array prefetch buffer на Эльбрус. Поэтому мы использовали более наглядную и простую характеристику.
          +5

          У них не только память разная, у них разные архитектуры. Было бы удивительно, если бы архитектура VLIW давала меньшую производительность на такт в задачах, которые явно хорошо параллелятся.


          Логичнее сравнивать отношение производительности к потребляемой мощности, но Эльбрус проиграет.

          +3
          А Вы учитываете, что у современных Intel частота сильно плавающая? К примеру у меня на i5-6600K она при небольшой нагрузке опускается до 800 МГц, в то время как при нагрузке включается еще и TurboBoost.
          и в два раза меньшей потребляемой мощности по сравнению с Core i7

          Это распространенное заблуждение, TDP у Intel очень часто далёк от реального потребления. К примеру, у того же i5-6600K тоже TDP 91 Вт, получается они одинаково «едят»? Так что сравнивать по TDP бессмысленно. Тем более, что TDP для Intel учитывает ещё и встроенную видяху, чего у Эльбруса нет. Вы бы ради интереса взяли померили потребление от розетки для системы
            0
            Действительно, энергопотребление мы сравнивали только по TDP, что не совсем корректно, и было бы интересно измерить реальную потребляемую мощность. Возможно мы проведем и такой эксперимент. TurboBoost при замерах мы отключили.
              +1
              TDP для Intel учитывает ещё и встроенную видяху

              Он вообще не понятно что учитывает, потому что мой 4790K по паспорту имеет TDP 88 Вт, а по факту в FPU stress test потребляет 120 Вт. И это без учета встроенного видео.

                +1
                Из вики: Требования по теплоотводу (TDP) показывают не максимальное теоретическое тепловыделение процессора, а лишь требования к производительности системы охлаждения.

                FPU stress test это не типичная нагрузка для процессора, поэтому давно не указывают максимальное потребление процессора. Он его почти никогда не достигает, кроме как в таких тестах, в которых нет ожидания памяти и вся работа только через кэш или даже просто регистры, т.е. никаких простоев, максимум нагрузки.
              +6
              Есть же штатные тулы для сравниения быстродействия — SPEC 2000/2006 CPU, зачем изобретать синтетические велосипеды?
              + Все примеры на счетные циклы, что явно не слишком репрезентативно.
              + Среди примеров нет ни одного с ветвлениями внутри цикла.
              P.S. Всегда умиляла любовь поклонников Эльбруса нормировать показатели на частоту.
                0
                Цель данного поста не сравнить производительность Эльбрус и Core i7, для этого наши примеры не очень подходят. Мы хотели показать, что несмотря на VLIW-архитектуру Эльбруса и написанный специально для нее оптимизирующий компилятор, простые методы оптимизации на нем работают также, как и на Core i7, и в этом смысле разработка программ для Эльбруса не требует дополнительных затрат на специфичную оптимизацию.
                  +12
                  Цель данного поста не сравнить производительность Эльбрус и Core i7

                  Ага, и в каждом примере шаблонные строчки


                  Пример 1. В случае совсем простого цикла, который мы рассмотрели, Эльбрус-4С работает значительно эффективнее Core i7 с учетом отношения частот.

                  Пример 2. Кроме того, Эльбрус работает эффективнее Core i7 с учетом отношения частот.

                  Пример 3. Кроме того, заметно, что Эльбрус без интринсиков работает эффективнее Core i7 с учетом частоты, а вот с интринсиками времена работы практически совпадают.

                  Пример 4.Кроме того, 32-битная команда popcnt на Эльбрусе работает быстрее, чем на Core i7 с учетом отношения частот. А вот в 64-битной случае времена работы на Core i7 и Эльбрусе сравнялись.

                  Пример 5 Код с зависимостью по данным отработал на Эльбрусе медленнее, чем на Core i7 в пересчете на 1 ГГц, а вот без зависимости Эльбрус всего в 4 раза медленнее Core i7 (при различии частот в 5 раз).

                  Пример 6 Соотношение по скорости между Эльбрус и Core i7 оказалось равным примерно 2.6, в то время как отношение частот равно 5.

                  Кстати, тут неправда. Вы подменяете сравнение производительности процессоров сравнением мощности ядер, но у i7 8 виртуальных ядер и при большом количестве потоков он работает в 2.6*2 = 5.2 раз быстрее. (например, в параллельном варианте для n=32 у вас время больше 10 сек для Эльбруса и всего лишь 2 сек для i7)


                  рассмотренных элементарных примерах для оптимизации кода Эльбрус показал себя просто замечательно с учетом тактовой частоты в 800 МГц и в два раза меньшей потребляемой мощности по сравнению с Core i7

                  Вы всю статью хвалите Эльбрус и во все таблицы пихаете отнормированные на частоту числа, вы бы ещё на "подгоночный коэффициент" их домножали, оно быть хоть честнее было.


                  Если бы целью было сравнение эффектов от оптимизаций, можно было бы неоптимизированный вариант брать за эталон и с ним уже сравнивать: "вот, такие-то действия ускоряют программу в 9 раз на i7 и в 20 раз на Эльбрусе".

                    0
                    В том то и вопрос, что данные тесты изначально достаточно неплохо ложатся на VLIW. Если говорить про SPEC, то там есть примеры другого класса, например gcc или perl, где поток управления превалирует над числодробительными цикловыми вычислениями.
                      0
                      По Эльбрус-4С уже опубликовано немало обзоров с результатами более или менее стандартных тестов производительности, 7-zip сжатие/распаковка, например. Для Эльбрус-2С+ есть результаты на SPEC 2000 на сайте МЦСТ. Поскольку мы занимаемся обработкой изображений и распознаванием, нам интереснее рассматривать профильные для нас задачи, которые довольно просто распараллеливаются и хорошо подходят для VLIW-архитектур.
                        +3

                        А что скажет конечный пользователь системы?
                        Ничего страшного что я подождал результата в 2,6-10 раз дольше на Эльбрусе, чем на iCore, ведь в переводе на частоту, Эльбрус всё равно быстрее?


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


                        Но если говорить о рамках пограничного контроля в аэропортах с большим потоком — то уж лучше iCore. Любой простой и любая задержка стоят денег.
                        Брюссель
                        Осло

                  0
                  Надо сравнивать деньги и время, необходимые для расчета одной и той же задачи.
                  Мне из статьи не стало понятнее, существуют ли задачи, в которых совокупная стоимость владения…
                  Электричество = деньги.
                  Железо = деньги.
                  Время = деньги.
                    0
                    Разница в цене на порядок, если не ошибаюсь
                    +1

                    Я всё жду того когда они откроют свои форки gcc и glibc как того требует лицензия. Тогда и будет понятнее про оптимизации и прочее.

                      0
                      А кто говорил про gcc на Эльбрусе? У них свой компилятор.
                        0
                        Так только слухи и есть. Как раз пишут что у них форк gcc. Хотя сейчас уже логичнее llvm пилить во всю.
                          0
                          У них свой компилятор, именуют они его не иначе как lcc. Фронтенд у него с gcc по большей части совместим, бэкенд свой. По glibc же напишите им запрос соответствующий, будет интересно узнать что напишут в ответ.
                            +2

                            lcc и есть форк gcc даже если не полностью то куски от туда они взяли… GPL лицензия требует открытие всего проекта если вы хоть что то взяли от GPL.
                            Про glibc, gcc они уже отвечали что "мы типо пилим для военных и мы чихали на ваш GPL".
                            Кроме того они правили Mesa, DRM и т.д. то же без фидбека сообществу. Короче пока они будут красть чужой труд я однозначно против их конторы. (пару раз был у них в гостях к слову пока учился в универе)

                              0
                              У них модифицированный lcc, а не gcc.
                                0

                                Дык это только Си а у них есть поддержка C++.

                                  +1
                                  По словам разработчиков Эльбруса у них полностью свой бэкенд компилятора, а фронтенд от компании EDG (к слову точно такой же фронтенд использует компилятор Intel, но его почему то форком GCC никто не называет).
                                    0
                                    Значит я ошибся.
                              0
                              По слухам, ллвм они пилят, но пока все в очень ранней стадии
                                +3
                                Им надо всё открывать и выпускать(думаю не без гос.поддержки) что-то вроде Raspberry Pi с минимальным процессором, ну и не дорого распродать. Тогда в стране появятся люди знакомые с архитектурой. И дело с инструментарием пойдёт и развитие побыстрее. Наверно. Иначе это всё так и останется в печальном состоянии, а жаль.Свой процессор это здорово, я бы и сам поковырялся.
                          0
                          Замечание по таблице. Сейчас данные располагаются так:

                          Эльбрус абс | Эльбрус/ГГц | Intel абс | Intel/ГГц

                          Но ведь сравнение идет между Эльбрусом и Intel, а не между Эльбрус абс и Эльбрус/ГГц. Последнее всегда дает отношение 0.8, зачем держать эти колонки вместе. Правильный порядок:

                          Эльбрус абс | Intel абс | Эльбрус/ГГц | Intel/ГГц

                          Что касается перерасчета на ГГц. А зачем это вообще? Ну так, забавный факт, который не имеет реального применения. У вас есть задача, есть ресурсы: кол-во процессоров/денег на процессоры либо киловатты энергии. Т.е. имеет смысл знать реальное время и перерасчет на стоимость или потребление. Но перерасчет на какие-то внутренние технические характеристики ничего полезного не дает.
                            0
                            Хотел бы заметить, что метрика на МГц или ГГц более правильная чем просто метрика производительности для процессоров изготовленных по разным топонормам, ведь очевидно, что переход на новую топонорму сделает процессор более производительным, поэтому на МГц это более точная метрика, но она всё равно очень долека от правды. К примеру, такой комментарий в аналогичной статье: https://habrahabr.ru/post/307512/#comment_9748816
                            Народу, безусловно, интересен потенциал архитектуры, а не конкретно этот камень, поэтому было бы логичным сравнить с топовым процессором от Intel на архитектуре 65нм, предлагаю два варианта:
                            Intel Pentium EE 955 3,46 ГГц. Presler
                            Intel Core 2 Quad Q6700 2,67 ГГц Kentsfield
                            оба 65нм второй вышел позже и как раз харктеризуется тем что метрика на ГГц тут будет не корректна, потому что производиельность у него должна быть не ниже. Вот хотелось бы узнать сравнение именно с этими процессорами. А так же ключевой вопрос (к эльбрусовцам): когда Эльбрус-8С выйдет, который до конца 2015г. «сделан»?
                            http://mcst.ru/vosmiyadernyj-mikroprocessor-s-arkhitekturoj-elbrus
                              +1
                              Так 8С и сделан. Сейчас тестируются предсерийные материнки с процессором, т. е. уже готовая платформа со всей обвязкой. Во втором квартале 2017 уже серийные системы на 8С, скорее всего даже на 8С1, уже будут в продаже. В общем, как я понимаю, то самая свежая инфа будет вот тут на тытрубе точно:

                              С учётом того что уже показали чип выглядит хорошо.
                              P.S. канал, можно сказать, первоисточник.
                              P.P.S. посмотрим какой ценник будет и какие условия для продажи серийных машин.
                              0
                              del, не туда. прошу прощения.
                              +2
                              Ну серьёзно, полное игнорирование тестов SPEC наводит на плохие мысли. Когда уже сделаете?

                              И раз уж тут про оптимизацию, где купить попробовать и где взять компилятор? У МЦСТ всё ведь закрыто. Зачем статья если её вообще не к чему применить? Интереснейший проект и всё закрыто.

                              Тем кто понимает про архитектуры процессов и так всё это знают — дайте тесты! В конце концов Intel Itanium тот же VLIW. А для него куча всего доступно.
                                0
                                Itanium не умер? :)
                                  0
                                  Чего вдруг.
                                    0
                                    А, это видимо я слышал звон об:
                                    Windows XP 64-bit Edition — это издание разрабатывалось специально для рабочих станций с архитектурой IA-64 и микропроцессорами Itanium. Это издание Windows XP более не развивается с 2005 года, после того, как HP прекратил разработку рабочих станций с микропроцессорами Itanium.
                                    :)
                                  0
                                  Вот +1 ну и где доступ к железу? Ладно, не могут продавать и раздавать компиляторы, не надо! Но блин, есть же доступ по сети!!! Просто давали бы терминальный доступ интересующимся, чтобы скомпилить, запустить, потестить хоть что нибудь.
                                  0
                                  А можно расскладку производительность на ватт? А то в пересчетах на гигагерцы 65 нанометров выглядит, наверное — не плохо…
                                    –1
                                    Мыши плакали, кололись, но продолжали жрать кактус
                                      +1
                                      Почему-то смотря на вашу аватарку, не могу сдержать смех с коммента.
                                      +6
                                      1. Нормировка к частоте это пустой звук, т.к. Эльбрус именно из за своей архитектуры никогда не достигнет частоты i7.
                                      2. SSE для i7? Серьезно? А теперь давайте возьмем AVX2+FMA.
                                      3. Где результат для сравнения EML vs MKL?
                                      4. Где результат для double операций?
                                        0
                                        на Эльбрусе использовался 32-битный режим адресации
                                        и
                                        Можно видеть, что обработка по 8 байт работает быстрее на Эльбрус-4С

                                        То есть в 32 разрядной ОС Эльбрус сможет работать с 64 байтными числами нативно? :)
                                        Интелы (x86) вроде так не умеют. :)
                                          0
                                          А x86 тут причём? Это же российский Itanium.
                                            0
                                            Блеать, конкурент! :)
                                              0
                                              Ну не смешно, процессор-то хороший. Надо только правильно подавать. Будущее у него может быть вполне приличное.
                                                0
                                                Так я серьезно и рассматриваю его как конкурента.
                                                В т. ч. и x86, и Itanium. :)
                                                Думаю на него Win XP поставить. :)
                                                  0
                                                  Сейчас это очень дорого и очень сложно.
                                            0
                                            ОС Эльбрус 64-разрядная, однако можно принудительно включить для приложения 32-разрядную адресацию с помощью флага компилятора -mptr32. Обработка по 8 байт работает быстро в дефолтном, 64-разрядном режиме.
                                            0
                                            Эльбрус без интринсиков работает эффективнее Core i7 с учетом частоты, а вот с интринсиками времена работы практически совпадают.

                                            В вебе (nginx | php7 | mysql 5.7) используется simd-арифметика или обычная? :)
                                            Вроде больше текст (обычная целочисленная?).
                                            Было бы выгодно их использовать в веб-серверах. :)

                                            Какая максимальная частота Эльбруса? :)

                                            Какие цены по сравнению с примерно равным по производительности Интелом? :)

                                            Есть поддержка последних линуксов? :)
                                              0
                                              С сайта Эльбруса:
                                              Качество эмуляции архитектуры х86 подтверждается успешным запуском на платформе Эльбрус более 20 операционных систем (в том числе несколько версий Windows) и сотен приложений.

                                              А есть ли нативная поддержка? :)
                                              И какой оверхед эмуляции? :)

                                              Стоит отдельно отметить, что в настоящее время вирусов для платформы «Эльбрус» просто не существует.

                                              И даже в режиме эмуляции? :)
                                                0
                                                Накладные расходы эмуляции видимо незначительные, так как 300 МГц проц сделал 500 МГц Pentium M. :)

                                                С вики о планах на будущее в 2009 (2013?) году (офф сайт):
                                                «Эльбрус-8С» — 250 ГФлопс, 28 нм к 2015 г. — восьмиядерный микропроцессор с архитектурой Эльбрус.
                                                Вышла чуток задержка, на оф. сайте его еще нет. :)
                                                0
                                                С их осью доводилось недавно сталкиваться.
                                                Их железо раздобыть не так просто, правда у них есть виртуалки с возможностью компиляции исходников под платформу эльбруса, но опять же это обычные привычные нам дистрибутивы линуха для x86.
                                                Сама ось Эльбрус последних версий — релиз Debian с вполне неплохим набором пакетов хотя и не очень полным. Правда крупные пакеты они собирают сами из исходников и там наблюдаются проблемы с тем как могут быть расположены скрипты, конфиги и прочее. К примеру сборка апача меня удивила тем, что привычных a2ensite и иже с ним не было, зато был один здоровый конфигурационный файл) И таких мелочей довольно много.
                                                Правда есть и плюсы. У них есть багтрекер где они вполне лояльно относятся к замечаниям и вполне адекватно реагируют.
                                                0
                                                Intel Core i7
                                                Число ядер 4 (8 c Hyper-Threading)

                                                при N = 8 показал ускорение в 8 раз.
                                                То есть при N = 4 процессор был загружен не на 100%? :)
                                                Или на 100%, но нашлись дополнительные вычислительные блоки для Hyper-Threading? :)

                                                Соотношение по скорости между Эльбрус и Core i7 оказалось равным примерно 2.6, в то время как отношение частот равно 5.

                                                А почему тут не приводили к 1 ГГц? :)
                                                  +7
                                                  Можно видеть, что развертывание циклов работает как на современном Core i7, так и на Эльбрус-4С. В случае совсем простого цикла, который мы рассмотрели, Эльбрус-4С работает значительно эффективнее Core i7 с учетом отношения частот.

                                                  Кобыла может тянуть телегу со скоростью 8 км/ч, автомашина может ехать со скоростью 180 км/ч. Мощность кобылы — 1 л.с, мощность двигателя автомашины — 308 л.с. С поправкой на мощность, кобыла эффективнее в 13,7 раз
                                                    –1
                                                    1. Кобыла может проехать там, где ваши 308 л.с. застрянут, хоть их и 308 :)
                                                    2. Кобыла может ехать и больше 8 км/ч. :)
                                                    3. Кобыла обходится условно бесплатно.
                                                    4. Расскажите это жителям моего села, что им нужна машина 308 л.с., а не кобыла. :)
                                                    5. Кобылу можно использовать и как легковик (верхом) и как грузовик (с телегой). :)
                                                    6. Не под каждую машину запрежешь плуг. Как-то глупо орать поле Жигулем, а тем более Бентли. :)
                                                      +3
                                                      Это демагогия уровня «раньше компьютеров не было и жить было лучше» (с) моя бабушка
                                                        –2
                                                        Почему же демагогия. :)

                                                        Или ты уже электричество употребляешь вместо еды? :)

                                                        Или ты в лес по грибы поедешь на Бентли? :)

                                                        Кстати, с твоей бабушкой можно частично и согласиться.
                                                        Не было компов — не было и проблем с компами, ну люди выходили на улицу. :)

                                                        А так да, можно залипать в компе.
                                                        У меня открыли были интернет клуб когда-то. Так один чувак там все летние каникулы провел, а потом говорил — «ах какие афигенные у миня каникулы были» :)

                                                        Я ж не спорю, что есть плюсы и у авто (как бы несомненные, поэтому и не описывал их, можете сделать это Вы :) ).
                                                        Просто не нужно так надменно смотреть на коня. :)
                                                        И для коня найдем применение.
                                                        0
                                                        по третьему пункту вроде кобыла стоит как ферарри, не?
                                                      0
                                                      А почему все еще 65нм? Или его разрешено производить только в России? Очень бы хотелось увидеть это чудо на 22нм хотя бы и еще меньше. Ну и на больших частотах. Заказать изготовление на стороне нельзя?
                                                        0
                                                        Не всё сразу. На вики со ссылкой на некий документ «Российские технологии «Эльбрус» для пер-
                                                        сональных компьютеров» пишут, что «к 2020 году планирует[ся] выпускать 14-нм процессор Эльбрус-32С». Нужно ещё четыре годика подождать. Не дешёвое это дело — уменьшать нанометры. Technologic gap в два прыжка не перепрыгнуть.

                                                        Заказать изготовление на стороне нельзя?


                                                        Во-первых, сама идея Эльбрусов заключается в том, чтобы своё и себя делать. Если заказывать — то легче сразу готовые процессоры закупать. Во-вторых, как я понимаю, Эльбрусы использует во многом военка. А там народ строгий — ану как враг прослушки какие-то в процессоры засунет. Поэтому, думаю, такое решение проблемы не подойдёт.

                                                        Надеюсь, автор статьи поправит если чего-то не так сказал.
                                                          +1
                                                          Эльбрусы как раз на стороне и делают. В России только 90 нм пока освоили…
                                                            0

                                                            Закупили списанное оборудование AMD.

                                                        +1
                                                        В такой простой синтетике обычно сравнивают не разные процессоры, а достигнутую производительность с теоретически возможной.
                                                        Сооветственно, как интерпретировать приведённые результаты?
                                                        вот берём «Пример 1. Развертывание циклов»
                                                        результат для i7: Время, мс 5-255.
                                                        Это что, 64000 итераций такого простого цикла много миллисекунд считаются? — как-то очень сомнительно.
                                                        Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию, т.е. ждём время исполнения этого кода существенно меньше одной миллисекунды (что не так-то просто и померить, кстати ;)).

                                                        Короче, взял Ваш код, обернул тестируемый цикл во внешний с числом итераций 100000 (дабы привести время к человеческим временам, а заодно и исключить краевые эффекты, типа непрогретого кэша), и прогнал на Intel® Core(TM) i5-4460 CPU @ 3.20GHz
                                                        результаты
                                                        $ g++ -O3 -o t1 t1.cpp; time ./t1

                                                        real 0m0.973s
                                                        user 0m0.968s
                                                        sys 0m0.000s
                                                        $ g++ -O2 -o t1 t1.cpp; time ./t1

                                                        real 0m2.834s
                                                        user 0m2.828s
                                                        sys 0m0.000s
                                                        $ g++ -O1 -o t1 t1.cpp; time ./t1

                                                        real 0m2.796s
                                                        user 0m2.792s
                                                        sys 0m0.000s
                                                        $ g++ -O0 -o t1 t1.cpp; time ./t1

                                                        real 0m14.453s
                                                        user 0m14.444s
                                                        sys 0m0.000s

                                                        то есть имеем 7.7/1.5/0.5 тактов процессора на одну итерацию цикла в зависимости от уровня оптимизации.
                                                        Первые два более-менее соответствуют ожиданиям, а вот последний — несколько выходит за рамки теории.
                                                        Дальше надо разбираться .
                                                        с ассемблером
                                                        -O0:
                                                        .L6:
                                                        movl -16(%rbp), %eax
                                                        cltq
                                                        movl -256016(%rbp,%rax,4), %eax
                                                        addl %eax, -4(%rbp)
                                                        movl -16(%rbp), %eax
                                                        leal 1(%rax), %edx
                                                        movl %edx, -16(%rbp)
                                                        movl -16(%rbp), %edx
                                                        cltq
                                                        movl %edx, -256016(%rbp,%rax,4)
                                                        .L5:
                                                        cmpl $63999, -16(%rbp)
                                                        jle .L6


                                                        -O2, -O1:
                                                        [code]
                                                        .L4:
                                                        addl $1, %edx
                                                        addl (%rcx), %eax
                                                        addq $4, %rcx
                                                        movl %edx, -4(%rcx)
                                                        cmpl $64000, %edx
                                                        jne .L4
                                                        [/code]
                                                        -O3:
                                                        [code]
                                                        .L4:
                                                        movdqa %xmm0, %xmm2
                                                        paddd (%rdx), %xmm1
                                                        addq $16, %rdx
                                                        paddd %xmm3, %xmm0
                                                        paddd %xmm4, %xmm2
                                                        movaps %xmm2, -16(%rdx)
                                                        cmpq %rcx, %rdx
                                                        jne .L4
                                                        [/code]

                                                        Там довольно много интересното:
                                                        • Видно, что для достижения около-теоретической производительности никакой раскрутки цикла не потребовалось.
                                                        • в -O3 использована автовекторизация, потому результат получился выше теоретического предела
                                                        • никаких ускорений на порядки раскрутка циклов дать не может

                                                        Короче вопрос: как именно Ваши результаты соотносятся с написанным мной?
                                                          0
                                                          Беглый взгляд на цикл показывает, что теоретический предел у core-i — 1 такт на итерацию

                                                          Почему?

                                                            0
                                                            потому что там навскидку видно 5 команд:
                                                            есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
                                                            у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
                                                            В частности, только один для сохранения данных. Так что навскидку получается такт.
                                                              0
                                                              В частности, только один для сохранения данных.

                                                              Действительно как и у коре2.

                                                              В целом ясно. Не совсем пальцем в небо как я думал, но всё же не далеко от этого. В действительности и реальности там никаких тактом и не пахнет, но это ладно. Сразу ответить не могу — отвечу позже. Спасибо за карму.

                                                                0
                                                                я же специально написал: «Беглый взгляд на цикл».
                                                                >там никаких тактом и не пахнет
                                                                В реальности получается две итерации за 3 такта. ;)
                                                            0
                                                            Мы использовали внешний цикл в каждом примере. Конкретно в примере 1 было сделано 10000 итераций внешнего цикла. На Core i7 компиляция выполнялась на Microsoft Visual Studio, оптимизация /О2. Одна итерация цикла заняла ~1.5 такта.
                                                            Смотрим ассемблер
                                                            :
                                                            000000013F1D6780  xor         eax,eax  
                                                            000000013F1D6782  mov         dword ptr [k (013F1EF280h)],eax  
                                                            000000013F1D6788  test        r8d,r8d  
                                                            000000013F1D678B  jle         main+10Bh (013F1D67ABh)  
                                                            000000013F1D678D  mov         rcx,r13  
                                                            000000013F1D6790  add         edx,dword ptr [rcx]  
                                                            000000013F1D6792  mov         dword ptr [rcx],eax  
                                                            000000013F1D6794  inc         eax  
                                                            000000013F1D6796  lea         rcx,[rcx+4]  
                                                            000000013F1D679A  cmp         eax,r8d
                                                            


                                                            Видно, что автовекторизация не случилась, а с Вашим результатом для невекторизованного цикла наш результат согласуется. Раскрутка цикла может дать более эффективное использование конвейера, поэтому на итерацию может уйти меньше 1 такта. Сore i7 — сложный современный процессор, включающий несколько АЛУ, усовершенствованный кэш, Out of Order Execution. Вполне возможно, что в таком простом коде задействовалось сразу несколько разных механизмов повышения производительности :)
                                                              0
                                                              Таким образом, самый плохой результат (255мс) — это реально 1.5 такта на итерацию, что уже соответствует околотеоретической производительности.
                                                              Хорошо.
                                                              Осталось понять чему именно соответствует результат 5мс (32 итерации за такт)?
                                                              Очевидно, сохранения 32 интов за такт одно ядро i7 сделать не сможет, даже при полной векторизации на AVX2.
                                                              Отсюда понимаем, что паттерн оптимизации «Пример 1. Развертывание циклов» соответствует замене приведённого кода каким-то другим, где не надо делать столько сохранений.
                                                              конкретно речь о строчке
                                                              a[kpp] = k; (тут я специально заменил k++ на kpp, чтобы не рассматривать лишнюю операцию сложения)
                                                              Суть:
                                                              в исходном коде эту операцию надо сделать 64000*10000=0.64*10^9 раз.
                                                              Утверждение: на одном ядре i7 это невозможно сделать за 5мс.

                                                              PS: «эффективное использование конвейера,… несколько АЛУ, усовершенствованный кэш, Out of Order Execution» — на это утверждение никак не влияют.
                                                                0
                                                                Вы правы, никакого ускорения с помощью раскрутки цикла в данном примере получить нельзя. Обновили результат в посте, спасибо :)
                                                                  0
                                                                  хорошо.
                                                                  Теперь применяем те же рассуждения к Эльбрусу.
                                                                  получаем 2 итерации цикла за такт, откуда сразу же следуют два вывода, находящиеся в противоречии с Вашей статьей:
                                                                  • раскрутка цикла делается компилятором Эльбруса автоматически (за такт ядро Эльбруса может сделать только один переход — см доки)
                                                                  • в «расчете на гигагерц» в этом тесте производительность Эльбруса и core-i одинаковые — две итерации за такт (если использовать максимальный уровень оптимизации компилятором)
                                                              –1
                                                              Видно, что для достижения около-теоретической производительности никакой раскрутки цикла не потребовалось.

                                                              Во-первых «около» — это на 50% медленнее? Отличная история — поймать результат лсд и рассуждать об «раскрутка не потребовалась» особенно вкупе с тем, что собственно поймали его ограничение. Вот ведь дураки пацаны — апаратный анроллер запилили, а у экспертов на хабре случилось «не потребовалось».

                                                              И даже не самое важно — стоит его зантроллить и он покажет максимальный трупут.

                                                              никаких ускорений на порядки раскрутка циклов дать не может

                                                              Слишком не хочу на это отвечать. Могу только сказать — могут. Сраться на эту тему мне лень — слишком сложно и долго — можете просто игнорировать этот пункт.
                                                                0
                                                                >Во-первых «около» — это на 50% медленнее?
                                                                это на пол-такта медленнее оценки.
                                                                >поймать результат лсд
                                                                какой результат?
                                                                >Отличная история… Вот ведь дураки пацаны— апаратный анроллер запилили
                                                                Такое впечатление, что Вы беседуете с голосами в своей голове.
                                                                Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.
                                                                >поймали его ограничение
                                                                Кто поймал? Если Вы о 1.5 тактах вместо 1, то никаких сложных объяснений тут искать не надо. Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).

                                                                >стоит его зантроллить и он покажет максимальный трупут.
                                                                исключительно за счёт ликвидации накладных расходов на саму организацию цикла (сравнение и переход), которые для такого простого цикла на 4 содержательные операции — весьма велики.
                                                                Но в общем и целом, после появления в интеловских процессорвах кэша предекодированных uop-ов, раскрутку циклов надо делать очень осторожно — велика вероятность в него не вписаться, и в результате попасть на ограничения куда более узкого места — декодера.

                                                                >Могу только сказать — могут
                                                                Моя сентенция относилась к конкретному примеру, где было показано ускорение в 30 что ли раз за счёт раскрутки. В данном случае это было явно следствие ошибки, что уже давным-давно выяснили.
                                                                А насчет «могут или не могут» — я за время своей практики многое встречал.
                                                                Тем не менее — пример приветствуется.
                                                                  0
                                                                  это на пол-такта медленнее оценки.

                                                                  Оценки в один такт один такт. Что является на 50% медленнее.

                                                                  какой результат?

                                                                  Полученный.

                                                                  Такое впечатление, что Вы беседуете с голосами в своей голове.
                                                                  Если хотите, чтобы я тоже принял участие в этой беседе — выражайтесь яснее.

                                                                  Когда нечем крыть — обвини. Был задан конкретный вопрос, что если по мнению эксперта анролл не нужен — зачем тогда существует лсд? Ситуация в целом типичная — человек не понимает что и почему происходит. Он получает результат и на делает выводы не учитывая того, чего он не видит и не понимает.

                                                                  Достаточно посмотреть ассемблер — там в теле цикла 6 содержательных команд, плюс StD. то есть просто не хватает ширины конвейера для исполнения всего в одном такте. У Эльбруса, кстати, должно хватать (собственно, даже на 2 итерации хватает).

                                                                  Ну пошли объяснения уровня детского садика. Что такое «ширина конвейера»? И почему её не хватает? Почему же эта ширина конвейера не учитывалась при:

                                                                  есть одна команда загрузки, одна команда сохранения, два сложения и один джамп
                                                                  у современных core-i 7 портов выполнения (>5), но они неуниверсальны.
                                                                  В частности, только один для сохранения данных. Так что навскидку получается такт.


                                                                  А я скажу почему — это всё просто пустой трёп. Эксперт рассчитывал на то, что на разницу между его выводами и реальностью он ответит «не у теоретическая производительность недостижима», либо как-то так.

                                                                  Моя сентенция относилась к конкретному примеру

                                                                  Враньё. Если бы она относилась — она бы на это указывала. Относительно к примеру она вообще не имеет смысла. Вроде как у нас есть «теоретическая производительность» и реальная и разница между ними +50%, то зачем повторять ещё раз то, что итак из этого следует при этом в обобщенной форме?

                                                                  где было показано ускорение в 30 что ли раз за счёт раскрутки.

                                                                  Меня мало волнует что там написано. Зачем сливаться на это? Я где-то хоть раз упомянул статью и её выводы? Нет. А если нет — зачем мне про это писать?

                                                                  А насчет «могут или не могут» — я за время своей практики многое встречал.

                                                                  Но ведь ваши выводы глупы, а понимание слабо. Толку с такой практики? Если бы я не пришел — вы бы продолжили всем рассказывать о том, что анролл ничего не даёт. Да, это моя ошибка — что-то я решил не вытягивать из вас подобные заявления, а они были бы.

                                                                  По поводу примеров. В данном случае каждая итерация зависит от счётчика, который имеет трупут 1 значение/такт. Не учитывая того, о чём я не буду сейчас говорить, чтобы не давать вам пути для съезжания. В этот примере это нивелируется тем, что это совпало собственно с трупутом записи. Чисто случайно.

                                                                  Если бы это было чтение, то мы бы получили -100%, а если учитывать всё остальное — 150%. А если нам надо чуть больше на итерации считать?

                                                                  Ну и конечно же юзкейсы уровня нескольких итераций.
                                                                    0
                                                                    >Был задан конкретный вопрос, что если по мнению эксперта анролл не нужен — зачем тогда существует лсд?
                                                                    1. Эксперт — это кто?
                                                                    2. C ЛСД Вам надо завязывать — тогда глядишь и перестанет чудиться то, чего нет на самом деле.

                                                                    >Что такое «ширина конвейера»? И почему её не хватает?
                                                                    число портов запуска, я это уже писал
                                                                    > Почему же эта ширина конвейера не учитывалась при:
                                                                    Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.
                                                                    Компилируем то же на icc и
                                                                    получаем:
                                                                    ..B1.5: # Preds ..B1.4 ..B1.5
                                                                    addl (%rsp,%rdx,4), %edi #13.3
                                                                    movl %edx, (%rsp,%rdx,4) #14.3
                                                                    incq %rdx #14.5
                                                                    cmpq $64000, %rdx #11.21
                                                                    jl ..B1.5 # Prob 99% #11.21


                                                                    как говорится — найдите отличия ;)
                                                                    ну и заодно — угадайте, сколько именно тактов работает такой цикл
                                                                    >А я скажу почему — это всё просто пустой трёп
                                                                    Знаете, в чём Ваше отличие от автора статьи — в отсутствии рефлексии. Потому как он исправил свою ошибку, а Вы, подозреваю, так и продолжите беседовать с голосами в своей голове.

                                                                    >Если бы я не пришел — вы бы продолжили всем рассказывать о том, что анролл ничего не даёт.
                                                                    На самом деле, до того как Вы пришли — я этого не говорил.
                                                                    Поскольку я последние три года занимался в основном оптимизацией для GPU. А там анролл циклов действительно нужен в подавляющем числе ситуаций (хотя конечно ни о каких ускорениях на порядки речи тоже нет).
                                                                    Но если Вы настаиваете, то я таки сформулирую своё мнение на unroll:
                                                                    Правило оптимизации 20-летней давности: «в любой непонятной ситуации делай unroll» — на современных процессорах работает с точностью до наоборот.
                                                                      0
                                                                      число портов запуска, я это уже писал

                                                                      у современных core-i 7 портов выполнения (>5), но они неуниверсальны

                                                                      Дак больше 5?

                                                                      Потому что GCC при компиляции добавил в цело цикла одну операцию «от себя», которая на самом деле там не обязательна.

                                                                      Да нет, просто кто-то не осилил спастить код и написать его вменяемо.

                                                                      ну и заодно — угадайте, сколько именно тактов работает такой цикл

                                                                      И сколько же?

                                                                      Потому как он исправил свою ошибку, а Вы, подозреваю, так и продолжите беседовать с голосами в своей голове.

                                                                      В чём же заключается моя ошибка?

                                                                      На самом деле, до того как Вы пришли — я этого не говорил.

                                                                      Собственно намекал и моя ошибка была в том, что я это не вытянул. Да.

                                                                      Правило оптимизации 20-летней давности: «в любой непонятной ситуации делай unroll» — на современных процессорах работает с точностью до наоборот.

                                                                      Очень смешно когда «экперт» с познанием уровня 20летний давно рассуждает о чём-то. Я кстати даже не заметил перлов выше. Надо ответить на них.
                                                                        0
                                                                        > И сколько же?
                                                                        это Вы у своих голосов разузнайте. Потом поговорим, если ещё будет о чём. ;)

                                                                        Да, Вспомнил, кого Вы мне живо напомнили: Глеба Капустина из рассказа Шукшина «Срезал»
                                                              –1
                                                              Все таки импорт-замещение работает)))
                                                                0
                                                                Ничего не понимаю. Почему вы разделяете Эльбрус-МЦСТ и SPARC? Это ведь одна и та же архитектура клманд.
                                                                  0
                                                                  Есть Эльбрус-SPARC и Эльбрус-Эльбрус:
                                                                  оф. сайт :)
                                                                    0
                                                                    Спасибо, не знал. Мы только с R-500 и Эльбрус-90 работали.
                                                                  +3
                                                                  «Время в пересчете на 1 ГГц» — это очковтирательство чистой воды. Напишите один и тот же алгоритм для 1Mhz и 1Ghz — это будут принципиально разные вещи по архитекруте, по площади кристалла или FPGA, по… всему! Интерес вызывает только абсолютное время выполнения задачи. Чем меньше тем лучше.
                                                                    0
                                                                    а что с JVM и CLR? сразу транслируется в VLIW коды или в x86 потом VLIW?
                                                                    0
                                                                    Я никак не вижу интригующих данных по главному вопросу: сам VLIW то дает преимущество?

                                                                    Вы анализировали, какие широкие команды генерируются в вашем коде? Может где-то переставили местами, запараллелили два процесса и всё стало быстрее в разы?
                                                                      +1
                                                                      Мы рассмотрели простые примеры на С++ и сравнили результаты работы на Эльбрус-4С и Intel Core i7-6700K. На Эльбрусе использовался компилятор lcc версии 1.20.17, для Core i7 — Microsoft Visual Studio Community 2015. Для lcc мы использовали флаги компиляции -O3 и -ffast-math.


                                                                      У меня вот этому месту очень большие претензии! Почему не выставили аналогичные оптимизации для MSVC?

                                                                      Вы же сравниваете дальше, фактически тёплое с мягким т. е. не результат работы кода на разных архитектурах с одинаковым уровнем оптимизации у компиляторов, т. е. фактически для x86 без каких либо оптимизаций со стороны компилятора. Не надо так делать :(

                                                                      Такими «тестами» в глазах специалистов вы только дискредитируете платформу. Это в чистом виде антимаркетинг. Особенно с учётом того что Эльбрусы не пойти и не купить, а потому провести аналогичный тест у себя не представляется возможным.

                                                                      Очень прошу: укажите параметры MSVC, а лучше выставите там соизмеримые с -O3 и тоже включите fast-math оптимизации и проведите тесты заново ;)

                                                                      Жду исправления статьи ибо пока выводы на основе таких «тестов» видятся неадекватными и откровенно ненаучными.

                                                                      P.S. а ещё гораздо больше интересен тест 8С1 (именно модификация, а не чистого 8С) ибо 8C1 за счёт более оптимального размера кэша L2 должен быть явно энергоэффективнее 8С. В общем слежу за архитектурой, а адекватных тестов без ахинеи всё нет и нет, а самое обидное: заказать и купить его даже нельзя :( Знаю что 8С ещё в предсерийке, но в серию пойдут во 2 квартале 2017 и я очень сильно сомневаюсь, что не юрлицу их можно будет купить.
                                                                        0
                                                                        У разных компиляторов различный набор настроек оптимизации и эти настройки могут быть по-разному реализованы, поэтому выставить полностью идентичный набор параметров затруднительно. Так, дефолтные значения флагов lcc предполагают довольно сильные ограничения floating-point оптимизаций. Флаг -ffast-math (отличается от -ffast-math в gcc) включает некоторые оптимизации, например, подстановку операций вместо вызова библиотечных функций. И только с флагами -ffast и -ffast-math задействуется полный набор floating-point оптимизаций, которые могут приводить к значительным изменениям результатов вычислений.

                                                                        В данных примерах для MSVC были использованы fp:/precise (не полностью соответствующий -ffast-math, но также дающий некоторые оптимизации floating-point арифметики), общий уровень оптимизации /O2 (максимизирует скорость работы) и включено использование интринсиков. Таким образом, мы постарались достичь максимального соответствия в параметрах оптимизации компиляторов.
                                                                          0
                                                                          Благодарю. Теперь понятно, т. е. вы просто не стали указывать параметры для MSVC, вот я и подумал что установки оставлены по умолчанию.

                                                                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                      Самое читаемое