MAX
Подпишись
стань автором. присоединяйся к сообществу!
15 ноября 50
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
    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 ↑