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

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

@sdelanounas_ru

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

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

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


МЦСТ, Эльбрус-8С, микропроцессор, SPEC CPU 2006
все комментарии
  • 8
    Нет аватара sarvizir
    02.07.1717:19:11

    Читайте про Itanium и поймете почему VLIW умер.

    Главное, Данила, чтобы вы читали.

    #928260 ↑
    • Комментарий скрыт по причине низкого рейтинга. показать
      • 8
        Нет аватара azurel
        02.07.1718:24:30

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

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

         http://mcst.ru/files/5757...izatsii_predskazaniya.pdf 

         http://www.mcst.ru/doc/130621/Shabanov.pdf 

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

        #928281 ↑
        • 0
          krotozer krotozer
          02.07.1723:48:57

          Спасибо за целевые ссылки на материалы!

          #928378 ↑
        • -1
          Нет аватара guest
          03.07.1710:20:35

          Какие еще переходы? Это вообще не о том.

          #928489 ↑
          • 1
            Нет аватара azurel
            03.07.1710:58:47

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

            Ну, а если вы говорили о том что компилятор не может эффективно распараллелить код, то вам уже сказали сказали что это чушь.

            #928498 ↑
      • 8
        shigorin shigorin
        02.07.1723:13:08

        А как это компилятор, затратив примерно сколько угодно времени -- не может, а аналогичный ему функционально блок железки в рантайме -- может? Может, Вы всё-таки своими мозгами немного пораскинете да матчасть подтянете, прежде чем людям понимающим указывать, кому чего понять?

        #928357 ↑
        • 0
          RadiantConfessor RadiantConfessor
          03.07.1705:54:39

          Более того, компилятор тратит энергию 1 раз, а специальный блок железки постоянно, при каждом исполнении программы.

          По этому VLIW всегда будет энергетически выгоднее RISC.

          Отредактировано: Zveruga~05:55 03.07.17
          #928439 ↑
        • 0
          Нет аватара segfault
          03.07.1709:07:16

          Миша, ну ты-то уж не перегибай палку! Архитектура VLIW безусловно хороша, когда речь идет о вычислительных задачах. В таких задачах достаточно мало динамических зависимостей по данным, и хорошо соптимизированное приложение будет показывать отличную производительность. Но как только мы имеем много динамических зависимотей, ситуация оказывается гораздо печальнее, а большинство современных приложений именно таковы. Именно поэтому последние интеловские Итаниумы (Пулсон и Китсон) уже out-of-order. Плюс к этому VLIW не очень хорош, когда мы имеем дело с приложениями, требующими малого времени отклика. Ну и головную боль с оптимизацией приложений, даже при наличии хорошего компилятора, никто не снимал.

          Собственно, Итаниум умер ровно тогда, когда алгоритмы динамического планировщика команд по эффективности превысили планирование в компиляторе.

          Я ни в коей мере не призываю отказаться от «Эльбрусов», но давайте все-таки трезво оценивать сильные и слабые стороны любой технологии.

          #928471 ↑
          • 2
            Нет аватара kerosene
            03.07.1709:31:59

            Аппаратный динамический планировщик никогда не превысит по эффективности статическое планирование. Это как бы очевидно всем. x86 выигрывает только за счет высокой тактовой частоты и быстрого переключения контекста. Если же вы приведете попугаи SPEC к одному знаменателю, то увидите, что интеля имеют меньшую логическую скорость чем Эльбрусы. Беда Эльбруса — низкая тактовая частота. Но это не проблема VLIW, а проблема конкретных реализаций микроархитектуры и отсутствия full-custom дизайна блоков ядра.

            #928478 ↑
            • 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 ↑
          • 2
            Нет аватара kerosene
            03.07.1709:34:07

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

            #928479 ↑
          • 0
            shigorin shigorin
            30.07.1720:22:17

            Спасибо!

            #938433 ↑
        • -1
          Нет аватара guest
          03.07.1710:28:07

          Потому что есть 100500 вариантов развития событий. Данные могут поступать в разное время, переходы и т. д.

          RISC процессор выполняет инструкции пока есть данные, а VLIW часто тупит и простаивает, пока ждет какие-то данные, хотя мог бы исполнить множество инструкций для которых данные уже есть.

          #928490 ↑
          • 2
            Нет аватара kerosene
            03.07.1718:15:14

            Во-первых, тебе уже сказали, что в Эльбрус запросто можно встроить предсказатель переходов. Его и должны были встроить в модель Эльбрус-1С+, но не успели чисто по времени. Во-вторых почитай уже наконец книгу про Эльбрус в PDF на сайте МЦСТ. А то похоже, что ты не имеешь никакого представления о том, что такое архитектура Эльбрус. Это не просто процессор с VLIW, это VLIW/EPIC с кучей крутых функций типа спекулятивного исполнения, условного исполнения, асинхронной предподкачки данных в РФ минуя кэш, некоторой аппаратной поддержки для трансляции x86-кодов (формат данных с плавающей точкой совместимый с Интел, сегментные регистры, указатель команд и стека, арифметические команды совместимые с x86 по флагам операций и т. д.), поддержки конвейеризованных циклов, 3 стеков из которых 2 защищенных аппаратных, режима защищенного исполнения, когда все данные в памяти тегируются, а обращение к структурам и данным идет только через 128-битные дескрипторы и т. д.

            Отредактировано: kerosene~18:19 03.07.17
            #928657 ↑
            • 0
              Нет аватара guest
              03.07.1718:49:02

              Собственно, там есть целый класс префетч-инструкций, полностью посвящённый управлению подкачкой. Причём подкачка идёт из многопортового ассоциативного кэша, что автоматом снижает частоту промахов, а весьма своеобразная организация РФ как набора стековых фреймов с хвостами в кэше первого уровня — позволяет значительно удешевить переключение контекстов.

              #928664 ↑
Написать комментарий
Отмена
Для комментирования вам необходимо зарегистрироваться и войти на сайт,