стань автором. присоединяйся к сообществу!
Добавить новость можно всем, без премодерации, только регистрация
Лого Сделано у нас
205
kerosene 02 июля 2017, 06:07 22 Электроника, электротехника и приборы

Эльбрус-8С: результаты теста SPEC CPU 2006

@sdelanounas_ru

На стратегической сессии «РОССИЙСКИЕ АППАРАТНО-ПРОГРАММНЫЕ РЕШЕНИЯ» представитель МЦСТ Константин Трушкин представил результаты теста SPEC CPU 2006 для микропроцессора «Эльбрус-8С».

читать полностью
Источник: www.youtube.com

Поделись позитивом в своих соцсетях


МЦСТ, Эльбрус-8С, микропроцессор, SPEC CPU 2006
все комментарии
  • 0
    Нет аватара segfault
    03.07.1711:02:00

    Уважаемый kerosene, я прекрасно понимаю Ваше желание представить «Эльбрус» с самой лучшей стороны, но давайте будем немного честнее в отношении читателей, которые не обладают достаточной глубиной познаний в микропроцессорных архитектурах. Поверьте, «Эльбрус» от этого только выиграет. Давайте по-порядку.

    1) Относительно статического и динамического планировщиков. Основная задача и того и другого — обеспечить выполнение кода, когда какая-либо процессорная команда не может завершиться в силу зависимостей по данным. На сегодняшний день бОльшая часть работы, связанная с разрешением зависимостей по данным решается компиляторами уже на уровне преобразования семантического графа программы, по сути на долю собственно планировщика инструкций остается не так уж и много. Кстати, появлению современных методов высокоуровневой оптимизации в компиляторах мы в немалой степени должны быть благодарны и VLIW-архитектурам в том числе. С другой стороны, есть множество случаев, в которых статический планировщик абсолютно бессилен.

    2) Что касается тестов: если судить по поиведенным данным, то «Эльбрус» по производительности на ядро проигрывает современным интеловским процессорам в 7.5 раз, по производительности на мегагерц — в 4 раза. Это ни плохо, ни хорошо, это голые цифры, и хорошо, что на этих тестах отставание уже меньше, чем на порядок. Что касается «логической скорости», то я не очень понимаю, что Вы имеете в виду? Если количество потенциально выполняемых за такт инструкций, то это и так очевидно, на то она и VLIW архитектура.

    3) Что касается тактовой частоты, то здесь вы тоже немного лукавите. Я не стану сейчас ничего утверждать, не имея конкретных цифр перед глазами, но есть два ключевых момента, препятствующих увеличению частоты: длина конвейера (а он не должен быть слишком длинным, иначе вся прелесть VLIW теряется) и необходимость иметь многопортовый регистровый файл. Еще раз повторюсь, не имея каких-то деталей по «Эльбрусу», оценить его потенциал в плане повышения тактовой частоты сложно, нл в целом у VLIW-архитектур он ниже, чем у других.

    4) Это уже к следующему комментарию: интеловские процессоры не будут иметь меньшую тактовую частоту, она на протяжении последних лет постоянна и таковой будет оставаться. А рост количества ядер происходит за счет совершенствования технологического процесса и (не слишком больших) архитектурных оптимизаций. Кстати, цифр по энергопотреблению «Эльбруса» я нигде не видел. Только цифры желательно не абстрактные, а снятые с реальной системы, с указанием теста на котором они получены; а то интел много чего пишет про TDP, а вы PTU запустите, много интересного узнаете на тему того, как процессор разогреть можно    

    #928501 ↑
    • 0
      Нет аватара azurel
      03.07.1711:35:52

      Если по вашему большая часть работы у всех уже выполняется компилятором, то почему-бы тогда ее всю не выполнять компилятором, как в Эльбрусе, тут у вас некоторые противоречия.

      Если в каких-то задачах, статический планировщик бессилен, то какие преимущества у так сказать полустатического ?

      Какие процессоры опережают Эльбрус-8С в 7.5 раза ?

      Так что если решили просветить далеких от темы читателей, то надо меньше слов, а больше конкретики.

      #928509 ↑
      • 1
        Нет аватара segfault
        03.07.1713:02:24

        Еще раз, компилятор не может разрешить динамические зависимости между данными. И VLIW здесь не помогает никак.Именно поэтому бОльшая часть современных процессоров — out-of-order. Компилятор выполняет ту часть работы, которую можно сделать на основе анализа кода, процессор — остальное. Сюда, помимо динамического планирования, еще добавляется динамическая предвыборка данных.

        #928540 ↑
        • 0
          Нет аватара azurel
          03.07.1713:43:33

          В чем проблем-то Эльбрус это тоже out-of-order процессор, и если в принципе есть возможность распараллелить код, компилятор это всегда сделает лучше чем аппаратный планировщик, в Эльбрусе помимо статического планирования добавляется так-же асинхронная подкачка данных.

          В общем пока непонятно о чем вы говорите, конкретные примеры у вас есть где не справится компилятор?

          #928552 ↑
          • 0
            Нет аватара segfault
            03.07.1714:31:30

            Это когда «Эльбрус» вдруг стал out-of-order? Вы не путаете часом out-of-order с возможностью параллельного использования нескольких коевейеров?

            Что касается ответа на Ваш вопрос: компилятор хорошо справляется с переоупорядочиваним инструкций в соответствии с графом зависимостей. Это работает и в случае VLIW, и в случае других процессорных архитектур. На этом этапе разница лишь в том, что эльбрусовский компилятор еще и разложит независимые команды по VLIW-инструкциям, а тот же интеловский процессор просто будет автоматически в несколько конвейеров их обрабатывать. Реальная разница начинается тогда, когда мы захотим понять, а когда у нас те или иные данные будут готовы? Время выполнения инструкций чтения/записи на этапе компиляции не определено. Никто не может сказать, попадем мы в кэш или промахнемся, если попадем, то в кэш какого уровня и т. д. Динамический планировщик может «кормить» арифметические конвейеры инструкциями по мере готовности данных, внн зависимости от того, как эти инструкции расставил статический планировщик.

            Отредактировано: segfault~14:32 03.07.17
            #928564 ↑
            • 0
              Нет аватара azurel
              03.07.1715:47:21

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

              Тут как не крути если вы статически все распланировали у вас код будет выполняться быстрее.

              #928593 ↑
              • 0
                Нет аватара segfault
                03.07.1716:44:00

                Спасибо. То, что вы сказали, не имеет никакого отношения к out-of-order исполнению инструкций. А насчет отсутствия промахов в кэш так просто позабавило     В этом случае МЦСТ смело может на премию Тьюринга подаваться     Не хочу Вас ни в коей мере задеть, но Вы бы все-таки сначала поизучали, как устроена архитектура памяти в современных микропроцессорах, и какие у нее узкие места.

                #928613 ↑
              • 1
                Нет аватара segfault
                03.07.1716:52:53

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

                Отредактировано: segfault~16:53 03.07.17
                #928618 ↑
                • 0
                  Нет аватара azurel
                  03.07.1717:13:24

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

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

                  Отредактировано: azurel~17:13 03.07.17
                  #928630 ↑
                  • 0
                    Нет аватара segfault
                    03.07.1718:21:17

                    С первым утверждением никто и не спорит, для счетных задач архитектура VLIW очень неплоха. И Итаниум создавался Интелом в расчете на именно такие задачи.

                    А вот второе утверждение (что «Эльбрус» обходит другие процессоры), к сожалению, пока является неправдой, хотя очень хотелось бы, чтобы было наоборот. Приведите хоть одну цифру честного сравнения «Эльбруса» с тем же Intel Xeon E5 v4, которая показала бы превосходство «Эльбруса». Без разницы, в сравнении систем целиком, в пересчете на одно ядро или на мегагерц — все равно.

                    Я очень высоко ценю труд коллектива МЦСТ и их достижения, но, пожалуйста, не надо заниматься шапкозакидательством, поверьте мне, это очень плохо влияет на имидж «Эльбруса» в ИТ-отрасли

                    #928659 ↑
    • 0
      Нет аватара kerosene
      03.07.1711:36:47

      MCST Elbrus-8C, 1.00 GHz:

      SPEC CPU 2006: 10

      SPEC FPU 2006: 13

      Sandy Bridge, 1.00 GHz (GCC):

      SPEC CPU 2006: 8.6

      SPEC FPU 2006: 10

      #928510 ↑
      • 0
        Нет аватара segfault
        03.07.1712:42:51

        Intel Xeon E5-2699A v4, 2,4GHz: SpecFP 2006 — 128.

        Итого, 128/17 = 7.53

        С приведением по частоте (128/2.4)/13 = 4.1

        #928532 ↑
        • 1
          Нет аватара kerosene
          03.07.1712:54:52

          Я писал про SPEC INT, а не FP.

          И к тому же: ark.intel.com/products/96899/Intel-Xeon-Processor-E5-2699A-v4-55M-Cache-2_40-GHz

          2 сокета — SPEC FP — 1120 — ЭТО НА 2-СОКЕТНОЙ СИСТЕМЕ С 44 ЯДРАМИ!

          А для Эльбруса даны показатели для 1 ядра!

          1120 / 44 = 25,45

          Для 1 ядра на 1 ГГц будет 10,6 попугаев, а у Эльбруса на 1 ГГц будет 13.

          Отредактировано: kerosene~13:01 03.07.17
          #928537 ↑
          • 0
            Нет аватара segfault
            03.07.1713:08:49

            Уважаемый kerosene, не путайте теплое с мягким. Тесты SPECfp и SPECfp_rate — это *разные* тесты. Мы говорим про SPECfp, который показывает производительность применительно к одному ядру. А результатов теста SPECfp_rate для «Эльбруса» Вы не приводили.

            #928542 ↑
            • 1
              Нет аватара kerosene
              03.07.1713:11:44

              Я вам привел тест SPECfp_rate для 2-сокетной системы на Intel® Xeon® Processor E5-2699A v4. 1120 попугаев.

              #928544 ↑
              • 0
                Нет аватара segfault
                03.07.1713:17:05

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

                Отредактировано: segfault~13:17 03.07.17
                #928546 ↑
              • 1
                Нет аватара segfault
                03.07.1713:21:32

                P. S. Если на двухпроцессорной системе с Эльбрус-8С Вы получите на SPECfp_rate хотя бы 200, я первый скажу, что это круто.

                #928547 ↑
            • 0
              Федор Синицын Федор Синицын
              06.07.1702:04:35

              На сайте www.specbench.org/cpu2006/results/ я не нашел результатов SpecFP2006 для систем на Sandy Bridge близкие к 37,68 как в статье и видео. Там вообще для двузначных результатов нет сотых долей, только десятичные. А сами результаты значительно выше от 40 до 70, если не ошибаюсь. Я к тому, что вообще непонятно как тестировали, и с чем сравнивали. Могу предположить, что тест проводился на своем компьютере, в конфигурации схожей с Эльбрусом.

              Отредактировано: Иван Смирнов~02:08 06.07.17
              #929488 ↑
Написать комментарий
Отмена
Для комментирования вам необходимо зарегистрироваться и войти на сайт,