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

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

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

читать полностью
Источник: www.youtube.com
МЦСТ, Эльбрус-8С, микропроцессор, SPEC CPU 2006
все комментарии
  • -8
    Alexander V Alexander V
    02.07.1710:54:26

    Почему от x86 архитектуры отказались? Intel и AMD как-то выпускают свои процессоры.

    Отредактировано: Alexander V~11:02 02.07.17
    #928170 ↑
    • 15
      Сергей Галин Сергей Галин
      02.07.1711:38:42

      x86 у нас последний раз делали, кажется, в первой половине девяностых, а потом сами знаете, что случилось. Эльбрус всегда поддерживал x86 только в режиме эмуляции. А вообще x86 сложная и неэффективная архитектура, которая тащит кучу наследия ещё с конца 70х и с приходом Windows 10 на ARM её будущее в долгосрочной перспективе под вопросом. Я бы задал другой вопрос, почему наши не делают ARM, которая на 2017 год является, наверное, самой массовой архитектурой в мире — ИМХО это бы позволило запрыгнуть в массовый рынок процессоров и поднять производство, а там уже можно и с Эльбрусом заходить.

      #928180 ↑
      • -3
        Alexander V Alexander V
        02.07.1711:43:48

        В режиме эмуляции сильно проседает производительность. Я так понимаю и Linux запускается в режиме эмуляции.

        #928181 ↑
        • 4
          Сергей Галин Сергей Галин
          02.07.1711:47:59

          Пишут, что есть порт Линукса на Эльбрус, который работает нативно. Но по интернетам не понятно, доведён ли он до годного к использованию состояния.

          Отредактировано: Сергей Галин~11:52 02.07.17
          #928183 ↑
          • 1
            Alexander V Alexander V
            02.07.1711:52:41

            Ну они говорили про совместимость х86 на 90%. Поэтому пришлось перепелить 10% кода ядра. Вот и закрались сомнения.

            #928185 ↑
            • 4
              krotozer krotozer
              02.07.1723:34:09

              На плате (слева снизу) имеется слот для CF-карты. На ней располагается байт-код, необходимый для бинарной трансляции кода x86 на собственный набор микрокоманд процессора. Макрокоманды он не тянет, этим занимается компилятор LCC. В общем-то, решение перевалить работу блока предвыборки на компилятор — это тот самый метод, что позволил процессору уверенно «плыть» в условиях ограниченного бюджета. Переделывать ПО — дешевле и проще, чем сам проц. Думаю, когда-то в будущем в составе процессора может появиться блок предвыборки. Научить компилятор собирать под такие процессоры — задача не сложная. Компиляция заметно ускорится. А может они напаяют на плату сопроцессор под эту задачу, кто знает…

              #928370 ↑
              • Комментарий удален
                • 0
                  Андрей Степанов Андрей Степанов
                  03.07.1707:13:42

                  Эльбрус на экспорт не идет, так что Интел не может ничего запретить.

                  #928448 ↑
                • 0
                  krotozer krotozer
                  03.07.1707:49:16

                  Частично программная поддержка трансляции. Сам процессор не содержит ничего, попадающего под американские патенты. Да и вообще, поддержка x86_64 — лишь вынужденная мера.

                  #928455 ↑
          • 3
            Нет аватара guest
            02.07.1718:42:34

            Давно доведён.

            #928290 ↑
            • 2
              krotozer krotozer
              02.07.1723:27:05

              Я бы так не сказал… Единого тулкита дистрибутива в нём всё ещё нет. Это — самосборный дистрибутив. Но МЦСТ тяготеет к «экосистеме» Debian, так что упомянутое «доведение» — дело времени, которого у МЦСТ не так уж и много. Хотите ускорить их работу? Сорганизуйте каутфайдинг в отношении МЦСТ. Они смогут нанять дополнительный персонал.

              #928364 ↑
              • 0
                Виктор Гюго Виктор Гюго
                03.07.1710:35:13

                Что такое «единый тулкит дистрибутива»? Что за зверь такой?

                #928492 ↑
                • 0
                  krotozer krotozer
                  03.07.1712:20:18

                  Самодумный термин. Как иначе обозвать весь инструментарий дистрибутива, навёрнутый поверх GNU/Linux, который отличает его от других дистрибутивов?

                  .

                  На т.н. «Эльбрус ОС» из пакетных менеджеров есть и Aptitude, и RPM, но своего репозитория нет, по крайней мере в открытом доступе. Так что, задача установки какого-либо пакета сводится к его сборки из исходников.

                  Отредактировано: krotozer~12:23 03.07.17
                  #928522 ↑
              • 0
                Нет аватара guest
                03.07.1711:30:28

                Думаю краудфандинг должны организовывать сами МЦСТ. Во первых потому что это их бизнес, а во вторых что бы не было варианта «собрал для МЦСТ и купил дачу на канарах».

                #928507 ↑
                • 0
                  krotozer krotozer
                  03.07.1712:27:11

                  У них нет специалистов в этой области. Иначе вопрос бы уже муссировался. А по поводу «дачи на Канарах»: ничто не запрещает заключить с крауд-менеджером договор об обязательствах и предъявить его электронную копию вкладчикам. Ясное дело, что это — договор на английском и русском языках, причём английский первичен, т.к. в РФ пока ещё нет законодательства, регламентирующего крауд-финансовые операции. Впрочем, не мне по этому поводу напрягаться-то)

                  Отредактировано: krotozer~12:27 03.07.17
                  #928526 ↑
                  • 1
                    Нет аватара guest
                    03.07.1712:55:37

                    ))) Ну мы все по этому поводу напрягаемся ))) переживаем потому что за них ) надеемся на их успех.

                    #928538 ↑
              • 1
                Нет аватара guest
                03.07.1715:41:28

                Тулчейн полный готов давно. Всё остальное — дело техники и времени. Да и вообще, полный юзерлэнд в военной, в сущности, оси вам никто обеспечивать не подписывался.    

                #928589 ↑
                • 0
                  krotozer krotozer
                  03.07.1718:00:46

                  Унификация, Сэр! Если предположить «полный юзерлэнд» военного назначения на основе Debian, то это значит, что «гражданские» скрипты и рецепты будут применимы для «починки» данной ОС. А так же все debian-зависимые узконаправленные scripted-tools, коих для «Бубунты» написали выше крыши. «Военная, в сущности, ось» уж слишком зависима от гражданских наработок)

                  #928651 ↑
                  • 0
                    Нет аватара guest
                    03.07.1718:43:45

                    Вы слишком много хотеть сразу от кастомной дистры.     Вон, камрад Шигорин Альт под это дело пилит — как напилит, вот вам и будет полноценная «рабочая» дистра без ограничений специального варианта.

                    #928663 ↑
                    • 0
                      krotozer krotozer
                      03.07.1722:06:41

                      Я? Ничего от этой «дистры» не хочу) Лишь рассуждаю на тему заданного выше вопроса. МЦСТ пусть делает так, как считает нужным. Да и вообще не являюсь ярым поклонником Дебиана, как могло бы показаться. Я — гентушник) Компиляция с флагами — наше всё)   

                      .

                      А с комрадом Шигориным мы ранее уже обсуждали дистру от МЦСТ. Надо сказать им спасибо за то, насколько дистрибутив сейчас является приближенным к стандартным. Всё не так уж плохо, в общем.

                      Отредактировано: krotozer~22:08 03.07.17
                      #928716 ↑
          • 6
            shigorin shigorin
            02.07.1722:57:28

            Работает, вполне доведён. Хотя недавно удалось воспроизвести для ребят багу в новых наработках по ядру на многопроцессорной конфигурации (мы купили сервер 4.4), но такие косяки и на интеле порой вылазят…

            #928346 ↑
          • 1
            Виктор Гюго Виктор Гюго
            03.07.1710:34:00

            Порт официальный, у Горшенина ролики выложены. www.youtube.com/channel/UC6pnRoVljXKpo5bgkVyQMJg/videos

            Так же Шигорин собирает ALT Linux под эльбрус. Никакой эмуляции, native, свой компилятор.

            #928491 ↑
            • 0
              shigorin shigorin
              26.10.1820:55:04

              Также Шигорин собирает ALT Linux под эльбрус

              Собственно, технически уже есть выпуск дистрибутивов Альт Рабочая станция и Альт Сервер ;-)

              #1080143 ↑
        • -4
          Нет аватара devorg
          02.07.1712:06:27

          Такого быть не может, просто потому что такого не может быть.

          #928189 ↑
        • 8
          Нет аватара kerosene
          02.07.1712:16:48

          Там не эмуляция, а система динамической трансляции кода x86 в родной код Эльбруса. Это сделано для обеспечения совместимости с тем софтом, для которого нет аналога в исходных кодах под Линукс. Сами же Эльбрусы работают под ОС «Эльбрус», в основе которой лежит ядро Линукс 3,14 и пакеты от Дебиан.

          #928193 ↑
        • 6
          Нет аватара guest
          02.07.1718:42:21

          Неправильно понимаете по обоим пунктам. Во-первых, совершенно необязательно, а во-вторых Линукс давным давно портирован на «родную» архитектуру.

          #928289 ↑
        • 5
          shigorin shigorin
          02.07.1722:56:26

          x86 не лицензируется (ответ со слов сотрудников МЦСТ).

          #928344 ↑
          • 0
            RadiantConfessor RadiantConfessor
            03.07.1705:47:55

            А что слова, в мире ещё кто-нибудь х86 производит? Нет.

            #928437 ↑
        • 1
          krotozer krotozer
          02.07.1723:21:02

          Компилятор LCC по формату управления является тем же GCC, потому он легко встраивается в окружение GNU. Собственно, сам GNU/Linux компилируется именно под этот процессор и работает на нём «нативно». Конечно стоит упомянуть ещё некоторые вспомогательные утилиты от МЦСТ и модули для ядра Linux. Но в основе своей это — такой же «Линух», как и все остальные дистрибутивы. Кстати, сейчас он пока что самосборный, а в будущем МЦСТ тяготеет к «экосистеме» Debian. Ещё надо упомянуть, что нативно под ним стартуют Astra Linux (Debian) и Alt-Linux (в некоторой степени — наследие «Mandrake», не «Mandriva»!).

          #928361 ↑
      • -5
        Нет аватара guest
        02.07.1712:59:39

        «x86 сложная и неэффективная архитектура"

        Хватит раздувать эти байки, х86 хорошая архитектура, как и АРМ, они ничем друг другу не уступают, если бы х86 был такой неэффективный, то АРМ бы его легко обошел, чего мы не наблюдаем, скорее они поделили рынок: x86 огромная производительность(странно да для «неэффективной» архитектуры), АРМ низкое энергопотребление.

        Проблема x86 строго административная, а точнее патентная, все закрыто патентами так что сделать процессор нельзя, его не разрашат прадавать ни в одной стране мира. У интел и АМД кросспатентный обмен, они готовы терпеть друг друга, но не третью компанию.

        #928200 ↑
        • Комментарий удален
        • 7
          Михаил Усоцкий Михаил Усоцкий
          02.07.1716:26:49

          На самом деле данная архитектура действительно сложная. В новостях можно не раз увидеть статьи о серьёзных ошибках в декодере команд. Надо сказать, что декодер команд у x86/x86-64 самый большой из всех известных нам. Именно они расходуют очень много энергии. Снизить энергопотребление в таких процессорах зачастую прибегают к сохранению декодированных команд в кэше, либо снижением частоты, либо уменьшением техпроцесса. Но такие процессоры действительно производительные. Но зачастую это из-за особенностей систем команд RISC (ARM) и CISC(x86/x86-64). RISC-процессорам порой требуется больше действий за единицу времени, чтобы достать или положить в памяти данные.

          #928250 ↑
          • 8
            Нет аватара kerosene
            02.07.1717:24:12

            У них не столько декодер сложный, сколько аппаратный шедуллер — устройство занимающееся выявлением зависимостей между командами. То самое внеочередное исполнение команд. Эльбрус же процессор с очередным исполнением. Он исполняет команды так, как их сформировал и расставил компилятор.

            Отредактировано: kerosene~17:24 02.07.17
            #928262 ↑
            • 5
              Михаил Усоцкий Михаил Усоцкий
              02.07.1717:31:45

              Да, согласен, это тоже. Видел блок-схемы, где планировщик занимал значительное место после декодера. У Эльбруса ещё называется статическим планированием. Поэтому компилятор для Эльбруса довольно продвинутый. А у Intel, соответственно, динамическое.

              #928266 ↑
          • 0
            shigorin shigorin
            26.10.1820:56:30

            В новостях можно не раз увидеть статьи о серьёзных ошибках в декодере команд

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

            Да, мельдоний и спектр спектров…

            #1080145 ↑
        • 5
          Нет аватара guest
          02.07.1718:46:31

          Вообще-то примерно 2/3 площади кристалла у х86/х64 процессоров занимают схемы преобразования команд из входной архитектуры во внутреннюю RISC-систему. Причём они намертво связаны в единый блок с диспетчером, отвечающим за спекулятивное исполнение и набивку конвейеров, так что даже чтобы открыть внутреннюю систему команд, процессор надо полностью перепроектировать с нуля. У Эльбруса же исполнение строго последовательное, а расстановкой команд занимается компилятор, так что из всей этой машинерии там стоит только ассоциативный кэш с системой управляемой подкачки.

          #928292 ↑
          • 0
            RadiantConfessor RadiantConfessor
            03.07.1705:49:47

            У Эльбруса же исполнение строго последовательное, а расстановкой команд занимается компилятор

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

            #928438 ↑
            • 0
              Нет аватара guest
              03.07.1715:45:52

              Ну да, но всё упирается в эффективность компилятора. Неспособность Штеуда сделать нормальный компилятор, не забивающий конвейеры НОПами, и привела к кошмару Итаника.

              #928592 ↑
              • 0
                RadiantConfessor RadiantConfessor
                03.07.1718:38:35

                Дак и от эффективности аппаратного блока тоже всё зависит. Его тоже нужно сначала придумать, потом «откомпилировать» в Verilog и реализовать в железе.

                #928662 ↑
        • 7
          shigorin shigorin
          02.07.1722:59:41

          Это хреновая архитектура, которая держится исключительно «на штыках» огромного наследия приложений и передовой технологии (не путать с архитектурой) интела. Все x86 «в душе» уже много поколений как RISC с прилепленным сверху транслятором из CISC.

          #928349 ↑
      • 12
        Нет аватара guest
        02.07.1713:58:24

        Наши вполне делают ARM, Байкал Электроникс делает процессоры Baikal на архитектуре ARM.

        #928220 ↑
        • 0
          shigorin shigorin
          26.10.1820:58:45

          По факту в прошлом году Байкал всё-таки не выпустил армовый вариант (М на v8), но уже шёл мипсовый (T1). А так-то армами (v7) ещё несколько лавок занимаются -- Элвис, сосед вон мой…

          #1080146 ↑
      • 9
        Михаил Усоцкий Михаил Усоцкий
        02.07.1716:14:27

        Наши делают ARM-процессоры. Поищите про процессор Байкал. Только читайте внимательно. Байкалы могут носить как MIPS, так и ARM, в зависимости от модели.

        #928249 ↑
        • 5
          shigorin shigorin
          02.07.1723:01:29

          Я пока не видел даже инженерников Байкал-М (ARM64), в отличие от вполне существующего Байкал-Т1 (MIPS32).

          #928350 ↑
      • 4
        Нет аватара guest
        02.07.1718:41:28

        С конца?!! Там куча хвостов ещё от 8008/4004 висит на самом деле, а это 72 год.

        #928287 ↑
      • 0
        Виктор Гюго Виктор Гюго
        03.07.1711:23:56

        > почему наши не делают ARM

        Делают и MIPS и ARM. Но ARM специфическая архитектура, на ниве серверов и десктопов у неё очень небольшая полянка.

        #928504 ↑
    • Комментарий скрыт по причине низкого рейтинга. показать
      • 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 ↑
    • 4
      Михаил Усоцкий Михаил Усоцкий
      02.07.1716:11:57

      Intel будет бить по почкам, то есть затаскает вас по судам, чтобы содрать с вас как можно больше денег за нарушение собственности на x86. С AMD немного другая история сложилась, из-за того со своими сверхдорогими Itanium Intel села в лужу. А AMD просто усовершенствовала x86 до x86-64. Intel использует наработки AMD, хотя и старается всем объяснять, что это их технология и они сами сделали. А разрабатывать процессоры на базе x86 как-то бессмысленно. Костыль на костыле работает. Что ни новость, то баги и ошибки в декодере команд, которые надо исправлять прошивками и заплатками.

      #928247 ↑
      • 0
        Alexander V Alexander V
        02.07.1716:45:28

        Есть еще VIA

        #928255 ↑
        • 3
          Михаил Усоцкий Михаил Усоцкий
          02.07.1717:00:14

          Есть, конечно. Но они не могут соперничать с монстрами в лице Intel Core iX или AMD Athlon / Ryzen. Максимум, что они могут соперничать — с Celeron / Pentium. Любой ARM легко уделает VIA. А тут как раз речь про самые быстрые процессоры, которые очень нужны всем нам. Особенно для разработчиков, занимающиеся в САПР или моделирование. Суперкомпьютеры в России, использующие зарубежные процессоры, контролируются американцами, чтобы мы не могли сделать что-то прорывное. А уж китайцам и вовсе запретили продавать. Таки появились у них собственные процессоры Гудзоны. И к тому же, VIA уже давно присутствует на рынке. Ещё до появления Pentium (появление данной торговой марки обязано судебному разбирательству на x86). Конечно, часть патентов уже перестала действовать за сроком годности. Но на некоторые части всё равно действуют патенты.

          Отредактировано: Михаил Усоцкий~17:15 02.07.17
          #928256 ↑
          • 4
            Нет аватара guest
            02.07.1718:01:34

            Процессоры у китайцев не совсем собственные, а сделаны на основе архитектуры MIPS в сотрудничестве с STMicroelectronics. Вообще с микроэлектроникой у китайцев(имеется в виду континентальный Китай) так себе, Тайвань — другое дело, но у них с самостоятельностью совсем плохо, приходится проворачивать схемы типа «организуем компанию в Китае, она заказывает разработку и производство компонентов на Тайване"(например мобильные «системы на чипе» MTK стоящие в подавляющем большинстве дешёвых телефонов и планшетов продаются от лица китайской компании, однако её хозяева, разработка и производство находятся на Тайване).

            #928276 ↑
            • 0
              Нет аватара segfault
              03.07.1709:10:15

              У китайцев есть и полностью собственные процессоры, посмотрите информацию о ShenWei.

              Отредактировано: segfault~11:34 03.07.17
              #928473 ↑
    • 5
      Нет аватара silicoid
      02.07.1717:50:12

      Интел очень жестко лицензирует свою систему команд.

      а между интелом и амд сужествует договор о корсслицензировании. скажем так интеловская 64-битная система команд есть, фактически, АМД64. вот так и живут.

      а всех остальных этот двуликий янус мочит в судах нещадно

      единственное, у кого еще осталась лицензия на х86. это виа. но сама виа скорее мертва чем жива

      #928270 ↑
      • 2
        Нет аватара guest
        02.07.1718:48:32

        Спасибо IBM, хихикс.    

        #928295 ↑
    • 0
      Олег Бахарев Олег Бахарев
      02.07.1722:54:32

      Потому что на архитектуру SPARC — очень дешевая легальная лицензия.

      #928342 ↑
      • 0
        Alexander V Alexander V
        02.07.1722:59:19

        На SPARC кроме Oracle кто-нибудь работает? Debian 8 уже не поддерживал SPARC, а на дворе Debian 9. Уж Debian всегда славился своей коллекцией поддерживаемых архитектур.

        #928348 ↑
        • 2
          Олег Бахарев Олег Бахарев
          02.07.1723:13:28

          А причем здесь Debian? На процессорах Эльбрус действует ОС Эльбрус или МСВС. Но поскольку это разновидность Linux, вы можете широко кастомизировать ее, там работает менеджер пакетов RPM и имеется список поддерживаемых пакетов.

          #928358 ↑
          • 0
            Alexander V Alexander V
            02.07.1723:18:03

            Вы представляете, что такое поддерживать экзотический дистрибутив?

            #928360 ↑
            • 0
              Виктор Гюго Виктор Гюго
              03.07.1711:20:26

              Да. Команды из толковых 5-6 человек вполне хватает.

              #928503 ↑
              • 0
                shigorin shigorin
                26.10.1821:03:53

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

                #1080147 ↑
        • 0
          RadiantConfessor RadiantConfessor
          03.07.1705:59:17

          На SPARC работают процессоры российских систем ПВО.

          #928442 ↑
      • 4
        shigorin shigorin
        02.07.1723:09:02

        Ну и собсно МЦСТ -- Московский Центр SPARC-Технологий, ага.

        PS@20181026: кстати, недавно выяснил, что это была историческая расшифровка, а теперь МЦСТ -- это просто МЦСТ.    

        Отредактировано: shigorin~21:04 26.10.18
        #928355 ↑
      • 0
        RadiantConfessor RadiantConfessor
        03.07.1705:58:48

        Архитектура SPARC не имеет отношение к архитектуре Эльбрус.

        #928440 ↑
    • 0
      Нет аватара superriva
      03.07.1710:41:23

      -> Почему от x86 архитектуры отказались? Intel и AMD как-то выпускают свои процессоры.

      Посмотрите википедию x86 уже по сути нету [ссылки отключены]

      «Наиболее широко используемые в настольных компьютерах процессоры архитектуры x86 ранее являлись CISC-процессорами, однако новые процессоры, начиная с Intel Pentium Pro (1995 г.), являются CISC-процессорами с RISC-ядром[10]. Они непосредственно перед исполнением преобразуют CISC-инструкции x86-процессоров в более простой набор внутренних инструкций RISC.

      После того, как процессоры архитектуры x86 были переведены на суперскалярную RISC-архитектуру, можно сказать, что большинство существующих ныне процессоров основаны на архитектуре RISC.»

      Отредактировано: superriva~10:43 03.07.17
      #928495 ↑
Для комментирования вам необходимо зарегистрироваться и войти на сайт,