стань автором. присоединяйся к сообществу!
Добавить новость можно всем, без премодерации, только регистрация
Лого Сделано у нас
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С, микропроцессор, электроника
все комментарии
  • 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 ↑
Для комментирования вам необходимо зарегистрироваться и войти на сайт,