Лого Сделано у нас
116

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

  •  © 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 Гфлопс.

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

Читайте также...

Вступайте в наши группы и добавляйте нас в друзья :)

Подпишитесь на наш канал в Яндекс.Дзен и сделайте вашу ленту объективнее!
  • 3
    Нет аватара Захарка
    29.01.1808:08:25

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

    На счёт того, что Эльбрус 16С и 8Св — одно и то же, честно говоря, не уверен.

    Отредактировано: Захарка~08:15 29.01.18
    • 3
      Сергей Барановский
      29.01.1814:43:57

      Там куча ошибок. Написано с 2008 — в 10 000 раз, но в самой табличке видно на 2008 год был первый Эльбрус 4,8 Гфлопс, сейчас есть 8с — 250 Гфлопс. Ну даже если 8СВ посчитать (а он пока тока инженерник) — 576 Гфлопс, никак 10 000 не получится. в 100 раз получается.

      Если имелось в в иду с 2000 года, а не с 2008 — то будет получше, но все равно не 10 000. Насчет Эльбруса 16С — изначально планировалось что в нем будет 16 ядер, а потом сделали 8. Так что как бы он там вроде обозначен как 16с (и википедии и в госзаказе вроде), но по сути это 8СВ. Хотя в 2021 хотят выпустить 16с — 16 ядерный, так что да тут путаница. Ну понятно почему — не получилось 16 ядер впихнуть в 28 нм. По ходу у китайцев — если перейти по ссылке из этой статьи — все еще хуже. У них вместо 8-ядерника получился 4-ядерник, на частоте 1.3-1.5. Т. е. он реально хуже Эльбруса.

      Еще наверно есть ошибки в производительности, МЦСТ обычно указывает одинарной точности (32 разряда), а Интел двойной вроде. Китайцы тоже думаю одинарной — но все это проверять надо. Ну и это пиковая- теоретическая производительность, в реальности все похуже, причем для Эльбруса похуже, чем для интела.

      Отредактировано: Сергей Барановский~14:48 29.01.18
      • 0
        Andrey Tupkalo Andrey Tupkalo
        29.01.1820:06:47

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

        • 0
          Сергей Барановский
          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
            Andrey Tupkalo Andrey Tupkalo
            30.01.1805:01:13

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

            Отредактировано: Andrey Tupkalo~05:09 30.01.18
            • 0
              Сергей Барановский
              30.01.1821:06:32

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

              • 0
                Isaac Newton Isaac Newton
                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
            Andrey Tupkalo Andrey Tupkalo
            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
        shigorin shigorin
        04.02.1800:29:03

        Так что как бы он там вроде обозначен как 16с (и википедии и в госзаказе вроде), но по сути это 8СВ. Хотя в 2021 хотят выпустить 16с — 16 ядерный, так что да тут путаница.

        8СВ и 16С -- разные камушки, первый и впрямь уже есть в образцах.

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