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

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

@sdelanounas_ru

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

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

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


МЦСТ, Эльбрус-8С, микропроцессор, SPEC CPU 2006
все комментарии
  • Комментарий скрыт по причине низкого рейтинга. показать
    • 4
      Alexander V Alexander V
      02.07.1712:08:50

      С софтом, как быть?

      #928190 ↑
      • 5
        Нет аватара guest
        02.07.1714:36:29

        x86 эффективно работает благодаря многочисленным расширениям инструкций, которые являются собственностью Интел. Почитайте про то как Интел протестует против попыток Микрософт запускать x86-программы на ARM-процессорах. Так что если уж делать что-то свое, так свое. А софт — надо делать свой в первую очередь.

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

        #928228 ↑
        • 4
          shigorin shigorin
          02.07.1723:02:26

          Хохма в том, что такая запускалка (exagear) уже сделана… бывшими сотрудниками МЦСТ. И да, работает    

          #928351 ↑
        • 2
          shigorin shigorin
          02.07.1723:03:13

          PS: попробуйте реактос. Серьёзно. А потом уже топите глупости в поддержку клона того, чему стоило сдохнуть в зародыше.

          #928352 ↑
        • 1
          krotozer krotozer
          02.07.1723:42:26

          Нынче появились методики, но этим нужно заниматься профессионалам в этой области. Т. е. каждый — своим делом. А вообще, тот ещё вопрос, нужно ли поддерживать Windows-приложения, если уже не всё старое ПО запускается под новыми версиями Windows? Может Вы не знали, но сейчас бухаются отнюдь не малые средства в разработку средств реинжениринга ПО при помощи нейронных сетей в исходный код.

          #928373 ↑
          • 1
            Виктор Гюго Виктор Гюго
            03.07.1711:28:39

            > Может Вы не знали, но сейчас бухаются отнюдь не малые средства в разработку средств реинжениринга ПО при помощи нейронных сетей в исходный код.

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

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