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

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

@sdelanounas_ru

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

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

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


МЦСТ, Эльбрус-8С, микропроцессор, SPEC CPU 2006
все комментарии
  • 13
    Сергей Галин Сергей Галин
    02.07.1712:41:23

    Странное противопоставление, ведь VLIW это развитие RISC, причём имеющее вполне определённые плюсы (железо проще и потребляет меньше энергии). Кроме того, VLIW прекрасно идёт по миру в GPU, DSP и прочих ембедах. CISC уже сдано много позиций RISC (точнее, ARM) именно из-за более сложного и прожорливого железа, а VLIW — ещё один шаг в том же направлении. Откуда такая уверенность, что это тупик?

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