MAX
Подпишись
стань автором. присоединяйся к сообществу!
20 декабря 44
197

Первый предсерийный ПК на базе микропроцессора Эльбрус-8С1

Камрад Максим Горшенин представил первый краткий видеообзор первого предсерийного ПК «Эльбрус-801-PC» на базе новейшего 8-ядерного микропроцессора «Эльбрус-8С1». Тактовая частота 1,3 ГГц!

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

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

Источник: www.youtube.com

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

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

  • 2
    Нет аватара guest20.12.16 13:37:19

    Падение производительности в среднем около 20% по сравнению с тем, как если бы софт, написанный для x86, был бы скомпилирован под Эльбрус.

    Что-то не верится. Прямо на днях здесь был обзор про Эльбрус, и кто-то в комментариях давал ссылки на Хабр, там подробно расписывали, что производительность достигается за счет широких слов инструкций — VLIW, и эти широкие слова компонует компилятор статически.

    Тогда как транслятор, про который вы говорите, делает преобразование «на лету». Какой же тогда смысл в этом навороченном VLIW, если разница составляет всего лишь смехотворные 20%?

    • 4
      Павел Дурнов Павел Дурнов20.12.16 14:04:38

      Вообще транслятор на процессорах с архитектурой VLIW явление не новое, у меня дома лежит ноут с Transmeta Effencion который вполне нормально работает под x86(2002 года вроде). Основным плюсом такого подхода является добавление новых инструкций процессора «на лету» без изменений в железе. А падение производительности в 20% это во первых достаточно много, а во вторых это среднее значение, в различных операциях снижение производительности может быть как больше, так и меньше. Поэтому предпочтительно все-таки нативный код, и желательно оптимизированный. Но в случае надобности можно использовать и x86-64 и IA64 и любую другую систему команд, достаточно просто написать транслятор.

      • 3
        Нет аватара guest20.12.16 14:14:24

        Ну смотрите, если вы на полном серьезе считаете, что «20% - это достаточно много», то зачем тогда огород городить со сложным VLIW, который заведомо не даёт расти частотам (та же проблема и с Itanium — его частоты намного ниже, чем у банального Xeon)? Даже просто сравнить процессоры поколения Core 2 и современных версий ядра Intel x86 — там нет никаких революционных изменений, просто эволюционное поэтапное развитие из года в год, и то суммарная разница выходит больше 20%.

        Нет, 20% - это ни разу не много, это как разница между 2 ГГц и 2,4 ГГц. Хотя на том же хабравском обзоре фигурировали цифры разницы порядка несколько раз в пересчете на МГц (это когда сравнивали Эльбрус с Интелом). Но так не может быть, тут надо или крестик снять, или трусы надеть, — у нас либо VLIW рвёт стандартный конвейер, либо не рвёт и даёт всего 20%.

        • 3
          Павел Дурнов Павел Дурнов20.12.16 14:40:04

          Вы путаете архитектуру процессора и набор команд процессора. Транслятор не меняет архитектуру, транслятор переводит команды х86 в команды VLIW для выполнения процессором. То есть 20% производительности тратится на перевод команд из одной системы в другую и обратно.

          Нет изменений? Вы серьезно? Что совсем, совсем? Я не говорю про архитектурные изменения, типа переноса на ядро всего северного моста и видеоядра, но хотя бы новые наборы команд то вы слышали(SSE4.1, SSE4.2, AVX, AVX2, FMA3, VT-x, VT-d, AES-NI, CLMUL, TXT, TSX)? А про аппаратное ускорение шифрования? Это как раз привязка к набору команд древнего как мамонт процессора Intel 8088 образца 1979 года тормозит развитие процессора…

          Частоты то Вам зачем? Merom на равных частотах будет проигрывать Skylake в разы именно за счет архитектуры.

          • -1
            Нет аватара guest20.12.16 15:06:32

            Вы хотите сказать, что динамический транслятор настолько эффективен, что теряет всего лишь 20% от производительности, по сравнению со статической компиляцией? И эти сведения получены из какого-то достоверного источника, а не придуманы лично вами или кем-то еще?

            Отредактировано: Настя Вилкова~17:07 20.12.16
            • 2
              Павел Дурнов Павел Дурнов20.12.16 15:32:22

              Мопед не мой!     Почем купил — потом продал, информация от автора поста!

            • 4
              Нет аватара kerosene20.12.16 16:04:28

              Вы читать умеете или блондинка? Где я писал, что 20% приходится на потери динамической трансляции? Я писал, что код, оттранслированный системой динамической трансляции из x86 в нативный эльбрусовский работает в среднем на 20% медленнее, чем код, полученный из исходников скомпилированных сразу под Эльбрус. Не верите? Сходите на сайт конторы ElTechs (стартап бывших сотрудников МЦСТ) и посмотрите на их систему ExaGear динамической трансляции кода x86 в код ARM.

              • Комментарий удалён
              • 2
                Нет аватара guest20.12.16 16:39:08

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

          • 1
            Нет аватара silicoid20.12.16 21:40:18

            то как раз привязка к набору команд древнего как мамонт процессора Intel 8088 образца 1979 года тормозит развитие процессора

            Ну. строго говоря никакой привязки к 8086 там уже нет. (8088, это кастрированная версия 8086 с 8ми разрядной шиной данных, вместо 16ти разрядной)

            уже давным давно, начиная с P6 все машкоды декодируются во внутреннюю систему команд, а потом уже эти внутренние команды исполняются исполняются.

        • 4
          Нет аватара guest20.12.16 17:01:32

          хабравском обзоре фигурировали цифры разницы порядка несколько раз в пересчете на МГц

          только вы забыли уточнить в чью пользу. Почти во всех тестах Эль 4с был почти в два раза быстрее, в некоторых в 4 раза (в пересчете на МГц)! Так что не такая уж VLIW плохая. И потом — кто вам даст делать х86 архитектуру?

          • Комментарий удалён
    • 0
      RadiantConfessor RadiantConfessor24.12.16 13:00:50

      Я думаю в экономии энергии. Аппаратный анализатор кода всегда будет потреблять энергию.

      В условиях суперкомпьютеров 20% это огромные цифры.