MAX
Подпишись
стань автором. присоединяйся к сообществу!
15 ноября 49
174
kerosene Информационные технологии

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

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

[читать статью полностью...]

Кстати, а вы знали, что на «Сделано у нас» статьи публикуют посетители, такие же как и вы? И никакой премодерации, согласований и разрешений! Любой может добавить новость. А лучшие попадут в наш Телеграм @sdelanounas_ru. Подробнее о том как работает наш сайт здесь👈

Источник: mcst.ru

Комментарии 0

Для комментирования необходимо войти на сайт

все комментарии
  • 0
    Нет аватара guest15.11.14 19:08:58

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

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

    #588752 ↑
    • 1
      Нет аватара guest15.11.14 19:40:46

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

      #588757 ↑
      • 0
        Нет аватара guest15.11.14 20:06:18

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

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

        #588767 ↑
        • 0
          Нет аватара guest16.11.14 05:30:43

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

          #588855 ↑
          • 0
            Нет аватара guest16.11.14 05:47:18

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

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

            #588857 ↑
            • 1
              Нет аватара guest16.11.14 07:33:51

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

              #588863 ↑
              • 0
                Нет аватара guest16.11.14 11:59:46

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

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

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

                  #588898 ↑
                  • 0
                    Нет аватара guest16.11.14 18:43:05

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

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

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

                    #588968 ↑
                    • 0
                      Нет аватара guest17.11.14 03:01:20

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

                      #589049 ↑
                      • 0
                        Нет аватара guest17.11.14 11:52:50

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

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

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

                        #589158 ↑
                    • 0
                      RadiantConfessor RadiantConfessor20.11.14 00:22:33

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

                      #590021 ↑
                      • 0
                        Нет аватара guest20.11.14 01:05:47

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

                        #590023 ↑
                        • 0
                          RadiantConfessor RadiantConfessor20.11.14 02:59:17

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

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

                          #590026 ↑
                          • 0
                            Нет аватара guest20.11.14 03:29:37

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

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

                            #590029 ↑
                            • 0
                              RadiantConfessor RadiantConfessor20.11.14 03:31:37

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

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

                              #590030 ↑
                              • 0
                                Нет аватара guest20.11.14 07:15:09

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

                                #590041 ↑
                          • 0
                            Нет аватара guest20.11.14 08: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 RadiantConfessor20.11.14 09:00:42

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

                              #590064 ↑
                              • 0
                                Нет аватара guest20.11.14 09:03:51

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

                                #590065 ↑
                                • 0
                                  RadiantConfessor RadiantConfessor20.11.14 10:41:32

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

                                  #590086 ↑
                                  • 0
                                    Нет аватара guest20.11.14 10:46:31

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

                                    #590090 ↑
                                    • 0
                                      RadiantConfessor RadiantConfessor20.11.14 11:10:11

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

                                      #590096 ↑
                                      • 0
                                        Нет аватара guest20.11.14 11: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 RadiantConfessor21.11.14 14:23:49

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

                                          #590684 ↑
                                          • 0
                                            Нет аватара guest21.11.14 14:29:43

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

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

                                            #590688 ↑
                                            • 0
                                              RadiantConfessor RadiantConfessor21.11.14 14:51:04

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

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

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

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

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

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

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

                                                #590699 ↑
                                                • 0
                                                  RadiantConfessor RadiantConfessor21.11.14 15:49:09

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

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

                                                  #590711 ↑
                            • 0
                              Нет аватара guest20.11.14 09:16:25

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

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

                              #590066 ↑
                              • 0
                                Нет аватара guest20.11.14 10:56:19

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

                                #590092 ↑
                                • 0
                                  Нет аватара guest20.11.14 11:06:50

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

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

                                  #590095 ↑
    • 2
      RadiantConfessor RadiantConfessor15.11.14 19:46:25

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

      #588760 ↑