стань автором. присоединяйся к сообществу!
Лого Сделано у нас
105
treins 28 января 2018, 18:27

C 2008 по 2018 год скорость российских процессоров увеличилась в 10 000 раз

Следи за успехами России в Телеграм @sdelanounas_ru
  •  © i.imgur.com

Вычислительная мощность российского 8-ядерного процессора МЦСТ Эльбрус-16С (международное название Elbrus-8CV, выпуск запланирован на 2018 год) составляет 576 Гфлопс, Китайского 8-ядерного Longson 3B3000 (2017 год) — 192 Гфлопс, 8-ядерного Intel Core i7-5960X (Extreme Edition Haswell-E, 2014 год) — 350 Гфлопс.

читать полностью


  • treins
  • 71
  • 0
    Нет аватара guest
    29.01.1820:06:47

    Начиная с 8С, в котором появилась поддержка х64, МЦСТ, вроде, тоже перешли на подсчёт в двойной точности. А похуже потому, что всё сильно зависит от алгоритма, зависимостей данных и степени его внутреннего параллелизма. Если зависимостей мало и алгоритм хорошо распараллеливается, то Эльбрус будет такт-на-такт даже производительнее штеуда, а нет — например, если в алгоритме многочисленные зависимости данных, гонки или много ввода-вывода, — ну на нет и суда нет, всё упрётся в производительность единичного конвейера, то есть, в сущности, в тактовую частоту.

    • 0
      Нет аватара guest
      29.01.1822:24:04

      Вики: «Производитель заявляет, что при 1,3 ГГц Эльбрус-8С имеет производительность около 250 гигафлопсов на операциях с одинарной точностью (FP32)"

      Все верно, просто заточить программу под Эльбрус чтобы она по максимуму выжала из него производительность, сложнее, чем для интел. Потому как надо как-то задействовать все 25 операций, которые выполняются за 1 такт Эльбрусом. Тогда производительность будет близка к пиковой. В реальных задачах, хотя бы 50% задействовать довольно сложно. Наверно есть какие-то специфические реальные задачи, где можно задействовать конвейер Эльбруса на 90-100%, но я пока про такие не слышал.

      Например, реально можно сравнить по SPEC — где-то тут sdelanounas.ru/blogs/95446/ на Суне были тесты, ниже есть коммент (я так понял везде производительность на ядро, однопоток):

      Эльбрус-8С (1300 MHz, 8 cores) — 13,03/17,02

      Уровень производительности соответствует (int/fp):

      Intel Xeon processor X5355 (2667 MHz, 8 cores) — 16.0/16.9 (2006г)

      AMD Opteron 6164 HE (1700 MHz, 12 cores) — 14.2/19,5 (2010г)

      Fujitsu SPARC Enterprise M3000 (2750 MHz, 4 cores) — 13,6/15,2 (2010г.)

      Т.е. в общем неплохо, но не надо верить байкам про то, что наш процессор порвал Интел. Этого пока нет к сожалению. Но главное что прогресс есть и производительность уже достаточная для нормальной работы ну скажем для 60-80% пользователей (особено в гос конторах)

      • 0
        Нет аватара guest
        30.01.1805:01:13

        Не сложнее, а не каждую можно. Дело в том, что вы, похоже, отчего-то считаете, что 24 (а не 25) операций за такт — это длина конвейера. На самом деле конвейер в Эльбрусах обычный, 4-шаговый, просто у него 6 параллельных АЛУ. Если компилятору удаётся раскидать исполнение в 6 независимых потоков — получаем полную производительность, нет — производительность падает сообразно числу незадействованных АЛУ. Реальных задач таких на самом деле много, просто большинство десктопных приложений, где много ввода-вывода и взаимодействия с пользователем, к ним не относятся. А вот игры — таки вполне.

        Отредактировано: Andrey Tupkalo~05:09 30.01.18
        • 0
          Нет аватара guest
          30.01.1821:06:32

          У 4с — 24 операции за такт, у 8с — 25. А в остальном согласен, но думаю все равно это не просто сделать, иначе бы уже были какие-нибудь программы, которые бы на Эльбрусе выполнялись бычсрее чем на Интел-ах

          • 0
            Нет аватара guest
            01.02.1821:31:26

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

            Наоборот, что бы выжимать из интела приходится писать на ассемблере и придумывать как напялить задачу на весьма неудобный SIMD, а в итоге последнее слово все равно за машиной которая в некоторых не тепичных случаях конкретно так лажает и исправить это никак. В случае эльбруса через его ассемблер контролируется практически все что происходит на этапе исполнения кода, то есть обход всяких таких корявых мест по крайней мере возможен; 23 операции/такт хоть и являются маркетинговыми все-таки операции скалярные и позволяют их замешивать в гораздо более удобном под конкретную задачу виде.

            Ассемблер эльбруса, в связи с том что он позволяет контролировать снаружи весь процесс, напичкан всякой служебной информацией и трудно читаем, плюс к этому в нем уже должны быть грамотно переставлены операции, проведены оптимизации что в принципе делает написание на нем руками чего-то такого мощного и скоростного практически невозможным, так как штатный компилятор знает и понимает (да и видит) уже больше и может в итоге оказаться что компилированный им код на С++ с оптимизациями быстрее написанного руками, поэтому с эльбрусом в основном рекомендуется писать на высокоуровневых языках и компилировать с ключами оптимизаций, в ассемблер только поглядывать. Конечно компилятор все равно не идеален и может лажать то-же, для чего ему можно делать в коде подсказки и пихать в опции компиляции всякие параметры. То есть не требует (и даже более того — не рекомендует) прибегать к ассемблеру — только яву и мощный компилятор, еще +

            Практически по всем параметрам писать эффективные программы под него по идее проще.

            иначе бы уже были какие-нибудь программы, которые бы на Эльбрусе выполнялись бычсрее чем на Интел-ах

            Есть, шифрование например. Потенциально наверняка бы хорошо ложились кодирование/декодирование видео, обработка изображений и тому подобное. Но это надо точно так же — брать конкретную программу (например libvpx) и исследовать что нужно что бы его ускорить на конкретной архитектуре используя ее потенциал по максимуму, как для всех остальных делают. Хотя нет, чаще может оказаться что там тупо ничего не сделать — ну вот оно написано так тупо с прицелом на процессоры интел (а все остальные как-нибудь сами подстроятся), как-то сильно ее переписывать не имеет смысла потому что потом попросту никто не примет такой объем правок будешь сам его сидеть поддерживать. Поэтому полезнее скорее будет исследовать отдельные алгоритмы и то как они ложатся на архитектуру эльбруса, разработчики со своими программами потом сами подтянутся.

            Отредактировано: Isaac Newton~21:49 01.02.18
            • 0
              shigorin shigorin
              04.02.1800:33:24

              Если что, мы уже потихоньку проталкиваем в апстримы правки, получившиеся при портировании альта на эльбрус. Начиная вот с этой.

    • 0
      shigorin shigorin
      04.02.1800:29:32

      Начиная с 8С, в котором появилась поддержка х64

      В смысле?

      • 0
        Нет аватара guest
        04.02.1808:20:20

        Могу, конечно, и путать, но в 2С, ЕМНИМС, поддерживался только х86, а 64-битные команды не воспринимались, а вот в 8С уже таки да. Насчёт четвёрки не уверен.

        • 0
          shigorin shigorin
          07.02.1816:05:21

          2С видел только глазами на полочке и по ssh => без всякого там rtc; на 4С он прекрасно работает и с x86 (один бинарь), и с x86_64 (второй).

          • 0
            Нет аватара guest
            08.02.1803:00:33

            Ну, тады понятно.

Написать комментарий
Отмена
Для комментирования вам необходимо зарегистрироваться и войти на сайт,