стань автором. присоединяйся к сообществу!
Добавить новость можно всем, без премодерации, только регистрация
Лого Сделано у нас
kerosene 15 ноября 2014, 11:19 41 Информационные технологии

Фото дня! Первая инженерная партия «Эльбрус-8С» и южного моста «КПИ-2» готовы к тестированию!

8-ядерный микропроцессор «Эльбрус-8С» создан компанией «МЦСТ» по технологическому процессу 28-нм. Он содержит 8 универсальных процессорных ядер с архитектурой «Эльбрус» третьего поколения. Кажде ядро располагает кэш-памятью 2 уровня 512 Кб. Кэш-память 3 уровня 16 Мб является общей для всех ядер. Микропроцессор содержит встроенный 4-канальный контроллер памяти типа DDR3−1600. 3 высокоскоростных дуплексных каналов LVDS с пропускной способностью 8 Гб/сек в каждую сторону для организации 4-процессорных систем на одной материнской плате. Частота микропроцессора 1,3 ГГц. Производительность 249,6 Гфлопс на 32-разрядных числах с плавающей точкой. Микропроцессор совместим с новым южным мостом «КПИ-2»

читать полностью
Источник: mcst.ru
МЦСТ, Эльбрус-8С, микропроцессор, электроника
все комментарии
  • 1
    Нет аватара guest
    15.11.1418:05:02

    Тут есть одна маленькая проблемка — VLIW хорош в некотором классе вычислений, но при этом он очень плохо себя показывает в исполнении неоптимизированного под него кода. Банально особенность архитектуры. Поэтому представители оной в основном осели в DSP и всяких там видеокартах (Radenon HD6000 были на нем, например, но потом ушли в сторону своих разработок). Поэтому в повседневных задачах VLIW будет даже без эмуляции хуже чем x86 или ARM в рассчете на 1МГц частоты (и 1 ядро), зато да, в числодробилках будет показывать себя намного лучше (в рассчете на 1МГц частоты и одно ядро конечно). Только такие задачи это редкость.

    #588729 ↑
    • 12
      Нет аватара guest
      15.11.1418:23:13

      Там всё несколько сложнее. Фишка в том, что у МЦСТ, судя по всему, таки получилось то, что в своё время не вышло у Интела — разработать нормальный оптимизирующий компилятор, оптимально набивающий инструкциями ШКС. В первых версиях интеловских компиляторов до 80% ШКС составляли тупо НОПы, потому что компилятор не умел в разрешение зависимостей в коде, и именно поэтому Итаниум-1 в нативном режиме работал как в лучшем случае как Пентиум-3, а в режиме эмуляции х86 — и вовсе как 486-й. Только к Итаниуму-2, заглотив персонал Трансметы, у них получилось добиться более-менее нормальной производительности, но поезд уже ушёл.

      Кстати, всё вами сказанное совершенно справедливо и для современных суперскаляров, которые все out-of-order, то есть по факту тоже имеют как бы виртуальное широкое командное слово — просто оно нигде реально не фигурирует, а представляет собой поток внутренних микрокоманд, генерируемых декодером, блоком предсказаний ветвлений, переименовщиком регистров и прочими устройствами, занимающими в современных процессорах до 60−70% площади кристалла. Переложив их функции на компилятор, в МЦСТ просто выкинули всю эту дребедень с кристалла, значительно сократив его энергопотребление и повысив утилизацию такта.

      И именно за счёт этого у Эльбрусов настолько высока энергоэффективность и производительность на такт в нативном коде — по ощущениям от реальной работы, 500-МГц машина пахала на уровне как минимум втрое-четверо раз более быстрого по гольной частоте i3. Так что всё упирается в компилятор — если все реально так хорошо, как нам рассказывают, то можно пить шампанское ;)

      #588739 ↑
      • 0
        Нет аватара guest
        15.11.1419:08:58

        Я, понятное дело, живых Эльбрусов не видел, но когда учился в ВУЗе, к нам ребята из МЦСТ приходили, агитировать идти к себе на диплом, ориентируюсь только на то, что они сами говорили.

        Про OoO и прочее — да, это все понятно. Проблема в создании эффективного компилятора, который сможет генерировать код, из-за которого не будет часто сбрасываться конвеер. Для сложной математики или каких-то предсказуемых вещей это очень просто, а вот для софта общего назначения — архисложно. Тем более свой компилятор это тоже мягко говоря не очень то и плюс, если бы все это было в виде порта gcc или порта llvm — это одно, но МЦСТ не очень хочет показывать свое творение и периодически утверждает что они делали компилятор с нуля — значит что понимание стандартов языков там свое, поддержка языков также ограничена небольшим их набором (и небольшим набором версий стандартов) и так далее. Это тоже не пойдет на пользу процессору.

        #588752 ↑
        • 1
          Нет аватара guest
          15.11.1419:40:46

          Ещё в прошлом году на ЛОРе были люди, которые крутили в руках первые версии чипа и компиляторы к ним. По их словам компиляторы собственной разработки, но 100% совместимы с gcc, правда не самых свежих версий.

          #588757 ↑
          • 0
            Нет аватара guest
            15.11.1420:06:18

            Я в «собственной разработки, но совместим с gcc» не верю честно говоря. Т.к. это или backend для gcc или он не совместим на 100%. В ГЦЦ слишком много специфичных расширений, трактовок, багофич и так далее, чтобы это реально было сделать.

            Это не говоря о том многообразии языков и их стандартов, которые поддерживаются даже в старых версиях гцц. Нет, конечно теоретически нет ничего невозможного, но если это так, то это не самое эффективное вложение денег, я бы сказал.

            #588767 ↑
            • 0
              Нет аватара guest
              16.11.1405:30:43

              Если у них пингвин собирается из непиленых исходников (кроме библиотеки реального времени и немножко ядра), то компилятор (да и весь тулчейн, тащемта) таки обязан быть совместим с гцц, нес па? ;) Конечно, можно быть уверенным, что он поддерживает далеко не все возможности, но саморазворот системы он обеспечивает, кросскомпиляция, по слухам, не нужна.

              #588855 ↑
              • 0
                Нет аватара guest
                16.11.1405:47:18

                Про «непиленные» исходники я не слышал честно говоря ничего, поэтому не скажу ничего. Пусть исходники покажут, тогда и будет видно насколько они «непиленные». Ядро то точно свое, в апстриме нет поддержки Эльбруса.

                Чем более тулчейн будет совместим с гцц, тем больше непатченного софта будет собираться и тем меньше новых уникальных косяков встретится. Одно дело, когда поддерживается сборка всех пакетов дебиана (помоему их колличество уже приближается к 100 тысячам штук), другое когда только базовая система и пара программ сверху. К тому же у gcc достаточно неплохой оптимизатор кода, чтобы его повторить или превзойти нужны многие годы разработки.

                #588857 ↑
                • 1
                  Нет аватара guest
                  16.11.1407:33:51

                  Проблема только в том, что и кодогенератор, и оптимизатор gcc все эти годы пилились в первую очередь под х86 и олдскульные RISC’и, что такое широкое командное слово и с чем его едят они понятия не имеют. Главное ноу-хау МЦСТ — как раз в разработке технологии выявления и разделения потоков управления и данных в AST, что позволяет вычленять независимые друг от друга сегменты кода и разбрасывать их по разным исполняющим устройствам. Плюс разные аппаратные вкусности, рассчитанные на более эффективное исполнение кода высокого уровня: аппаратная поддержка контекстов исполнения (там есть регистры дескрипторов задач, например), регистровый файл совмещённый со стеком и оборудованный аппаратной защитой контекстов, ассоциативный кэш первого уровня, в который вылезают хвосты регистровых файлов задач, аппаратная подкачка массивов, модуль обработки циклов и прочая. ГЦЦ всего этого просто не понимает, единственное что он умеет — это распознавать кодовые паттерны в AST и ляпать вместо них бинарные патчи из базы. ;)

                  #588863 ↑
                  • 0
                    Нет аватара guest
                    16.11.1411:59:46

                    У GCC есть несколько стадий оптимизации и в целом интересна кодогенерация. Я думаю не надо напоминать, что большая часть оптимизаций является архитектуронезависимой? Они могли бы вполне написать хороший backend для своей архитектуры для gcc и получить все плюшки оптимизации кода. Аппаратным фишкам как раз и можно научить на этапе написания backend’а.

                    Отредактировано: Vladimir Smirnov~13:01 16.11.14
                    #588893 ↑
                    • 0
                      Нет аватара guest
                      16.11.1412:17:59

                      Вы не читали МЦСТшную книжку про их архитектуру? У меня большое сомнение, что банальный бэк-энд справится с тамошними архитектурными различиями, там по-хорошему полноценный новый кодогенератор и оптимизатор нужны. В первую очередь потому, что структура оптимизации нужна совершенно иная — нужно, например, перетасовывать инструкции не так, чтобы на них не спотыкался предсказатель ветвлений (которого в процессоре просто нет), а так, чтобы они не ожидали результата друг друга и их можно было распихать в потоки разных исполняющих устройств. А перед самой инструкцией ветвления нужно воткнуть инструкции преподкачки кода и данных для обеих ветвей — у Эльбруса раздельные кэши 1-го и 2-го уровней для кода и данных, общий — только 3-го уровня: он, строго говоря, вообще гарвардский, а не фон-Неймановский внутри. И так далее…

                      #588898 ↑
                      • 0
                        Нет аватара guest
                        16.11.1418:43:05

                        К сожалению не читал.

                        Опять же, у GCC есть разного типа оптимизации. И довольно значительная часть — не зависит от архитектур, т.к. банально уменьшает колличество результирующего кода.

                        В любом случаи, пока простые люди вроде меня не могут себе приобрести компьютер на базе Эльбруса и пока исходники GPL софта не выложены — можно только догадываться о том, что они сделали с компилятором и как. Просто есть некоторая вероятность, что они могли взять GPLый софт и выдать за свое (военным так вообще в целом безразлично GPL или не GPL).

                        #588968 ↑
                        • 0
                          Нет аватара guest
                          17.11.1403:01:20

                          А вы почитайте, она у них на сайте свободно лежит. Это ОЧЕНЬ своеобразное и интересное устройство, к которому готовые рецепты просто неприменимы.

                          #589049 ↑
                          • 0
                            Нет аватара guest
                            17.11.1411:52:50

                            Да, спасибо, почитаю.

                            Про рецепты — я еще раз говорю, что у GCC есть платформонезависимая часть с оптимизациями, она как раз применима ко всему, т.к. банально упрощает имеющийся код, прежде чем из него генерировать ассемблер.

                            И я еще раз повторю — что пока нет общедоступных железок за вменяемые деньги и пока МЦСТ не выложит исходники GPL кода, в целом бесполезно гадать использовали ли они ГЦЦ и просто наплевали на GPL или правда сделали свое, а если сделали, то каков его уровень совместимости с GCC.

                            #589158 ↑
                        • 0
                          RadiantConfessor RadiantConfessor
                          20.11.1400:22:33

                          Они не могли взять GPL и выдать за свой. Архитектура не позволит.

                          #590021 ↑
                          • 0
                            Нет аватара guest
                            20.11.1401:05:47

                            Почему не позволит? Написать кодогенератор, а frontend взять от gcc.

                            #590023 ↑
                            • 0
                              RadiantConfessor RadiantConfessor
                              20.11.1402:59:17

                              1. VLIW в Эльбрусе позволяет выполнять 21 команду за такт, а это значит можно сразу несколько С++ команд организовать в одной машинной команде. Тут нужно не каждую отдельную команду С++ преобразовывать в машинный код, а целые блоки.

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

                              #590026 ↑
                              • 0
                                Нет аватара guest
                                20.11.1403:29:37

                                Не могу не вмешаться в вашу беседу.

                                Ого! Не знал. Вообще не думал, что так возможно. Это получается, что если компилятор ошибся, то код получается чуть менее оптимальный и при желании можно сделать красную кнопку «доработать человеком»?

                                #590029 ↑
                                • 0
                                  RadiantConfessor RadiantConfessor
                                  20.11.1403:31:37

                                  По этому его и назвали, Суперкомпилятор.

                                  На самом деле ошибается и аппаратный предсказатель ветвлений. Когда он ошибается приходится заполнять кэш новыми данными из относительно медленной памяти.

                                  #590030 ↑
                                  • 0
                                    Нет аватара guest
                                    20.11.1407:15:09

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

                                    #590041 ↑
                              • 0
                                Нет аватара guest
                                20.11.1408:55:40

                                И еще раз, ну позволяет, и что? Конкретно в gcc (впрочем в clang’е тоже что-то похожее) код на языке высокого уровня преобразуется сначала в промежуточное представление на RTL, а затем уже из rtl генерируется машинный код. Кто мешает, каким бы особенным ни был VLIW, взять уже готовую часть трансляции в RTL + все оптимизации (т.е. взять frontend часть от gcc) и написать свой RTL -> VLIW (т.е. бэкэнд для гцц)? Пока кроме «он не такой как все» не было названо ни одной причины. GCC умеет достаточно большое колличество архитектур, притом с ходу нашлась поддержка 4-х VLIW архитектур, не считая DSPшек. Я еще раз повторю, что не вижу пока в этих двух пунктах никаких причин чтобы не взять примерно 2/3 от gcc и дописать 1/3 самостоятельно. Как бонус автоматически получается использование всех поддерживаемых в gcc языков и большая часть оптимизаций, которые идут на уровнях до RTL включительно.

                                P. S. Да и как бы сейчас абсолютно все процессоры умеют выполнять куда более одной команды за такт. Конечно не 21, но все же. И более того, под каждый процессор нужно знать особенности его работы (как работает предсказатель ветвлений и т. п., на каждую интеловскую микроархитектуру существуют многостраничные гайдлайны по тому какой код эффективнее будет работать), чтобы генерировать эффективный ассемблерный код.

                                Отредактировано: Vladimir Smirnov~10:03 20.11.14
                                #590060 ↑
                                • 0
                                  RadiantConfessor RadiantConfessor
                                  20.11.1409:00:42

                                  А графы по вашему кто строит?

                                  #590064 ↑
                                  • 0
                                    Нет аватара guest
                                    20.11.1409:03:51

                                    А кто мешает это делать backend’у, транслирующему RTL в машинный код?

                                    #590065 ↑
                                    • 0
                                      RadiantConfessor RadiantConfessor
                                      20.11.1410:41:32

                                      Наверное, вы хотели сказать, должно быть что-то между RTL и backend`ом?

                                      #590086 ↑
                                      • 0
                                        Нет аватара guest
                                        20.11.1410:46:31

                                        Да не принципиально как это воспринимать. Никто не мешает из RTL’я иметь свой собственный генератор, который бы делал практически любую магию, а на выходе выдавал уже готовый код. Для краткости проще это все назвать backend’ом (что может быть и не совсем корректно с формальной точки зрения).

                                        #590090 ↑
                                        • 0
                                          RadiantConfessor RadiantConfessor
                                          20.11.1411:10:11

                                          Тогда bakend будет составлять самую сложную и большую часть gcc.

                                          #590096 ↑
                                          • 0
                                            Нет аватара guest
                                            20.11.1411:19:23

                                            А это не такой простой вопрос. Бэкэнд сложный всегда, да. Но это позволяет использовать уже готовую инфраструктуру и автоматом получить поддержку всех языков, которые поддерживает gcc (я только по памяти могу вспомнить порядка 12, не считая разных их стандартов). Согласитесь, что реализовать поддержку хотя бы C (ANSI, 89, 99, 14), C++ (c98, 2011, 2014) и fortran (77, 90, 95, 2003, 2008) это уже не очень простая задача. А потом вспомните, что таких языков не 3 как я перечислил, а не менее 12. И опять же, у гцц есть какой-никакой оптимизатор работающий на уровне RTL и позволяющий хотя бы слегка минимифицировать код. Делая свой компилятор с нуля нужно будет все это реализовывать с нуля, а чтобы собрать ядро линукса, оное надо будет или патчить или в компиляторе реализовывать поддержку GNU-расширений хотя бы для C. Вон Clang пытается протолкнуть патчи для сборки ядра (как в себя, так и в ядро) уже не первый год и пока mainline clang не может собрать mainline ядро целиком даже на x86.

                                            #590097 ↑
                                            • 0
                                              RadiantConfessor RadiantConfessor
                                              21.11.1414:23:49

                                              Как сказали специалисты МЦСТ у них не gcc. Когда-то у них был купленный gcc, но они от него полностью отказались. Текущий компилятор написан ими полностью с нуля, самостоятельно. Компилятор поддерживает форматы gcc.

                                              #590684 ↑
                                              • 0
                                                Нет аватара guest
                                                21.11.1414:29:43

                                                Фраза очень клево звучит, учитывая что gcc — GPLv3 софт. Я не нашел, к слову, как купить gcc. Вот совсем. Для ARM есть платные сборки от некоторых компаний (в комплекте с IDE), но не более того.

                                                Если написан полностью с нуля — это печально по причине поддержки стандартов. То, что умеет gcc в плане языков и стандартов, они своими силами будут пилить очень и очень долго. А это значит, что использование в домашней-корпоративной среде плат на Эльбрусе будет очень затруднено дополнительными несовместимостями компилятора. Если они заявляют что умеют все то же, что и гцц, то скорее всего или врут в этом месте или врут что не использовали код из гцц.

                                                #590688 ↑
                                                • 0
                                                  RadiantConfessor RadiantConfessor
                                                  21.11.1414:51:04

                                                  Нет там ничего печального. Их компилятор полностью совместим по форматам с gcc. По этому у них есть и С, С++ и Fortran`ы.

                                                  Лучше поговорите сами с КТ вот здесь

                                                   http://forum.ixbt.com/top...c.cgi?id=8:24645−82 

                                                  Отредактировано: Zveruga~15:53 21.11.14
                                                  #590693 ↑
                                                  • 0
                                                    Нет аватара guest
                                                    21.11.1415:13:43

                                                    За ветку спасибо. Хотя читать 80 страниц честно говоря сильно влом, а по последним 5-и страницам понять что у них на самом деле реализовано и как — не получилось. Есть фразы про «мы написали компилятор с нуля», потом есть оговорки «кроме фронтэнда», а что как фронтэнд использовалось — не очень понятно, на этот вопрос ничего кроме «почитайте тему с начала, там есть ответ» нету.

                                                    У вас кстати терминология слегка прихрамывает. Не по форматам, а по расширениям (точнее в той же теме сказано про макросы и препроцессор, про остальное тоже ни слова). Вопрос еще в том, как оно понимает стандарты, насколько точно реализует внутренние структуры гцц (есть некоторый высокопроизводительный софт, который позволяет себе подхачивать внутренности libgcc в рантайме, понятное дело не с помощью gcc оно не собирается).

                                                    Так что я все равно скептически отношусь, т.к. раз «свое» значит будут проблемы со стандартами и gcc-специфичными расширениями.

                                                    #590699 ↑
                                                    • 0
                                                      RadiantConfessor RadiantConfessor
                                                      21.11.1415:49:09

                                                      Давайте уж лучше там продолжим эти беседы.

                                                      И эта тема не на 80 страниц, эта тема уже переоткрывалась не менее 5 раз.    

                                                      #590711 ↑
                                • 0
                                  Нет аватара guest
                                  20.11.1409:16:25

                                  Да и как бы сейчас абсолютно все процессоры умеют выполнять куда более одной команды за такт.

                                  А разве они не в конвейере одна за другой стоят?

                                  #590066 ↑
                                  • 0
                                    Нет аватара guest
                                    20.11.1410:56:19

                                    К сожалению, проще послать в обзорные материалы по конкретной микроархитектуре, чем устраивать пересказ. Например по Intel’овским Haswell’ам начиная с Frontend’а и далее ([ссылки отключены] и далее или [ссылки отключены] или искать соответствующего класса обзоры по конкретно интересующим микроархитектурам (к сожалению, по тем же ARM или Power это не всегда просто сделать).

                                    #590092 ↑
                                    • 0
                                      Нет аватара guest
                                      20.11.1411:06:50

                                      У Вас ссылки ортключены))))

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

                                      #590095 ↑
        • 2
          RadiantConfessor RadiantConfessor
          15.11.1419:46:25

          Специалисты говорят, что МЦСТ создали суперкомпилятор, в создание которого многие не верили.

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