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

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

@sdelanounas_ru

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

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

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


МЦСТ, Эльбрус-8С, микропроцессор, SPEC CPU 2006
все комментарии
  • Комментарий скрыт по причине низкого рейтинга. показать
    • 9
      Дмитрий Тёмный Дмитрий Тёмный
      02.07.1716:08:28

      так умер Itanium, а не VLIW.

      Вон Silicon Graphics со своим MIPS (который вполне себе RISC) умер, PA RISC умер, Alpha умерла. Все они уступили x86, то есть можно сделать выводы что RISC — тупиковая ветка?

      #928246 ↑
      • Комментарий скрыт по причине низкого рейтинга. показать
        • 5
          shigorin shigorin
          02.07.1723:04:04

          Ох уж мне эти Данилы, ни хрена обобщать не научились.

          #928353 ↑
        • 1
          krotozer krotozer
          02.07.1723:43:53

          Вы, главное, верьте в это!    

          #928375 ↑
    • 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 ↑
Написать комментарий
Отмена
Для комментирования вам необходимо зарегистрироваться и войти на сайт,